This week was a bit slow. We’re in the middle of trying to buy a new apartment (and sell our existing one) which has been particularly stressful. 

The main brunt of the work for this week has been reworking the existing UI in the main menu to match the newly made graphic designs. There was one major issue preventing me getting started with this though. The UI framework I’d built was primarily built for mobile screens. 

I’d made some relatively hacky changes to it for Interloper to allow it to sort of conform to larger screens, but at its core it only ever allowed one “view” on screen at a time. What I really wanted was to show multiple views on screen at once on a larger screen (iPads, desktops and tv’s). This should make the game feel more native across the board, but this provides a bit of a technical challenge.

I needed to change my existing UI framework from a view to view based system to a ViewController with subviews  whose visibility is controlled by a media query. So in the above example, we’ve got three views that can transition to each other on mobile, but all three are visible on desktop. There’s some subtler differences too, the navigation buttons are gone, and there’s only one heading. The general concept is that the UI should be grouped into these larger views, then when it comes to mobile, inject a navigation layer between the sub views. 

So I ended up spending half the week retooling my underlying UI tools to support this paradigm. The end result works pretty much as expected. Supporting all these various aspect ratios is a bit of a pain, but I think it’ll be worth it in the end.  So far this week beyond the system upgrade I managed to get both the main menu and the campaign choice views complete, only ten more pages worth of this to go! (wish me luck) 

Beyond the UI work this week I also spent some time finalising my content for the Australian governments Emerging GameMakers fund application. I realised after submitting the application that it’s really for… game ideas and games in preproduction… not… games that are in beta. Whoops. Ah well, good experience. 

Exoloper Tasks completed:

• System: UI needs to properly respond to show multiple views on larger screens.
• UI-Rework: Campaign Page
• UI: Identify all pages requiring reworking
• Emerging GameMakers fund application
• UI-Rework: Main Menu
• UI: implement proper view handling for multi screen views
• Graphic Design: Build layouts for all aspect ratios

In 2015 I was asked by someone I used to help out from time to time to do some graphic design work. Up until this point most of my graphic design had been completely in games, but this was for an app. I said sure, why not. I was freshly out of a job, wrapping up work on Unstoppable and kinda needed some cash. What I proceeded to make was utter crap work, wasn’t proud of it, but I got paid. 

Since then I’ve worked on improving my skills, once again self taught. I eventually picked up a full time job with the person who contracted me for a couple years, mostly doing graphic design, game dev and app dev. 

Now I wouldn’t say I’m a great graphic designer, but I can certainly do the work and this week consisted almost entirely of graphic design work. While I’d spent some time near the start of the project laying out colours and basic layouts, this week was a complete pass. I went over every screen, filled out missing ones, refined existing pages. Honestly I could probably spend another two weeks on this, but time is of the essence, so what I’ve managed to get done will have to do. 

The net feeling is much a tighter and more controlled iteration of what I already had. I did spend some time looking at alternative designs, different colour palettes and such, but nothing could quite tear me away from this lovely shade of purple. Overall I’m happy enough with where this is all going. Just have to design for all the screen orientations and sizes now. Wish me luck!

Exoloper Tasks completed:

• Graphic Design: Figure out menu backgrounds.
• Graphic design: figure out required icons
• Graphic design: Icon – max weight
• Graphic design: Icon – component genre
• Graphic design: Icon – campaign menu – roster
• Graphic design: Icon – campaign menu – tutorial
• Graphic design: Icon – campaign menu – quickplay
• Graphic design: Icon – campaign menu – Continue campaign
• Graphic design: Icon – campaign menu – new campaign
• Graphic design: Icon – roster – Mark unit as player-controlled
• Graphic design: Icon – UAV
• Graphic design: Icon – edit unit – paint unit
• Graphic design: Icon – edit unit – saved loadout
• Graphic design: Icon – inventory – component properties / sort types
• Graphic design: Icon – campaign – exobay
• Graphic design: Icon – campaign – campaign remaining time
• Graphic design: Icon – campaign – salvage
• Graphic design: Icon – campaign – repair
• Graphic Design: Menu Campaign: Hall of honor (completed campaigns) (resets on loss?)
• Graphic Design: Settings: Save handler page
• Graphic Design: Controller: Edit bindings
• Graphic Design: Settings – in game – vs – menu
• Graphic Design: Full graphic design pass
• Graphic Design: Identify missing pages.
• Graphic Design: Unit Editor: Saved builds (think the auto-buy loadouts from Hunt)
• Graphic Design: Quickplay: Build exo
• Graphic Design: Quickplay: choose mission
• Graphic Design: Unit Editor: Paint Exo
• Re-evaluate remaining Todo’s for Exoloper based on current knowledge
• SFX: Vehicle Movement
• SFX: Exo Movement
• Identify tasks for DLC features

I skipped posting here last week mostly because I couldn’t be bothered. That happens sometimes. Life’s too short to get all tied up on some deadlines. 

The past two weeks have had me wrapping up a lot of the loose ends for Exoloper’s Alpha phase. I’d be lying if I said it wasn’t satisfying as all heck to tick the last box in the pre-alpha phase. 

With gameplay more or less sorted for combat and meta-game inventory, the last part that needed unfolding from its prototype phase was the campaign. There were a couple systems missing from the campaign but I honestly had no idea what exactly they were, only that the campaign lacked any kind of tension. It was mechanically easy to complete the objectives and extract, and there didn’t seem to be any real challenging decisions along the way. 

So I played the living heck out of the campaign. I spent half a monday playing through campaign after campaign after campaign to get a feel for what worked, and what didn’t. I found a couple things

• There was no resource tension. Partially a balance issue, but, you could leisurely run around doing whatever you want. Fuel did apply a resource cost, but on its own it wasn’t enough.
• The player had perfect knowledge of the world. You know your path as soon as you drop into the world, making it just a matter of choosing the right nodes.
• The decision system wasn’t filling the narrative role I wanted it to fill.

And voila, I now had a plan for the things that needed to be changed. So now, when you start a campaign, a mechanic not unlike Darkest Dungeon’s recon system reveals the contents of nodes that are close to you at semi random intervals, a new rare and limited resource (UAV’s) has been added to allow you to fire this recon at will, paths between nodes are hidden (though not inaccessible!) and decision nodes have been hidden entirely. Now it really feels as though you’re traversing unknown territory and finding your way through a dense colonial cityscape, and you’re always at risk of spending too many resources on going the wrong way, or running blind towards your goals. The one concession to all of this extra difficulty is that at any point you can choose to leave via a spaceport/space-elevator, and that you always start at one. 

Beyond the campaign, another critically missing piece was the games tutorial systems. Interloper launched to an extremely lacklustre, and text heavy tutorial. This time I want to give the players time and space to figure the game out at their own pace, whilst also reducing the amount of text I throw at them out the gate. 

The main goal here is to get the player to learn the combat games basic controls using level design as a main teacher. I monitor the player unit’s condition for things like “current speed”, wait for trigger boxes, or enemy destruction and change the state of both the tutorial and the UI accordingly, revealing new controls as the player completes objectives. 

I’m proud as punch of what I’ve built so far and It’ll be much harder to introduce concepts in a similarly progressive way for the campaign and for the exo builder, but I’ll figure something out. I fully imagine what I’ve built so far isn’t going to be anywhere near final, but it’s a starting discussion point for the alpha community. 

And then the final piece of the puzzle for Alpha. Monetisation. 

I’ve been avoiding this topic here because my decisions around monetisation have flown in the face of every game I’ve released under the Anchorite banner. I strongly believe that the App Store deserves high quality games where you, the player, do not have to think about money after you pick the game up. Thats how I grew up playing games, and I find most games with micro-transactions to be insulting in that the purpose of the game blurs from an entertaining product to a wealth extraction/generation machine. 

With that said, Interloper has to this date sold 31 thousand copies. I’m incredibly proud of this number, but it’s netted me a living wage of averaged out to AUD $34K / annum (which incidentally is under the minimum annual wage in Australia, of 39.9K).This is despite having a worldwide feature at launch where over 50 miillion people saw its app icon, and a continual set of minor features that net approximately one million views each week. Thats still 34K that I’ve earned from my work and as I say, insanely proud of it, but it’s not enough (literally).

With all of that context: Exoloper will be free to play. 

But.

I still want to create a game that treats it’s players with respect, and so the monetisation strategy is as such:

The core game, with a single campaign will be released for free. That’s more or less what the Alpha is right now. All the existing weapons, utilities, enemies, and so forth are included in this base game. Thats a lot of value for literally nothing. If you so choose though, there will be three additional campaigns built for the game. One will be available at launch, and two more post launch. Each will include a new campaign map, new biomes, environments, combat maps, weapons, utilities, exos, weather and more. These will be priced at $2.99 (USD) each. Anything you unlock for one campaign can be used in any other campaign. 

And thats it. My hope here is that instead of trying to convince new players to spend money on the game out with a couple screenshots and videos, I’ll do that instead with what I’m actually good at, which is making a compelling simulator experience. 

I’d love feedback on this idea, so if you’re reading this and you have thoughts, please feel free to reach out to me. 

There’s one last thing I’d like to cover today though, Interloper Discord member NoLeternox made some incredible, industry quality fanart for Interloper a while back, and I just couldn’t resist asking them to draw up some sketches for Exoloper. What they’ve come up with is absolutely gorgeous and I can’t wait to turn some of these into Exos / tanks in the game!

You can find their work here: https://www.instagram.com/leternox/

Exoloper Tasks completed:

• Graphic design: Campaign page
• Graphic design: Difficult decisions page
• Graphic design: exploration of design identity
• IAP: Add a tip jar?
• IAP: handle iAP’s not being available?
• IAP: Handle Purchase failed
• IAP: Split off “waiting” screen from the new campaign view, make it pop up anytime there’s an IAP pending
• IAP: Disable iAP for regular testflight builds
• IAP: Handle purchase clicked more gracefully
• IAP: Handle restore purchases
• Tutorial Systems
• Tutorial: add to main menu + block gameplay.
• Tutorial: Combat tutorial implemented
• Tutorial: objectives
• Tutorial: enemies
• Tutorial: movement
• Tutorial: Shooting
• Tutorial: optional gameplay elements
• UAV nodes reveal over time now
• Map: Weather (Sunny)
• Map: Generation / layouts
• Core Systems: AI – Infantry
• UI: Campaign – Difficult decisions redesign
• Deal with cost requirements for difficult decisions
• UI: Campaign –  Node information page
• Campaign: Visibility of enemies
• Limit epic loot to objective missions + only when they’re complete
• Campaign: Deal with combat scenario fail states
• UI: Campaign – Difficult decisions redesign
• UI: Campaign –  Node information page
• Deal with cost requirements for difficult decisions
• Campaign: Visibility of enemies
• Limit epic loot to objective missions + only when they’re complete
• Campaign: Deal with combat scenario fail states
• more balance tweaks, fixes for double click moving the player when it shouldn’t
• fix for bug where loot + parts were flipped on combat resolution
• added in mission time
• balancing decisions
• difficult decisions reworked to use a % of player resources
• resources now show on decision page
• rebuilt difficult decision system
• added radar POI, fuel POI now drops more decisions, sorting inventory by rarity.
• Updated campaign objective UI
• campaign objectives properly reflect the task at the poi
• added UAV system to campaign
• campaing fog of war added.
• combat objective ui notifies on failure
• added defend-building missions
• added penalty for failing objectives
• added penalty for failing missions

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 : 

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. 

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.

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. 

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. 

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

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.

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. 

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