DT: Building a Better Building



Nice blog post, quick question though. Is there any issue with using a blueprint from alpha 16?

I created a town hall blueprint in the previous alpha which didn’t build. It was right at the end though so I didn’t worry. Once alpha 17 hit steam I started up a new game and tried again. This time they didn’t quite get as far as previously in the build before stopping. I checked the building and it didn’t have any issues flagged for missing components and there was a good stockpile of wood and stone available.

I still have a save game where in this half built state, is there a new thread for posting them for alpha 17?

Keep up the good work, loving the game.

1 Like

wow 200th stream already, It feels like we just had the 100th! Can’t wait for the 200th stream :slight_smile:
Also a very good desktop Tuesday (as always) , Love hearing about building :smiley:


Nice article! Just wondering, Why not look at a 3d printer software for inspiration >.>:wink:

And because of this sentence - here again the full 100th stream :smiley:

1 Like

@not_owen_wilson Great article! :slight_smile:

Question: I’ve noticed hearthlings tend to avoid building exterior walls from the insides of buildings. They will only try to erect scaffolding on the outside of those walls only, even when a wall is not externally accessible, but is internally (etc). I think that’s still a thing as of A17 stable, right?

If so, are there future plans to explore this as another means of finding a happy path through the build graph?

@TyreeC, yes, here: [A16/A17] The buildings my hearthlings will not build (round 2!)

If you could upload the template too, that would be great!


I always love the occasional written-out technical post. Great job Chris!


Hi, I have a suggestion!

So, the algorithm biases towards finding scaffolding placements that minimizes the number of inverse dependencies (“This scaffolding needs to go in a place where you are going to be built, so depend on me!”) Those are typically the nastiest, and so we try to avoid them. Putting up scaffolding inside a building will tend to involve more inverse dependencies than putting it on the outside, so you’ll still see this bias. That said, two things: we should NEVER put scaffolding in a completely invalid place, now, so if you are seeing this, I want to hear about it. Second thing: I lied a little just now; there was a stupid bug where we weren’t counting the number of dependencies correctly, which leads to some dumb behaviour. We will hopefully be getting a release hotfix out soon-ish that will address this, as well as a bunch of other bugs I’ve uncovered in the past few days.

As for better happy path stuff: like I wrote, this is going to be ongoing, and in the back of my mind. There’s a lot of spatial intuition I have about scaffolding placement that involves exploiting convex building subsections as much as I can, but I haven’t been able to codify it at all, it’s all really vague right now. We’re very “bottom-up”, in that we just explore each building structure bit-by-bit, when I feel like a better approach would be to somehow cluster building pieces into reachable “sub-sections” that we could reason about, and plan scaffolding on a section-by-section basis. The part that really stays my hand is how varied everyone’s buildings can be. The Basilica Kythandra built is both beautiful AND obviously decomposable into nice subsections. Other constructions would probably confuse the hell out of the more obvious convex-decomposition algorithms that I know. More research is required :slight_smile:


Thanks for detailing this! Exceedingly helpful insights.

With the caveat that I know I’m coming from a place of relative ignorance on this subject and that you’ve been in the weeds here for a very long time, a thought that comes to mind about build prioritization, and trying to predict when it makes sense to adapt to adversity when building:

If every block in a building’s design is individually timestamped at the moment the build was started, then you could conceivably watch for individual unbuilt blocks whose age has drastically exceeded the built blocks adjacent them, and leverage that age disparity as a means of determining if a particular region of a build is stuck or unreachable.

For example:

  • Building Start timestamp: 20160720110500
  • All unbuilt blocks use the building start timestamp
  • All blocks, once built, get their own built timestamp
  • A process pulls a list of all blocks marked as built, determines which blocks are adjacent to them and which are currently unbuilt. It then compares the built timestamp to any adjacent unbuilt block timestamps.
  • Once a certain disparity threshold is crossed, the process considers those aging, unbuilt blocks to be unreachable, and tells the scaffolding logic to find an alternative path to that block.

Something like:
for all built blocks in building ID, find all unbuilt adjacent blocks; compare unbuilt block ages to build start time; if disparity is equal to or greater than X, tell scaffolding process to find new happy paths to stuck blocks

Sounds great on paper, but like most of my hairbrained ideas, it’s probably too CPU intensive; definitely not something I’m an expert in. In any case, such an architecture would allow the scaffolding UI to stay leaner, and only get more in-depth (CPU expensive) when absolutely necessary.


Thanks, template is uploaded, hope it helps.