Hey everyone, it’s Desktop Tuesday time! Last week, we learned that 70% of you were interested in hearing updates on features that are in super early stages of design but that may not make it into the final game in this form. Today I’d like to show you a small preview of one of these: Engineer Chris and UX Designer Nikki’s first stabs at an upgraded building user experience. As we get through this first cut, I’d like to explain why we as a dev team make prototypes, and why most of what you see here today will change a lot between now and when it finally makes it into the game.
UX Building Prototypes
So what is a prototype? In general, prototypes are artistic or technical exercises that help the team explore large design spaces where the right or final answer is not immediately obvious. Those of you who have been with Stonehearth for a while know that many people find the building UI hard to use, despite the fact that the building UI in Alpha 22 is actually the second iteration of the UI. This is because modeling things in 3-D is actually quite difficult on a 2-dimensional screen. Professional modeling programs can take years to learn. At the same time, forcing players to model voxel-by voxel, Minecraft or Quibicle constructor style, can be tedious, and doesn’t offer shortcuts to capitalize on the fact that most buildings share common attributes like walls and floors. There are very few existing tools or other games that allow for intuitive, quick creation of buildings in voxel space, so to create the best experience, Stonehearth has to discover the tools and metaphors that will be most enjoyable and empowering for everyone.
Building’s design problems are exacerbated by the fact that, as we discussed when we did our deep dive into conversations, features have to go through design, art, implementation, and QA phases in order to be ready for use. Even if you are pretty confident of what you’re doing, this can take a long time. If you had to do this process every time you wanted to try out an idea, it would take forever. In novel-design territory like building, where you expect to go through multiple designs before finding the right final solution, AND if you have the time and resources to do this exploration, it can be faster to try all your design ideas out in a low-fi, hacky, fast and cheap fashion, before committing production quality art and engineering time to them.
Hopefully now we’re all on the same page that what you’re looking at is a hacky, unpolished implementation of how one might possibly draw out intersecting or multiple rooms with just a few clicks of the mouse. In this prototype, you can create rooms that merge with each other, or that have distinct walls. You can move the whole floorplan around by clicking and dragging on a floor. You can raise and lower walls in a given room by pulling on them. You can also stretch rooms to make them bigger. Most controversially, the prototype remembers each room you created, even if it’s intersecting other rooms, so you can change your floorplan’s shapes by dragging the rooms you’ve built around.
We got a lot of solid design principles out of these prototypes: for example, that it makes a lot of sense to build floorplans out of rooms, and that rooms and floors work best when manipulated at the same time. (One early version of this prototype had the floors remain still when you dragged walls around, and it was very surprising to everyone who used it.) We learned that it feels good to make both merged rooms and distinct rooms.
However, the prototype also revealed that there are some series UX issues with a model that Chris and Nikki still need to address. For example, if you create a room and then drag another room over it, in some modes the first room disappears. This can cause unexpected behavior later, when moving the rooms around.
Second, in order to manipulate a room shape, you have to remember how you built that shape up out of rooms. For complex wall structures, you have to keep your whole build history in mind in order to get rooms to look exactly as you’d like them to. The cognitive load is exhausting.
Finally, because the prototype allows you to make large, tall rooms quickly, you can easily get yourself into a situation where it will take your hearthlings a million years to build the incredibly ugly stack of boxes you’ve created.
In future Desktop Tuesdays, I’d like to cover Chris and Nikki’s answers to these issues as they discover them. I should also mention that because prototypes are designed to answer specific questions–again, in this case, the question of how it feels to make floorplans out of resizable rooms–prototypes often do not address details outside of the question. In this case, Chris and Nikki have plans for completely different prototypes that address questions about the UX for roofs, stairs, interior walls, and multiple floors. All these items are related, and should eventually be addressed, and may in fact change the results of these tests, but by limiting our questions to specific systems, we can make solid progress on our target question without getting distracted by edge cases introduced by other systems.
Clearly, we’re still a long ways away from being done with the prototype phase for an improved building UX feature–much less finalizing a design so that art and engineering to take a deep dive into the feature. Even so, we’d love to hear your thoughts on our progress!
Stream should happen as usual this week on Thursday 6:00pm PST. Engineer Justin and Engineer Angelo will be streaming together, so come with all of your hard technical and/or mod related questions.
Alpha cadence! We will not start work on Alpha 23 for another couple of weeks as we continue to focus on long-term projects, but you can look for an small update to Alpha 22, which we’re calling Alpha22.5, sometime between now and when A23 is officially ready to go onto unstable. Alpha22.5 will contain a few small things that have fit in between the cracks of this long-term feature development.
Finally, I’d like to mention that Richard has been doing a number of long-term, high-level projects about the overall player motivation arc for Stonehearth. As part of this, he and Angelo have been doing some very early explorations into multiplayer. We’re not ready to talk about this at great length yet, so I won’t update the roadmap with specific milestones and goals, but for those of you who feel keenly about MP, please know that we’re thinking about it whenever our context shifts to considering the overall game, as opposed to specific features.