DT: Elevator Needed

Hey everyone, welcome to another Stonehearth Desktop Tuesday! This week we’re ironing out a few last water bugs (there will always be water bugs), continuing design work on our revisions to our crafting system, and continuing to evolve our building UX prototypes. For today’s DT, let’s again investigate Nikki, Chris, and Justin’s building user experience prototypes, this time looking at variable wall heights and how they interact with multi-floor structures!

Multi-Floor Prototypes

Recap from the video:
Since hearthlings have first tried to add furniture to multi-story buildings, you guys have asked us to make a mode where stories above your current floor are transparent so we can more easily interact with stuff on higher level floors. In this janky, unpolished, no-artists-were-involved-in-the-creation-of-this prototype, we temporarily turn off the ability to create interior walls in exchange for the ability to make new floors on top of existing floors. As we suspected, it turns out that making higher floors transparent looks great!

Better yet, if you create a building with multiple floors, you can move up and down between them, allowing you to focus on only the floor you care about. In future prototypes, we may also see how it feels to jump you automatically to the new floor you’ve created.

In order to get this floor-jumping working properly, Justin and Nikki had to solve the following conceptual problem: if you want to go up and down between floors, but you can make buildings of arbitrary wall heights and use the slab tool, how do you know and remember what things count as floors? Even if you leave out the slab tool and only count floors created by the room or floor tool, imagine you have a building with two towers, each of which contains walls of different heights. How do you determine which floor you should next jump to?

In this prototype, Justin and Nikki settled on an elevator model, in which each floor added to the building is added to a central index and sorted by height. When you go up a floor, you jump not to the floor that is directly above the part of the building you’re looking at, but up to the next highest floor anywhere in the building. In our use case, where a castle has two towers with walls of variable heights, this may mean that we jump back and forth between the two towers as we go up and down with the floor tool.

Some further complications arise from this: Is there a situation where you might like to see floors not just on a building-by-building basis, but across all buildings in your town? If you have buildings of lots of heights, might you then have to spend quite a long time moving up and down between floors to find the one you want?

Other complications that the team discovered involved having structures with variable wall heights. In early prototypes, all the walls in a room rose and fell at the same time. However, if we ever want to create houses with asymmetrical sloped roofs, yes, we will need to support rooms with walls of variable heights. But then, how do we deal with joining/abutting rooms that have different wall heights? What about two different wall heights that overlap to form a shared wall? Finally, when users drag and move rooms and walls around, with different wall heights, and then start dragging walls into other rooms so that walls start overlapping, then there appear to be lots of areas in the system, and in the code, where we can mess up and incorrectly fuse rooms, get wall heights wrong, not have holes move around correctly, and just encounter a large amount of general data ‘staleness’ issues. What kind of model do we need in order to support all kinds of different changes to rooms, and to do so without sacrificing performance of the system, or to endure a fragile system that we will always be fixing? The answer to this turned out to be the same hybrid polygon model we described last week, in which we ‘diff’ old and new room shapes, and then re-derive what the walls and floors look like fresh after every edit. Happily, in our prototypes, this turns out to work reliably and quickly.

At this point, the team feels that it’s answered quite a few questions about the user experience and engineering of the building editor. We now have a nice model to be able to represent rooms and walls and flooring in a way that is consistent, fast, and that offers nice UX affordances. We’re pretty sure we know how to handle multi-level structures, though we still need to figure out how to switch between adding interior walls and adding second stories, as these tools currently collide. We also know where to go next–experiments with undo, with roofs, holes in walls, and of course, with the voxel slab tool.

Other Announcements

This week, our 6:00pm PST dev stream will feature Richard, so come with all your game design questions. 🙂 For extra bonus points, see if you guys can suggest a good (or really bad!) game he’s never played, or for even more points, never heard of! (Aside from: fighting or racing games.)