Legacy Projects: Real-time Strategy

Yesterday I decided to post some vids of old projects that I've not posted about or which I never posted videos of. Today I'm dumping a few vids of RTS projects I've tinkered with.

They all use my RTS framework 'Warsmith', which I've been working on for many years. My old project Zyrtuul was where the framework originated. There are 4 prototype games that use the framework. My main focus has always been the framework itself, with the game prototypes being just a side effect.

Battlescape

Back in 2014 I started work on a real-time strategy game called Zyrtuul. I knew that it was too much work for a single person, but often I just want to work on what I love rather than focusing on what is feasible, so I went ahead anyway.

I made a lot of progress over the year, but eventually (and inevitably) I ran out of steam. RTS games are complex and a lot of work, so I chose to rather change course and focus on games with smaller scope that I could actually release.

Since then I have released a few games on iOS. But although I had fun with them (despite the torture of the iOS deployment process) the problem with games that are small in scope is that, put simply, I'm not really passionate about them. Often I ask myself, would I play this myself? And usually the answer is no. I'm into games with more complexity and depth, and those are the kinds of projects I'd like to work on. Those are the kinds of projects that challenge and excite me.

With the games market so over-saturated the chances of getting your game recognized are pretty low anyway, so I thought "well fuck it, I'm going to work on whatever the hell I please, it's just a hobby in my spare time anyway."

And so I resurrected Zyrtuul. Except this time I decided that I'd go all out and make it multiplayer.

Back in 2014 when I first started work on Zyrtuul I was still fairly new to Unity and C#, and the idea of RTS networking admittedly scared me off a bit. Fast forward to 2018 and I have a fair bit of experience with Unity and C#, and my way of doing things has shifted significantly (coding conventions, design patterns that work well with Unity's world-view etc).

And so... I decided to start 'from scratch' (create a new project) and just drag in / re-factor the useful bits of code. I also decided to expand the scope and go all out. I wanted to challenge myself -- multiplayer and the full shebang.

The new project's work-in-progress name is Battlescape. It's a squad-based multiplayer game focusing on co-operative gameplay. I've always loved games like Starcraft and Warhammer: 40k, and back in the day LAN battles of Starcraft were inspirational for me. However, they've become very niche and overly competitive over the years (for example, the only way to be competitive in Starcraft 2 is practically devote your life to the game). I miss RTS games. I feel that they have become a niche genre; almost abandoned.

So I'm thinking, why should they be? I love them. Other people used to love them. I honestly feel that the mutliplayer RTS genre does not need to be inaccessible or intimidating to average players.

My idea with Battlescape was to focus on the co-operative aspect of it. It's multiplayer RTS, but you're all on the same team working together to overcome increasingly difficult challenges. Team-work, camaraderie, low pressure and a focus on allowing you to easily choose to play with your friends as if it was an old-school LAN.

I've made some really good progress so far. I'm quite proud of my squad formation logic. You can change formations on the fly and the units handle it intelligently (I was tipsy when I wrote the code and had to do some fair bit of math-wangling with a fuzzy brain). The core logic of the game is in place. However, as with most pet projects of large scope, I ended up burning myself out a bit.

I'm still in love with this project, but I've decided to take a break and come back to it later with fresh eyes. Also, I have unfinished older projects which (as with this one) I've abandoned due to burn-out. They need to be re-visited. Check out my posts on Araxxis Squadron and Lyntheria for more info.

Hero Brawler Game Prototype

About two months back I revived a game I developed a few years back called Death Arena, making various improvements, integrating it with Facebook, implementing various new gameplay features and getting it ready for deployment on the iStore. It's pretty much ready to go but I feel the need to do one last pass and see if there is anything else that can be improved before putting it out there.

Screenshots of Death Arena

However, the last phase of any project is often the most cumbersome and I started feeling a bit burnt out on it and decided I needed a break. This is how I justified allowing myself the twisted pleasure of working on an entirely new project when I had a 99.9% complete one waiting to go (and others on hold!). Admittedly, I felt a pang of guilt as I wrote this paragraph.

Anyway, I shall now cease this mincing of words and get to the point. I began experimenting with other game ideas for my next project. I experimented with transforming my PC-based real-time strategy game, Zyrtuul, into an iPad game, but it was a bit of a daunting task so I decided to hold off on that.

This is Zyrtuul. Attempting to simplify it so that it works on iPad (rather than PC) turned out to be a bit too complicated for my liking.

I toyed with several other game ideas before developing a two week long addiction to the iPad version of the game Injustice. Injustice is a one-on-one fighting game featuring DC Comics superheroes. The mobile version differs from the console versions in that it is less action-oriented and uses a collectible card mechanic, allowing you to acquire characters as you progress and level them up.

Character Store in Injustice

As always, whenever I get into a game I started feeling the urge to develop my own game inspired by it. So I started experimenting in Unity, trying to implement a similar concept. It's still a very early prototype (none of the game mechanics are in yet), but it's looking promising. I'm considering making this my next project (though I'll need to evaluate other existing projects that are closer to completion before making this call).

I purchased character models a few years back for another game prototype (called the Weeping World -- it was grim and awesome, but too large in scope). Hence the decent looking characters despite it being only a few weeks in.

It has a dark fantasy theme and is somewhat inspired by the early Mortal Kombat games (I had Goro's lair from the first game in mind when developing the first combat arena). As a prototype / proof-of-concept mock-up it is, of course, very rough around the edges, but I thought I'd post some screenshots of it's current state anyway.

In an act of callous heartlessness, an evil wizard gives his equally evil twin a solid blow to the crotch, thus reducing the likelihood of the poor fellow ever reproducing.

I added the blood last night. I'm not sure whether they'll allow this on the iStore though.

The arena needs more work to really live up to it, but was inspired by Goro's Lair.

Battle Setup Screen

Zyrtuul Progress

Progress on my real-time strategy game slowed down a bit in the last few months, so I decided to give it a bit of attention in the last week. It's at the stage where many of the core game mechanics are down -- it's fairly playable, but needs some more work for it to provide a genuinely good user experience.

I'm not sure where to take it from here. Initially this started as a fun creative outlet and as an artificial intelligence development testbed. It's grown into a full-fledged RTS game now. The removal of the multiplayer component still irks me a bit, though I still feel the scope reduction was necessary.

I've been considering toning the entire game down from a traditional RTS to something targeted more at the casual gamer. I've been playing Clash of Clans and was wondering if I shouldn't be moving in that direction -- it's easier to compete with the casual strategy games than it is to try put something out there that tries to compete with franchises like StarCraft or Command and Conquer (even if I was working full-time on it, it would take a loooong time to get it at a level where it could compete with games of that scope).

On the other hand, I've already put so much work into bringing it to its current state that trying to force it into a casual Clash of Clans style game would be pretty tough (I'd probably be better off starting from scratch, though there would be a lot of re-usable code and art resources to speed up the process).

I recently taught myself PHP and was experimenting with the database / server side components of a framework for making games of that type (Clash of Clans, Boom Beach etc). But I'm too attached to Zyrtuul as it currently is to butcher it like that. It's something to think about though. I'm considering buying a Mac Mini in the next few days and deploying to my iPad to get a feel for it.

Anyway, it feels like I'm rambling now. Here is a recent screenshot.

Loading Terrain Heightmap Data Via C# Script in Unity

For my real-time strategy game Zyrtuul I need to be able to load different landscapes at run-time. A fundamental part of this is loading terrain heightmap data from script. I implemented this last night. I noticed that many people have been asking how to do this online, but I did not see any complete solutions presented. It turned out to be significantly easier than anticipated. This implementation allows you to save your heightmap using any image format (I assume it is saved in Assets/Resources/Heightmaps). Simply attach this script to your terrain object and it will load up the specified heightmap automatically.

Experimental Art and Design Work for Zyrtuul.

Work has been busy at the moment and I was feeling a bit worn out, but I still felt like doing work on Zyrtuul. So I decided to take a break from programming for the weekend and focus on the artwork instead. I started off searching for source material and looking for inspiration online, in an effort to settle on an overall look for the user-interface, splash screens and overlays of Zyrtuul.

For a while I was attempting to take rendered images of various vehicles, super-impose them over a background and then modifying them in Photoshop to fake a hand-drawn / painted feel. I was initially happy with the results, but after comparing them to other games' splash screens I realized that, while they were okay, they weren't great.

After that I decided to stick with my original plan, using more generic spacey images, which are much easier to make (there is a lot of good source material out there that you can combine to get a unique-looking, visually appealing final image). The image below is still experimental and not final, but gives some indication of what I'm thinking the overall look and feel of the splash screen will be.

I had already designed the look of the mission select screen, but I wasn't 100% satisfied with its current state so I spent some time tweaking that as well. I still don't think it is perfect yet, but it will suffice for now. The current mission select screen can be seen in the image below. It may be too dark to see, but there is a square spot reserved for a top-down image of the map near the top right of the screen. I haven't implemented that yet though (the game is still in the rough early stages).

As the artwork starts to look more polished, elements that I previously liked no longer seem as good as they did. This was the case with the in-game overlays (which I put together sometime last year). These include the minimap border and the 'command panel' (that is, that panel where command buttons such as 'move', 'attack', 'stop' and 'patrol' would appear). In addition to that, I felt it was time to change the way resources are displayed (previously I just had placeholder text at the top-right of the screen). I have put all three in-game overlays into the image below to show what they currently look like.

At the top is the minimap border. The minimap would appear in the square black region. Below that is the resource display panel. When in-game, a number will be shown for each resource type. Below that is the command panel. When in-game, if a unit (that is, a vehicle or building) is selected, buttons will be displayed in the command panel. These allow you to issue commands to the unit.

I was happy with the way the terrain looked, but I felt that some textures looked better than others. I spent a few hours making new terrain textures yesterday. I wanted uber-high levels of detail, and so I composited various images together for the diffuse maps (I've had a lot of practice so I'm getting pretty good at it). I then manually constructed normal maps in Photoshop. Ordinarily, converting the diffuse maps to greyscale and then using that as a heightmap will, although a cheap hack, do the job when using it as input to construct a normal map. However, I wanted a very specific look, and so I instead (painstakingly) constructed the height and normal maps. It is difficult to clearly see the results from the screenshot, but they look very good when viewing the game at full size (especially when combat is occurring, due to the way weapon lights interact with the normal maps).

The final bit of work on Zyrtuul for the weekend was done this morning. I wanted to settle on the game factions and their banners / logos. This took surprisingly long (it took me many hours to do the banners). This is what I'm sitting with at the moment (the logos at the top-right of the image).

Deciding what the factions would be was difficult -- it often feels like most of the good ideas are taken already, and so coming up with something genuinely original seems impossible. They say that most stories are just variations on a few common themes, and so I consoled myself with that thought and decided to just settle on something.

The idea of an empire vs rebels is very cliched for obvious reasons, but Star Wars wasn't the inspiration for that (although now that I have made that connection, I'm wondering if I need to change this). Anyway, I may end up changing this, but the inspiration for this was actually Spartacus.

I thought the idea of designated slave planets would make for a good story -- entire planets whose populations are automatically born into slavery. Groups of slaves are periodically 'harvested' from these planets and brought to work on the elite planets. And, of course, such a situation would inevitably result in rebellion, which would then require those in power to quickly squash it to prevent other slave planets from joining in.

As for the Smugglers' Guild, well they have no interest in such conflicts but occasionally get involved when it profits them. The Smugglers' Guild is amoral and neutral, but if they can get away with attacking either side so as to benefit from the spoils of war, they will not hesitate to do so.

Implementing Fog of War

Last night I began implementing fog of war for Zyrtuul, and made some decent progress. Tonight I spent a few hours and got it working properly.

My implementation uses render-to-texture functionality, and involves the following steps:

- Create an orthographic camera that renders the scene from a top-down perspective. This camera does not render any of the usual objects. It will only render special objects called 'fog of war revealers'.

- Attach a quad to each unit in the game. This is simply a flat upward-facing rectangle positioned just above each vehicle or building. I call these 'fog of war revealers'.

- Map an image which will control the way fog of war is revealed for units. I initially used a simple black image with a blurred white circle in the middle, but then experimented and am currently using the image below (made it in Photoshop). This simply makes the fog of war boundaries more interesting. Basically, each unit will be surrounded by an area of 'transparency' with the following shape (completely arbitrarily chosen at the moment and definitely subject to change).

- Create a render texture. This is a surface that the fog of war camera will render to. That is, instead of rendering to the screen, it renders to a separate image in memory. Set the fog of war camera to render to this texture.

- The first time the camera renders it clears the image to black. It then disables its clearing behaviour so that for subsequent frames the image is not cleared. This allows the fog of war state to be permanent. If we wanted the fog of war to re-appear at locations where there are no longer any units we would skip this step and have the camera clear the render target to black every frame.

- Set the blend mode of the fog of war revealers to be 'additive'. This means that wherever the unit moves, the image above will be added to the black background. The following is a visualization of what the render texture might look like if there were four units in the scene.

- Render a large plane at the height of the terrain. This will cover the entire scene. This plane will render in both the main view and the minimap view.

- Map the render texture to this plane's material. What we are doing here is having the render texture control the alpha state of this plane. Thus, the white areas will be transparent but the black areas will be opaque.

- Set the depth buffering behaviour of this plane's material to 'no z-test' and 'no z-write'. This will make the plane always render on top of anything (so that we don't have to concern ourselves with situations where objects are above the plane). Also modify the render order of the plane so that it renders after all objects that must be obscured.

Below are some screenshots of the game with fog of war enabled. The turrets do not currently have fog of war revealers attached to them (so they can currently be obscured by fog of war, which I'll fix later).

Zyrtuul Screenshots.

I put a lot of work into a new pet project toward the end of last year -- a real-time strategy game that is currently going by the name Zyrtuul. I took a break for a few months but recently decided to do some more work on it.

I've added various new vehicle types. At the moment I'm focusing on getting the art in and looking good rather than on implementing specific vehicle capabilities. I quite like the new harvester. As it gathers red suphur (visible in one of the screenshots, the red stuff on the ground) a heap of red sulphur gradually grows on the back of the vehicle, until it is full.

I'm experimenting with a darker, more grim sci-fi look. I've taken out the trees and water and have put in rocks and lava instead. I've also removed the grass terrain textures and replaced them with dark rock / dirt textures. The look I'm going for is that of a barren planet. To further promote that atmosphere, I've subdued the lighting and given it a bluish tinge. The vehicles themselves are quite detailed, and when combat happens there tends to be a lot happening on screen, so I thought it best to keep the terrain dark and unobtrusive.

Implementing Path-Finding in Zyrtuul

In this post I discuss my implementation of path-finding in the real-time strategy game I'm currently building (the working title for the game is Zyrtuul, though I might end up changing that).

A commonly used path-finding algorithm in game development is the A* algorithm (pronounced 'A star') which is an extension of the older well-known graph traversal algorithm called Dijkstra's Algorithm. I coded up a C++ implementation of various path-finding algorithms back in 2005 (as part of one of the demonstration applications that accompanied my CompSci master's degree), so I chose to re-use my old implementation of A* rather than re-inventing the wheel.

I started off coding the game as well as the game engine in C++ because, at the time, my main interest was in developing the underlying technology. But as it progressed I started wanting to focus on the actual game rather than the technology. Coding the engine and game simultaneously was simply taking too long (and I wasn't really learning anything new, having done so much engine work over the years already). So I decided to switch to the Unity engine for the game.

Unity doesn't support C++, instead you write scripts in C# or Javascript (edit: apparently Boo and their own language called UnityScript are also supported). I am therefore now coding in C# (simply because I have more experience using C# than the others).

Converting the code from C++ to C# was initially pretty straight-forward until I realized that C# does not provide a priority queue (a fundamental component of the path-finding algorithm) as part of its library. With my initial C++ implementation I was using the STL priority queue, but I now realized that I would have to find an implementation online or else write my own.

A priority queue is a data structure that keeps its elements sorted based on some user-specified criterion, in our case based on the path node cost / distance when conducting a path-finding query. In short, a priority queue is the most efficient way of performing path queries because of the fact that it automatically keeps itself sorted when you add or remove items.

It seems that the Microsoft C# team decided that a priority queue was too niche to be included in the .NET foundation library, so I was out of luck. Fortunately others had encountered this problem as well and so I was able to find a priority queue C# implementation online that, with some minor modification, suited my needs. Once the priority queue was done the rest of the graph traversal / path-finding code came together nicely. So I ended up getting a task that would ordinarily take a significant amount of time and effort done in about a day due to code re-use.

Path-finding solved the macro-navigation problem (navigation on a large scale), but micro-navigation was still a problem due to the fact that the pathing grid has limited resolution and also due to the fact that the grid is not static -- moving entities can invalidate previously valid routes. A vehicle could easily determine that to get from one side of the map to the other it needed to move around a lake or large obstacle that was blocking its way, but it still had issues on a smaller scale. For example, if vehicle A was told to find a path to some point and then vehicle B was instructed to move to a location that blocks this path, vehicle A would eventually encounter vehicle B and need to determine how to deal with it.

For this game I could get away with very simple collision detection and collision response based on bounding spheres and having vehicles 'pushed away' from one another when they are colliding. This partially solved the problem of vehicles coming into contact with one another (they would simply push one another out of the way), but was far from perfect as it could lead to 'jostling'. Also, it just made them look downright impolite. If two vehicles were headed directly toward one another, they would simply push head to head with neither able to get past. Alternatively, if you told many vehicles to move to a single location they would all mass together, jostling and pushing one another in an attempt to settle at that location.

One attempted solution was a "frustration factor"... when a vehicle was too close to another vehicle it had a frustration factor value that represented how 'frustrated' the vehicle was, with the idea being that it would eventually decide to simply find a new path to its destination it it became annoyed enough. This was simply a floating point value that increased over time when the vehicle was too close to another vehicle, and decreased over time when it wasn't. If a vehicle's frustration factor rose beyond a certain threshold it would request a new route to its current destination. Unfortunately I spent far too much time trying to get this to give the desired results and I found it to be too unpredictable. Eventually I decided that the moment a vehicle encounters another vehicle, one of the two vehicles must immediately find a new path. I arbitrarily decided that in the case of path blocking conditions the unit that was created first gets to keep its current path and the more recently created unit has to find a new path.

Quite a few other rules are also in place to handle various conditions and edge cases, but I think I've already written too much and so won't go discuss these here. The navigation behaviour of the individual units is fairly solid at this point, but not quite perfect (it's close though, better than some commercial RTS games I've seen). However, it will suffice for now -- I can hone it further later on, when polishing the game up.

New Real-Time Strategy Game

I've been working on a real-time strategy game for the last while. I've kept it quiet until now, but it is getting to the point where I actually have something worthwhile to show. It is still in the very early stages, but here are a few screenshots of what it is looking like so far. I have developed a mini-map but disabled it for these screenshots.

I've decided to go the open source route and so will be releasing the source code for the game eventually (I'll only be releasing the C# code itself, not the content).

I'll probably talk about the development of the game in a separate blog post later.

Note: some of the art content is just placeholder art that I threw in to make what was initially just a fun AI experiment easier on the eye. I just realized that it's about time to replace it (I have acquired 3D models and have a friend working on more, just need to put them in). Rather silly of me not to think of that before posting screenshots.

Edit: I have modified the screenshots and blurred out the art that I know I'll have to replace. I'll post updated screenshots at a later stage.