You ever open up a bit of code, look at it intensely for a few minutes trying to decipher it before coming to the conclusion that it may as well be written in Egyptian heiroglyphs, calling it a dreadful mess and cursing the bastard that wrote it, only to run a git blame and find out that you were in fact the aforementioned bastard? Well, there's been a lot of that lately in development of Simple City.

I recently started reading Game Programming Patterns by Robert Nystrom. Given my day job as a back-end developer, I figured looking up how game devs handle things compared to standard software patterns was probably a good starting point. This book (which is also available for free on the website) is a great read, full of insightful takes on how to handle various levels of complexity in game development. I'm about 40% in according to my Kindle, and it's taught me many wonderful things. Including the fact that on top of a bastard, I am also, in fact, an idiot. The codebase for the game is a spider's web of overlapping dependencies, references, and the dreaded singleton pattern. I also found that I'd inadvertantly implemented patterns that I hadn't even known existed, but I'd casually designed them as solutions to problems I had. Funny how these things develop from need, then become industry standards. Now thankfully, I may have a convenient "out" in terms of needing to rewrite things courtesy of Unity deciding that their strategy for a business is finding out just how far they can push their customers before the customers tell them to get fucked, but it still means that the entire codebase will need to be rewritten.

Gameplay updates

Existing mechanics

Visually, very little has changed since I last shared a video. I've added 2 more types of block, Parks and Agriculture. I added these as having only 4 user assignable types led to a fairly static way of playing. It led to building industry on the outside, then a layer of shops, with entertainment blocks surrounded by more shops, and using offices wherever it could be spaced in. Adding a new type of block adds an exponential number of new combinations, meaning adding 2 more is double the exponential-ness... Maths wasn't always my strong suit. Anyway, this brings the total list to 6 user assignable block types, with a total of 9;

• Empty - Nothing there
• Blank - A blank block that can be built on
• Restricted - A greyed-out block that can't be built on
• Agriculture
• Shopping
• Industry
• Parks
• Offices
• Entertainment

This seems like a good number to me. Given that population count will be your score, this seems like enough categories that there's plenty of variation to break the monotonous and frankly un-balanceable gameplay from before these changes. Here's one of the few cases where more actually is easier to work around, because the variation makes it harder to get things perfect.

New mechanics

This is where the fun begins. The other consideration to do with complexity is that, with no driving force other than "Make number go up", it was pretty easy to force certain patterns of block types to work. The aim is to make it more difficult to game the system, not just making pretty patterns. The player was able to change whatever blocks it felt like at any given time, to whatever they felt like, and that was it. There needed to be some restriction on players placing blocks to make it a puzzle to solve, rather than a pattern to draw. I tested a few different approaches including more restrictions on neighbouring blocks such as not being able to have more than 2 of the neighbouring blocks be the same type, and developing a "City Needs" system, based less on block type and more on 3 arbitrary categories, of which different blocks had different effects. The neighbouring blocks bit could still work, as I'm testing a few different restrictions, but despite me pouring hours into the city needs idea (fun fact, developing this was exactly the moment I decided that I needed to read a book on software patterns), it was never going to work. It was arbitrary, it was boring, and it also started leaning more heavily into the simulation aspect of city building games, rather than the casual arcade style I was hoping for.

The last mechanic I'm testing is limiting the user's block placements per gameplay tick. Each tick is 2 seconds (at the moment), and I'm currently developing a "3 move" system, giving the player 3 moves when the game starts, then an additional move every tick, however capping their max storage at 5. This is still being written and isn't even at the point of playtesting yet, but I like how it should play, and I can see it being a clever approach. Stockpiling moves to do a major revamp of a city? Better wait 10 seconds and hope it doesn't kneecap you in the meantime.

Music & Visuals

Only real update is I've reached out to a friend who also happens to be a really solid musician, and asked him to make some music for the game. He's going to be well compensated for it, and I've heard some early samples, but it seems like a really solid start. I'm excited to hear what comes next. There has been 0 movement on visuals. I'm not sinking time or money into those yet because it's so damn fluid that I don't even know quite what I want yet.

No longer waiting for Godot

And then we come to the final piece of today's post. Unity loading the shotgun, pointing it squarely at their toes, and deciding "Yep, that's my target alright." Unity announced they were going to start charging developers based not only on revenue, but on install count. What a phenomenally stupid move. Initially, my thoughts were "Eh, I mean it sucks but also it shouldn't affect too many people, because it's once you earn $200k and have 200k installs." but then more news started coming out. Someone reinstalls your game without buying it again? That's an install. Someone pirates your game? If the Unity telemetry isn't disabled by the pirated version, that's an install. You want to donate 1000 keys to a charity bundle? 0 income from it, but 1000 installs. My favourite thing about all this though? Doesn't matter which version of Unity your game was built on, this applies to everyone. This is going to do a ridiculous amount of damage to the indie dev community, and I expect you'll see all but the biggest games in Unity start to get pulled from stores come November, when the new policy kicks in. By sheer fortune, I actually hadn't sunk in to Simple City more than the prototyping phase. Unfortunately, at this point, that's all that Unity will be for Simple City. A prototyping tool.

I'll be making the switch to Godot engine when I am ready to start rebuilding the codebase. It's a good opportunity to clear out a whole lot of tech debt from not using proper patterns, and just generally making a mess of things, and removes Unity from the project entirely. It's a shame. I liked Unity. It taught me a hell of a lot about how games actually worked, and made prototyping nonsense actually work. I have 0 experience with Godot but that'll definitely change in the near future.

Ludum Dare

Oh, yes, I'm entering Ludum Dare. The theme hasn't been announced yet, I have no idea what we will be making, but I know that myself and 2 friends who are very talented in various forms of programming/artistic wizardry will be trying to make something. I'll post a thing when all's done on that too.

Right, I think that's it?