Chappington

Back home

Previous: February 2024 Dev Diaries

Next: April 2024 Dev Diaries

Iron Village Dev Diaries - March 2024

Diary #8 - Prototype Delays

1 March 2024

So you may have noticed that a prototype hasn't been posted yet… Yeah, it turns out I did not make the arbitrary date I set for myself. I've been doing software engineering for over a decade, and I'm still awful at estimating things, although I think this has been one of my most accurate timeline estimates.

It was a pretty common mistake this time - I totally underestimated how long it would take to make a minimum viable train scheduler. It’s just about done now though, apart from the load/save logic. At the moment, the first train is scheduled for 00:02 in-game time with a starting load of 8 gold, 8 wood, and 4 pops. Trains then come every 90 in-game minutes with randomized cars and randomized prices - I’m definitely planning on improving the economy and giving it more logic, but this will at least give the game some playability.

There’s a couple minor bugfixes after this, but no new features, so it’s unlikely that there’ll be any further delays, although I definitely just jinxed myself. I’m estimating the prototype will be out by the 8th of March, in time for the next dev diary. Then I’ll finally be able get some feedback that isn’t from my 5 year old!

8 March 2024

Yet again, I’m talking about the prototype - because it’s out! I actually already posted the link on Discord (LINK HERE), but now I’m sharing this a bit more broadly. It still isn’t indexed on ItchIo though, think of this as an extra early access. There’s lots of outstanding work, bugs, and other issues (which I’ll go over in a bit), but the idea is to get general early feedback: how does the concept work? Is it fun? Could it be fun? Does it need to pivot to something else?

So the overview is on the ItchIo page above, but here’s a rundown of what is left to add and be fixed. First up, the menu. Like in a lot of games, there's a menu you can pull up by clicking a button on the top right, letting you save the game, load another one, quit, etc. some of those buttons are currently disabled though:

• New Game: You have to close and restart the game to do this.
• Settings: There are no user adjustable settings yet. The resolution is set to 1280x720 windowed; the window is resizable but be prepared for odd behavior if you do.

Also, there is only one save game slot - pressing “save game” will overwrite that. The file is stored at INSERT LOCATION HERE on Windows.

Next, the art. Most of it is pieced together from Minifantasy assets, but the trains were done by me. A few things that are definitely planned:

• Crops growing over time, instead of just existing.
• Train cars showing goods inside of them, rather than just being empty.
• General train car improvements - showing depth is pretty tricky, and at the very least I think the roofs need to be lit differently.
• Finally give the pops some clothes.

Two other big things to note: Roads do not currently function (i.e. they don’t make pops walk faster), and the train car UX (the way you trade resources) doesn’t feel great to me. Like, it doesn’t come across as particularly intuitive IMO, which might be due to my avoiding the use of text.

Anyway, please take a look and give some feedback, it’s really important! (Don’t worry, I won’t be sending spam calls asking for survey responses saying “your feedback is important to us”.)

15 March 2024

First off, a new build is up, including Linux! The linux build is totally untested, so be warned - I’ll get around to testing it eventually, I just figured I’d provide it now. A couple of new features in this build:

• A main menu: When you start the game, it won’t immediately jump into the game.
• Crops now visually grow when being worked.
• Resources now have a set price when trading with the train.
• Misc. bugfixes and tweaks.

Next, the topic of the diary itself: pricing. So I’ve been going back and forth on three different options: $0/Patreon, $5, and $8 (all USD). I was hoping to get some feedback on this, but here are my thoughts on these options:

$0/Patreon: Regardless of price, I’m planning on starting a Patreon. However, this option would mean that Patreon would be the sole source of income for the project. The game itself would be free on itch.io, and I might sink the $100 into putting it on Steam as well. The pros: a free game would reach more people (theoretically), and it’s a price that fits a first game. The cons: the point of this is to practice making games - releasing them for money is part of the practice. Also devalues the game market - free games shouldn’t be the expectation of the market if it is to be a viable career for anyone, and releasing a game at this price point might nudge the expectations towards that.

$5: Decently cheap price. I think it’s a good amount for a small first game, although the price may suggest a lack of quality.

$8: This is kind of what I’ve been leaning towards lately. I’m not planning on this game being a huge project (key word: planning), so my gut is saying something below $10. This also gives wiggle room to put the game on sale and still get a few bucks from it. I just don’t know if it counts as too high for what it will be.

Of course, maybe it’s too early to decide, since the game isn’t super close to a finished product yet. But if anyone has input, please let me know!

29 March 2024

As mentioned on the various social mediums, I was attending PAX East at the end of last week, and didn’t have time to put together a dev diary. In hindsight, it’s silly that I even thought that was feasible.

For this week, I'm picking something that some of you will fall asleep reading, and some of you will find interesting - resolutions! Since the start of the project, I've been building the game in 720p: that is, a width of 1280 pixels and a height of 720 pixels. This is a pretty standard resolution, and generally the smallest you'll find on any modern device. (For example, this is the handheld resolution of a Nintendo Switch.) However, the actual game space has been 640x360, and I used a zoomed in camera to blow that up to 720p. This is mainly for the pixel art aesthetic - you can double the size so that the individual pixels are more obvious to the player.

This resolution was also deliberately picked to scale easily. I had watched a video by Adam Younis to explain the history and context of resolutions for pixel art games, but the gist of it is that 640x360 scales well to some of the most common resolutions: x2 for 720p, x3 for 1080p (regular “full” HD), and x6 for “4K”. There are plenty of other resolutions, including for ultra wide monitors, and a plethora of different resolutions for phones, but I figured I could deal with those later.

Anyway, I started working on properly handling different resolutions, and it turns out that Godot actually handles this really well. It can handle scaling the game automatically based on window size. This is especially handy if you want to make the game full screen - you don't have to actually set the screen’s resolution (which takes a second and can sometimes have side effects), it just makes the game look and act that way.

The thing with pixel graphics though, is they really only look good when they're displayed as designed, or evenly scaled by whole numbers. So, a game with a base resolution of 640x360 will look great in 720p (2x), and great in 1080p (3x), but what if you have something in between? Like, what if you have to scale by 2.5x? That is, 2 base pixels become 5 on the screen. Let's say we have pixel A and B, and we need to render them as 5 pixels. Pixel A maps to 1 & 2, pixel B maps to 4 & 5, but what do we do with pixel 3?

In most cases, there's two options. The first is to just pick one of A or B through some sort of deterministic choice. This is simple and quick, but can lead to jagged edges, especially in 3D games. With pixel art, this distorts the graphics slightly, unevenly enlarging parts of the image. The other option is interpolating between the two - basically blurring it, with various degrees of complexity in how you calculate the blur. In 3D games, this is part of anti-aliasing, which makes edges less jagged and zig-zaggy. The issue with pixel graphics is that the whole aesthetic is based on sharp, well defined shapes. Adding a blur kind of ruins that.

With pixel art, the only winning move is not to play. Godot has an option to automatically round down the scaling factor, so in this case you would get 720p (2x) and some black bars to fill in the remainder. This is great for more cinematic scenes where you want to control exactly what's on the screen, but for a game like Iron Village it looks odd - there's perfectly good screen space that can be used to show more of the town! There are some settings that let you have the aspect ratio adjust as the window adjusts - either making the screen wider/narrower or taller/shorter, but I haven't found anything that does both. So instead, I manually added code to the camera that would calculate the scaling factor, but round it up to the nearest integer. In some cases this will make the area shown by the camera smaller, but not by enough to be an issue, we keep the pixels nice and square, and don't waste any space with black bars.

Now that the resolution scaling is sorted, that finally allows Iron Village to run well on phones without having to squint at the tiny pixels, and also blow it up onto big screens - all with the same code.