AnchoriteGames

This week I spent most of my time on design thinking.

Exoloper has been built using a bottom up method: build out the minimum viable product, and then add to it as I go. I personally prefer this approach as it allows me to quickly build the core loops of the game, and then design around those. This means though that often I'll come to a point where I need to design a concept, and simply stub it out gracefully. One example of this has been handling objectives in the combat scenarios, up until now the game simply checked to see if either a) all spawned enemies were inactive, or b) the player was inactive. It'd then boot you back to the campaign with little ceremony, not really conducive to feeling like you've accomplished much of anything.

So the goal this week was to figure out how this is all actually going to work. Helpfully listed in my task manager as : It took me longer than an hour.

The basic idea is that each Point of Interest on the campaign map can have an array of "scenarios" tied to it. When the player begins combat, one is picked at random. Each scenario lists out the enemy types, quantities, an objective type and finally the actual map to load. Each map therefore needs to support the kinds of objectives available for each scenario. This seperates the concerns of map building, scenario definitions, and enemy compositions.

So for example, a Campaign POI might have a scenario labelled "destroybuildings-tanks-difficult" or "destroyforces-exo-verydifficult" or "capture-convoy-easy". each of those will determine the kinds of enemies that spawn into the level, or which buildings are active. For instance, the targeting capacity for buildings is only enabled when "destroy buildings" is active. checklists that are explosively satisfying to complete

This week also saw me adding some basic UI elements for objective UI, and for tracking components that aren't just enemies in worldspace. Turns out sometimes things are as simple as you'd expect. Target buildings are handled the same as units, controlled by the same systems (albeit without some functions, like movement... though.... moving building boss you say?....) So, as long as they get initialised along with all the enemies, boom, target icons. (keen eyed readers will see an exo-paper-doll icon next to the unit. That's just me being lazy, each "base-unit-data" entry has an optional icon that I've not yet set.)

One thing that came about whilst testing objective gameplay this week was that when you completed all objectives, as I said before, I'd simply boot you back to the campaign screen (or main menu for quickplay), and this felt jarring. I didn't want to throw UI in your face, and while I'd thought of adding some animation or something, that'd get tiring pretty quickly. Instead, I added "exits" to the combat space. Each level now has an array of entrances and exits for the player, and now, once your objectives are complete, you may leave.

The image above has an important clue though: You can leave before your objectives are complete. I think it's important to have retreat as an option in games. It's rarely ever explored, but it's a critical component of any conflict. Sometimes it's better to leave, lick your wounds and try a different approach, or to just leave that particular conflict altogether.

Going back to where I started this post, everything is designed from the bottom up, so right now, yes you can leave a mission, but the campaign only cares that you're alive after returning from a mission, so for now that still counts as a win, and the campaign clears the combat status of that POI. Another stub of design to follow for another week.

Exoloper Tasks completed:

• BUG: Enemy buildings register as "units" for destroy units objectives.

• Feature: Bug report system added

• UI: Combat objectives need proper localised text.

• UI: for objectives in combat

• UI: Campaign: Cleared travel button when nothing is selected.

• Design: Player now must physically exit combat levels.

• Design: Combat objectives added.
• Design: Destroy buildings objective added
• Design: Added ability to target objective buildings
• Design: Added combat exit points

• Design: Combat: Reduced spread on Vulcan weapons

• New Combat Map: AA Battery.

It's been a couple weeks since my last update. Life gets in the way sometimes.

Two weeks back was Melbourne International Games Week, usually a good time to do some bizdev stuff, so I took the train down there for a handful of meetings. The sleeper down was fine, an 11 hour trip with a cabin mate that snored for the most part was lovely by comparison to the trip back. I took economy on the way back, so imagine an 11 hour flight where your sleep is interrupted every hour or so as you stop at a new station and people get on/off the train. Oh yeah and also the seat is made of concrete.

a lovely view of my sleeper cabin's seat, pre folding down

Admittedly I also took two days off to dive into Starfield. I rarely take personal time off, and when I do it's usually for family stuff. Once every Bethesda cycle* though I'll take a couple days off to get oriented with their latest game. I've spent countless hours in the various Bethesda open world RPG's and often love their attention to detail, immersive nature and freeform style. Starfield has been my least favourite so far specifically because the landscapes aren't as handcrafted or as easy to get lost in. But it's many improvements beyond that are all really welcome. I still get the feeling that having one continuous engine since Daggerfall holds them back technically. That said, what they can do with such a relatively small team is nothing shy of amazing.

My kid also managed to get sick between the last release and this one, meaning I lost a couple days of work there too. Fortunately they're getting old enough to entertain themselves more easily now, and so I can squeeze in some time to work here and there.

On top of all that I've had a bunch of extra-curricular activities on my hands, including pitches, a presentation at a school, and a ton of admin (yay tax time) to handle in amongst trying to get this patch ready.

With all that out of the way, lets talk about Exoloper. The main thrust of this dev was two fold: Getting active utilities on the table, and beginning the rework the of the campaign.

Active utilities are more or less the same as they were in Interloper, with some neat new additions. Press a button, and something cool happens. I could probably write an entire post on why I kinda hate making these in games, but in short it comes down to the fact that I rarely pre-design their functions, and instead build them as I go. This means they're hardly ever accounted for in the codes architecture. Want to make an exo go faster? gotta hack that in. Spawn an energy shield? Hack it in. Zoom optics? Hack it in. You get the idea. Partially this happens because I'd ideally like them to be able to do nearly anything, to mess with any of the systems I've built for the game so far, and partially this happens because I happen to be not such a great programmer. The solution I came to was to simply build out the generic component, something the player can activate, has timers, disables when required, etc, and then to subclass each of the utilities to do their own thing on activation / deactivation / while running / while recharging. This mostly works for now.

mw3 inspired zoom lens, no.. not that mw3

As for the changes with the campaign, this is a little more holistic. The campaign as it has existed so far has divided sectors up into their function. Combat sectors give you combat, resource centres give you resources and so forth. This... sucked. It felt more like a board game and less like you were trying to unseat the local Commonwealth forces. Mechwarrior 3's campaign is a prime influence here, along with most other games that do a militaristic campaign (thinking early ARMA / Operation Flashpoint). The idea that a set of small strike teams go in to attack key components of the infrastructure of the opposing force is really tangible. You're not out to personally kill their leader, you're not gonna showdown 1 on 1 with their general, heck, you're not even facing the brunt of their armed forces, you're using fast moving attackers to quickly disable their key resources. Thats the feeling I want to give the player here.

The first part of achieving that is replacing the existing nodes with something more tangible. Instead of functional nodes, now each node is a place, be it a section of badlands, a Commonwealth fortress, fuel supply point or a stretch of highway, each node serves a narrative purpose.

The second part is moving the function of those nodes into parameters. A node can have a list of parameters, it can be a combat, it can have a difficult decision, it can give the player resources, and it can also be an extraction point. All of this is defined by values assigned to each node type, and a campaign dictates what node types are available. Once I've generated the map I start figuring out what nodes exist where, and defining the players objectives, so that now instead of the objectives being a simple number you have to complete, now they're targets you have to clear out.

The third part is tying the campaign world to the battle world a little more closely. This includes a day and time cycle, tracking weather, and more. Right now all of this has little effect beyond how it impacts sensors, it may as well be random for the player, but eventually I'll give you the option to wait at a node for a time of day or weather that works for you. I'll also add roaming enemies to the campaign map, and sensor complications that make it so that you don't have 100% visibility on where enemies are / what their force strengths are. This should all add up to give you a much more rich campaign experience.

As you can see there's a lot more to go with the campaign, but I think this release is a good step towards where I want that to be.

ma the rains are coming

Exoloper Tasks completed:

• Design: Campaign weather systems + day night cycle
• Design: Campaign node types
• Design: Campaign combat node evaluation now gives player resources
• Design: Campaign nodes now have to complete combat before being able to extract / use difficult choices.
• Design: Active Utilities added
• Design: AI - Unit Grouping (squads)
• Design: AI - Vehicles
• Design: AI - Awareness Systems (inc radar)
• Design: Missile Weapons
• Design: Energy Weapons
• Design: Vision Modes

• Design: Campaign map input allows double-tap to move.

• Exo Component: Zoom lens

• Exo Component: Smoke Launcher
• Exo Component: Shield Generator
• Exo Component: Fuel Injector
• Exo Component: Field repairs

• Exo Component: Generic Active Utilities added

• UI: Added ammo counters for weapons

• UI: Added recharge counters for Utilities
• UI: Added buttons to activate utilities

• UI: proper objective tracking in campaign

• Balance: massively increase Missile audio range

• Balance: reduced fuel consumption levels in campaign

• Bug: UI for utilities is dropped below screenspace on some combat scenes

• Bug: Player PaperDoll doesn't properly update on campaign start
• Bug: Player being destroyed doesn't always result in campaign loss
• Bug: Nullref throwing when attempting to edit an Exo in pre-campaign.
• Bug: Weather not spawning in combat
• Bug: Shadows in campaign look bad
• Bug: Environment lighting doesnt blend in weather controller.
• Bug: Rain at an angle looks bad in combat scenes,
• Bug: Nullref in MAST assets in prod.
• Bug: Missiles don't damage enemies sometimes?
• Bug: Refresh rate seems to be locked to 30?

• Bug: Radar UI doesn't turn off when radar component destroyed... sometimes

• Graphics: Set minimum render scale to 0.4

• Graphics: Campaign Weather systems
• Graphics: Reworked skyboxes
• Graphics: Reworked combat weather systems
• Graphics: Day night cycle imported from campaign

One of the things I really want from Exoloper is the player to feel like they're properly out gunned and outnumbered. You're running guerrilla warfare against a dug in colonial force, mobility and hit+run tactics are the name of the game here. Stand still too long and you're toast. At the start of the week I play-tested the game a bit, and there was something sorely not fun about having the entire map of enemies aggro'd against you from the moment the game loaded. To combat this I tweaked the AI's awareness systems and the UnitPart systems to build a radar signature for each unit, I then applied the same approach to a visual signature. All of this leads to rudimentary stealth mechanics for the game, do you take the most powerful weapons and risk letting every enemy know you're here, or do you go quietly taking out patrols around the map one by one?

I'm honestly super happy with the simplicity of how this all works, both from an implementation perspective, and what'll eventually be a user facing mechanics perspective. The larger your Exo's power draw + mass, the bigger it's radar signature. Making noise via firing simply adds to both your visual and radar contact range, and the same goes for enemy units. This means that if you're running rubbish sensors, enemy artillery should be a briefly visible target each time they fire.

Of course, if you've got stealth mechanics, you need some way of going completely silent, so that was a nice segue into implementing Melee weapons. Functionally they're just super short range projectile weapons firing invisible bullets with giant colliders. It works. So much of good melee though is selling that feeling of a hit, so a vast majority of the time I spent working on the system involved animation, knockback systems, impact sounds and sparks. The system that exists is fine, if a little rudimentary, but has scope to be expanded quite easily. Still, it feels excellent to crush a tank with a gigantic pneumatic hammer or slice an enemy exo with a crudely shaped sword. I also spent a bunch of time this week on AI behaviours, setting up their abilities to flank, to decide if they go toe to toe or back off when engaging enemies. All of this works independent of the player, so the option exists to setup firefights between multiple AIs that the player can take advantage of. As someone who's avoided doing much in the way of AI behaviours so far, it's gratifying to see them both a. doing the thing they're expected to do and b. doing so relatively performantly!

All in all a solid week. From here it's work on designing the specifics for the campaign and combat scenario types.

Exoloper Tasks completed:

• Core Systems: AI - Exo's
• Core Systems: Terrain
• Animation: stagger effects
• Animation: Medium Exo
• Map: City Combat Map #1
• Map: City Combat Map #2
• Assets: Unit: Medium Exo
• Assets: Cockpit: Medium Exo
• Assets: Cockpit: Pilot
• Assets: Unit: Artillery Tank
• Assets: Unit: Infantry Squad
• Assets: Weapon: Medium Ballistic
• Assets: Weapon: Medium Melee
• Design: Ai Behaviours
• Melee animations
• Icons for various weapon types
• Design: Unit types
• Design: Enemies
• Design: Weapons

Up until now I've been working on getting the bones of the game working, the bare systems needed for the game to function. Now I'm starting to work on some content, some design. I'm not quite out of the prototype phase yet, but it's getting close, and this week was dedicated to really dialing in the base combat for the game.

When I started the week I wanted to have the game in a state where combat (without extra utilities) was both fun, and kind of looked the way I'd like it to be, AKA, I want the player to be a glass cannon at all times, I want them to never stand still and most importantly I want them to feel when things aren't going well.

So I started off with some basic bits: Enemies didn't have much of an array of weapons, and getting hit didn't feel quite right. I added a bunch of new Howitzers of various calibres, created visual hit effects and staggers, and audio effects by layering several takes of me hitting baking trays on top of each other. (I'm particularly proud of that foley) I think the overall effect really sells being hit.

After that it was all about diversity in enemy types. For now there's just two bodies for enemy tanks, medium and super-heavy, but they cover both the average enemies and the boss types pretty well. After loading them up with the weapons I already had, I quickly sketched out the basic mechanics of the two missing weapon types: missiles and rails and added them in. Initially I had missiles doing AOE in a similar manner to explosive world items but I quickly realised that made them incredibly overpowered, and I want to dive into why.

Exoloper is built on a component system, each component can send and receive events back and forth between each other and their overall parent entity. I chose to build my own abstraction of this for performance reasons, but it's not too dissimilar to Unity's standard component system. This means that each "part" of a mech can be destroyed, from legs, to servos to engines and weapons, even the "pilot" is a part capable of taking damage. Several components are flagged as being "core" and their destruction will in turn destroy the unit, stuff like engines, the pilot, Legs for Exos, etc. As it stands the damage system from explosions just grabs all components within a collision sphere (because damage can only be done to a component) and damages them equally. This lead to situations where Missiles, designed to explode on impact or within a certain distance of their target, would just AOE the pilot every time.

Wasn't expecting that behaviour, but hey, its fun! In the future I'll consider changing the system so that it uses a raycast instead to check components that can be damaged. This should avoid an insta-kill on the pilot so long as the Exo's armour is in tact.

After adding missiles and working on enemy units for a bit more, I added Railguns. Again this was the kind of thing that took me a week or so for Interloper, but mere minutes for Exoloper. Goes to show what a couple years and a better framework can do.

All in all the game is shaping up to be pretty close to what I'd initially envisioned. It's starting to get that same hectic feeling that Interloper gives you, those sweaty "oh crap" moments when you turn a corner to see a heavy-tank or an enemy Exo staring you down. Most importantly it went from "I can see where this is going" to "I'm legitimately having fun playing this" this week, which is probably a good sign I'm on the right path.

Exoloper Tasks completed:

• Added: Hitmarker
• Added: Missile launchers
• Added: Railguns
• Added: Sub component loss
• Added: Missile Tank
• Added: Flame Tank
• Added: Howitzer Tank
• Added: Heavy Howitzer Tank
• Added: Super Heavy Support Tank
• Added: Super Heavy Long Range Tank
• Added: Tanks spawn wrecks on destruction
• Added: Stagger effect for heavy hits
• Added: Light sound effects for small arms hits
• Added: Heavy stagger on component loss
• Design: Unit types
• Design: Enemies
• Design: Weapons
• Bug: Player not autofiring on mobile
• Build New Sprint
• Map: Destructible terrain system
• Campaign: Gameplay conditions (win / loss)
• Campaign: Resources
• Campaign: Intro Map Layout + Decoration
• Campaign: 3D Map: Travel connections
• Campaign: 3D Map: Points of interest
• Campaign: Movement Systems
• Campaign: Battle Generation
• Campaign: Difficult choices system
• Campaign: Data systems

It's been a little minute since I last posted. The past few weeks have been... unstable.

The week after my last post I decided to take some time off. Bit of a long and personal story, so I won't go into it, suffice to say, I needed it.

The following week consisted of me struggling to get back into the swing of things after taking time off, it's part of the reason I don't take much time off. And then Starfield launched, and whilst I spent half a day playing that (Bethesda games are a huge favourite of mine, all their jank included) I was still out of sorts.

This week kicked off strongly though. I picked up on the major thread of Level Design for Exoloper. I'd toyed with some procedural generation techniques that... didn't work. More precisely the early experiments showed that (as I expected) I'd need to put a lot of dev time into each biome type and that there wasn't really much of a quick and easy solution. With that in mind, I switched gears and started looking into building my own level editor tools. I approached a bunch of options, but eventually decided that an asset would be the way to go, if your'e also a unity developer and looking to use something simple and extensible then I'd highly recommend MAST.

My level editing suite in all it's glory. Yes it's mostly default unity with a grid placement system.

Making the levels tile based, prefab inherited and importantly, relatively blocky makes it super easy for me to crank out new levels quickly, whilst also making it easy for me to make geometry kits for new biome types. I'm pretty happy with the way this has all turned out.

After that I spent the rest of the week doing some.. what I'd like to call stream of consciousness development. It's a super complex methodology that involves just bouncing from one shiny idea to the next bug, to the next shiny idea and so forth. None of it was structured in any sensible way. One minute I was tweaking projectile speeds, the next implementing exploding silos (thanks moe_from_famly_guy). Then onto improving the sound effects for the Exo's, through to fixing splitting up torso armour and then fixing bugs from all the chaos I'd done.

legendary suggestion

I try not to do this fugue-state style of development too much, as it's where most of my bugs come from, but conversely it's where a lot of my game's feel tends to kick in. The moments of going "hey wouldn't it be cool if..." and then just putting that in the game. I distinctly remember the first time I did this. I was about six months into developing Unstoppable, I'd had some breakfast, and was sipping coffee when as I was idly thinking through some implementation ideas about putting a pneumatic hammer into the game, I realised I could create a damage zone and attach that as a weapon to the trucks. Boom! Buzzsaws! It's was a trivial idea, but I genuinely had no idea how to do it before then. I spent the next hour or so on modelling + animating and coding the buzzsaws, and then the rest of the day ripping enemy trucks to shreds with them. I knew I had something good right there.

Anywho. Good Times.

Onto Unity.

I'll be upfront. All my previous games have been a pay once and play situation. I personally hate the idea of microtransactions and in game currencies. I strongly believe that if you've bought a game you shouldn't have to think about the money side of the fun equation again. But. My business plan for Exoloper was to make it free, and then charge for additional campaigns, which would come with not just new maps but new scenarios, new weapons and new enemies. A way of monetising not just the core initial offering but also covering the cost of ongoing development. It was the fairest way I could conceive of making a free to play game.

Then on the 12th of September Unity released a blog post changing their pricing structure and effectively charging for each install once a set of (not as high as they seem) thresholds were met. They also deleted the payment plan that I've been using for years now, which will force me to pay nearly 2.5x more per year for Unity. The issue here is that if I have to pay per install, and I'm expecting a small percentage of installs to pay, then I'm setting myself up for failure.

After the initial shock and disappointment faded I knew I had to drop the engine, it was just a question of when. I spent a day evaluating the next best thing, Godot, and whilst it's good, it's not quite ready for me to jump ship. Particularly, it's iOS support is a little bit lacking. Thats all good though, I will switch to it once Exoloper is released, just... not right now.

In the meantime I've made some adjustments to the business model for Exoloper that I think will both work pretty well, and should cover me in the case of runaway Unity install fee costs. I'll talk about this in more detail as the game comes together / as Unity reveals more details about their price changes.

I'd like to leave on one last note: Be kind to the people working at Unity, they likely didn't have much of a say in all of this, as at the end of the day the decision really feels like a top level business decision more than anything else. So please be kind.

I'm sure there's good business reasons for Unity to change their pricing model, I just wished they'd talked to some devs first about it and come up with a change that was reasonable.

Exoloper Tasks completed:

• yep. I did things.
• Level design tools created
• Exploding silos
• Improved sfx for autocannons + footsteps
• Torso twist + sfx added
• Weather systems added
• I know I did some other stuff....

This week started off slow by moving the unit data code into something a little more generic, allowing me to track the status of all player units across campaign and battles alike. In short, if you or an ally gets damaged in a battle, it'll carry across to future battles through the campaign.

Simple enough data stuff, and really not a lot to write home about.

My major task this week was to figure out how I was going to deliver campaign maps. My initial thinking on this was to hand make them, build them out in the editor and more or less manually assign the data for each connection, node and more. But the more I played that first campaign map (pictured above, left) the more I began to optimise my decisions and the less I felt like I was having to face new decisions, and that really didn't gel with the feeling I wanted for the player whilst going through a campaign.

A little aside on my approach to game design: I always design with an emotion in mind. I want the games look, feel, and structure to evoke a particular kind of feeling. In Unstoppable, that was simple: "HELLYEAH!". In Interloper it was all power fantasy, I didn't really care about difficulty as much as I did about reinforcing that idea of going against the odds and winning. In Exoloper I want you to really, really consider if violence is necessary and when. Your job is to push the colonial forces out of the system, but not at the expense of your own forces. A big component of that is to evoke the idea of cautiousness, and an optimised, pre-travelled route through a map is the bane of caution.

So I looked into procedural generation once more. I tried a handful of techniques I'd used in the past, scattering nodes randomly, grid placement and more, but none were reliably good looking nor could they give me a dataset that was easy to work with. So I decided to take the plunge and look at Voronoi generation. I'd toyed with this in the past but it all seemed a little too complex for me, but for whatever reason it clicked this time. I grabbed a library played with it, tweaked it and finally started building my own data structure that I could save + load easily on top of it.

I'm not the worlds most technical person, so I'm not going to pretend I really know whats going on under the hood here, but the end result is that I've got this cool map of polygons, their centres and corresponding edges. From a game design perspective it was as simple as placing nodes at the centres of these polygons, then using some systems I'd already written to join them together, this time just filtering those connections by adjacent edges to ensure there weren't any crossovers. Throw in some dice rolls for allowing multiple connections on particular nodes and we've got the system.

Immediately I began to see cool things crop up. Highly connected nodes looked like city centres, with branch nodes becoming rural as they got more remote. This is all stuff that I'll work on further later on, but for now there's a lot of possibility.

Anyway for the time being this is where it's at. It loads in a handful of tiles at varying probabilities, with special tiles for specific node types. I've also started work on biome generation, with the idea that I can blend them to allow for things like jungle biomes intersecting with a city, rural intersecting with water and more.

All of this has been fun. Almost makes me feel like a real programmer.

The rest of the week was mostly dedicated to fixing up some issues, adding reload mechanics to the battles, filling out more utility loot options (new reactors and engines) and building out better systems for delivering data to unit-parts.

Next week I plan on looking into map generation for battle maps. Maybe I'll do some more procedural generation there... maybe?

Exoloper Tasks completed:

• Determine if Campaign maps need to be procedural.
• Do a proper build of a campaign-map
• Scope out remaining features
• Campaign: Map Generation
• UI:Roster Auto-Fill Unit slots
• UI: Roster - Fill up on fuel / parts
• UI: Campaign: Battle Results + Data
• Tie procgen campaign map to actual gameplay
• Make custom editor for unit parts
• Build Biome based prefab containers for campaign maps
• Gameplay: Add reload mechanics
• UI: Campaign - Repairs
• UI: Show all roster paper dolls
• EDITOR: Build out Exoloper control panel
• Campaign: save whole roster data
• Seperate movement from inputs and unify movement

• Refactor anything with "Mech" into "Unit"

• Bug: Delete all data does not hide "continue" button

• Bug: Campaign UI info doesn't update properly on load
• Bug: Extract UI overlaps
• Bug: Roster menu going back gets stuck
• Bug: Can't delete units in rosters
• Bug: Campaign selected poi edges aren't properly highlighting
• BUG: enemies don't stop when they see the player.
• Bug: AI aren't shooting at the player anymore

This week was a bit of a slow one. After the first closed alpha launch last week I got to work on fixing bugs and cleaning up the codebase. For the most part I began work on the games tooling.

The cool thing about where the game is right now is that it's become very clear where it needs to be, and how long it's going to take to get there. This is something I spent so long in the dark on with Charge. There's a lot missing from Exoloper right now, and a lot of work will still need to be done, but at the end of the day I know exactly what that looks like.

A good example is some of the work I put into building out the prefabs for units in the game. Building out the base of this smartly will make it much easier to add new units in the future. Making sure there's a minimum amount of places where user error can happen will reduce the amount of bugs that can happen from poorly constructed components. Setting up proper validation will reduce that further.

In the prototype I launched last week, everything is hand build, very little is constructed at runtime, but I'm slowly shifting all of that over to a tooled system that allows me to quickly and easily crank out new assets whilst giving me flexibility and complexity to work with.

the medium-exo in all it's editor-prefab glory

Because of introducing little, not-so-flashy systems like this, it was relatively trivial for me to add friendly AI to the game (it took about three minutes to code, and an hour of bugfixing). Same goes for extending radar systems and AI awareness to the actual installed Sensors component. Now the quality of the sensors dictate not just how frequently / far you detect enemy units, but also how the AI handles them. More advanced sensors give AI more choices for combat.

One thing I've been mulling over from a design perspective is whether to keep the current slot-limitations for components. Currently components are limited to particular slots, a weapon can only be placed in weapon slots, engines in engines etc. If I removed that, you could come up with some absolutely cooked loadouts (engines on arms? reactor on hips?) but it also might lead to some amazing strategies and opens up for potential emergent gameplay. It's very much an accessibility vs openness question that I'll have to think about.

Exoloper Tasks completed:

• Show Defeat reason in campaign
• Unify unit locomotion (make it all navmesh agents?)
• Add Camera Shake setting
• Add Haptics toggle setting
• Add control sensitivity to settings
• Fix missing hit sounds
• Clean up entity + components in exos.
• Genericise paper doll concept
• Tie Campaign Hull to Exo status in battle. Show Paper dolls on campaign map.
• Unit auto config systems
• UI: Campaign: Extraction

• UI: Settings

• Bug: Can walk through enemies

• Bug: Sometimes can't walk backwards
• Bug: Sometimes player mover gets stuck
• Bug: AI Exo's don't animate
• Bug: friendly ai don't have a targeting icon.
• Bug: Infantry don't work well at all
• Bug: Tanks are kinda broken
• Bug: Target icons don't always show up.
• Bug: Nullref when selecting a unit
• Playtest the heck out of the game on device. Clean up rough edges.
• Bug: Clicking on Settings Nullrefs

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.

Exoloper Tasks completed:

• Playtest the heck out of the game on device. Clean up rough edges.
• When your legs get destroyed game wigs out. It expects player to die via torso, not legs.
• Core Systems: Radar
• Upload to testflight, get that process going.
• add some sounds
• Assets: Unit: Light Tank
• UI: In Game - Mech / Vehicle Paper Dolls
• UI: In Game - Touchscreen controls
• UI: In Game - Radar systems
• UI: In Game - loadout information
• Build New Sprint
• Core systems: Movement
• Core Systems: Ballistic Weapons
• Core Systems: Base Projectiles and Weapons
• Core Systems: Prefab component constuction for Exos
• Core Systems: Component Damage + desctruction

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.

Charge Tasks completed:

• Bug: Rout retreats to spawn point, not board edge.
• Significantly condense logs
• Bug: p2 for game centre games doesn't pick an armylist?
• Bug: First replay text doesn't show.
• Bug: UI recycleables disappear?
• Bug: Turn 0 should be shown as "Turn 1"
• Bug: Changing the current replay state manually with slider doesn't pause replay
• Bug: Dice rolls sometimes don't appear (again, recycler..)
• Bug: Replay pause button doesnt work.
• Bug: Replay shows empty logs
• Bug: After replay all the orders show up on in game screen
• Bug: Local game, not switching properly again.
• Bug: Entering pass and play, exiting pass and play then selecting game centre (or vice versa) locks game type selection
• Selecting a unit then ordering an ability does not deselect the unit.
• Bug: Leadership rolls don't show up in log.
• Bug: Archers trying to fire after turn one fail because they count as moving?
• Bug: No rolls show up in summary log.
• Bug: targeting enemies with "Ranged Attack" immediately bails out of target screen
• Bug: In Waiting Screen, p2 presses "ready" button doesn't dissappear.
• Input: Touch
• UI: Pick Armylist View
• UI: Invite Opponent
• UI: View Army
• UI: Settings
• UI: New Game View
• UI: Games View
• UI: Main Menu
• UI: Alpha Test: Add Help page to in game view / Deploy view
• Unit Painter: Unit spins too easily
• Unit Painter: not zoomable?
• UI: Not clear the button to get to paints is the unit logo
• Bug: Armybuilder: Inconsistency beteren "Armies" and "Rosters"
• Bug: Deploy screen: Hard to deselect units
• UI: Leader ranges need to be always visible during deployment?
• Gameplay: Camera needs to be able to zoom out some?
• UI: "Continue" on mainscreen is confusing, maybe use play? Begin?
• UI: Tick on armylist select in roster selector is confusign, should be an eye
• UI: Banner Style flow is confusing, add continue button on create flow.
• UI: Unit picker needs to show that at least one leader is required for a force.
• UI: unit id numbers are confusing. Deprioritise them
• UI: Unit picker needs to show a better summary of owned units?
• UI: Need to show maximum points on unit picker.
• UI: Unit picker gives information overload. Consider redesign
• UI: Show all three armylists for launch, only enable one for alpha
• UI: Alpha Test: Add quick tutorial tip on GameType page for using Game Centre || Ready screen
• UI: Add link to armybuilder from newgame if player has no army
• UI: Add "Waiting" to ready screen
• Bug: Local game often has the camera at the wrong spot
• Can't pivot units on default deployment
• Bug: UI scale in settings doesn't work
• Bug: in-gameUI shows through during non-ingame moments
• Bug: have to press twice on delete game for local games in games view
• Bug: Upgrades aren't saving to roster?
• Remove user editable Roster names.