• Pizzazz 

    I watched a video last week on adding Pizzazz to your game early. It’s not polish, it’s not juice its just.. stuff to make the game look and feel better than wherever it is in development. It’s used to rally morale for the team or to make it easier to show the game off to publishers earlier. 

    I’d also said for the past three weeks that next week I’ll try to work on some graphical stuff but.. that next week never came. So I set aside some time this week to do it and by george it’s nice.

    I kicked off the week working on the trait systems for units. The stuff that allows them to have latent abilities (including eventually, upgrades and equipment) It’s the kind of thing you’d expect from something like Magic The Gathering’s keyword system, or more familiarly, the special rules system in Kings of War. Anyway, it’s functional.. more or less, but not very extensible, also… poorly written. 

    I think I’m going to have to come back to a lot of these systems before the public alpha or beta milestones. Probably have to do a whole rewrite of how I’m building units to follow something more like the system described by Brian Bucklew in his talk on entity component systems. But for now, my crappy Frankenstein system does the job for now.

    As for the rest of the week, well… they say a picture is worth a thousand words, so here’s an essay.

    At the start of the week:

    At the end of the week:

    It’s nowhere even remotely close to being ready, but it’s looking and feeling more like a real game now. 

    I also spent a lot of time this week just making things a little more responsive, and adding a little affordance wherever I could. For instance, today, I added a little function to the camera to auto move to the current selected unit. Nothing groundbreaking, just little bits and bobs that add up over time to make a game feel more like a real game

    I can’t tell you how much doing stuff like this really makes the game feel more positive in my mind. 

    At this rate I should be on track for a good set of more public splashy posts in the next month or so, and honestly, I can’t wait.


    Tasks completed:


    • Move debug bools into their own config file. Ensure they’re reset properly on builds. (GameDataEditor values)

    • Show arcs on unit when selected


    • Tons of graphics work


    • Game UI: Unit Card View

    • Move all magic strings into LocalisableStrings

    • Graphics work


    • Unit Traits

    • Trait: Fast

    • Trait: Exceptional

    • Trait: Cause Fear

    • Trait: Armour Piercing

    • Trait: Regen

    • Trait: Aura

    • Trait: Leadership


    • Look at implementing nsubstitute via Unity package

    • Remove all EventRaised Functions

    • Investigate event-only, No dependency  architecture.

    • Build New Sprint

    Bugs squashed

    • Units always rotate in one direction when executing a pivot order (meaning they flip around 360 sometimes)

    • Unit model heights aren’t properly set on load

    • Build crashes on iOS … but just on iPhone?

    • Fadeout from pre-game shouldn’t happen until it’s current player’s deploy.

    • Hide unit arcs during deployment / on leaders

    • Camera is panning when pointer is over UI

    • Exceptions firing from localisation

  • Interloper 1.7 WIP

    This week has been primarily focussed on work for interloper. It’s always a little strange going back to a previous project after working on a newer shinier one. You get accustomed to doing things using the improved processes, and using newer, more improved features.

    I kicked off the week with some marketing work, building out some new screenshots for the App Store page. What started out as a chore eventually became fun. I enjoyed trying to do something a little different, a little more splashy compared to the original screenshots (which on retrospect are awful) I also set them up in an A:B test to see if they perform any better than the originals, which to no surprise seems to be the case so far.

    After that I dove right back in where I last left off building out the new “ship customisation” system. This first step of that process is effectively a b-skin for each of the ships in the game, each with an associated unlock requirement. Think something like achievements. Some will be clearly telegraphed, others will be more subtle.

    I really struggled to get back into the ship designs. While I enjoy making models and designs, I think the spark for working on Interloper just isn’t there right now. Four years of work non stop will do that to you. I wouldn’t call it crunch, but when sandwiched into being a full time dad for a good couple months there, and then dealing with some mental health stuff, I don’t particularly have much in the way of a good time. Thats not to say I disliked working on Interloper during that period, but its more just.. I’m a bit burned out on the project.

    Anyway, all that said, the new feature is shaping up nicely. I even managed to push a build up to TestFlight, so that’s good! It’s buggy as hell, but it should give a good taste for what the end product will look like.

    Also spent a fair amount of time this week thinking about the future of Interloper, how I intend to keep maintaining it and what I plan on doing for new features going forward. Don’t really have anything conclusive to say on that, but.. I’ve thought about it!

    Tasks completed:


    • Cosmetics: B-Skin- Bomber
    • Cosmetics: B-Skin- Interceptor
    • Cosmetics: B-Skin- Sabre


    • Cosmetics: B-Skin- Bomber
    • Write out basic descriptions and draw up concepts for remaining cosmetics.


    • Continue reworking hangar
    • Hangar Photo mode button


    • Build multiple product pages
    • Update App store screenshots.
    • Change support emails and whatnot to support@anchorite.com on AppStore connect
    • Migrate tasks and info from Notion
    • Cosmetics: Build UI for Post-game unlock view
    • Remove Roadmap button
    • Complete UI work for Cosmetics in Hangar

    Bugs squashed

    • none this week.

  • Reduce and Refactor 

    This week was a bit of a mess. At the end of last week the game was in an ok position but still not fully working. The newly implemented reducer was definitely doing its job but only a few things had been migrated across to it. 

    I spent Monday doing admin stuff, cleaning up bugs and generally making the project a little smoother. Tuesday focussed on getting some new features in, such as dice modifiers (and a general rework to the dice class), retools and then finishing off dependent tasks like abilities and unit psychology.

    But then.. Disaster! Turns out that the game would crumble pretty quickly on device. 

    The issue was down to the way I’d architected the multiplayer classes, LocalMultiplayer and GameKitMultiplayer. For testing (and eventually for local play) I’d built a parallel version of GameKitMultiplayer that just works on my dev machine, but over time the two classes drifted in terms of functionality, meaning that whilst everything worked fine in my editor, nothing worked on device. The reason for this drift was effectively because they tried to manage too much. From handling local player info, to talking directly to the game controller.

    Anyway I made the decision to completely rewrite these classes into small, clean interface implementations. This should ensure their functionality going forward, and make them much easier to debug. 

    That process took the rest of the week. But at least the game is now singing along nicely in both the editor and on devices.  

    I also spent a bunch of time thinking about how I’ll end up monetising Charge, and a whole set of time building out tasks for the lead up to a public alpha (games kinda need some graphics, sounds and UI) 

    I know I said this last week, but I think next week I’ll work on some more fun stuff and less systems-y stuff.

    Tasks completed:


    • Look into the Project Auditor tool
    • First pass at Unit Traits systems


    • Rework broken tests 
    • Complete switch over to Reducer Pattern 
    • Reducer: Write Tests 
    • Reducer: Identify further events that need to be transmitted 
    • Re-implement UI Lobby for local games


    • Before hooking the new multiplayer handlers up to the game, test them out in both dev and prod environments
    • Unit distance for orders is calculated on leaderpoint. Suggest using corners instead.
    • Turn on TDD Build guards again


    • Run another playtest of reducer functionality, both in editor and on device 
    • Unit Psychology 
    • Reducer: Implement ability logging
    • Unit Abilities 
    • Rerolls & Dice Modifiers 
    • Change initial deployment to be one big event. 


    • Write up Monetisation strategy for Charge
    • Line up graphical tasks for Charge 
    • Line up audio tasks for charge 
    • Line up UI design work for charge 

    Bugs squashed

    • Archers attempted to fire, but were exhausted on first try.
    • Game state isn’t properly rebuilding across player turns.
    • Significant issues with turn replays / board state
    • Nullref on game load / create on Device
    • Nullref on game load after turn one
    • Null ref on loading existing game (iOS)’
    • Sometimes the “Complete deployment” button doesn’t properly show (iOS)
    • Local multiplayer breaks on setting camera position
    •   Player two can once more see player one’s units during deployment
    • RaiseGameLoaded and RaiseDataLoadeda are firing too often inside GameController
    • Local games. Quitting then attempting to load again causes issues
    • KeyNotFoundException: Dependencies keep firing between editor game play runs.
    • Loading a match results in units spawning at 000
    • Localmultiplayer doesn’t properly mirror gamekit multiplayer in the create-game-flow, leading to inconsistencies between the two.
    • Camera not swtiching under new multiplayer systems
    • Player 2, iOS, After sending complete deployment, Deployment zones are still visible
    • terrain doesn’t sync on iOS?
    • Save games need to be cleared properly on iOS
    • New system to cast abilities via order has broken all other abilities aside from Attack

  • Sprint Reviews

    This is the first in the series of blog posts detailing how I’m going with Charge.

    So far I’ve got most of the core gameplay systems up and running. There’s turns, each player has an army, you can do all the core orders for each unit, movement, pivots, charges, using abilities, etc etc.

    The game isn’t much to look at right now, but I’m thinking that once the core systems are implemented I’ll move onto making it less.. placeholder-y. Then the screenshots will come thick and fast.

    I hit a roadblock last week where the data that was being sent between turns (aka, the entire game state and history) was too big for Apple’s GameKit turn based systems. I figured I’d hit this point eventually, but not quite so soon. So this post picks up where I left off last week trying to implement the reducer pattern roughly inspired by this blog series:

    Making a turn-based multiplayer game in Rust – What’s a turn-based game anyway? (part 1/3)

    Long story short, we just send the actions for the previous turn, and then rebuild the game state locally.

    It’s more or less working at this point minus a couple missing features and a nasty bug with the Unity Editor itself. I’ll figure that out sooner or later.

    It’s also a roaring success for transmission size. Back down to under 10% of the budget.

    I’ve got some concerns about how saving the game state to iCloud is going to perform, I’ll have to keep an eye on those sizes, but at least 1mb is bigger than 64kb.

    I genuinely think it’s all coming together pretty well so far. Sure it’s taking forever, but I think I’m getting better at programming whilst doing this, so fingers crossed it doesn’t all fall over in a shit heap.

    On the productivity front, I switched out Notion for Things 3. Had a couple days where the internet was basically dead and I couldn’t get onto Notion to see what I had to do next. Decided I wanted something with a little more purpose, a little more offline and Things definitely seems more of both.

    Next week I hope to finish the work on the reducer pattern and get back into regular dev. Might even treat myself and make some more models or work on effects.

    Tasks completed:

    • Playtest Reducer pattern some more.
    • Reducer Event: Dice Results
    • Reducer Events: Combat results
    • Attacks aren’t deterministic, their results occur upon consumption.
    • Reducer Events: Morale Results and Psych changes
    • Change auto-deployment so that it intersperses leaders amongst regiments
    • Orders: advanced
    • Unit Controller Status Checks

    • Anything that is consumed by the reducer should be logged to logger system.
    • Split order results into individual result-events
    • Look into building a better way of divvying up tasks into sprints

    • Switch bug reporter over to Things
    • Research Astra Fellowships
    • Add Deselect button to Unit UI
    • Don’t store full unit data in game data
    • Replace existing c# events with messenger service
    • Camera FOV gets wonky sometimes with an NaN error
    • Change gamplay transmission to be orders only
    • Unit Exhaustion

    Bugs squashed
    • Using abilities causes a nullreff
    • Attacks just fall over. The event doesn’t actually fire.
    • Order results are busted completely lol.
    • Orders get spammed / looped somehow
    • Missing Ref: UnitUI.ShowAbilityRadius
    • Player one can see Player Two’s army on deploy
    • Individuals are hard to select
    • Cannot pivot a unit unless dragging from centre
    • Unit names incorrect in viewer
    • Order events only send state, not dice rolls or logs
    • Local games camera always starts at player one
    • Turns aren’t sending on Device
    • Load game crashes after a game has already previously been loaded

  • Command and Control

    One of the elements that was prevalent in older tabletop games was a concept of leaders directly.. well.. leading their units. The main title I keep thinking back to is Napoleons Battles. In that, a unit can only be ordered if a leader model was within range, else they’d either hold or at best, return fire. I’d played many games with this mechanic and always thought it gave a sense of value to the leader units beyond their direct combat utility.

    Modern titles reduce heroes and leaders down to a morale bonus at best and at worst, mostly redundant. To me this feels like a shame and a missed opportunity. The leader, as part of the hobby is going to be a centrepiece to the army, and as part of the gameplay should feel like the core gear that an army turns on.

    In Charge then, my initial approach is to make them both a powerful unit and a centrepiece of an army. Leaders begin each turn with an order pool. They may issue any order to a unit within their radius, including themselves and other leaders. They also may function as a bonus to morale checks (depending on the army list) and / or also function as a powerful hero unit. In this sense I feel like they’ll act as directorial units. A powerful melee hero leader with a small pool of orders and limited range will naturally pair well with cavalry or shock troops, where a more strategic leader will offer options to a wider set of units..

    This also creates opportunities for vulnerability within an army, as a unit without orders cannot do much. That aforementioned hero unit might be killed early in the match, opening up opportunities for a counterattack.

    There’s a ton of edge cases this opens up, like losing all leaders early on, or not having enough orders to cover the army, but I think that the overall opportunities for interesting tabletop storytelling outweighs the potential issues. I also feel like modern techniques for handling individuals lend themselves nicely to keeping them alive long enough to be effective.

    All this is to say I’m still exploring the subject within the game, but I do feel that it’ll feature heavily.

  • Up next for Anchorite

    So for the past few months I’ve been primarily working on my next title. Interloper has done way better than I could’ve expected, but after two and a bit years I think it’s time to work on something new.

    I’ve built a bunch of prototypes over the past year or so, every now and then taking the time to create something small, or some tiny slice of a larger game. From a spiritual sequel to Unstoppable, to some experiments with smaller game mechanics to taking some new swings at old ideas I’ve had running around, none of them stuck.

    That is until Apple released the Unity Plugins at WWDC last year. There’s a lot of good API’s exposed via these plugins, including some cool audio stuff, a neato input alternative, but the one that stood out to me was GameKit, particularly Turn Based Games.

    I’m a long time tabletop wargamer. I was brought up on the likes of Operation Warboard, Squad Leader, Napoleons Battles and then of course… Warhammer. My first miniature was a 2nd edition Space Marine Dreadnaught, but the first army I’d fully painted was a 5th edition Warhammer Fantasy Brettonian army. This is where my love for what became the genre of “Rank and Flank” games began. Growing up through my teenage years I’d assembled both the aforementioned Brettonian army, and then later a Skaven army. Building the miniatures, painting the ranks of rats, trying out the odd combinations of the army lists, winning and losing games were all some of the most formative moments of my life. I was extremely fortunate to have an incredibly supportive family with this hobby. My Dad, Brother, Stepdad and Uncle were all just as into the game as I was. Most weekends we’d have a game of some kind.

    This is all to say, I’ve spent the past twenty years forming opinions on tabletop wargames. That through my time as a game developer I’ve felt that I can bring something to .. uh… the table.

    Enter: CHARGE (working title) a tabletop wargame that spans both digital and physical versions.

    The core conceit is that it should get to the meat of what makes a rank and flank interesting quickly. It’ll bring back some mechanics that’ve been lost to time, and it’ll simultaneously be a multiplayer digital title (initially available on apple platforms) and a rules set for physical tabletop play. (there’s a stretch goal of adapting the digital models as printable files for 3D printers, separately available on something like MyMiniFactory)

    This is a bit of an ambitious project (why would I make games if they weren’t ambitious) and I expect it’s going to take a while to build, and I’m hoping to chronicle it’s development here.

  • Introductions

    Hey, you’ve stumbled on this little blog.

    I’ll be posting technical bits and bobs on the games I’m working on at any given time. Some will be useful, some will be absolutely rubbish.

    Lets see where this goes, shall we?