Time for another update!

In this post I’ll be talking a little bit about the back-end of the game itself, so any pictures that are in the post won’t actually be showing the game this time. I’ve still included some to keep things interesting.

While planning for the project was minimal, I did think over the essentials around the time I started, and one of these decisions was to make the game somewhat data driven. This has multiple benefits, both for me and potential end users.

• Game data is easy to add and remove as items are handled modularly
• If something goes wrong it’s easy to track it down from the fail-safe importing methods
• RTS units and buildings are much more dynamic – I’ll come back to that in a moment
• Custom content (think mods!) is really easy to add
• Code is much cleaner and structured

So let’s talk about a few of those points. I’ve decided that game content is handled from three different sources.

1. Core game content (.NET Assemblies, code, core assets, etc.)
2. Game Data (Units, levels, buildings that I created, etc.)
3. Mod Data (Custom user created content)

A visual demonstration of the importation process is shown in the picture on the right. Core game files are loaded as per usual, then the data folder is unencrypted and uncompressed. Compression and encryption are here just to keep my own assets in check, and should I be outsourcing any 3D assets then you’d need to go through a bit of effort to actually obtain them.

The mod folder is actually loaded first, and therefore is able to override original content. Original content data is available in help files, so as an example, a player is able to replace the construction yard to use custom models or use the original buildings for tech references. The data and mod folder are actually the exact same format, it’s just that the former is simply packaged with the game in a less accessible way.

Files that provide the game with information are standard XML format which then point to any additional resources that the entity is made of. Currently there are only two formats, one for buildings and one for units. A level format might be added in the future, but it seems more appropriate to leave that as a binary file.

As part of the data structure, I have designed units and buildings to be somewhat in reverse order. Typically, a building may have a list of units it can create, or a building may have a list of new buildings that can be built after it. Instead, units refer to the string ID which they spawn from, as well as any tech requirements before they become available. Buildings are similar, in that they also have tech requirements.

As an example I have attached an image of the current barracks building. Note that the XML structure is very likely to change as there are some essential gameplay items that need to be provided, such as view distance, fire rate, damage, and what not. It wouldn’t be much of a fun RTS without combat would it? You can see that the building ID is listed at the top of the file, with basic properties below, tech properties then data files. Of course the order doesn’t actually matter, but that’s how I’ve structured it. You’ll also notice that the tech requirement of the BARRACKS building is the CONSTRUCTION_YARD, which means that it can only be built after the construction yard has been built. What isn’t visible is the upgrade XML nodes, but as these haven’t actually been implemented in-game they wouldn’t be much use yet anyway.

Upgrades can of course also serve as tech requirements for a building as they have their own string ID. It is currently planned to allow upgrades to replace the mesh of the unit or building, or even add to it if it’s a building, depending on if performance isn’t a concern (seeing as shadows would greatly increment the vertex count with all kinds of upgrades on screen). At this point the default texture formats of PNG/JPG are supported and OBJ models, but seeing as the asset loading is written in a modular way I’ll probably add a few more formats in the future such as TGA and 3DS.