I have not forgotten about this game or abandoned it – quite the opposite really.
Since the last progress update, the most noticeable changes amongst hundreds are, as detailed:
I cannot tell you how much of a pleasure it has been to code this. I didn’t use a special library, which some will exclaim is a waste of time to code from scratch, but I chose to do this for a couple of reasons:
- I have been itching to write some form of AI for many years now.
- The code is actually rather simple – it is pure logic. Programming is all about logic, and in this case, it gets applied directly to a completely logical outcome.
The AI is essentially only as smart as the tactics given to it by the author. The author could tweak and enhance the AI to an extremely high standard, but that introduces its own problems – if the AI is too good, the game is far too hard. The AI will not have human error, or mis-time the construction of a vital weapon, nor will it mistake the best research queues. The AI can have the ability to know exactly what units you have and where. That is unless it is purposely given human error and only basic information (like the fact a map region is occupied by the enemy, rather than what is currently in it).
Tweaking the AI is like teaching the device what it needs to do to win. You get to see it improve from trial and error and further tweaking, until it is good enough to be able to win against most players depending on the goals. Detailing this in a way that makes it fun for the user is something that requires it’s own blog entry.
There are three AI systems in place:
The Navigational AI controls the battle map – a navMesh is generated across the map detailing the typical “ground units cannot move through here”; which route a unit needs to take in order to get from A to B; but on top of that, it can also be used to inform AI controlled units that an area of the map is hostile to an unarmed unit. The AI would be pretty daft if it sent a lone construction unit straight into the path of a group of enemy tanks for example.
The Combat AI controls the behaviour of units, including the player’s units. The player still controls the units, but the AI kicks in to handle behaviours such as auto-targeting enemies who get too close and chasing a retreating enemy who poked in to test the water. It also links with the navigational AI in order to follow routes. In a bigger way, it controls how the enemy units behave as far as hunting out enemy units, knowing when it is best to retreat, and so forth.
The Overworld AI decides where units go, as far as the Overview map. Does a region need a weapons factory? Does it need reinforcements? Does it need more defenses? Should the units in a region assault an enemy region? Do we have the resources and required build tree to build a certain structure in a certain region?
I had doubts about the performance of the game considering the pathfinding algorithms involved. After testing it, so far with up to 50 units moving across the map (each plotting a new path at each move order given), the iPad 2 didn’t even shudder. I am confident it would handle double that number.
The AI really makes the game come to life. Suddenly those various graphics representing units and structures have some form of understanding of their surroundings.
User interface and user acceptance
When creating the user interface, it felt simple – an option shows units on all regions, another option shows structures. So far so good, except it wasn’t so obvious which was which on a second look. Simply highlighting the selected (and currently active) option made a significant difference. Adding subtle sound effects to UI touches made it feel more responsive. Adding a message box of what has just finished building and where, which units arrived where, and other such messages made the feedback to the user far more involving. There are numerous improvements to be made, but they are important – the game otherwise feels lifeless and flat.
I am limited by design skill. So far the interface still consists of touchable text – button graphics fitting in an overall theme would instantly improve the feel of the game. Better sounds would do wonders too.
Each addition of an interface element needs a lot of consideration. Where can I place it where it won’t distract from the action in game? What size should it be so it is not dominating, but can also present the relevant information? When should it show? When should it hide? A user does not want to manually close an information box when trying to command a real-time army…
My idea of what works is not going to be everyone’s idea either. People will need to play test it in good detail. Heck, at this stage, a designer looking over it would be a serious boost, and definitely someone who doesn’t yet know the concept of the game fully. Some bits are obvious to me, but in showing and explaining the game to various people, they didn’t fully get what they had to do. This fact is concerning.
Unit and structure construction
This isn’t so much a concept like AI or User interface guidelines, but it was the difference between a very static, basic game, to one where the larger portion of the game starts to take shape. Building bases, constructing units, and dominating most the Overview map with more than just the starting units was a big step forward – not a tricky one, but very significant. Suddenly the game mechanics are getting involved more so than getting various test units to behave and respond. This area becomes more fun when the units can actually kill each other mind…
And the rest…
There are countless small features which would be ridiculous to list given that the game is still very much in development. Most of the time, if anything is added or improved, I take a screenshot. So far the screenshot count is 68. Various items are tweaked numerous times, and even still it’s by no means perfect.
Multiplayer could be a good possibility, but the nature of the game is that it would take a rather long time for someone to win. Unless two very dedicated players had half a day to spare, a multiplayer save feature would need to be implemented. Certainly possible, but the focus so far is getting the single player correct.
One of the hardest and most mundane steps comes once the game is actually playable though. The bane of RTS development is balancing the different races. Starcraft 2’s Heart of the Swarm (at time of writing) is “99% complete, but that last 1%’s a bitch.” If one race has an advantage over the other which cannot reasonably be countered, then there is a serious problem. Fixing that balance could break other balances, and there are numerous factors to take into account – cost, health, armour, weapon damage, speed, even build speed.
I do not have a release date yet. I am not working on this full time, however there have been couple-of-week stretches where I have had a shortage of work from the web development freelancing (purposely done in most cases). I still need to pay the bills, and various topics on TouchArcade‘s developers forum detail that it is unrealistic for any game developer to expect to live off iOS game development alone – the competition is just too vast. Primarily though, I am writing the game because I want to play the finished result, not to make a typical annual salary in a week, or a month, or even a year. I am very optimistic about porting it to other platforms too – although it is written in Objective-C, the logic really isn’t difficult to port to C++ and get this rolling onto Windows platforms.
I am in brief discussions with a designer too, hoping to work something out. With the design being such a vastly important part of a game, this isn’t something I can get away with lightly either. Interestingly, part of the deal could be making his game ideas too, which would be a pleasure.