Another side project

I really, really, really want to work on Failed State but I started another side project that has the potential to make a fair chunk of pocket money. As a result I’ve completely put the game on hold as I work on getting this side project to a minimal viable project. Actually, just getting it into a prototype so that some live testing can be done on it would be a good milestone at which to then spend a couple of weeks on Failed State again.

I write this after just after reading about Putin potentially getting cheeky with Georgia again, more specifically, in Samtskhe-Javakheti.

It also comes a few days after continued fighting near the Donetsk airport. Just look at how much Open Street Map data has been contributed to the Donetsk region. The contributors have almost accounted for every single house to the immediate south of the airport. Amazing.

Lots of data means lots of layers and therefore lots of z-fighting; something I still haven’t found a solution for yet.

One day it’ll be fixed.

Combat Engine

What is combat? What is a combat engine?

I suppose (because I’m really just guessing) a combat engine for a game is anything from a turn based system all the way to a high accuracy physics engine with projectiles colliding with physic bodies. With Failed State’s game world being merely a 2.5D environment where terrain is flat and the height of buildings is contrived, it makes little sense to try and perform accurate projectile physics.

In fact, there may be no point in having bullets fly around that map. The infantry of the original Command and Conquer series did this quite well, whereby the infantry would be doing all this shooting and with an animated sprite to show it and another animated sprite to show kicks of dirt around their target.

That and health bars which I don’t intend to use.

That being said, C&C did use projectiles for their tanks and missiles yet even then, they weren’t there to perform high accuracy point to collision mesh collision detection; there’s a good chance it was known in advance if there was going to be a hit or not.

Level of accuracy

Failed State only requires a certain level of combat accuracy to be exposed to the player. Although seeing individual bullets might not be required, there is something to be said of seeing missiles with vapour trails. This video of M1A1 Abrams tanks doing live fire exercises clearly show projectiles in motion and it would be a shame to not see some of those in the game world.

I am definitely going to try and pull some audio from that video for sound effects.

But even if there are projectiles along a 2D plane, they needn’t “hit” anything; not in a physics sense at least. The system I’m interested in making involves the idea that something shoots at something else and that there is a chance of hitting the target. You could say I want to conduct a dice roll in realtime.

Here’s a really basic example…

One soldier fires on an opponent soldier. Either the target is hit or it is not. Now, what are the chances of the hit occurring? What affects the likelihood of hitting the target?

  • The skill of the shooter
  • Dumb luck

Let’s expand upon this. The skill of the shooter alone is not enough to determine if a target will be hit. Here are things that could make the shot more difficult.

  • The target could be moving.
  • The target could be far away.
  • The target could be behind cover, partially or fully obscuring them.
  • The cover could be of various strengths. A bullet might pass through wood but not steel.


There’s a possibility of lots of shooting and not much hitting, especially considering modern combat tactics. Suppressive fire (and modern weapons) use a lot of ammo. What will make Failed State interesting is if these modern combat strategies can be realised. Suppressive machine gun fire or artillery can make a target ineffective (they can’t move, shoot back or even see their opponent approaching their position). Different weapons would create differing amounts of suppression. Implementing such a system would bring some strategic elements to the game because when suppressed, a unit’s awareness of their surroundings is compromised. They may also take time to become effective again as the shock of being shelled diminishes. A unit with high moral and/or experience would recover quicker than a ‘green’ unit.

By taking the above into account, a rudimentary combat system can be constructed.

Let’s say there is a valid target.

  • Every 5 seconds the soldier takes a shot at the target
  • Typically this soldier has a hit ratio based on some non linear relationship with distance (and skill), i.e. when really close they’re more likely to hit but when further away, they’re more likely to miss.
  • Assuming this curve exists, let’s say that the soldier has a 50% chance of hitting
  • …but the target is behind cover, reducing the chance of hitting to 20%
  • Also, the soldier is in turn under fire, reducing their effectiveness and thus reducing their chance of hitting to 5%.
  • So the soldier mathematically needs about 20 shots to hit the target which would equate to about 100 seconds of shooting before their target is hit.

But then there are other considerations. What if the soldier doing the shooting is part of a squad? Surely a squad would be more efficient at eliminating a target than a lone (non sniper) soldier that is isolated?


As much as I want to avoid it, projectiles are important. They take time to reach a target. It would be a strange sight in a game to see one unit fire at another and the target to get hit immediately. It would look like there was a disruption in the time-space continuum.

When dealing with straight line or artillery projectiles, the time for a projectile to reach a target can be calculated in advance; all the visuals are just cosmetic. Yet despite there being no need for collision detection because the start and end points of the projectile are known, this does complicate the timing of the combat engine. Unit A could fire at unit B while the projectile of Unit B is already in flight.

It’s as if the game is turn based but where each turn is 0.01 seconds long.

Attack step and damage resolution

Thankfully the attacking step and the resolving-of-damage step are independent of each other.

Attacking modifiers:

  • Range
  • How good a shot are the units? Are the weapons accurate?
  • What type of weapon? Small arms or a tank shell?
  • Are they currently under fire (suppressed)?

Damage resolution modifiers (NB: it takes distance / velocity of the projectile before this can be resolved)

  • Cover
  • Moving (will probably affect cover)
  • Armoured? Infantry with kevlar or tanks with steel all have an affect
  • Do they generally suck at keeping their head down (skill/experience level)
  • Are they being shot at from all sides? This is probably part of the suppression.

Note that suppression probably only affects a unit’s ability to see and shoot back rather than a likelihood of being hit.

First draft complete

And with that brain dump to a blog post, all my initial thoughts for a combat engine have been collated. There’s a good chance that many of these ideas will ultimately be flawed and will have to be modified but one has to start somewhere.

New Game Kick Off

It’s been a lethargic last 4 months from a personal project point of view. I dabbled in some web based languages just to scratch an itch but have come to the realisation that what I really want to do is get stuck into this map based war game. I’ve been thinking about it for years, years because time flies and suddenly I’m a lot older, more of the house is paid off and my face is not looking so 20 something any more (though strangely I’m the fittest I reckon I’ve ever been courtesy of me trying to overcompensate for being a desk-jockey during the day).

But I digress. The point of this hacked together post is to finally kick off my new game project which I’m probably going to call Failed State. I’m pretty confident that that name is in the clear for iOS and Android but I do notice that there is an open source project using the name. And here I was thinking I was being original.

Time: Enemy no. 1

All part time code warriors fight time. That cursed 7-8 hours of sleep required to maintain one’s sanity means that there is about 2 hours max per evening to hack something together and that’s on the proviso that the screen at work hasn’t sucked the soul of enthusiasm. Going to the gym frees the mind somewhat, although that sacrifices another 60 more valuable minutes.

And where am I at with Failed State? Well, I have a rough ‘world’ being rendered using pre-downloaded Open Street Maps data of Auckland. Cool huh? Not that that makes a game; I’m miles from a game and that’s why I need to devise a strategy. I need to know what the heck I’m doing and how to go about doing it.

Program like an author

You can’t edit what isn’t already written down.

I can’t remember the exact words but essentially the idea is that, as a writer, you just have to keep writing and writing despite the likelihood that what you’re writing could ultimately be edited out. The important part is that something existed to be edited in the first place. There’s no such thing as a perfect draft.

The same thing can be said for a game project and I’ve come to the realisation that that first pass is not cutting code; there’s a quicker way of actually getting to the end of that first draft.

What I need is drawings, mockups, ideas; I have to flesh out the entire scope. I have to actually make a game on paper first. I’d love to be writing that in the past tense but the reality is that despite having drawn a few things, I’m nowhere near the finish line. The process then raises even more questions about game play. Good. That means there is less chance of coding myself into a corner.

I’ll admit that I’ve been a little guilty of spending too much time doing my OSM map importer. Sure, it’s work that had to be done and understood but it’s a slow way to get to the finish line; a slow means of doing the first draft. That being said, it’s been great for show and tell with the guys at work. My sister says it’s too dark.

Auckland CBD (landscape)

Balsamiq Mockups

After paper sketches will probably be the digital equivalent. Balsamiq Mockups seems the perfect way to bring order to my mass of sketches. The good thing about Balsamiq is that the output still looks like a rough prototype; it will be my second draft.

Planning for AI

I haven’t even dared to think too far into this. I need to make some decisions trees or something. Ah… so much to do.

Everything else

Scope! What is the scale of the game? Individual units like Command & Conquer? Squads of infantry like World in Conflict? Grand strategy like Civilisation? Touch controls like Autumn Dynasty? Airstrikes? Reinforcements? Is there base building? Air units?

There’s so much to decide. I kind of know what I want but that’s why these paper mockups are so important. From them I can get a sense of scale and scope and how much work will be required to get to the end. Multiplayer? Doubt it. I’d love to finish something by October and I have to cut as much scope as I can to make an entertaining game.