Archive for October, 2013

Data Driven System

October 30th, 2013 No comments

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.

buildingFiles 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.


Categories: Me, Programming Tags: , , ,

The Command Interface

October 25th, 2013 No comments

I figured a progress update every 3 days would be a fair update interval, giving me an excuse to slack off for a day (which thanks to some determination hasn’t been necessary yet) as well as give some headway in case I get stuck on a module that I plan to discuss, which shouldn’t happen for a bit as I should have enough content for two weeks already, assuming I don’t go off and make a huge post for some reason.

Either way, I figured the next topic I’d mention is the command interface – the bar somewhere on the screen that gives you pretty much half the control of an RTS game, probably a bit more so in a strategy game. There isn’t a huge choice where to put the interface, there’s basically three options.

  1. Put the bar on the left or right side of the screen, turning the play area into what’s more of a square but allowing a more equal area of visibility.
  2. Put the bar on the bottom (or the top?) of the screen, turning the play area into a more wide field of view, but depending on the camera angle this can limit visibility depending on the size of the interface. (Notice the “depending on” going on)
  3. Use a minimal interface which some of the newer C&C games have done, having essentially a transparent panel

While I’ve played a variety of RTS games including the C&C series, Age of Empires series, Company of Heroes, Men of War (more on that later), and a few more (trying to keep the list short!), my main influence are the old C&C games so I figured I’d put the bar on the right side of the screen.

 In the image below, the left is the Red Alert 2 ‘Allied’ command interface, the right is my current version. There’s a few design changes here which haven’t really been finalized. The style is very bland but it allows me to work with the core features of the interface. There are no tabs, and the power bar on the side has been changed into a numerical display. Buttons will only display items that the selected building can produce rather than at all times. Pages can be cycled left and right to remove the restriction of a limited number of buttons being active for a building. The green arrow button at the bottom will essentially be the ‘upgrade’ menu, which at the moment I’m still deciding if it will open a secondary dialog or if it will simply show upgrades in place of buttons.


The next specific item is the minimap itself. Initially, the minimap was rendered in real-time with a constant Camera feed rendering to a Render Texture in the corner. Adding on to that, I was rendering actual 3D geometry on a hidden minimap layer directly above objects, and objects controlled their own “icons”. This would, more or less render it on the minimap. Fortunately, after being somewhat happy with the other systems I was simultaneously working on, I decided to refine the minimap. I added dedicated classes – one to handle the command interface, which would handle the minimap, which would handle icons. The minimap now contains a list of active icons which are now only loosely controlled by entities, in the sense of creating, destroying and selection. Thanks to some helper functions I added, I’ve made it a lot easier to convert a position on the world to the minimap, and vice versa. These handy helpers lead me to add clicking on the minimap to move the camera, which through the class was only a single line of code.

Icons themselves are no longer 3D geometry either, and are now properly drawn quads, with the camera direction using the OpenGL line drawing functionality. The minimap render texture is now only rendered with a camera once in the first frame of the scene after which it is destroyed and stored. There is essentially no performance loss using this method over using static imagery and it allows me to modify the terrain without having to keep track of minimap layouts.

The new render method no longer keeps the camera in the loop.

The new rendering method no longer keeps the camera in the loop.

I also wanted to go into detail a little bit about the complexity and goals of the project. I’ve made somewhat of a lazy decision not to plan and document anything with fancy UML diagrams, which has lead to some moments of confusion when developing essential systems that worked together, but it has also allowed me to head astray and work on odd little features that appeal to me on the way. The fact it’s a hobby project prevents this very decision from being a recipe for disaster, but it also makes project scope a blurred outlook. In terms of set goals, I do at least want to get base building in with units pathfinding and essentially killing enemies. Whether the enemy is going to be an AI controlled commander or a human opponent with networking isn’t really something I’m focusing on at all yet. Should I design the ‘team’ component correctly then interchanging the two scenarios may actually allow both with very little code change. However, I’ll leave this to be determined from a few more hours of late night pondering, and ultimately another post!

RTS Project Introduction

October 22nd, 2013 No comments

As I mentioned a couple of days ago, I’ve started on an RTS project. I’ve always enjoyed RTS games, since I’m particularly fond of systems that allow you to upgrade things or purchase stuff with your virtual earnings. On the other side I’ve always been terrible at RTS games so I never play them online either!

Moving on to the actual development there isn’t much to go on right now. Every night for the past week  or so (Apparently the project folder was made on the 14th) I’ve been working on the game for a few hours, in quietness and occasionally with some music to inspire the mind – in total that’s quite a number of hours already, and I have indeed completed a fair number of systems.

In terms of actual RTS gameplay, there is absolutely nothing yet. I’m developing the core systems which are nearly done and are progressing nicely. At the same time I’m occasionally taking the time to experiment with some things, such as attempting to model my own buildings (I’m not at all creative, as you’ll soon see) or creating a nice little terrain to work on.


The texture work may just be the worst part, as I literally slapped some seamless Google images on – I’m reasonably happy with the mesh itself considering I don’t model at all – of course it’s a placeholder :).

For reference, tonight I’ve pretty much overhauled my placeholder terrain, added a power plant model and building file, a fair number of miscellaneous code changes I’ve written up in the versioning system – Definitely not skipping backups this time! Finally, I’ve generated a navmesh, which isn’t really a real accomplishment seeing as I’m using the built in Unity navmesh tools and haven’t actually utilized yet. However I’ve left it until now as I’m finally reasonably content with the systems in place and want to move on to producing the first unit tomorrow, which may very well just be a cube for now, hopefully at least a placeholder free model.

As I’m developing quite a complex project and I haven’t started really that long ago, there really isn’t anything exciting to show. I’m going to keep the post short so I don’t run out of things to say and also don’t turn the post into a giant wall of text. I’ve got some really exciting systems that I’m quite proud of so definitely expect more soon!

Categories: Me, Programming Tags: , , , ,

Reflection – Operation Blockade

October 18th, 2013 No comments


Some years ago, I set out to develop a recreation of an old classic game, ‘Operation Blockade’. It was something I embarked on before any real programming knowledge and it was both a lot of fun and very educational. I attempted to mimic the game as much as possible, as it was a game I really enjoyed. Suffice to say despite my coding experience, I actually did a pretty good job if you can ignore the many duplicate classes as seen in the screenshot above (Whoops!).

Unfortunately about half way through the project I had somewhat of a hard drive failure, and at the time I wasn’t really smart enough to have proper backups. Thus the only real trace of the game I had left was an older, compiled build of the game I had once uploaded to show one of the original creators who was nice enough to give me an insight on the development of the original game.

It wasn’t until recently, after I was contacted by another original developer (kudos to you guys!) I came up with the idea of salvaging what I could. After a bit of research I discovered that reverse engineering Unity was supposedly incredibly easy. Surely enough, simply using a handy tool such as ILSpy, I was able to peek into the assembled code of the game and I had essentially retrieved a huge chunk of the game. While the code doesn’t compile flawlessly, I’d say that 90% of the code is recognizable and with touching up it would most likely work.

The next stage would be the actual assets. Apparently it was also possibly to load the assets of a compiled Unity game back into the editor. After some initial attempts it did not seem successful until I discovered that Unity’s asset system has very little backward compatibility. Upon retrieving an older version of Unity, 3.6.2f4 to be exact, I tried once more. Unfortunately again I had no luck extracting the assets – perhaps the reversal tricks only applied to even older versions of Unity.

Despite the results, it was very refreshing to see the old code I had written years ago, before my tertiary programming courses, to see what had inspired me to move on and continue writing bit by bit, an old classic game that’s gotten me to where I am today.

Finally, I’d like to add that after reflecting on my old project, I’ve decided to start anew on a new project while I seek employment in the real world. This time it will be designed with my own ideas, perhaps taking influence from classic games in its genre. I’ve decided to try and construct a versatile Real Time Strategy (RTS) project, loosely in the style of the old Command & Conquer series (I’m thinking Tiberian Sun, my personal favourite, and Red Alert 2) although this time in 3D. As it’s been over a year since any real updates to the blog, now is as good a time as ever to start producing regular development updates. Expect to hear more soon!


Site Transfer

October 18th, 2013 No comments



As the three year plan from my old web host came to an end I’ve decided to transfer my hosting services elsewhere after having experienced less-than-spectacular website speeds among other issues. If you’ve visited the site before then that shouldn’t be hard to notice. Hosting is now done in Australia instead of the US and has allowed me to have more seamless experiences through FTP and other direct connections such as disk access.

Having not posted anything for quite some time, I imagine this was an appropriate revival topic after a hosting services switch. As I’m writing this some DNS propagation is still taking place (for example, the ‘www’ prefix is currently in limbo and won’t load either the new or old host). As things are slowly sorted I’ve got some interesting new development content to start posting, similar to what I did many years ago with a remake of an old shooting game ‘Operation Blockade’.

Categories: Me, Site Tags: , ,