Chappington

Back home

Previous: January 2024 Dev Diaries

Next: March 2024 Dev Diaries

Iron Village Dev Diaries - February 2024

Diary #5 - A Bit of This and That

2 February 2024

One of the problems with committing to a weekly dev diary schedule is sometimes, there's not a lot to talk about. This is one such time. I've done some UI work recently, mainly touching up the build menu and adding a little pop up menu to hold the load and save button. There's a bakery now, so now we have a secondary industry in place. Then there's implementing actual navigation for the pops - the refactoring to use Godot’s navigation system is mostly done, but actually avoiding obstacles is not a thing the pops bother doing right now.

Maybe I'll have more info about Godot's navigation system next week - actually changing it dynamically doesn't seem to be super straightforward the way that other Godot features are. But for now, that's the update - there's no single feature to dedicate a few paragraphs to, but progress is definitely being made.

P.S. If you're on Discord, feel free to join the Discord server!

9 February 2024

It finally happened - I ran into a Godot feature that was just not intuitive. At least, I didn’t find it especially intuitive. So here’s my experience dealing with that.

I went in having done my research - reading the docs, I understood that this was first and foremost designed with static levels in mind - levels where the player isn’t significantly altering the environment. The documentation doesn’t really cover cases where the player is actively altering the environment, which is basically the main feature of most city builders. I searched for other tutorials, but they didn’t seem to cover this situation. Still, it looked technically feasible, so off I went.

So I set up a box for my NavigationRegion2D, and I notice something about source geometry - nice, that should be exactly what I need! There’s something about static colliders, so I figure if I add some StaticBody2Ds to my buildings, the NavigationRegion2D should pick up on them, right? Nope. Just fills in the whole box. I had also added a CharacterBody2D to each of the pops, and they were successfully blocked by those static bodies, but the navigation just totally ignored them. The pops just helplessly ran against the wall, trying to get to their destination, and failing. (I have since made them AnimatableBody2Ds, since they kept colliding with each other as well. I’m not entirely sure that they’re necessary though.)

I tried messing around with the source geometry, but no combination seemed to be able to get the buildings picked up. (While revisiting the NavigationRegion2D for writing this diary, I finally realized the actual solution was adjacent to this all along - I’ll get to that eventually.) So fine, I guess I can manually mess with the geometry in code - not super pretty, but the API suggests it’s doable, right?

Long story short, it is. But there’s a few caveats:

1. Baking the navigation polygon (that is, generating the navigable space based on input geometry) is asynchronous. I think you can force it to act on the same thread, but that seems like bad practice? Idk, doing that just gives off bad vibes. (Yes, I have about a decade and a half of programming experience, I’m obviously super professional.) So, you’ll want to be sure you gather all of the geometry in one place before baking it.
2. The direction of the outlines matters. This is not documented in the official docs, but is mentioned in some videos.

This second part was really the WTF moment for me - manually entering in rectangles counter-clockwise would add to the navigable area, so I never saw any changes. Pops would try to walk straight through buildings still, and the debugger was showing it really was adding those rectangles. Flipping the order around to clockwise though, and now these rectangles were treated as holes in the navigation polygon. I’m guessing there’s some sort of mathematical reason for this, but that was kind of a ridiculous way to discover that “feature”.

Anyway, I got that all finished at the very end of last week, and now that I’m looking back at the NavigationRegion2D source geometry area, I finally figure it out - if I set it to source geometry groups with children, and add all of the StaticBody2Ds to a group that I specify (groups being a feature I haven’t used in Godot until now), then it will finally pick up on those obstacles and include them when baking the navigation polygon in the editor. It still won’t work if I specify root node children, but the grouping does work at least.

So anyway, that was quite an adventure. I’m honestly really tempted to create a video tutorial about it, just to cover things that I missed.

16 February 2024

There has in fact been some planning to Iron Village’s development. The first major milestone is coming up, what I have named the “Prototype”. I don’t know if it fully fits the definition of a prototype, but it’s basically the first build I’ll be making available to gather feedback. It has all the mechanics, and the basics of gameplay implemented. The game-breaking bugs should be sorted out, but other bugs will definitely be in place.

The original goal was to get something done earlier, as a very bare bones prototype - basically, get the idea out in front of people to determine if there’s a decent game idea here, and get feedback as early as possible so it’s easier to pivot if needed. It’s been a bit of a bigger task to get here though - about 2-5 months depending on how you measure. (I was sporadically working on this starting in September 2023, but ramped up starting in January of this year.) So why did this end up taking longer?

1. Learning Godot. Obviously it’s going to take some time to learn a new engine, and changing languages partway through definitely didn’t help. Still, I don’t think this took up a huge chunk of time, Godot was fairly easy to learn - of course, I do have prior Unity experience, which really helped.
2. City builders have lots of mechanics. Again, this should be expected, city builders in some ways are about having a bunch of different mechanics, and playing around with how they interact. For the prototype, this should just be the minimum set of mechanics. I actually got the main mechanics done back in January, the main one that was missing was a way to have more trains come in - it’s not exactly much of a game if you run out of a way to get more gold or people. In fact, it still hasn’t been implemented 😅.
3. Art, Sound, and Polish. From what I’ve seen, the best practice is to not have too much art implemented early, especially if the scope or requirements change. While there’s definitely art here that needs work (mostly the trains that I made myself, the buildings and terrain were assembled from Minifantasy assets that are already great), I definitely put a lot of time into making assets better than “programmer art”.

Anyway, I’ve been aiming for a February 29th release of the prototype to gather feedback - and I think I’m on track, but I’m off on vacation next week (no dev diary then), so it’ll be close. Next steps kind of depend on what sort of feedback I get, if there’ll be more public prototypes/betas/etc, but there’s a pretty solid amount of additional content I’m planning on adding, and of course bugs to fix too.

For now, here’s some more screenshots: