After last weeks shenanigans I thought this week would be good.

No.

My partner got Covid so we all locked down for the week. My kid and I somehow managed to not get it, but it meant that I had to take care of everyone for most of the week. I managed to squeeze in some time to do some graphic design work and thats about it. 

A friend recommended this great website that got me thinking about using a colour pallet that’s less aggro with Charge. From there I did some basic sketches on how I wanted the overall forms to feel and then whipped these up.

None of this is even close to final, there’s issues left right and centre with the design, but I’m pretty happy with how it’s shaping up.

Going to keep it brief today.

The past four months have been particularly trying for me. I’ve been away from my desk, my tools and importantly, from the home. 

I’ve also had a ton of super stressful factors going on, many are personal, but they include the Interloper update that I’ve been meaning to get live for quite some time now. 

But this week my body literally told me to sit down and chill. I pulled a hamstring on monday doing some exercises. Caught some kind of cold that’s left me with a constant sore throat, and just because I’m a glutton for punishment I went and got my latest COVID vaccine which absolutely knocked me out for Thursday and Friday. 

All this means that I’ve done very little this week. 

I think I’m overdue an actual holiday where I go away and get some quiet time to myself, but that’ll be another week. 

Tasks completed:

• Work on CI/CD server
• Army builder: Force composition
• UI: Army Builder: Pick new unit view
• UI: Army Builder: Select army
• UI: Army Builder: Per-army-banner

This is my last week in the US, and next week flying home is going to be both arduous and time consuming (please, try to imagine flying with a toddler, or if you’re already a parent.. I’m sorry.) So I purposefully limited my scope for this week. 

The big takeaway was Charge’s first playtest. My stepdad (hey Pete!) was super accomodating and was up early enough for us to get a “game” in during my work hours over here. The test honestly went better than I was expecting, in that we got something that kind of looked like a game in. There were plenty of bugs and issues, from not being able to order units after doing certain commands, to connection issues, to the game’s turn order getting out of sync, but fortunately all of these were trivial enough to fix.  More than all that though it was so incredibly nice to get a game going with Pete. We live in different states, and when we do meet up it’s hard to get the time to get any kind of tabletop games in, let alone something as large as a rank and flank. He’s a major reason I’m building this game, and to even get a glimmer of the tabletop games we used to play was incredibly nice. 

On a more technical level I managed to squeeze in a few features this week, namely, a new terrain system, a new graphic design for unit cards and the ability to play local games on iOS / iPadOS devices.

The new terrain system in particular is pretty exciting to me. In the old system, I had a pre-baked base board that was always the pre-set 4×8 size, then I’d lay terrain pieces on top of it, much like you would in a real life tabletop environment.

Old Terrain System

In the new system, I instead sculpt a terrain mesh in Nomad Sculpt on my iPad, building both a low (game ready) and high poly (detail sculpt for normal mapping). I then generate UV’s and export that over to Procreate where I then texture it up.  After that I take my terrain prefabs and scatter them about the mesh in the Unity Editor. 

The trick is that I make the terrain piece quite large. probably close to a real life 16″ x 16″ table. Then when the a new game starts, I simply find a random position on the board to centre the gameplay on.

This all came about because I was trying to optimise the game’s graphic load so that it doesn’t burn device’s battery, and I found that Unity’s default terrain system is both a performance hog and inefficient. In the process of getting nicer looking terrain I also shaved the overall draw-call count from ~200 down to 80. On that note, I was inspired by the recent release of Pocket City 2 and just straight up removed all the post-process effects I generally rely on. I think that’ll work for the most part here, but I get the feeling I’ll need some bloom or something in the future. 

What this all ends up meaning is that the game’s board now has elevation and topology, something that’s notoriously difficult to do in a sensible modular way in traditional tabletop. Gameplay wise, all it effects for now is Line of Sight checks, but maybe in the future i’ll add some kind of environmental buff system for height advantage / disadvantage. 

New Shiny Terrain System

Local play on device is a big part of the overall strategy for the game, so it was nice to be able to get that running. It also helps from a debug point too. All it required was splitting out user authentication from the kind of multiplayer system and it more or less worked by default. Probably a sign that the way I’m writing the code is far better than stuff I’ve done in the past? 

The remaining new feature is the new unit cards. It’s also a bit of a glimpse at where I feel like I want to go with the overall graphic design for the game. The functional thinking here is to have large portraits, and only the most essential info on each of the cards, so, the unit’s remaining wounds, and their current status. Graphically, I wanted them to feel like old beaten up playing cards, tying the overall feel a bit further into that tabletop-y feel. The main inspiration is actually the deck of cards you get in the 80’s HeroQuest box for things like treasure, monsters and other bits and bobs. 

One of the main functional things this card UI has to do though is work well on all screens, from a tiny iPhone mini through to a 100″ tv screen. It needs to be easy to pick out the unit you’re after, to quickly see which how most of your units are doing and crucially not take up too much space. Thus the accordion animation. 

As I mentioned before, I’m going to be out of action next week, and likely even the week after, depending on how painful the flight / jetlag is. So don’t hold your breath for the next update!

So I haven’t mentioned this yet (and if I have, forgive me), but I’m a dad to a toddler, alongside being a solo game dev. 

My kid’s great. They’re intelligent, emotionally in touch and super curious about the world. I really couldn’t ask for more. 

But

They’re a toddler. Which comes with all the great stuff you get when you’re still coming to terms with the absolute basics of being alive. Sometimes you get so into playing with lego that you forget that you’ve got poop slowly migrating down your pants. Sometimes the only thing you want to eat in the world was that last biscuit that your Dad just ate. Nearly all the time you absolutely do not want to go to bed because it means missing out on more fun. 

The net result of all this is that I’m almost perpetually exhausted, which is to be expected, but.. exhausted. On a week to week basis this is all fine, but the killer is when they’re sick. They get sick roughly once a month on average, 99% of the time it’s just a sinus thing, but it means i end up having to take care of them during the week when they’re not at daycare.

Taking care of a toddler needs nearly 100% of your attention as you never know quite when they’re gonna try something new… like eating lego, or sending a toy for a trip out the window. As I said, they’re mostly good, it’s just that underlying, constant possibility that something might go wrong any second.

Anyway this is all a preamble to say: I’ve managed to do very little this week. Monday my partner was lovely enough to take time off their super busy schedule to look after the kiddo, so I managed to get some bugs fixed then. 

The rest of the week has been trying to squeeze in some quick art whenever I could.

Bugs squashed

(10/04/2023) 

• units that don’t have a move order available can move by default

• Units that have died no longer show up in replays.

• Dead units still have active colliders

• Killed unit didn’t dissappear

• Attempted move whilst invalid, counted towards orders.

• Charged unit, not exhausted.

• units just plain don’t exhaust anymore

• Units that have taken any order shouldn’t be able to charge.

• Unit select audio doesn’t play when selecting from cards

• LD trait is stacking lol

• replay starts on last known state. Not first state of turn

• cannot deselect unit in worldspace

• Camera pan to unit needs to stop on mouseDown

• selecting a unit in worldspace doesn’t highlight their card

• Can charge friendly units lol

• p2 in local games cannot select units during deploy

• Cache previous unit states.

• killing an enemy unit in your turn doesn’t make them disappear?

• Watched Bluey, seasons 1-3 1000 times over.

• Watched Frozen 1, 1000 times over.

Sometimes when you work on a feature it takes a couple attempts to get it right. Prior to working on the Reducer approach to turn based games i’d had a kinda-working version of replays in the game where each unit stored their own history? I don’t know.. I was tired.

Anyway this week the main focus was getting the replay system working properly. To do this, I’d effectively grab the previous turns orders and consume their events again, literally re-playing the events of that turn. 

Getting this up and running in the first place was surprisingly easy. Literally just grab the data and iterate over it firing consume for each relevant event. 

The hard part came when I noticed that my M2 MacBook Pro burned nearly half it’s battery life in the span of an hour. These things are supposed to be all day devices. It was also nearly half as hot as my older 16″ intel Core i9 device got on boot. Looking into it and sure enough the game was absolutely thrashing the cpu. 

Now, creating a game that is highly inefficient isn’t new to me, but I was very surprised to see my turn based code performing so poorly. Normally it’s something dumb like throwing a ton of code into the update loop, but no, in this case it was the dreaded C# nested foreach loop issue. 

If you haven’t encountered this yet it’s a doozy. Most languages have some kind of default way of iterating over a collection. Normally this looks like:

for (int a =0; a < list.Count; a ++)
{
	// do something to list[a]
}

in C# there’s a handy shortcut in ForEach

foreach(Object item in list)
{
	// do something to item
}

Easier to type no? It comes with a catch. Each iteration creates a teensy bit of garbage memory that gets collected whenever the garbage collector is ready. On top of that it also uses a bit more processing power. On their own and in isolation they’re not a problem for modern machines at all, but nested? Thats where we get real issues.

So say a unit moves, and I raise an event to say they’ve finished their move. I want to know if this unit is still orderable, and if it has any Aura based buffs or debuffs. Now I’ve gotta check from this unit to every other unit within range. Now there’s follow on effects for units moving, like if I move a leader then I need to know if any of my units are within range. Effectively every time I move a unit I need to check their distance against every other unit. And in the case of buffs/debuffs on auras then I need to iterate on every unit’s aura data to see if they’ve got one, so on and so forth

All this is to say that each time I moved a unit, the game would generate nearly half a gigabyte of garbage data from all the foreach iterators. The last time I hit a bug like this was back in 2016, running a core i5 iMac with 32gb ram at my old job. I had to restart the machine each time the bug occurred as it just overloaded its poor cpu and memory. 

The M2 device? Just took it and ran with it. Got a little hot.

Lessons learned from all of this: 

1. foreach is fun but be careful.
2. geez louise these M series devices are incredibly good.

Theres so many things in game development that require a pipeline, a workflow, a process from beginning to end. Whether it be something simple like creating an icon for a UI element through to complex like creating whole systems, the results are generally better when a process is followed. This applies to large, small and solo teams alike.

Concept art is no different.

The issue i’d been having with Charge is that while I have some ideas for the setting, and some very rough ideas for the look and feel, I don’t particularly have a good feel for the style, or the details. There’s a problem in art called the “blank canvas problem” where it’s always harder to start on a new artwork when the canvas is blank, and that it’s almost always better to just slap some thin layers paint onto it just to get started. As the game currently stands, I’m deep in the blank canvas problem.

Tabletop gaming is one of the core sources of inspiration for Charge, and this morning over coffee I thought.. what if I just kitbashed a model? Grabbed parts from various sources and just stuck them together to see what turned up. What I ended up doing was stumbling on the process for coming up with looks for units.

The general process then looks like this:

1) Start with a brief.

Even the simplest of briefs will help bring an idea to shape. In this case I wanted to create a knight, but one that’s been on the campaign trail for some time. I wanted to show that they not only fought on horseback, but lived on horseback. I also wanted them ready for cold climate warfare, and to look and feel as though they might be ready to weather a blizzard.

2) Block out the basics.

I started out by trawling free 3D print files on Thingiverse and Cults3D, I have no intention of using these for anything other than building the rough forms I need for the concept. The other benefit of this is that tabletop style models have a set of proportions that aren’t quite in line with the real world, but are something I want to capture in the game.

Once I’d grabbed the varying bits and pieces that I wanted, I began assembling the model. Again, paying attention to the major forms of the model, and not really caring too much for the details at this point.

Effectively this is all going to be shorthand for quickly generating a sketch that is both anatomically correct (within tabletop bounds) and projected correctly, something that I struggle with when pushed for time.

For this first attempt at this process I used blender on my mac. I think in the future I might try and keep the entire process bound to my 12” iPad Pro for efficiency reasons. That and it’s also more than capable.

3) Add some details

After initial assembly I took the model into Nomad Sculpt on my iPad and began sculpting out just a couple details. Again, I didn’t care too much for how good they look so long as they give me the overall silhouette and form that I’m after.

4) Make it all your own.

Once that was done, I took a rough screenshot into Procreate to sketch out the details that I wanted to see. I focused on surface details like armour, Chivalric iconography, basing details and more. I’ve got a lot of units to make, and nearly all of them will require concepts in some shape or form, so I can’t go into too much detail here, but the form exist, the details exist and this is more than enough for me to go on and build my own 3D models for both the digital game, and for printing for tabletop.

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: 

• The game has to be multiplayer

• Ideally i’d pay $0 for server upkeep.

• The server calls and responses need to be idiot proof (aka me)

• It needs to support turn based gameplay

• If I choose to stop maintaining the game, it’ll still be playable.

• It should be easy to find someone to play with and play a round.

• The game should not require a realtime connection. Need to leave your turn for a minute, hour, day, week, year? Sure go nuts.

• I really, really, really do not want to collect user email addresses nor create account systems.

There’s a ton of multiplayer options out there, from Unity’s own inbuilt one, through to several third party options through to writing my own server for it. The catch is nearly all of these options require both ongoing maintenance as they continue to improve / get sunsetted, and often they’ll also require fees to maintain the games servers, and more often than not those fees scale with the game’s concurrent player count. 

The first shot I tried was play by email, way back in 2015(?). I had only just discovered C#’s email functions and thought AHA! The early prototypes failed to run at all (due to my lack of coding experience, I’d only been coding for a year or two at that point) and it was shelved within a week or so. 

The second attempt was using Googles Firebase. That was a lot more promising, I actually had a couple games with my brother online. Again though, riddled with bugs, barely worked, and I realised during that time that it would end up costing in the long run. 

Third and fourth attempts were with an amazon product and some third party thing I found on the asset store. Same issues.

Then last year, Apple announced this cool thing called Apple Unity Plugins. Effectively they just expose a bunch of stuff that’s built into the various apple OS’s to Unity. One of those things was an older system I hadn’t heard of called GameKit which oh guess what has a Turn Based Multiplayer system just built right into it. And this is how it fits into my requirements:

☑ The game has to be multiplayer

☑ Ideally i’d pay $0 for server upkeep.

☑ The server calls and responses need to be idiot proof (aka me)

☑ It needs to support turn based gameplay

☑ If I choose to stop maintaining the game, it’ll still be playable.

☑ It should be easy to find someone to play with and play a round.

☑ The game should not require a realtime connection. Need to leave your turn for a minute, hour, day, week, year? Sure go nuts.

☑ I really, really, really do not want to collect user email addresses nor create account systems.

Basically it literally ticks all the boxes. Apple handles the accounts (via iCloud), so theres never a sign in screen. It’s a service available to all developers on apples platforms, so it doesn’t cost me anything more than my dev account, and from what I understand if I for whatever reason decide to shut down my developer account, then the game still kicks on. Matchmaking is built into it, so it’s easy to find a random to play with, the code is literally just an async turn.send(byte[]);  and an onTurnRecieve(byte[]) callback. 

And would you know it.. It just works. 

It’s got other limitations sure, like a maximum turn size of a whopping 64kb, a requirement for players to be logged into iCloud/Gamecentre to play online, etc. But they’re not so bad.

Honestly the one limitation that bothers me the most is….

The fact that it’s tied to Apple’s ecosystem. 

If i wanted to release the game on say.. PC? Console? I’m back at square one. Fortunately I’ve developed the game in such a way that it allows for multiple multiplayer backends, (for now, just for local, pass and play), and I honestly think that if I’m going to go down that route I’ll end up just having to write my own super lowfi server solution. Something I can host on a potato somewhere and pay next to nothing to maintain. 

Thats a future problem though. For now I’ll stick with GameKit. The game wouldn’t have gotten this far were it not for that little announcement at WWDC last year. Props to the team for taking the time to write up stuff that honestly could’ve been left to the community.