Blog

This week I spent a lot of time bringing the game into a proper scale, building out radar systems properly, getting it all running smoothly on mobile and a ton of other.. stuff, all in the name of getting the game ready for you to play. Scale is a kind of important, but not really, element of game design. In Interloper, the scale is all off. Matches take place in a 5km radius, but I purposefully fudge the speed numbers, the size of ships, the size of projectiles and more to make it feel more immersive on a smaller screen. Rarely anything is to scale. This is both a benefit and a curse. On the good side, it allows me to make things feel bigger or smaller than they actually are, on the downside, the moment you view the game from within a VR headset, its’ all off and feels very weird. So from the get go I’ve decided that Exoloper will be true scale. This is extra important mainly to make many of the world assets feel the right size. Very few people have been to space, and conversely a vast majority of the worlds population knows what size a building should be. Also, if I decide down the line that for some reason I want to properly support the Vision Pro.. well.. at least it’ll look about right. NO PROMISES! I also implemented a ton of new features this week, from the data structures required for multiple campaigns, to improved ground textures, to squishing enemy infantry, Touch UI, auto aim, and soooo much more. If you’re interested in giving the game a shot, feel free to join my discord where you’ll find the link. ...

This week kicked off great. I managed to finally play a fully online game of Charge with someone I didn’t personally know, even got up to the final turn without it breaking (it broke on the last turn). I was over the moon! This playtest had validated so many hypotheses I had with Charge: A digital version of a rank and flank can be played really quickly. People unfamiliar with the concept can pick up the basics quickly without having being told the specifics. The UX I’d designed is mostly sensical. Most of the concepts around interacting with the game work well enough. This isn’t to say there weren’t issues, there were hundreds, but they were all details, not necessarily deal breakers. Actually.. there were two. The game really really needs a singleplayer option. See, I don’t expect to have the reach of getting tens of thousands of concurrent players across the worlds timezones. So far Interloper has reached less than ten thousand players. I’m fine with those numbers personally, but it leaves a bit of a hole in a game that’s primarily a multiplayer 1v1 game. The last thing I want is for the game to feel dead because nobody is playing it. So.. we need a singleplayer experience, or at least.. AI or Bots of some kind. Concerned by this development I went back and re-scoped the entire game. I’ve got limited runway to complete the title (or at least.. to start earning money from it) and the minimum length of that runway is March 2024 (it extends quite a way beyond that under certain circumstances, but I like to plan for the worst). After spending Tuesday and Wednesday scoping, prototyping, feeling the edges of whats possible with Charge I came to the conclusion that the earliest it will be ready for launch is May 2025. That’s a long time to be working on a title without significant income I was devastated to see this. The extra scope from singleplayer options, AI, testing and exceptions blew out the rather lean multiplayer game I had planned. I can absolutely forge ahead without singleplayer, or even cut back on scope some more, but I think this would be a pretty grave mistake, especially after what I’ve learned playtesting I’ve done so far. The second dealbreaker is how complex the codebase is so far, and how difficult it has been to develop a multiplayer title on my own. Many things I thought would be simple to implement have become way more complex than I initially imagined. Even the basics of just sending a turn to the opponent is difficult (in part limited by the GameKit restriction on turn size being measured in bytes). Anytime something breaks with this, it leads to a headache inducing period of bugfixing that.. I’m not 100% sure I’m built to handle. So, faced with this situation… I went back to the drawing board. I’m not 100% sure on this just yet, but it looks like Exoloper (the mech game) will be my next title going forward. From what I’ve scoped out of that project so far it looks like launching early next year should be doable, maybe even later this year. There’s a ton of efficiency built into that project, from its similarity to Interloper from a design perspective, to its not quite sequel status, to just being a singleplayer title to start with. Part of the scoping exercise was looking into the game’s persistent campaign concept, and working on some “mood” concepts. Charge is a game I love deeply. It’s been the title I’ve wanted to make since before I got into the games industry in the first place, and so the decision to put it on the backburner is not something I take lightly. I’m not sure if the game needs a total rewrite, or if there’s enough of a good game sitting there as is for a future launch. Bit of a bittersweet week really. Started great and now I’ve gotta put that project to rest for the time being. Charge Tasks completed: Add painting ability to beaky models Build a system for scoping out work Player should be able to see their deployed troops while waiting for opponent to finish deployment Drop volume on Lightning in menu Once you start panning ui shouldn’t interrupt it. UI: Warn before next turn (popup, hold to confirm, something like that ranged attacks don’t actually fire? Charges should include a pivot. Collect interloper bug reports Damage / event system add things to destroy add basic enemies Build New Sprint Bug: Getting current roster from armybuilder often leadst to either a null or out of range exception. Think of a better implementation. Bug: Somehow Authenticator’s playerinfo gets nulled? UI scale setting does nothing Bug: Replay segments don’t always show a log Somehow got out of turn order on device.. Somehow got into a state where player two was controlling playerone’s units. Cant do automatch Setup proper disconnect method for players Determine 3D print scale for charge minis Flow: figure out automatching properly. Interceptor skin not unlocking despite completing requirements. Audio sliders don’t zero out at zero. Exoloper Tasks completed: Built out production schedule Scoped out major features Investigated weather effects, lighting, mood Prototyped persistent campaign.

Kevorki Lord overseeing her guard at the battle of Krag Pass. This week was.. in a word.. intense. I got so much done and a huge part of that was thanks to kicking the week off with an internal alpha test (read, my partner and I played a game). My partner has played something like Charge in the past, but A) it was a long time ago, and B) their interest in tabletop wargames isn’t huge, so it was actually an ideal test in that we managed to glean quite a lot of issues with the overall flow and feel of the game, it’s UI and the overall design. Some of the issues were pure UX and copy issues. In my designs I’d mixed up the definition of what a “roster” was and what an “armylist” was. Some were implementation issues, it was very difficult to move a unit after deployment. Others were expectation issues “I thought I should be able to zoom in on the model to paint it”. Replay feature in full swing There’s so many that I haven’t yet gotten around to fixing, and plenty more, but the overall impression of the game so far is that it’s in a much better spot than it was at the start of the week. And I know I’m only just getting started with feedback and implementation. Starting next Monday (Australian time) I’ll be reaching out to people to invite them to the first closed public alpha for the game. In theory it should be playable without too much direct input from me, but… lets just say I don’t have high hopes. The first proper tests are always a brutal exercise in watching your game fall apart. It’s a huge reason why I’ve been avoiding sending out the codes so far. A quick aside. Please don’t ask me for a code. The initial rollout is just to a very select few people. If this all goes well, and if there’s genuine interest after this, I’ll start thinking about doing an open alpha release with a much wider audience. Until then, it’s closed. Look at those dice rolls and logs. ...

This week had some moments of downtime. Monday had me looking after my kid again. Tuesday I spent the day looking into a macOS issue for Interloper. Not really sure I’ve solved it, but theres unfortunately no way for me to know as I can’t replicate it here. Wednesday I got a little bit of work done but then I got notified that the parts had come in for my new gaming pc, so the rest of that day was spent putting that all together. It aint much, but it’s a step up from using Bootcamp and an eGPU on my 16" macbook pro. It even booted first try? The rest of my time this week was on Charge, in particular, working on the painting system. I needed to work on something simple and fun to get back into a rhythm this week, so it was that. I’d already blocked out what the background scene would look like and I’d done some work on the graphic design, but none of it felt quite right. paint scene initial blockout with INCREDIBLY PLACEHOLDER paint pots Quick sidebar: In Charge, I specifically want to keep the painting systems quick and simple. I opted to go against the direct painting method because: A) it’s a lot of engineering work to get it feeling right. I’ve built a paint-on-model app before and it wasn’t fun. B) Theres strict filesize limits for sending turns via Game Center, and textures are a no-go. (we’re talking bytes here) C) I can’t easily filter for profanity. Again, nothing is impossible, but if someone wants to draw a penis or something hateful, then there’s limited options within my scope to stop them. Over the weekend I spent a little time building a quick proof of concept for interpolating colours on a texture, and it seemed to work pretty easily? It’s a relatively common system usually used for team-colours in RTS games, but I wanted to extend it a little further. Here you can see it in action. The Red, Green, and Blue sections of the model get swapped out for more appropriate colours. another INCREDIBLY PLACEHOLDER model, showing off the paint system so far I spent some time prototyping interaction models, starting with directly selecting the parts of the model, but that quickly became a rabbit hole of bad interaction patterns. Where exactly do you press? How can I ensure that the target zones are easy to pick on a small phone? Does this mean I have to create completely custom target zones for each model? How do I highlight those zones easily? etc etc etc. Often in these cases the solution is to do it the simplest way, and that way is buttons! Not terribly exciting, but they do the job, at least for now. The painting system as it stands today. This is all still a massive work in progress, nothing is quite finished yet, but it feels as though its on the right track. I said last week that I’ll be working towards an Alpha test build this week, but with all the distractions I didn’t feel it was the right thing to do. Fingers crossed that’ll be next week. On that topic I did manage to put in a few things to make the game Alpha Ready™️. I’ve built out an Alpha feedback form, a bug reporter (including a handy-dandy screenshot system) and a more generic feedback form. I’m hoping to get a lot of feedback throughout the alpha / beta period so, may as well get that stuff started sooner rather than later! ...

This week was.. tedious. Literally just going through and fixing bugs left right and centre. What initially looked like it would be an easy week turned into a slog when I realised that the UI flow I’d setup over the past few weeks actually only worked for local pass-and-play games, and not really for online games. Simple stuff to start with like, the deploy screen being active for both players at the same time, and then slowly more complex issues raised their heads. Issues with synchronisation of data, issues with not quite knowing which game I was joining, having to create specific UI for connecting to games without using Apple’s game centre views, etc etc et. Here’s an example of what that looks like in practice: This particular element shows games that you’ve previously played. First I actually had to make the system that generates a name for the match (whoops, forgot that), then an icon to say whether it’s pass and play or online, and a game ID field, and uhh… a delete button. it’s subtle, but it’s there Lots of little things like this added up to make an entire week of issues. Anyway, it all works nicely now. (at least in my limited testing so far) Which brings me to the next bit. Soon I’ll be doing a very limited public alpha of the game. Five to ten people, mostly looking to iron out major issues with the game. I still need to build a bug reporter that can handle screenshots, and probably do more bugfixing before I get to that, but that’s the plan for now. ...

This week I worked like a madman on Exoloper. I built out the basics of the games menu UI, ported over systems like save + load, UI frameworks and my general purpose utilities and then got to work tying together the combat, campaign and loadout prototypes to turn them into a fully fledged game. In particular I worked on the exo editing systems. Similar to Interloper’s loadout system, but more complex. The idea is that each section of the exo has a series of slots that can take either a Utility, Weapon, Power Source or Locomotion system. This then ties into the campaign system, which then ties into the battle system. It was really something seeing all of that tie together so nicely, but also be decoupled enough that none of them rely on the other to work. I mentioned this on Mastodon and the Anchorite Discord, but it looks as though I’ll have a playable prototype very soon, possibly next week. I keep close tabs on my hours for a variety of reasons, but it looks as though I’ll have created the Exoloper first alpha in approximately 40 hrs of work. For those keeping tabs, Charge took nearly 823 hours to fro to the same spot. I think I’ll go into more detail on this with a separate post later, but suffice to say, it’s a significant difference that I’ve chalked up to inexperience with multiplayer systems, and doggedly trying to implement Test Driven Development. As I said before, I’m so damn happy with where Charge ended up, and the general direction its going in. I can’t wait to finish it, but.. just not right now. For now though: as I haven’t done this yet, here’s a quick overview of Exoloper (in its current form) ...

(this also covers last week, as I was too exhausted to post an update last friday) So it’s been a long couple months of doing Charge’s UI work. What I’ve ended up doing is completely rewriting the existing, terrible, UI and replacing it with something much much nicer, and more extensible. I also spent a fair bit of time decoupling more systems, just making it easier to test / fix / figure out issues in the future. All in all this patch of work has been an absolute slog. From the hyper enthusiasm of the graphic design through to the minute to minute issues of implementing it. I’m glad it’s done, and I’m proud as punch of it all. There’s finally a couple bugs that still need sorting out, so I’ll work on those next week, then if all looks good, I’ll put together a proper armylist… and start actually testing the game? 👀 An in game screenshot with the new UI. Starting to look like a real game now! Also as a little tease. I’ve been working away at the ‘mech game Exoloper too. I haven’t formalised the tasks for that just yet, but the things I got working this week include: ...

More chaos this week, but still got some stuff done. Managed to get most of the core UI and the game UI up and running. Everything is broken and barely playable, but it’s quickly coming back together nicely. It’s nice to be actually able to play the game again for the first time in what feels like over a month. Charge Tasks completed: UI: In Game: Stubbed out all base UI. Ui: In Game: End turn button Ui: In Game: Turn and order Info UI: In Game: Waiting for players to connect UI: Armies Page UI: ArmyBuilder UI: New Roster - Pick Armylist UI: Armybuilder - Add Unit UI: Army Builder: Army Details page UI: Armybuilder: Set Roster Details UX: controller pass UI: FIll out details for each UI Pageview UI: Design system

This week saw more graphic design work, particularly focusing on implementation. One of the things I find most people get surprised with when it comes to game development is just how much you have to write from scratch. In this case, it’s responsive design. So typically when I’ve created graphic designs in the past for UI’s, I can usually rely on the existence of responsive design tools. These tools allow a design to shrink or grow from as small as a phone screen all the way up to a TV scale experience, usually without much futzing about. The most widely used tools are HTML and CSS, but you find the same concepts in iOS layout tools, Android, and pretty much any OS level UI framework. Another concept that’s generally agreed upon in UI frameworks is a concept of a style sheet, how each component should look (as opposed to how it should function) this sheet is designed to be reusable, in Web it can be applied to a whole website, or as specific as a single button. Unity, the engine I’ve been using for god knows how long, does, on a surface level provide tools like this, but they’re rudimentary and at best and don’t allow basic stuff like having independent sizes for text or content based on the size of the screen, at best it can linearly scale the text up and down, which.. doesn’t really fit the bill. Unity also has no sense of global styling, favouring a per-component or prefab system instead. So I’ve spent the past week investigating a better way to do achieve this than how I did it for Interloper. There’s 3 main “screens” I need to design for when it comes to the platforms I choose to support (Apple’s platforms: iOS, iPadOS, tvOS, macOS) and thats Phone-Portrait, Phone-Landscape, and then everything else (more or less, landscape-large-screen) While some people will use the iPad in portrait (myself included) the landscape-large-screen format generally works well for that, and where it doesn’t I can introduce specific exceptions. In Interloper, each screen has a “portrait” and a “landscape” layout, and these then have further modifiers based on the screen size. These modifiers were controlled by each screens view-controller, meaning that if I wanted to make a global change to the way the UI looked, I had to do it manually, screen by screen. As for styling, in Interloper, that’s almost entirely done on a screen by screen basis, again, lots of manual work. I had some reusable components, like buttons and some labels, but it was a bit of a mess. So for Charge, my goal is to have a global set of styles and a universal responsive layout that I can tweak from one spot and have it update universally. Charge’s UI responding to various screen sizes and orientations For this all to work I needed a system for using Unity’s newer prefab systems, nested prefabs and prefab variants. First I laid out all the basic components I figured I’d need, text and buttons. From headers, to subscript, banner buttons to icon buttons and placed them all in the one scene. Each component is a variant of a base component, meaning changes flow down the line. Then I built a base view-controller-prefab (think of this as the root for each page.) with all the required controls pre-set onto it, and inside that I setup my responsive layouts; one for “portrait”, one for “iphone-landscape” and one for “landscape”. These media-query-triggers are baked into the prefab, so any time I make a new screen, I simply have to inherit this prefab as it’s base and I’ve already got my ducks lined up. From there it’s as simple as defining what content of the UI goes where under each of the scenarios, along with the regular custom code that each screen may or may not need. All of that work, to achieve this: It doesn’t look like a lot right now, and the larger screen sizes haven’t seen any specific work go into them just yet, but the systems are there to allow me to be as fine grained or as lazy as I want with the UI. ...

This weeks wrap up is more of a combination of the past few weeks worth of work. Between Covid, working on Interloper and my kid staying home from daycare with yet another minor illness, I haven’t had as much time as I’d like to work on Charge. That said, I’ve made some strides with the games UI and the broader graphic design of the IP (yes, IP). Armylists are at the core of your expressions for the game, so it makes sense to pay special attention to them ...