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. project management: satisfying at best ...

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

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

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

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

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

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

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

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

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