Skirmish Sangin App – Post 5: Live Test/Skills/Close Combat

So had the first live fire test of the app – almost a perfect storm of new players, unfinished army lists and not much time to get a game in helped to make it a useful test. Overall the features seem to work well in game – its maybe a little clunky navigating around the app but I will soon have some help improving the overall design of the app.

I also forgot to factor in the effects of injuries on skill tests so I will be adding them to all the calculators.

See how I mentioned unfinished army lists? Well I added in a brand new calculator last night to help streamline the character creation process. Skill Calculator lets you enter in your new character’s experience level, any experience package you may have bought and their rolled body value and then spits out all the skill values you need to fill in your character sheet.


Close combat is also added. Select the attackers skill, special move, number of attackers and the defenders skill, hit the button and suddenly there is a hit percentage.


Its been a rather rapid set of updates over the past few weeks but it will slow down a little this week as I am a) on holiday b) refactoring the code to fix all the hacks I did to get the app working and c) moving the project around to make it less platform dependant (letting me export it to iOS and Android)

Speaking of platforms, one of the guys I was talking to doesn’t currently own a smartphone and was wondering about a web version to run on a laptop.

Skirmish Sangin App: Post 4 – Grenade/Morale

Morale and Grenade Calculators are now in. I also changed the main menu to be less expansive.

Much more to do!

Skirmish Sangin App: Post 3 – Shooting Calculator

Calculator 2 is now in. The calculators all share a very similar backend solution with different values for the modifiers and a starting value. The main difference is that the shooting skill is a custom starting value (rather than 100 for spotting). This is a simple text entry field with a some logic to limit input to between valid shooting skills.

There are a couple of modifiers that need tweaking. These are mainly modifiers you can have multiples of (such as height differences or additional enemies) and a need to find a smart way to easily let players set values

Next up: Morale and grenades and close combat and then 0.2 should be good for testing.

Skirmish Sangin App: Post 2 – Spotting Calculator

So I just got the first calculator in my app working. Spotting is the simplest of them – it has the most modifiers BUT has a default starting value that isn’t changed by skill.

Its taken me a little bit to get back into developing for Android (Activities, views and fragments, oh my) but Xamarin is making it a little easier. I do wish it had Visual Studio support in the indie version but I can live without it (just).

Next step is to make the shooting and morale calculators which should be based off the spotting calculator but with a few changes.

Skirmish Sangin App: Post 1 – Introduction

If you read my personal blog over at, you will know I’ve recently started playing Skirmish Sangin, a tabletop game. Its great fun and I really enjoy it but there are three aspects that I have been finding a little annoying.

1.  Army Lists- This game really needs you to have your character sheets printed off seeing as they need changing on a regular basis due to injuries. My usual google doc method doesn’t support this and as always, I prefer not to have to print and carry bits of paper around.

2.  Calculating skill/morale rolls – There are lots of modifiers every time you do many actions. The level of detail is great but its can lead to slow down while you frantically work out if your trooper is about to nail the bad guys.

3. Counters – The game is counter heavy. This can be reminded by downloading and printing some off but it does lead to the board being covered in pieces of paper. Useful for detail but can be a pain when moving figure around.

So to help solve this issue, I’ve started looking at an app for Android that can help to relieve some of these issues. The idea is that all the tools are a touch away, letting you tap away and speed up play. At the moment I have three features in mind:

  • Feature 1: Skill calculator – Designed to assist with midgame calculations, this is a simple set of tick boxes and number fields to let you feed in what values are need. At the press of a button, it spits out your percentage chance. The design is to have a calculator for morale, shooting and spotting.
  • Feature 2: Pocket List generation – Want to generate and store your army list on the go? This feature will let you create your list from a vast amount of options before saving it. The generator will initially only support soldiers but will add weapon teams, vehicles and off map assets. Special lists (such as the new Somali miltia from Maalintii Rangers) will also be added. Templates for specific formations are planned. Lists can be named and assigned to specific factions.
  • (Possible) Feature 3: Game Manager – Find yourself loosing track of who needs to move this combat phase? If your current list is in the app, then set it as active in game, tell it it the turn and it will feed who needs to move back who needs to move. The manager will also track injuries before politely informing you when someone has been killed. If you are playing, the current soldier will autopopulate the calculator’s with their basic stats making it even easier to perform the calculations. I’ll also investigate tracking the counters as well to make the calculators even better.

The app is being made in Xamarin in order to write using a familiar language and to reduce difficulties in porting to other mobile platforms. However, the initial aim (due to my current devices, current license and access to developer centres) is to focus on an Android release to begin with.

I’ll be writing more details on this as development goes on but I’m already a good way into writing the soldier generation code.

The GunFighter Engine – Post 3: Modifiers ,The Timeline and Turn Orders

Previously I mentioned the concept of modifiers. These are additional options that can be applied to standard actions, letting them be executed in different ways. The design behind this is to introduce a small range of standard actions for the player to learn the basics and then a huge number of combinations to allow much more advanced play, letting players dictate exactly how their squad should move around and act in according to what they have planned. Modifiers can affect both the effects of an action and its presentation of an action.

As mentioned previously, every action has a common set of three modifiers:

  • Stealth – Stealth focuses on actions that keep the attention away from your characters. Stealthy movement in general is slower and quieter and actions will take longer. Actions try to maintain original stances as much as possible in order to prevent detection. Shooting actions will only take place if a character
  • Normal – Normal is a character in combat’s normal movement and action. When interacting with something they do it at the normal speed.
  • Aggressive – In Aggressive mode, the characters focus is speed of movement and maintaining combat. Movement is the fastest while at the same time applying the most penalty to the actions (including aim). Aggressive lets characters continue to shoot while doing other actions (where it makes sense – characters using a ladder or any other action that requires two hands do not allow shooting) but it does slow them down.

So lets talk through some examples of other modifiers:

  • Sprint – Only used on an action that features movement, this modifier instructs the character to focus on getting to the next action as fast as possible. Its stops them from shooting during the next turn but does increase their movement speed.
  • Hold Fire – A character with this modifier enabled doesn’t shoot at all. Instead they will keep a bead on possible targets but not shoot until the modifier is removed. This is primarily used for stealthy work, but can also be used to gain a first shot advantage in an ambush situation.
  • Non-Lethal – Any offensive action with this character will aim to incapacitate or knock out the target. This will be done using the character’s currently equipped weapon or in close combat depending on the characters proximity to the target.

Modifiers rely a lot on the actions that are implemented into the game so I’ll be revealing more as I add more actions to the game. But the general idea is to give players the biggest toolbox of actions they can do.

The key idea tying all of theses actions together is the timeline. The best way to think about it is similar to Premiere Pro’s timeline, with each track representing a different member of your squad. Each action you place will appear as a dot on the timeline. By moving the dots around, you can match up actions to occur at the same time. In certain group actions (such as room clearing) the dots become linked together letting you easily see any combined actions taking place.

I need to do some more work on this system overall – the main thing for me is getting the UI system up and working. It needs to be simple to use but at the same time present a lot of information so I can see it being something that I need to get working early and then iterate on in order to get it working the best possible way.

The GunFighter Engine – Post 2: The Theory of the Actions System

I mention a few terms in the paragraph that will be standardised. For more information, look at the terms at the end of this post.

The current core of GunFighter is the idea of Actions. These form the base of the commands you give to your team and their depth and level of detail is one of the ideas that draws me to this project

A great way to think of it is similar to the idea of verbs in the old adventure games – every item could be interacted with in a selection of different ways. Actions is similar but rather than a set of generic terms, it goes off custom actions for each and every object type. This lets players interact with the world in a wide range of different ways, allowing a selection of playstyles to be implemented from combat focused team operations to very stealthy single character missions. However, another way to look at it is to think of games such as Metal Gear Solid 2. In that game, the environment and characters allowed a huge amount of interaction with it, letting you do things like see glass be shattered while hiding behind a bar or having soldiers shot in the arm be unable to radio for help. GunFighter aims to be a framework that lets players feel like they are an isometric camera hovering just over a game of Metal Gear or Payday 2 or even Rainbow Six, directing the actions of the troopers below.

To walkthrough the idea, I’ll start by looking at the humble door. Seeing as the game is based around the idea of clearing out buildings, doors play a pretty vital part and a fair amount of time will be spent opening, wrecking and stacking up on them.

To begin, nearly all objects share the same similar actions. These are:

  1. Walk to – the default action and included by default in many other actions. This moves the selected character to the location or the object’s side closest to the character
  2. Watch – This tells the character to look directly at an object or area. Its more of a flag than an action and is almost immediately moved past in the timeline. What it does do is focus a character’s aim in the direction of the watched object. When defending, watch is a good way to setup the action but also helps to focus your squads fire on different targets. More importantly, Watch is an interrupt action, a special type of action that lets players gain a little more control over their squads behaviour. When the game starts playing back the action currently in the timeline, an interrupt will pause execution of the timeline and let you add or adjust new orders based on new information gained by whatever casued the interupt to be triggered. When watching a door, this is when something happens to the door (normally it opening, but also if someone on the far side pops their head up to a windows or if the door suddenly leaves it hinges) letting the player setup a reaction. Orders given during an interrupt can not be previewed (a feature of the standard order giving (or Plan) phase) so players have to gamble on their effectiveness. In addition, some items (such as flashbangs and other disorientating devices) can prevent interrupts and stop them being triggered.
  3. Check – This is an action much more focused on intelligence gathering rather than actual aggression. Check lets players gain more information on their environment. On a door, it lets players check if a door is locked, which way it swings, where the hinges are and if they can hear anything beyond it. Eventually, characters with different skillsets will notice greater details –  for example, a character with demolitions can spot if the door has been set up for demolitions. You can check all entities – checking an injured character will tell you how they are injured while checking a live enemy with give you a quick rundown of their equipment, helping you to assist in fighting them.

In addition to the common actions, doors also have a large number of specific actions. I haven’t finished the full list

  1. Open – Walk up to door, open door, move through. This is a prime case for where another system comes into play. Modifiers is a similar system to stances in an RPG, letting you adjust common actions in a very slight way. I’ll write more details on this in a later post but for now, here is a small example. The overall modifier is in three parts:
    1. Stealth – Produces the lowest noise, most focused on letting your character sneak around. When using this with a door, your character will slowly open it, pushing the weapon through in front of them.
    2. Normal – This is a standard combat pace, not creating too much noise. When using a door in this style, the character will simply open it,
    3. Aggression – This is the loudest you can get but the actions are focused on causing the most damage and shock. When using this with a door, the character kicks it open (and potentially off its hinges) with a chance and damaging someone behind it
  2. Trap – Characters will be able to arm themselves with a selection of gear during the various missions and in some cases will need to stop bad guys from coming through a door. Trap lets you place an explosive or something similar in place to dissuade enemies. A potential idea is to also allow barricading or blocking with other, less exploding items but that is something to be tested at a later time.
  3. Stack – The engine’s focus is on team operations and a primary feature to facilitate this is a system focused on team operations. I’ll write up more about this later (he said for the 10,00th time) but stack is an action that either starts a stack around a position or joins an existing one. Stacks often lead to the next item…
  4. Breach – Breach combines actions like throwing grenades and moving through doors into one. With breach, you will be able to specify the factors around the breach (what is your breaching tool, are you using grenades, where in the room are you going to move to). The exact mechanics of this are still being worked out but this is a quite advanced feature that will be coming soon
  5. Look through – This is another Interrupt but rather than being a passive one (you set it off and it gets triggered later) it is an actual order much like move or open. Look through lets you see into a locked room via the door – again this is a place for modifiers, letting you specify if you look through the lock (restricted fov but little/no chance of being spotted), look under using a mirror (larger field of view but requires some setup) or look through any windows in the door (you’re getting spotted if anyone glances at the door but you can see pretty much the entire room). Look through is perhaps best thought of as preparation for a breach, letting you see the layout of the interior before you choose just how to chop your way through a door.

This system sounds rather complex and yes, it is. The core focus of the system is to make it that you can play the framework using almost any style of soldier and have a selection of ways within that to succeed. I’m currently working using an idea that both Rob Pardo and Chris Hecker stick to which is Make the deep and hardcore game first, and make it accessible later in development, a.k.a. Depth First, Accessibility Later”. With this being a spare time project, I’m not required to release anything anytime soon and so can take great delight in creating a super detailed system. However, I already have a few ideas how to handle this for newer players, using a cut down list or generating a selection of the most used

In practical implementation, I’ve managed to get the base entity class set up containing within it an action list. You can assign each entity a type (such as character, door, cover etc). The next step is to prototype the UI linked to it, making it easy to see all the available actions. The aim is to have this showable before Christmas, letting a player mouse round a room and see the various actions available to them.

To conclude, a quick primer on GunFighters’s Terminology so far.

  1. Action – The building blocks of the game’s systems
  2. Action List – A list of actions that a character can do to an entity. These are stored on the entity
  3. Orders – The commands given by the player during the plan phase or after an interrupt is triggered and then put into the timeline
  4. Timeline – A combined view of all the orders a players has given to their characters. This is designed to let players more carefully link and synchronise orders
  5. Interrupt – Special actions that pause the game and lets players add new orders to the timeline based on the events that trigger the interrupt
  6. Entity – A object that has an action list and can be interacted with. These range from soldiers and civilians to desks, doors and even walls
  7. Character – A special entity that can do actions. Action lists of other entities will be adjusted depending on the characters team (a friendly character is interacted in a different way to your enemy).
  8. Squad – The set of characters that players controls directly
  9. Modifiers – Overall rules that can be set on a character to adjust the actions they do. The most common one is their overall stance (Stealth, Normal, Aggression). This will be the focus of the next blog post


The GunFighter Engine – Post 1: Introduction

Well, a couple of things.

  • The restart slowed down a little more than I originally planned. Work has been bedlam (but oh so much fun) and has been teaching me a lot. I have also had a busy few weekends visiting friends and such so development time was cut down a huge amount
  • A certain major games company has grabbed the name I have been pseudo developing under to go make a TF2 alike with. Their game looks good and as I hadn’t really done much in terms of development, a name change is probably one of the most minor things I have to do at this point.
  • I’m adjusting my method of development. Looking down the list of game ideas I’d like to develop, many of them would benefit from the combat system and basic tech I had in mind for what was Overwatch. For this reason, I’ve decided that rather than trying to focus on one game, I should instead make a framework to be utilised across multiple games.

This framework (which I’ve named GunFighter) will provide the basic combat system for a tactical turn based strategy game, with a particular focus on urban environments. It has three aims:

  1. Provide common elements that can be reused with different sets of content and additional mechanics
  2. Be extendable and modular – Future games will add new features to the core framework therefore it must be easy to add additional part.
  3. Take advantage of Unity’s core features (such as the component system) and focus on keeping the performance of the basic layer high.

So what does this mean practically?

  1. Within the next 12 months I will create a basic prototype level showing the core framework in action
  2. The framework contains support for the following features
    1. The entity and action list systems
    2. The queueing and execution of orders
    3. A combat system focused on close to medium range combat using modern weapons and equipment
    4. The various additional utility systems required to support the main body of the codebase
  3. I will be doing a weekly blog post to chart my progress and show off any practical changes in either Unity or in video/GIF format

Thats the plan, more coming next week when I will talk the theory about the action list system and then go into greater details about what has been made so far.


Overwatch – Update 6: Knocking It Flat

So just under a week ago, I sat down with a slightly updated version of the prototype floating around (with some barebones animation and UI added to it). At this point, its still pretty janky but playing around with it I realised that I was now happy to carry it on.

So the first thing I did was push everything I’ve done to one side.

Why? Well my time at work has made me think a little more about the structure of the engine behind the game. Unity can lull you into a false sense of security, giving you a terrible structure if you don’t plan for it. So my number one goal is to get a good structure setup.

One thing I’m working on first is getting the UI and environmental stuff tied in at the base. Its going to be a key part of the game with a focus on making even mundane items like desks and tables interactive, letting the player’s merc use the environment for both mission objectives (by looking for intel) or for defence.

I’ve also done some more design work – primarily focused around how the characters are setup, such as classes and weapons. I’ve also begun looking at the possible setup and layout of the main focus of the game, the rogue-lite campaign.

More stuff coming soon although I am super busy at work.

Overwatch – Update 5: Progress and Investigation

So first up, big news. I have been employed by Big Bit in Brighton as a programmer (my first day was monday) and so my own personal stuff will be slowing down a little bit in terms of the hours spent on it. On the other hand, I am learning a lot more so hopefully it should balance out? I don’t know.

That said, I am still hard at work on Overwatch. The main part is sorting out the paper design – less to focus development and more to get ideas down, to be judged, analysed and then implemented or tossed out. I’ve also been working on various formulas relating to actions, such as shooting, in order to make my life easier.

Practically, the basic barebones structure of tactical mode is near enough done. Shooting formula is now in and orders know onto what object they are palced. This will be used to let the player put many different order types down, letting them breach walls or assist allies.

The next two tasks are to a) refactor my code and b) add in the UI elements. I’ve been doing a lot of work with 4.6’s UI to learn it while on another smaller project and so hope to roll that knowledge back in. As for the other task, the main culprits are the character details and the order details. Both of these are currently groups of interlocking components – I’ll be moving them to a single partial class, removing the need for parentrefs and other structure within them. There will need to be a few changes but it should make my job easier down the line.

There are also three features I’d like to speculatively work on which relate in some way to the tactical game, but may play a bigger part in a strategic or campaign layer which focuses on the evolving and customisation of your team of mercs.

  1. Character customisation: Even if it doesn’t fit 100% into the first major version, I really want to get the modular characters nailed down to make it easier down the road. I have a few ideas I’d like to try – the main one is to rig and set up a mesh to be used as the base before generating a replacement from parts, merging them into a single mesh and swapping it out. I need to first get a character and its parts together so I can try it out.
  2. Saving and loading data: This is much more of a longer task and is split into sections. I need to be able to save custom mercs, save a character progress and possibly save out replays of missions to let you watch a playback of each one.
  3. Recap feature: I’ve been watching the Giant Bomb guys play Metal Gear. One of the things I really love is the popup it gives you at the start to tell you the plot so far and keeping the mind fresh as to what the next objective is. The last point is something I really needed when I came back to XCOM – jumping into a partially complete campaign can be a little disorientating. The first version will be text based but ideally it could generate a short animatic, using precanned animations to show off some combat and plot scenes.
  4. Memory and Trait system: Inspired in part by the madness of Clockwork Empires and also some of the scenes in Spec Ops (“YOU LEFT ME TO DIE”), I really want to look into the idea of the mercs having memories that affect them. Important events such as helicopter crashes or exposure to certain effects such as flames, could lead to mercs loosing effectiveness or refusing to go on certain missions. Worse, not recovering injured or mortally wounded personnel will wear heavy on your troops but it can also cause a slightly greater issue. On a more positive note, mercs that team up repeatedly will begin to gain a bro bonus, improving their effectiveness. There are plenty of directions this could go so only time will tell

These four ideas are currently on separate branches, with the idea to prototype them before folding into the main branch.

Overall, the project is progressing slowly but surely.