So this week I also wanted to have a quick chat about the foundational tech that Charge is built upon. Quick history lesson: This isn’t my first stab at this game. In fact it’s more like my… fifth attempt? Its a game I’ve wanted to build for almost as long as I’ve been working in the games industry. Getting the core gameplay has been relatively easy each time, moving units around, rolling dice, and all that jazz, pretty simple stuff. No the hard part has been multiplayer. So this is my first multiplayer game. It’ll also be my first released turn based game. I’m also a solo indie dev with… lets be honest, not a ton of cash behind me. This leads to a stringent set of requirements: ...

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. ...

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! ...

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. ...

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. ...

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.

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 this 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.