So 1.700 recently launched. I added some fun unlockable content and fixed a majority of the issues with controller navigation in the game. Pretty happy with that. Next month marks the three year anniversary for Interloper which is huge. I’ve never worked on a title post-launch for that long before. I’ve learned a ton doing this, and honestly I’m surprised it went as well as it did. Interloper’s sales have supported me through both the pandemic and becoming a father, no small feat. Which brings me to the hard part. I’m no longer going to make any new features for Interloper. This is for two reasons: a) Sales have been steadily declining for over half a year now b) The game’s codebase was architected back in 2017 and choices I made as a less experienced developer are limiting what I can do going forward. fig a: my attempt to describe the above. also my handwriting. (sorry) There’s a ton of stuff I would love to do with the game, but just can’t with the way it’s architected right now without sinking a ton of time for not a lot of gain. Things like a campaign, multiplayer, more cosmetics etc. I might end up making these things into a sequel of sorts for the game, but only time will tell there. One thing to point out, one critical thing: I will still do patches to update the game with bugfixes. I’ll also try to keep ontop of OS level updates as they come (thinking new screen sizes and whatnot) One last note: Thank you. Thank you to everyone who played the game, to everyone who submitted a bug report, left a review (positive or negative) on the App Store. For just interacting with this little passion project I made. You’re all great.

After the past few weeks of rubbish this week was finally productive (read, actually good). At long last I finally got around to working on Interloper again. Here’s the thing. As a creative of any kind you’re always chasing the high of the next big thing. The next thing you do is always more interesting and better put together, easier to work with. So coming back to the codebase and art for Interloper is always a little hard. Some of the stuff I made here is nearly seven years old (inherited from previous projects) and so its um.. how do I say… a bit crap. Poorly written code (I thought it was smart at the time), inefficient art assets, poor design decisions etc etc, they keep coming up every time I touch the project. It’s not the worst thing in the world, just makes coming back to it a bit slow. So Monday was a slog. By the time I got to lunch time I was seriously considering just switching back to Charge, but you don’t get to make games without some discipline. I pushed on, and by the end of the day I actually found I was back to enjoying working on the game. A couple design refreshes, fixes to ancient issues, and mostly improvements to the controller experience, the rest of the week went by far too quickly. It’s always great to get really stuck into some work. The best part was taking the time to go through every menu, cleaning up any issues that cropped up when changing UI scales, and across various aspect ratios. Anyway so this update is close to being done. I’ve got some bugs to figure out with the build procedure for macOS and tvOS, and once they’re sorted it’s off to the races. Fortunately there’s no issues with the iOS build at all, I’m sure, definitely. I’ll be testing it out thoroughly over the next week to be sure. ...

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

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

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

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

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

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