Hey everyone, welcome to another Stonehearth Desktop Tuesday! This week, while the rest of the team wraps up water fixes on A22.5 and design officially starts on A23, let’s check back in on UX designer Nikki, Engineer Chris, and Engineer Justin’s prototypes for our new building editor!
Recap from the video:
As we described several weeks ago, we’ve learned from all of you that it’s hard to predict what will make for an intuitive building editor. The building editor in our game is already on its second iteration, so instead of building another one end to end, we’ve decided to build the third one as a series of experimental prototypes, in which we use throwaway code and art to explore a wide variety of designs.
From our first few janky, gray prototypes, we learned that floorplans should be created out of rooms, that rooms and floors work best when manipulated at the same time, that rooms should be adjustable in space, and that people want to make both merged rooms and distinct rooms. However, these first prototypes worked only if you as a player remembered what order you created your rooms in. If you forgot, or if you inherited a floorplan from another player, it was really easy to click on something, expect it to move, and discover that it did something else instead.
One month later, Chris, Nikki and Justin have revised the metaphor so that floorplans no longer require you to remember what you’ve done in order to manipulate them. Instead, players should get options based on the current visible state of the floorplan. So, for example, as you drag one room over another, the second room alters the first one, such that when you pull them apart again, the first room retains its new shape. This is less immediately convenient if you make a one-off mistake during dragging and immediately want to undo it, but it’s much more intuitive if you discover your one-off mistake only after adding a bunch of other rooms and furniture and then have to remember how you built the room in order to know what will happen when you drag next.
For much the same reason, walls of rooms are split when a new wall bisects them, so that distinct-looking sections can be dragged around easily. This creates a lot of visual clutter in the prototype, but we’re sure that we can clean this up in the actual game once Designer Nikki and one of our artists does a pass on the model.
We also did a pass on interior walls! In this prototype, interior walls can be added! We still have some outstanding questions here, though: if an interior wall bisects a room, should that room become two rooms, in terms of dragging them around?
In related functionality, we have the option to remove interior walls. However, this raises interesting questions for the dragging of rooms. Should two rooms merge when the walls that separate them are removed? According to our rule of updating the room model based on what the current state looks like, the answer should probably be yes, but what if we have a single voxel eraser tool that you can use to cut lattice holes in a wall? At what point does the wall become sufficiently full of holes that the two adjoining rooms are now one room? Chris and Nikki are still actively working on these questions.
These prototypes also taught Engineer Chris a ton of interesting things about how rooms should be remembered in memory, in order to allow their manipulation to be performant. Originally, when we created a room, we would remember all the walls as “real, 3D objects.” Take, for example, the walls of this square room. In addition to knowing where they stand in the world, each wall has to remember which way is “indoors” so that they can draw a roof around themselves in the correct direction, and so they can come down properly for RPG mode or any other indoor/outdoor rendering thing we might want to do. However, if you take one of these walls and drag it to this other structure, suddenly a lot of its data changes: its space in the world, its adjacent neighbors, and which way is “indoors.” Updating all this data on the wall object requires keeping a lot of data in sync, becomes more complex as the system grows more features, and opens the door to hundreds of possible bugs. (Note, it may not actually be possible in the future to drag a wall in this way, but it’s a simple potential example that illustrates the point.)
After working at this for a while, Chris realized that a far more futureproof and performant thing to do would be to record rooms as polygons, do a diff between the previous state and the new state whenever anything changed, and recalculate the new state of the wall from scratch once the editing had settled.
This Thursday at 6:00pm PST, Stephanie will be streaming with new designer Luke, so come with your design questions for A23! We will also be working more on crafter house templates. See you there!