Chappington

Back home

Previous: Dev Diary #0

Next: February 2024 Dev Diaries

Iron Village Dev Diaries - January 2024

Diary #1 - GDScript & C# in Godot

5 January 2024

For this week, I wanted to start the whole thing off with the captivating topic of… programming languages? Ok, not exactly gripping stuff, but bear with me.

So Iron Village is being developed in Godot, a free and open source game engine. It actually started in Unity, but then the whole pricing fiasco happened about a day or two into actual development, so I went ahead and made the switch. One of the goals of the Iron Village project is a learning experience, so it wasn't too much of a stretch to extend that to learning a new engine.

As those of you with knowledge of the game dev space may know, you can use two different languages with Godot: GDScript and C#. C# is a pretty common language, it's the main language used when developing in Unity (originally one of three, but when they focused on just one language they picked C#), and it’s used in some programming for Windows as well. (I'm honestly not that familiar with that side of things.)

GDScript is a really interesting language though. It's specifically designed as part of Godot, and syntactically it looks just like Python, with some minor improvements that regular Python ought to have. You can tell it was the main language the engine was designed around, and the API reference documentation is all in GDScript.

So at the start, I decided to try out GDScript for Iron Village. I like Python as a language, the main thing I've used it for in the past few years is automating some of the grunt work with setting up mods for Paradox games, or duplicating files for building variations in Cities: Skylines asset creation. This would definitely be the biggest project I've done with anything Pythonesque though, and the last time I had done so for a game project was more than a decade ago in college using Pygame.

It's been working fine so far, but curiosity got the better of me and I wanted to see what C# in Godot was like. It turned out that the languages are supposed to be interoperable with each other (more on that later). So I decided that I would either make one new script in C#, or convert an already existing class without too many dependencies. Accessing C# code from GDScript is supposed to be easier than the other way around, so I converted something that was relied upon by everything, but relief upon nothing else: the GameResources class. This is a singleton object I made for storing and checking resources, things like gold, wood, and crops.

This actually went pretty well. There was one snag, accessing C# enums from GDScript, so I did have to temporarily hard code some numbers and come up with a better fix later. Except that triggered part of my brain to go, why not convert a few more small things?

Lol.

It's still early enough in the project that it's technically feasible (although arguably a waste of a lot of time), but I'm about two thirds of the way through converting everything to C# now.

Ultimately, I missed strongly-typed languages too much. Having to declare and keep track of exactly what is in each variable can be a decent amount of overhead, but the benefits (especially with IDE features like refactoring and right click -> go to definition) are so good. Ultimately, I think it makes you write better code, since a lot of mistakes that would cause runtime errors in GDScript get caught by the compiler in C# instead. It was still nice to use GDScript, but I've made the choice that works best for this project, IMO.

TL;DR: I'm a dumbass who started switching languages part-way through development.

P.S. I’ve made a Discord server, because that’s a thing I guess.

12 January 2024

So the biggest thing I’ve been working on during my off time this past week (and a chunk of last week) has been what I call “Pops”. Sims is probably trademarked? Cims is specific to Colossal Order games (Cities in Motion, a.k.a. CiM). So I went with Pops, short for population. It’s used in Paradox grand strategy games too, most prominently in Victoria, but I figure it’s the most generic name possible.

Every town needs people, whether it’s a hamlet or a city. In a happy and shiny way, they’re the soul of a place - a town is nothing without people. In a grim way, people are the town’s most important resource, and Iron Village is a game all about resources!

Pops are the game’s simulated people. In the current implementation, they can do one of five different things (i.e. their states):

1. Idle (i.e. do nothing)
2. Walk to Work
3. Work
4. Walk to Rest
5. Rest

What a wonderful and meaningful life they have! Pops prefer to have their own home to sleep in, but can technically exist without one - while it's not yet implemented, they will have the option of resting in other places, such as the train station. They'll also take whatever job is available, they're not picky. They work until they run completely out of energy (or you demolish their workplace), then go rest and free up their job slot.

Pops are kind of a resource as well - trains (when implemented) can bring you more pops, as well as take them away if they don't have homes.

That just about covers Pops, here's a video showing all of this in action. (As you'll note, clothes have not been implemented, thankfully cold weather is not a thing in this game.) Here’s a video of them going back and forth between work and home:

Except, that isn’t quite the end of the dev diary. You see, I began working on trains this week (that’s a later dev diary), and realized that while these pops don’t need food or water, they make them as resources, which feels odd. So here’s some more feature creep! Originally my plan was to make a game over the course of a few months (i.e. the equivalent of one month full time), but that isn’t quite happening.

Right now I’m thinking I’ll give the pops water, but not food, at least for the first prototype. (That’s another future dev diary topic!) It won’t be too much of a stretch to add that to the state machine, and hopefully that’ll avoid more feature creep. Once and for all.

19 January 2024

Now for the dev diary on the most important thing, the thing that I’ve (over)hyped - trains! Trains are the lifeblood of your town, delivering the resources you need and giving you opportunities to trade what you make. On the other hand though, your village is a part of the railroad - it’s being settled to provide it with additional resources.

A quick note on resources - right now, there are five different ones (besides Pops): wheat, mushrooms, water, wood, and gold. Wheat and mushrooms are both agricultural exports; wheat for more standard foodstuff and mushrooms for the more magical concoctions. Water may be used as a vital need for Pops, as well as for any steam engines that come by. Wood is the main construction material, and can be obtained through removing trees. (To be implemented.) Gold is the standard trading currency, to which most resources can be converted. A sixth resource is planned before the public prototype is available, bread, to create a more valuable food export.

Anyway, trains consist of a locomotive (sorry, no multi-locomotive trains here), and multiple cars. Each car will have a resource or some passengers, and has a transaction it’s going to make: gift, purchase, sale, or request. The first train in the game is just gifts, representing the initial supply to start your town. Future trains will give you the opportunity to sell certain goods for gold, and purchase others for gold. Finally, requests are the opposite of gifts - depending on game mode (to be implemented way down the line), you may be penalized for not fulfilling these!

That’s about the jist of it. Some more detail & variants are planned, but here’s what I have so far:

26 January 2024

So this entry is going to be a lot more personal, but still related to this project. This week has mainly been some work with the train station and trees, not really enough to write a whole diary entry about.

One thing that stands out to me though, is I actually cut a planned mechanic. You may remember from diary #2 that I was thinking, oh, I should let the pops drink water to sustain themselves. And it would be a pretty simple system to add - just another couple of states into the state machine, and it's done. The thing is though, it's a slippery slope. It's easy to think, oh, this mechanic makes sense, let's fit that in too. But the cutoff has to go somewhere, otherwise the game will never be finished. Especially in a town builder, it's easy to just keep adding things that make it more “realistic”, but the real questions are: Does it really add to the game? Even if it does, is it worth the time investment and added complexity?

Especially in game development, I think that this concept of “feature creep” is prevalent because it relates to the question, why do we create games? That's different for different people, but I can do my best to explain it from my point of view. My day job right now is software engineering at a global megacorp. I'm sure a quick Internet search or two of my name will pull up the specifics. Overall, it's been pretty good. It pays enough that I can support my family of five - it's not my fair share of the profit my labo(u)r generates, that goes to the shareholders (yay capitalism!), but it's still plenty. Some of the work has been interesting and meaningful, like reducing Internet traffic by up to 0.5%*. Some not so much, like code migration and features for projects that got shut down soon afterwards.

It's never really been my “passion” though - a word I have to put in quotes because it gets misused so much. That's been games. After studying game development in college (i.e. university) and working in the (mobile) games industry for a bit, a very well-timed recruiter email and a lot of luck sent me over to the megacorp. And there's always been this desire to build what I want to build - it can only be suppressed for so long.

So the next question is, why did I wait until now? The other piece of the puzzle will be familiar to some of you - late diagnosed ADHD. I had occasionally done some “side projects”, but never ended up finishing any of them. Turns out, there was a reason for this! And while getting on a regular dose of amphetamines hasn't been the perfect solution (among other things, I've still had depression and anxiety to deal with, and getting COVID last fall did not help that at all), it has helped me start to figure out the question, what do I really want to do with my life, and how can I make it work?

Of course, this can easily turn into, “I want to make my dream game”. Realistically though, is it really only one “dream game”? Or is it just a vague concept in your head? For me at least, when I come with something extra I should add, it's in the service of a vague “dream”, rather than an actual game concept. It hits the need to work on the project you want to work on, but doesn't necessarily help the game itself. And that's what makes feature creep so sinister, at least for me - it scratches that gamedev itch, but gets in the way of your long term goals. It feels like the right thing at the time, but if the more fulfilling goal is actually releasing a game, it's a net negative.

Anyway, I hope that made a coherent point and wasn't just a stream of words. Here's some screenshots of what I've been working on:

*This is based on very rough calculations, and is oversimplified to the point of just being wrong. The full explanation would make up its own article, but the gist of it is that we weren't clearing any bottlenecks (not all Internet traffic has the same impact on infrastructure), but were delivering substantial data savings to users.