• Controllers and Cosmetics

    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.

    Tasks completed:

    • Weapon count is doubled in cosmetic unlocks
    • Control tooltips for pitch,yaw,throttle,roll need to be hidden during Tutorial
    • Fix headphones logo being crunched
    • New screenshots for tutorial pages
    • Icons for Cosmetics + Ship Details
    • Can equip multiple weapons of a given type when only one exists
    • Dying only deletes the first in the array of items equipped
    • Tutorial needs to be updated to match new control layout
    • “Back” from in game settings should resume game?
    • new Pilot screen, controller back doesn’t work
    • UI Fix overlaps in ship select screen
    • Game Gets stuck in Post-Run state when all perks are unlocked
    • Change descriptions to be a scrollview.
    • Menu tutorial screen fixes
    • Loot Manifest Screen Fixes
    • Group weapons in loadout
    • Take screenshots of all screens + states for interloper
    • In game settings menu doesn’t use RB / LB navigation.
    • Do a complete navigation pass for controller buttons in the main menu.
    • Left Dodge doesnt work?
    • Controller remapping doesn’t work?
    • back button isn’t universally working with controller
    • Mission select doesn’t auto pick selectable
    • If the UI is scaled far enough in, you can’t reach other buttons in loadout when using controller.
    • Ship VC layout is a little busted on lower UI scales
    • For some reason player data is null?
    • Add labels to photomode and ship-skins buttons.
    • Update game’s home screen to be more.. interesting
    • Add SFX to skin select buttons
    • Upload new screenshots

  • Covid

    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.


  • Week off (sort-of)

    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

  • Army Builder

    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.

  • Playtest

    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!


  • Toddler

    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.


  • Bugfixin’

    Bugfixin’

    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


  • ForEach

    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.

  • Pipelines: Concept Art

    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.


  • Bonus Post: Multiplayer

    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.