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 place that makes me feel comfortable.

I've also had a ton of super stressful factors going on, including 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

So I'm back in Sydney, Australia after three and a bit months in Philadelphia. I can't say I enjoyed my time over there but it's done. There's just so many differences between the US and Australia, and many of them make very little sense to me.

The flight home was brutal, and my kid's Jetlag worse, so this week has been thin on the work front. It took me a day or two just to find my feet again, and by the time I did I had to fly out to Brisbane for my best mate's wedding. Lovely as it was, I've had trouble getting back into the flow for work.

Bonus points for the flight back from Brisbane: I'd spent some time on a nice little animated concertina for the orders panel. Relatively simple, but with some additional graphic design I reckon it'll look nice.

Anyway.

This week I had set myself one major milestone: organise the tasks required for a proper public Alpha version of Charge. While the game is technically playable at this point, and all the core systems are in place and functioning, there's still a ton of work before I can blindly hand it over to players. Very little of the game makes any sense at this stage, even if you are familiar with the general concepts of tabletop wargaming. So I spent a fair amount of my limited brainpower this week organising what I'd need to do to get it to a point where I could blindly hand it over.

Turns out, it's a lot, but that's alright, that's always the case.

Once I'd sorted that out, I set to work on the first major task: Building out my own home build server. There's plenty of options for build servers online, but either they cost a fee that I'm not willing to pay, or they lack control, and a core tenant of Anchorite (at least.. for now) is that I maximise control and minimise cost.

This process was going smoothly, I had the device remotely building on git pull requests, but then... Disaster Struck! Internet maintenance on our street (in fact.. in front of our apartment building) had knocked out our home wifi for a couple days.

So I switched gears and picked up the next task: the Army Builder.

Up until now the game just deploys you with a default armylist that I'd put together in the background. The full game should allow you to not just put a roster together, but to paint it, maintain it, and over time evolve it, and the first step towards that is a UI to build your roster.

For now it's simple, when you open the game, you're given an option to create an army. You choose from the grand array of one army lists, and then go to town adding units and upgrades to that list. It's not much, but it's honest work.

It's brought up a couple questions though, for instance: What is the points scale for Charge. Warhammer Fantasy Battles and Kings of War use a 2000 point system which feels natural to me, but as a designer I generally prefer smaller numbers. I could in theory chop that number down a decimal place, but that limits some of the choices for fine-tuned balance of upgrades. I could opt to not go with a points system at all. There's a lot of options, but for now I'm sticking with what I know just to get it started.

The next steps from here are to allow the player to select from multiple saved army lists (I'm thinking about capping this at 3-6. Theres no good storage reason for this, but I feel it'll lead to experimentation more if you have to change your armylists more often), some kind of Army Details page / Statistics page where you can get a feel for how the army is designed to perform (thinking maybe a pie chart or something else nerdy like that), and most importantly.. the army painter.. though thats an entirely seperate blog post.

Next week though I'm going to jump back onto Interloper. It's been too long since I've pushed any builds out for that, and now that I'm back home I can test it across all the platforms.. looking at you tvOS.

Tasks completed:

• Work on CI/CD server
• Army builder: Select Armylist
• UI: Army Builder: Modify Unit
• UI: Army Builder List View
• UI: Army Builder: Army List View
• Change charge to be a blind move.

Bugs squashed

• Save scumming can still happen.

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 4x8 size, then I'd lay terrain pieces on top of it, much like you would in a real life tabletop environment.

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.

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!

Tasks completed:

• Build new terrain system + pipeline
• Detach authentication from Multiplayer classes.
• Send out Playtest invites
• Build list of play testers
• Build list of playtest questions
• Setup debug roster to be competetive and interesting ~2000pts
• Replay UI should filter out just the orders.
• Add graphic design to Unit Card UI
• Draw up unit portraits for remaining default units

Bugs squashed

• If there’s no internet connection, the game doesn’t load
• messages invite flow is broken
• Changing settings throws an exception
• instant-turn switching seems to be broken on local games
• Loading back into a game after a crash / app quit switches player turns?
• Turns get out of sync on crash / quit.
• Moving heroes stops input for other units?
• After trying to use ranged attack, can no longer use units
• show command and control in deployment
• Check that config settings set via game data editor aren't carried across to builds, and if they are, figure out a way to reset them.
• Deployment shows other players deployment zone.. instead of current players on device.
• Leaders without available orders are still selectable

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

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

So this week is the last week of features for the Pre-alpha epic of dev for Charge. I've been working hard to make sure that the build is relatively stable, and in good enough shape for me to send some builds off to a few friends and walk through a game with them.

The few features I added were all quality of life ones, minus a fun little set of camera pans as a kickoff for the deployment phase of the game. One thing that's come to light working on this is how much more of a traditional program Charge is vs my previous titles. It also highlights how green I am when it comes to code architecture and performance. Last week's blog post goes into that in detail, but the long and short of it is that I'm not a great programmer. (thats ok, it's just something that hit me again this week)

As for bugs, well at this point in the proceedings there's a lot of little ones, but first a story: A couple years back I was working in a digital agency making educational games for kids. We playtested one game at a high school, but against the youngest cohort of kids there. At the end of the session we did a little Q&A where the kids got to ask me questions about game development. One kid, probably about twelve years old asked "What are bugs and why do developers put them into games", I stifled laughing because it was such an honest and great question. In case you're also curious: the short answer is that a bug is a mistake that isn't fixed before sending the build out to players.

The longer answer is that at least for me, they're issues that more often incorrect assumptions about how some code should work with the rest of the codebase than a mistyped variable. For example, there was one bug I fixed this week where when ordering a leader to move, they'd turn around to some random direction, rather than facing towards their destination. Under the hood I've got a little invisible GameObject that looks directly at their destination, and sits at their position that only exists when ordering leaders around (as they're the only unit that can pivot and move in one go). This worked a charm, no issues. About a month after implementing that I added a function to show a direction indicator on the standard unit movement indicator. Turns out when I added that indicator I accidentally removed the positional code for the lookat object. Making units copy the rotation from the lookat object that was sitting in a completely different spot in the world. Most bugs are dumb like this, and usually relatively easy to fix (at least... on my scale of game)

There were a couple other things that made a difference this week. Adding sound effects is always a great boost to the "finishedness" of a game, and I wanted a couple of those in before shipping out to any players. Nothing too crazy, but I did some foley for button clicks, and some freesound mixing for units. Also put in a rudimentary music track for the game that's all warhorns and drums. The second ever piece of music I've ever written and placed into a game!

One other thing worth chatting about this week is.. well another prototype. I actually started it last week, but it's in a better state now. I'm not sure if this'll go anywhere, but I've gotten very excited about it. For now it's called Exoloper, an incredibly dumb take on Interloper, but I just love it too much. Imagine Interloper, but make it a 'mech game in the vein of the Mechwarrior series, more of a simulator than an action game, but more accessible than the aforementioned series.

Also how freaking cool is camerashake?

Tasks completed:

(07/04/2023) * Dice Roll view in Gameplay log doesn't wrap. Maybe use a gridview?

(06/04/2023) * Units can auto-deploy into terrain * Unit Move Target views should go red if the target spot is invalid. * Exhaustion really should be on a per Order type.

(05/04/2023) * Run builds and check that the game is ok on devices * if it's not the current players turn, there needs to be a super clear indicator on screen.

(04/04/2023) * Move current events into Gamedata to stop save scumming * Save gamedata on data update so that lts always up to date * UI: Deploy - Intro screen * Colliding units need a better shuffle-away algorithm

(03/04/2023) * Add rudimentary unit sounds * Add rudimentary Ambient sounds * Add rudimentary UI sounds * Run project auditor on current project * Build New Sprint * CheckUnitAuras() in BoardController is very inefficient.

Bugs squashed

• Settings list aren’t showing up?
• More hits are landing than dice rolls?
• Ranged attacks fail validation due to not being engaged.
• Trying to run multiple games in one "Play" session in editor causes exceptions
• When a unit's finished their move they're deselected but the UI doesn't seem to think as much
• Units charging each other sometimes collision bounce, failing the charge
• Leader selected boxes are too large
• Leaders face odd directions on move
• Can't move leaders lol
• Units are showing exhausted status on new turn?
• Events are double ID'ing for some reason. Likely some kind of race condition
• Moves allows 2x movement forward. Should be 1x.
• When moving multiple units in sequence, sometimes the camera will unlock
• Leader move targets aren't properly centered.
• Individual move is hard to use.
• When a unit collided with terrain it sent two move order events.
• In local game, deployment zone for player2 doesn't show
• Units are visible during camera path flyby
• Can't select units during deploy lol.
• Game Type Systems and Pitched Battle Type
• remove replay button from UI_InGameView
• Removing the buttons from deploy screen was a bad idea. Put them back

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.

Tasks completed:

(31/03/2023) * Create unit distance lookup table * Smooth camera movement doesn't account for flipped camera

(30/03/2023) * Log view is double writing for some reason? * Change Logview to just show the most current log by default. * Disallow orders whilst replay mode is active * Show which units can be ordered at a glance

(29/03/2023) * UI: Disable unit cards for units that are unable to be ordered * add acceleration to touch based flicks for camera movement * Game UI: Build Replay Slider

(28/03/2023) * Replay System * Create Barebones website for Charge

(27/03/2023) * Board Edge and Retreating units * Unit Upgrades

Bugs squashed

• LOS Fails on slightly uneven terrain.
• Too many order items are showing up in the order list for archers
• Unit's status doesn't update on change
• Identify performance issues on device, and do a quick optimisation run
• CPU and Energy usage is really high, should be brought all the way down.
• Dice rolls aren't propagating across turns properly.. or they're being rerolled.
• Events are doubling up in ID.. probably just race conditions for event ids
• Replays break units readying up after being exhausted
• Unit Cards show outdated info sometimes.
• Deployment doesn't work with replays
• Logview starts in a bit of a broken state
• Sometimes the final element of a replay is the initial position?
• Aura / LD Range checks aren't properly updating

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:

• [x] The game has to be multiplayer
• [x] Ideally i'd pay $0 for server upkeep.
• [x] The server calls and responses need to be idiot proof (aka me)
• [x] It needs to support turn based gameplay
• [x] If I choose to stop maintaining the game, it'll still be playable.
• [x] It should be easy to find someone to play with and play a round.
• [x] The game should not require a realtime connection. Need to leave your turn for a minute, hour, day, week, year? Sure go nuts.
• [x] 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.

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:

(24/03/2023) * Move debug bools into their own config file. Ensure they're reset properly on builds. (GameDataEditor values) * Show arcs on unit when selected

(23/03/2023) * Tons of graphics work

(22/03/2023) * Game UI: Unit Card View * Move all magic strings into LocalisableStrings * Graphics work

(21/03/2023) * Unit Traits * Trait: Fast * Trait: Exceptional * Trait: Cause Fear * Trait: Armour Piercing * Trait: Regen * Trait: Aura * Trait: Leadership

(20/03/2023) * 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

dev/blog_update

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:

(16/03/2023) * Cosmetics: B-Skin- Bomber * Cosmetics: B-Skin- Interceptor * Cosmetics: B-Skin- Sabre

(16/03/2023) * Cosmetics: B-Skin- Bomber * Write out basic descriptions and draw up concepts for remaining cosmetics.

(14/03/2023) * Continue reworking hangar * Hangar Photo mode button

(13/03/2023) * 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.