Hi and welcome to the third devlog about After the Collapse, our post-apocalyptic base building game! Since the last article, a lot of work went into properly implementing multi-tile agents, the save/load feature and tweaking the game’s UI and rendering engine. Let’s check our progress, and as usual: screenshots are mostly using placeholder sprites and assets.
Multi-tile agents and buildings
This is probably the most important improvement here. As it’s common with this kind of game, for all building placement purpose (and path-finding), we’re using a grid to which buildings ‘snap’ to. That way, you can align those walls and buildings/furniture properly. Until now, we could have objects for which the sprites would be bigger than a single tile, but it was purely cosmetic. Only the center tile would count as being occupied by said object, which was fine until you tried placing such objects next to each other (causing a sprite overlap) or try implementing big objects that would block path on multiple tiles.
In our games (ATC inherits some systems from our previous game, Unending Galaxy), agents’ position were defined by a simple Point (X,Y coordinates basically). With the new system, we’re using a Rectangle to define where and how much room is an object taking. Objects occupying a single tile will just have a size of 1. All what’s left was to update our collision detection routines to take the rectangle into account and update our existing data files to include the size of the object. Of course, this improvement also extends to living creatures, meaning that later down the road we’ll be able to implement large baddies who won’t look silly navigating into spaces they shouldn’t be able to fit in due to their size. We’ll still have to tweak the pathfinder for such creatures, but we’ll get to that later.
Save System
Well, this is straightforward enough, the game save/load system has been implemented. While it’s not exactly groundbreaking, I’m pretty proud of it, especially compared to what we ended up in Unending Galaxy. This time, it’s pretty fast, robust and game-agnostic, in addition of being extremely easy to maintain. It’s a couple hundred lines of code long compared to two thousands previously. As with all our data, save-games are written in JSON (a formatted, computer readable text file) which make them quite big (couple of megabytes) but we can still compress them if need be.
In more practical terms, we should be able to maintain save-game compatibility between most future versions. Also, contrary to our previous system which was slot based, here you’ll be allowed to store as many saves as you want. Finally, given that the process is pretty fast, the auto-save feature should feel much less invasive than in our previous game.
Rendering
While the implementation of the game’s systems is still a priority, I still made a few improvements to the rendering engine. Objects can now drop shadows, giving a better sense of depth. Below is a comparative screenshot with and without shadows enabled. It’s fairly costly on the GPU as it’s basically drawing each texture twice: one time for the black(ish) shadow and another time for the object itself, but we’re still well within acceptable margins.
Of course not all objects have to cast shadows and here again, it can be changed in the data files directly. While at it, I added the option for factory type buildings to fire up a particle effect/animation when in use. For instance, our forge when active is now showing smoke coming out of it. It’s doubtful I will be able to make the actual particle effects moddable, but I will try to include a fairly decent selection to chose from for the modding community.
User Interface Tweaks
While the whole current UI is barely in it’s infancy, I think it’s still worth mentioning. Writing an UI from scratch is an iterative process and it’s better to improve it along the way instead of trying to do everything at the same time. Truth be told, it is boring to code to write and slow to test, so it’s generally better to do it in smaller chunks. Generally speaking, I’ve been trying to reduce the numbers of clicks and movements required to do actions.
For instance, until recently, if a player wanted to change the production of 2 crafting stations in a row, he’d have to click the first station, do the changes, hit the close button, click the second station and repeat that process. Annoying and inefficient. Now, clicking an empty space will close any opened menu, and of course if you click on something with an associated menu it’ll automatically switch to the relevant one.
I also started standardizing the various list layouts (inventory, build screen). While the layout itself is far from being ‘final’, it will make things much easier to improve alter when the need arise. The idea at the moment is to have a fully working UI, not a slick definitive one.
And as a sign of things to come in the next updates I also added a very bare-bone character screen (not ready for prime time), highlighting a survivor’s traits and statistics.
Closing Words
Simply put, we have all the basic mechanical parts working. Factories, storage zones, the ability to convert basic resources into useful material, etc. Of course it’s far from being fully fleshed out, but as a foundation to start working of the survivors’ behaviors and their management, it’s perfectly adequate. So with that out of the way for now, the next step will be to translate those traits and stats that define each survivor into noticeable differences on your screen (which will also make for more interesting devlogs).
Cheers,
EsKa.