DesktopTuesday: UX Building Prototypes

Hey dude, I’m happy to speak to this a bit. Thanks for raising your concerns in a constructive way.

When I joined the team, there was a ton of excitement for the game’s potential, but it felt like we lacked a clearly articulated vision for what the game was or should be. We had a broad understanding of what the genre was, and in terms of the final vision we mostly only had a list of features that had previously been promised. There was not a strong theory behind why one feature may need to go in versus another, what the list of features would build up to, or why the game would ultimately be a compelling and fun experience when we were finished.

My early work on the team was to help provide some answers to those questions, because I and the rest of the team really do feel that there’s something special here. However, achieving that imagined final game would take work and more resources than the team had at the time, and it’s difficult to make a case that you need more resources if you can’t explain where you are going. That style of problem requires a lot of deep thought and many, many conversations, and as such I personally haven’t had as much time to delve into some of the major player facing feature design that I’ve wanted to. That said, the work of developing that underlying theory and argument has paid dividends so far, which is why we’ve been able get the budget to almost double the team size. Especially once the new designer I’m bringing on joins, I’d expect you’d start to see new features and improvements arriving in game at a more rapid pace as we continue through the year.

This time of re-examination has also allowed us to take a step back and examine big fundamental problems as well. Chris’s work in the building system represents not only a new user experience for how to construct a building, but a re-architecting of how construction works. For example, the current construction model treats all the portions of a building - wall, floor, second floors, roofs, etc - as different objects, which leads to all sorts of weird problems. For instance, internal wall construction is a nightmare, and good luck getting a roof on a building that has them unless you know the exact pattern of actions to take. It also commonly leads to buildings that will be forever incomplete. The new model shifts in a new direction, so that even if things are framed to the player as walls, floors, etc., they’re treated all the same underneath the hood. This should lead to a huge gain in expressiveness of the tool while also resolving a raft of really painful experiences, but it came at the cost of basically a full re-write of the architecture code.

Water is a similar style issue. As you are probably well aware, water just doesn’t work in the game right now. There’s no gameplay with it, it will frequently pause mid-air, and all sorts of things. As Albert was looking into it he realized that the problem wasn’t a matter of just a random bug here and there, but a core issue with how the system was architected. If we didn’t take some time to go back and re-implement it, a lot of the features you guys have asked for (dynamic moats, irrigation, etc.) just wouldn’t be possible. That type of work takes time.

On my side I’ve been working on prototypes for possible game directions Stonehearth could go, and as Stephanie alluded to at the end of this DT that includes multiplayer. Adding multiplayer to a game that wasn’t designed for it, let alone one in a genre that has few contemporaries doing it at all, is a huge undertaking. It’s unfortunately not as simple as “oh, it works in Terrarria or Minecraft”, because since those games have the player playing as a single character the entire problem set is fundamentally different. There are exceptionally few games that have multiplayer community building in the manner of Dwarf Fortress or Rimworld. That said, we’ve made good progress here in understanding the space, and I’m hopeful to talk about it soon.

Regarding the RPG question, I don’t have an interest in turning Stonehearth into an RPG. People can go play Rune Factory or Dark Cloud if that is the experience they are looking for, which are great games in their own right. Stonehearth does lean a lot on RPGs for its fantasy though, and you can see this if you go back and look at the original kickstarter pitch, what with its references to D&D, RPG class systems, and other such things. Stephanie has told me before that she always imagined Stonehearth as a “community builder where you are constructing Kakariko Village” from Zelda. That inspiration is why the game has things like character levels, class trees, base stats, dialog encounters, etc. My primary goal is to continue incorporating that inspiration where appropriate, all in service of allowing the player to form attachment to their hearthlings as individuals, and not merely as automata that exist to do the next most important task (beep boop). But, as with anything, we need feedback and input from people like you to help guide the direction.

I hope this helps provide at least some amount of context. I didn’t touch on all of the points you brought up, but if there are any you specifically want me to reply to I’m more than happy to do that.


Thanks for sharing your thoughts. One part I personally am confused on:

What do you mean the game wasn’t designed for it? I thought that in the base of the code it was, seeing as there’s already a client-server process. What wasn’t designed for multiplayer?


I’m not referring to the tech here; I’m referring to the game design. The tech as I understand it is built on some good foundations to support multiplayer.


Ok. The way you phrased it seemed in my head like you meant tech.

So since it’s game design, do you have a basic idea currently? Or are you still deciding what would serve StoneHearth best?

1 Like

Yeah, I’ve got a good feeling about the direction. I just need to flesh it out more before I openly talk about it. I don’t want to set expectations for one thing when we still might pivot.


This seems more like an AI issue in my opinion though, not a UX issue. When you 3D print something, it works one layer at a time. The AI could just be reworked to do the same, starting at the base and working one voxel up at a time (or couple at a time, regardless you get my drift). So that being said, combined with my previous statement about round and diagonal buildings, this UX rewrite seems…stupid to me. What’s the real advantage to being able to draw buildings like in The Sims 4, when we don’t have round assets like they do? How is changing the UX going to change how 'lings build buildings and still get stuck? OOOOH it’s flashier and more modern compared to other like titles, but it still would leave the underlying problem of pathfinding.

And if you told everyone here that you were rebuilding the pathfinding, I’m sure we’d all end up throwing a party. But instead we’re getting upgraded from The Sims 3 to the Sims 4.

I appreciate the info on this, and it’d be nice to get more explanations like this. Because up until now, it’s sounded like it was just a couple bugs.

At the same time, what’s showing that they’re more than this? The conversations system is flat, and honestly doesn’t add more than direction of what to build…in a subtle way. Traits help in the sense of giving you the random direction of what to build. There are no friendships, no loves, no diplomacy, anything. And when asked about this, it’s another “How far we want to take it is a bit up in the air, to be honest.”. The idea of kids and families has been dismissed since the days of Tom (even though there are PG ways to do it), and what’s called complete after a decent amount of time is nothing more than the NPC’s of Skyrim that took an arrow to the knee.

I actually was going to bring up her quote before and forgot to. That being said, with the current systems, throw in the Song of Storms, and you could recreate a perfect replica of Kakariko Village, especially from the earlier versions. As far as D&D goes, Stonehearth doesn’t have the specifics like they did. I’ve got two examples of this:

  • When I used to play in High School, I had a half-ling knight, that was predgudice against wizards, was hated by dwarves (took out half the country side to get out of a bar tab), and earned the nickname “Nut-High Knight”.
  • One of the guys I ran with attempted (and I use that word strongly) to be a Drawven Theif. Now if you’ve ever played it, you would understand why this was hillarious and didn’t work.

Just those two examples would be impossible to make in Stonehearth, and unless y’all built the system to have experiences/quests/stories like this, the player doesn’t have much to get attached to. Sorry but my carniverous blacksmith in Stonehearth doesn’t make for as good of a story, nor does it make me feel very connected to them.

But when there’s so many unsures of where the future will go right now, how can it be said that it’s any better now than it was when you came in? And if y’all do have a mission statement, an end goal, then why is it so hard to share that with us, or to even share what we can look foward to long term, in more detail than the roadmap? You and @sdee keep saying that y’all had to sit down and re-examine everything, but from what little we get, it seems more like we’ve hopped from one person’s list of random features to anothers.

1 Like

You’re absolutely right, and in a sense that’s what we’re shifting to do. However, the way that the system is currently architected does not make this a possibility, hence the re-write. Chris can speak to this a bit better than me though, to be fair.

Also, you’ve mentioned pathfinding a few times. If it’s not clear, this type of rework will very much help the pathfinding in relation to building a structure. The different underlying model allows us to decompose the structure in a different way than we can currently, which in turn will allow the AI to be smarter about how it builds the structure.

The current tool for building UI is a struggle for players that aren’t familiar with the intricacies of it. The current model doesn’t line up with the intuitive expectation that new players have when they first come into the game, and this problem became exceptionally clear as we continually saw players stumbling over the same problems and then walking away at our PAX booths. The Sims has a good model for building construction, so we are looking at it for lessons we can take away, but our goal is not to replicate the Sims tool. As you’ve pointed out, it’s simply a different problem space then us, and it isn’t 1:1 applicable. We want a tool that’s powerful and easy to use, both for new and old players alike, and one that’s fun enough that players may find themselves defaulting to custom construction instead of relying on existing templates.

The two systems you mentioned are stepping stones along the way to building a social system. As a result of the work associated with traits, we can now crate more variety in individual hearthlings and can have them react to situations in different ways. As a result of the conversation system work, we now have a formalized way for hearthlings to interact with each other, and each hearthling has a living memory of the things they most recently interacted with (and opinions of them too). Ideas and concepts can pass around a town. Now that that groundwork is laid, we can shift into building a reasonably deep social system, where people get into arguments, for rivalries, make friends, get angry when people insult their family, etc. A social system isn’t the next thing we plan to work on (we want to focus on more gameplay related things next), but we have the groundwork in place ready to go when we want to start.

I don’t think this is impossible at all. Dwarf Fortress has emergent interactions almost exactly like this.

Fair. We’re not there yet.

Every week we go through a process as a team talking through what is the most important thing we can be working on. That process is informed by the feedback people like yourself provide here on this forum every day. The work we’ve been doing now gives us a shared framework to have this debate, so that even if we disagree we are all debating based on the same core fundamental goals. We feel this type of process ultimately allows us to be more reactive to you guys, but there is a hidden cost. There’s a lot of stuff we want to do, and a bunch of it is stuff that we’re probably 85-90% sure will get done at some point. However, if we come out and openly discuss specifics, that sets your guys’ expectations, and if our priorities end up changing then that can cause problems and frustrations down the road.

This conversation has a specific example of that. We previously talked about how Albert’s next major tech priority was to fix water, and it was going to happen soon. However, after a bit of investigation we realized that we had underestimated the water work that was involved, and at the same time we started discussing the need to add more engineers (especially senior engineers), to the team. Of anyone on the team Albert was among the best suited to help us recruit and vet really talented engineers, so we ultimately decided that work was more important to do now than to finish the water work, as on-boarding a bunch of new engineers would allow us to accelerate everything the team does. I definitely feel that was the right choice, especially because those new hires have allowed talented engineers like Chris to focus on big problems like building instead of always having to context switch from one bug to another. That said, since we were so specific about what Albert was doing, it set expectations for players like yourself, and in turn makes the associated delays with fixing water feel like we are letting you guys down.

We don’t want to be closed off about what we’re doing, as we think a healthy and open discussion around the game with players is essential to crafting a lasting and delightful experience. Figuring out that balance though, of being open and managing expectations, is a super tough thing to do, and even with eight years in the industry I get it wrong sometimes myself. I do try and err on the side of being open though, which is why I’m willing to sometimes come out and say “Yeah, we don’t quite know yet, but here’s what we’re thinking,” like in the post you linked. My theory is that it’s better to push the conversation forward and get feedback then to remain silent.


I do want to say though, that you being that guy and raising your concerns has, multiple times, lead to interesting conversations with the dev’'s which I have found informative about what they do and why the’re doing it. While I do not always agree with you, I appreciate your contributions.


Heartily seconded. While I am not as concerned about these issues, they are on my radar and them being brought up in a… devil’s advocate kind of way really helps any concerns I would have had, because they get addressed at least in writing.


Any time you guys have questions, please just ask them. The more we talk about it the less mysterious stuff will be! :slight_smile: When I make Desktop Tuesdays or when we stream, we do it believing we’ve explained what we’ve done in any given week, but it’s hard to tell what we’re forgetting or leaving out, because we’re so close to it.


Thank you very much for this paragraph! :merry: It helps me to understand what is going on better and to not be unhappy about the progress or lack thereof. Not that it matters :jubilant: , but I agree with those decisions and eagerly look forward to the new engineers’ contributions as well as a working water system. I’ve already enjoyed Chris’ focus and previews of his building work.


As an example, the key binding stuff and alt-enter fix that just went out to unstable happened because one of the new engineers we brought on to the team had a little free time and felt strongly about it. That kind of opportunistic improvement is tough to do when you only have a few engineers fighting all the fires.


Going on a limb here, it’s been stated a few times that the current architect doesn’t allow for almost anything y’all want to do. Could you elaborate on that? Almost sounds like y’all lost the source code to the game.

You’re the boss, but this seems kinda backwards to me. Even if you make it easier for the AI to understand what it’s supposed to do, when it comes time to add to or rewrite the AI, won’t this be effected? Couldn’t trying to make it easier for the AI actually cause more problems when it comes time to rewrite that?

So what exactly are these expectations? And what didn’t they understand about it? Saying people at PAX had problems with it is a lot like saying people that drive any motor vehicle fall flat at driving semis. People who normally play Call of Duty, Leage of Legends, Grand Tourismo (is that even still around?), aren’t going to walk up to this genre of game and be able to take it on. Even them walking up to The Sims, SimCity, Cities Skylines, etc would be a cliff of a learning curve, and at PAX, you don’t have time to clime that cliff. So unless you’re going to go to the extreme of constantly finding new ways to idiot proof your design, it isn’t going to work. You’ll just end up over simplifying it to the point it’s too complicated for your already established customer base. Example of this is my statement above about round and diagnal buildings.

I wouldn’t call it a let down, as much as lack of information. Way back in the day, Tom promised us water mechanics, and if I recall correctly, said they’d be flushed out, or at least in process, by Alpha 19. I may be wrong in the exact number, but I know it’s one that’s past. That being said, it obviously didn’t happen. So (at least for myself) when @Albert came along and said for the second time we should see some improvements soon, and then too kinda drifted away, it hit a little harder. This is where my previous request to @sdee to give us something as far as updates are going, comes in. Yes we’ve been told he’s working on it, but an update that it’s slowed down to bring more people onto it would have been a litter better than just letting it ride.

And I want to say thank you for this, as many could have told me and others to shove it by now (as much as I’m sure y’all want to).


Speaking for myself, half the time when I use the building UI, I forget that interior walls don’t work until after you put on the roof. Which is what happened to me while I was making this Desktop Tuesday, and which was captured in the video. That rage you see as I wiggle my mouse around the screen is real rage :wink:

Also, I often make buildings that are asymmetrical, and wish I could fudge them just a bit. I also wish I could move buildings a bit. Oh, and I wish I could add voxel blocks to stuff without mis-clicking half the time and having to use undo. And then, I wish undo would work without breaking the building back-end.


Not really, as it’s not my area of expertise. That said, maybe I can provide a bit of an analogy? Let’s say that you built a rope bridge across a ravine. The bridge was good and solid for what you wanted it to do, and people could comfortable walk back and forth across it without trouble. You know that the bridge will get more and more traffic with time, and you hope that it will generally be able to expand to meet your needs. One day someone asks if they can ride their bike across it. You say “Ok, well, there’ll be some problems with that, but if we add more slats to the bridge, your tires shouldn’t get stuck.” So you do that, and everything works out. Now people are biking back and forth, and someone asks you if they can bring a motorcycle across. A motorcycle is a lot more weight than a bike, but maybe if you add some rebar reinforcement, line the bottom with metal, and double-run the cords, the bridge can support the weight. So you do that, it works, and things progress. However, now this bridge is starting to see a lot of traffic, and someone asks you if they can bring their car across. Worse, they need to bring their car across, because the two sides of the bridge now depend on regular and fast traversal between the two sides. However, there’s no way that you can simply widen the bridge to accommodate the car; the reinforcements you’ve done are too fundamental now to the function of that bridge, and there’s not a way that you can break and then add more metal without compromising the integrity. Additionally, even if you could make it wide enough, the simple physics of a suspension bridge will not allow it to support the weight; the amount of stress a ton of metal would place on the supports is just to great once the car hits the middle. Maybe if the initial bridge had been a drop bridge, one where the bridge is supported by pillars rising from the bottom of a ravine, you’d be able to accomodate the additional weight. But, since the initial structure was a rope bridge, there’s just no further that you can push it; the car can’t make it across.

In other words, while you can frequently re-purpose and improve a design to be used in a way that it wasn’t intended to, in all designs there comes a point where the ask is too great. As we’ve started to talk through what we want with the builder, and noticed the frustrations players have, we’ve come to the conclusion that that is the case of where we are at.

Nah. If the AI has a better understanding of what to do when, that can only be a benefit to the system.

I think the basic hope is that the building tool is not a point of churn for the game. Players should not be confused about how to make a simple building for their first hearthlings. We’re not looking for an idiot proof solution, nor are we trying to create a tool that can work for someone that has never held a mouse, but building is a core component of Stonehearth. Of any action that players do in the game, this should be among the easiest.

Fair. Stephanie and I have talked about ways to give more visibility into what we’re doing day to day, and stuff like this is part of why we have those discussions.


This makes me a feel a little better. After watching Angelo and Justin this last week, as well as a couple other recent streams, I’ve begun to question whether y’all actually play your own game or not, but this statement definitely shows you know our pain. Angelo and Justin this last week reminded me of Cypher from The Matrix. When they were playing, it almost seemed like they had never played it before, but as soon as the lines of code came up, they knew right where they were.

That actually makes perfect sense. From a development side, I’m interested to what parts of that analagy apply to this game, but none the less I understand what you’re trying to get at. Appreciate that explanation too.

My arguement to this though is that it shouldn’t be too easy either. That’s what tutorials are for.

When you jump into SimCity, it gives you the basics of how to place things down and how to navigate the menu. It doesn’t begin to explain how the economy works, how civil buildings work, any of that. City Skylines even more so with everything they can do. Yet when any of us master those advanced features, it really makes for that much better game.

Regardless, I’ll digress on this, as I’m beginning to run in circles. Needless to say, I’m against the current plan for the new UI, and feel that even though the only one needed some tweeks, it doesn’t need an upgrade like we’re being shown.


I’m honestly kind of terrified by the building editor sometimes. It seems to me like when it breaks, it really breaks - I don’t know how many times I’ve managed to get it into a broken state where I can’t do anything not only in that building, but I can’t start or make any changes to any other buildngs, and there’s nothing to do but reload from an earlier save. So I’ve gotten used to saving compulsively. And a lot of times when it doesn’t break that badly, the undo option is still broken on that particular build. I’ve been working with this building editor since Alpha 10, which means I’m probably more used to its quirks than new players, and I still don’t get it sometimes. And it’s not really explained anywhere. I think I only have a sense for how Stonehearth wants you to design buildings just from using for even longer than that. The fixes we’ve had since Alpha 10 have helped a lot with making buildings build, but I still feel that a new building editor is necessary.

Though I do have a lot of reservations about it. I don’t like to be “that guy” much because I prefer being positive - and so far I’ve mostly been happy with changes I was lukewarm about before they were released - but also because I don’t play the game much anymore so I don’t feel I’m qualified to be picky. But maybe for once:

  • “Diagonal” (zig-zagged) walls aren’t too bad to make in the current building editor if you know what you’re doing - manually making a diagonal part of the floor isn’t that painful - but it seems like so far in this new prototype you’d have to drag out a new combining room for each step you wanted the wall to have. Will there be alternatives? Right now, this is the main thing I worry might be a step back.

  • Roofs. They’ve always been a bit of trouble with the current building editor and it seems to me like they’re likely to have many of the same problems. Of course, I’d like even more control over them. Gables that aren’t along a whole side are basically impossible right now, but I have no clue if there’s a simple solution possible.

  • Interior walls. I’ve never been able to get them to work myself, so I’ve just made them with slabs. It seems the new building editor prototype is much more based on joining rooms into buildings, which may be how some people think, but I still prefer to start with the overall layout and set rooms up inside. Will there be a tool to make simple interior walls or will we have to use the room tools cleverly?

I get that this is in pretty early progress and the team might not know the answers yet, but I’d like them to at least consider these.


By the way, if you can’t make a roof on a building with created rooms and you don’t won’t to use slabs as a roof, you can first make the “main” walls, then make roof and then use free standing walls to create your rooms. In that way when you use V(i forgot what was that option called), the roof will not cover your building as if it were with slobs-created roof.

@Brackhar, I wanted to quote this here as I feel it’s a really good fit with how we were talking. It’s this post, but it’s another player who doesn’t understand y’alls new direction. This isn’t an attack by any means, just a suggestion. But when @sdee does the next Desktop Tuesday, or hell make it the next Dev Stream so we can ask questions, maybe y’all should try and explain what’s going on and what y’alls end game is, in detail. I know above you stated it’s only 85% - 90% mapped out, but y’all should really share this with more detail.

That’s a fair point. I’ll make sure to bring up diagonal wall support in our next UX discussion. Chris may already have plans for this that I’m unaware of.

Yeah, we’ve not tackled roofs yet. I have some ideas, but we’ve done no testing here.

Easy creation of interior walls is a core success criteria for me. I’m pushing really quite hard to allow us to do this in an easy and intuitive way.

Fair. I’ll talk with Stephanie about how to approach this.