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.

Failed State Progress (or lack thereof)

It’s been over 3 months since the last time I posted about something Failed State related. I’ve rambled on about a bunch of other topics but nothing that actually explains away anything constructive.

I’ve also been overseas for four weeks to have a long needed adventure. Now that I’ve gotten the travel bug shaken out of the system a bit, it’s time to get back into the coding projects. Did I miss these projects while overseas? Not really because I having too much fun to care too much about stuff outside of what I was in the midst of.

I have to actually refer to my version control history to figure out exactly where all that time went. It seems that this has happened…

  • Oh, my tanks and infantry units fire projectiles now. That’s kind of a big deal.
  • Cool, sound effects. That happened too. I sourced the audio from combat footage in Afghanistan and some M1A1s firing on a weapons range.
  • A unit (the interactive element on the screen that could be a tank or whatever) now comprises of “entities”, e.g. a squad of infantry could have 5 soldiers/entities.
  • Added handling of when and whether one unit can attack anther unit. e.g. if a target goes out of line of sight, the attacker eventually cancels the engagement.
  • The entities of a squad all have their own firing timings and can be individually wounded, incapacitated or KIA. Because the game world is too high level to see and individual entity, I show them as little health-like icons above the unit icon.
  • Added some rotation to the camera as it zooms out so that as the altitude increases, the angle becomes more satellite-like. Conversely, as you zoom in the view is more 3D.
  • Ah, yes. My great fun and games with the Unity A* library I’m using. I had to make certain areas traversable for infantry but not for vehicles, but the heuristic had to add a penalty when traversing buildings because it’s slower than taking open streets. I had great fun with this because of various confusions not just with reading the API but because I even forgot what my own code’s logic was doing. Whoops.
  • Better colouring of building areas when they’re occupied but units. It cool to see the map light up with team colours as it’s being taken over by the player.

So, there has been progress despite the significant number of other things I’ve had going on lately, which is a relief. Unfortunately none of those things result in spectacular screen shots; this is the best I could do.

Upon making this screenshot I remembered the biggest oversight of the moment; shooting from and into buildings. Because of the line of sight intercepting with buildings, it’s impossible for one unit to shoot from one building into another building. In fact, you can’t even shoot from within a building at an enemy unit in the street because of the line of sight collisions. Whoops. This is going to require some work.

Motivation Molifiers

There exists many opportunities during application development where one’s self esteem takes a hit. One starts to question if they’re creating their app in the best possible way or even worse, why they are even bothering to create it at all. It’s made worse by having a day job that sometimes saps the life out of you to the point where you dare not look at a screen any more, although usually that can be remedied by some vigorous post-work exercise.

The internet is full of clever people

The internet is the Cave of Wonders holding fast amounts of valuable knowledge; there’s so much there that you can’t possibly absorb it all. Likewise there are huge amounts of amazing projects for us to admire but a lot of the time they serve to show us how much further away our own projects are from completion.

I’m continually trying to brush away those thoughts, continually telling myself my little mantra of “do a little bit every day, then it will be done” but alas, there will be something that I stumble across on the internet that gives me pause.

Here are some of the themes that stifle my enthusiasm.

Mapping tools, apps, visualisations and libraries

Mapbox GL, although not a game, has done an amazing job of making OpenStreetMaps data look amazing.

Then there are the Geoweb3d guys that take OSM data and make amazing visualisations as demonstrated in this youtube video.

More closer to what I’m doing, there’s this guy’s awesome OSM/terrain data render inside Unity. Still not a game but it looks amazing.

Any game that has a map-like feature

Even today I stumbled across a gameplay video which had an awesome looking map feature. Homefront 2‘s main protagonist can use a mobile phone with a map feature that is used to coordinate attacks (and things). Then there is Watch Dogs‘ complementary iOS game that uses a fantastic map interface and also Battlefield 4’s Commander Mode. That Commander Mode really makes me jealous because it uses abstract map styling and incorporates game play like airstrikes and airdrops.

Other Strategy games

Did you know that Slitherine/Matrix are working on a new 3D Close Combat title? Games from the Close Combat series are some of my most favourite games of all time and yes, I’m trying to rip off some aspects of the game play. Seeing them make this new title makes me a little envious that they can take all the game logic of their very mature (2D) series and re-write it into a new piece of art.

Any Indie game with an amazing art style

It doesn’t have to be Indie but the downside of following the likes of TouchArcade and PocketTactics is that you see some fantastic looking titles. When I say looking I mean in art style rather than game play. I have a looong way to go before I should afford the luxury of messing with art because the gameplay really needs to come first. Eventually that day will come though and I’ll need to make something look amazing or else, seriously, who’s going to give a damn.


So what does motivate me? Dare I say it, I really want to create dramatised versions of current (or very recent) world conflicts. Putin is being cheeky in Ukraine and the Islamic Front are doing a Genghis Khan through the Middle East. Imagine being able to brings aspects of those conflicts in to a game. A bit morbid perhaps.

Better pinch-to-zoom

The horrific pinch-to-zoom implementation that I had in my code up until recently was interfering with user testing. When I say user testing, I really mean that I show the game to my work colleagues and get feedback on what is or isn’t working.

The problem is that I had to apologise all the time about the crappy camera pan and zoom which was annoyingly jerky and nothing like Google or Apple maps.

I needed to find a solution and in the process found some posts like this and this, both of which followed my own naive approach to pinch zoom, i.e. useless for zoom.

Field of View

One of the things that really confused me was that often people were changing the field of view in order to achieve the zoom. I thought moving the camera closer or further away made more sense but maybe that’s because I don’t use SLR cameras very often (I’m no photographer). That’s essentially what changing of the FOV mimics; the camera stays still and the lens zooms in/out.

Perhaps I figured that if a camera pan is achieved by moving the camera then a camera zoom would also move the camera. After all, I want to ‘fly’ the camera around the scene. Plus I didn’t actually want to mess with the FOV because it puts distortion on the 3D world (it at least changes it).

It was educational though, even if what people said on forums created some confusion. It turns out that a camera dolly has nothing to do with a dolly zoom.

Never immediate, always transitioning

Finally I found a gem. The author wasn’t even writing about camera zoom but rather about linear interpolation; I can’t even remember how I came to be looking into LERP.

Ignoring his grammar, the author’s conclusion struck a chord…

In general, is a fairly common mistake in beginner videogame developers that elements in the games are either in position A or B. For us, programmers, is much easier the world were things are never in a “travelling” or “transition” status. [sic] – Juan Gomez

The jerkiness of my camera zoom was because I was moving the camera immediately from A to B rather than letting the update loop transition the camera to the new position. Position B needed to be a requested destination to which the camera moved toward every clock tick. The LERP function smoothed this transition further because it can be set to accelerate away from A and decelerates into B.

And with that, another problem was solved. Yay.

Line of Sight

Typically, my foray into trying to detect line of sight using 2D objects turned into a misadventure. It turns out that Unity only does 2D in the x, y plane and this matters because my entire world has Up in the Y axis and thus my entire world is rendered along the x, z plane.

But hope was not lost, it turns out that for all my GameObjects that needed some 2D collision checks but already had a 3D collision mesh added to it, I could attach a child GameObject and then add a PolygoneCollider2D to that (you can’t have 2D and 3D collision meshes attached to the same GameObject).

The result (if you look at the Scene view) is a perpendicular world where all the 2D collision polygons are visible along the x, y plane. It doesn’t matter though because after some Vector3 to Vector2 conversions are done, a 2D Raycast works just fine and the collisions are detected. The Vector2 can then be converted back to Vector3 and then used for whatever purpose that was intended. Phew. Why is this important? Well, I got a line of sight indicator working for when making a unit target something and I figured 2D checks would be cheaper to calculate. Here’s a screenshot.

Marvel at my awesome placeholder UI (and just ignore the fact that some tanks have been randomly placed in the water).

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.

Culling, normals and face winding

The internet is an amazing resource for programmers, especially when using a language or platform that has a massive community behind it. It’s almost guaranteed that someone has experienced your current problem and found a solution to it, a solution that’s shared on a forum post or mailing list somewhere. Unity3D is one such platform.

Unfortunately though, if you don’t use the correct search terms you can end up going in circles for a while and such a thing happened to me last week when trying to extrude my OSM buildings into 3D. I kept telling myself that it was not important for gameplay (and it isn’t) but I was so curious to see what it looked like that I’ve spent just over a weeks worth of free time trying to implement it.

Inevitably trying something new (or even doing something that was done ages ago but is now being reimplemented in some new manifestation) results in all sorts of problems, puzzles, frustrations, mindless hacking and misinterpretations.

Mesh extrusion should be easy, right? Just duplicate the initial mesh, offset it then create new triangles between the two layers to create the walls?


Fun with normals

It turns out that doing a ‘sandwich’ style join between two layers of the 2D mesh (one at a y offset to the other) was a bad idea because of the way shading (from lighting) is done in the grahics pipeline. If there is only one normal per vertex, the buildings would look like they have rounded edges instead of flat shaded (hard) edges. What’s required is to have three copies of a vertex in order to hold the three normals that represent each face. Consider a cube. There aren’t 8 vertices, there are really 24 vertices with 24 corresponding normals (3 per corner).

I had to break the code down into its most basic form and try an extrude just a box into a cube so that I could figure out where my code was breaking.

Fun with normals part 2

Oh, so Unity uses a left-hand coordinate system? That right hand rule for cross product I learnt at Uni and is all over the internet doesn’t actually apply here? Grrr. If I’d been more diligent I’d have noticed that the Unity3D docs clearly state the use of left-hand rule when using Vector3.Cross but it took a while to ‘get it’. My Vector3 normal = Vector3.Cross(b-a, d-a).normalized; should have been Vector3 normal = Vector3.Cross(d-a, b-a).normalized; (I didn’t want to multiply by -1).

With the normals facing the wrong way, the walls would look dark despite the intensity of the lighting.

Fun with normals and culling

Upon investigating the ‘why are the walls dark’ issue, I experimented with some Unity3D provided shaders, but oh no!

Why oh why are some of the walls of my buildings being culled out?! The normals are definitely outward facing!

I stumbled across this forum post (see, someone had a similar issue). Normals are only used for shading and colour, the triangle winding order determines what triangles are back facing.

*sigh* I felt like I’d had that very issue before when my collision meshes didn’t work; the triangles had to be drawn with CCW winding instead of CW (or was it vice versa) for the raycasts to ‘hit’. Anyway, duh! I felt stupid for wasting an evening.

Fun with normals and culling part 2

But holy crap! It still didn’t work! Some of the buildings had walls disappearing but others were fine.

Think, think…

Oh, the OSM data has some polygons defined in CCW order and others in CW order. I had to make them use the same ordering. More searching and I found this. Yay for pseudo code. It works. Ship it.

And now for a screenshot.

Oh look, I’ve got placeholder art from Shenandoah Studio’s Battle of the Bulge; I hope they don’t mind. Their games looks amazing.