It’s been a while since I last wrote anything, that’s for sure. Before I get to rambling about the reasons (excuses?) for that, here’s a new video of Exon: from starting the game to playing an Arena match to indulging in the side-questy exploration that will make up… the actual game. Some glimpses of the inventory, journal, shop windows and even a surprisingly seamless performance of the save/load system are included!
The natural counterpart to the inventory screen is the shop. It’s one thing to be able to pick up, equip and drop loot, but that is only half of the ecosystem. The other half is offloading that loot so you can
hoard your wealth and never spend it because the best items are actually always in the world buy better things.
This week, I have been building shops… and quests, so you’ll have some money to spend in them (without me having to litter the train station with gold ingots).
Much as I decry the trend in games of giving the player objective markers and leading them around by the nose, they can’t be expected to remember everything — especially in a complex RPG with many moving parts. Since I am intending to build a complex RPG with many moving parts, I need a place to store information about your current objectives.
Enter the Journal.
The inventory won’t be particularly useful in the Arena, so I don’t really know why I’m doing it now. It may not an essential feature for the initial demo version of Exon, but it is an important feature for the long run — after all, you’ll find lots of equipment in your travels, not all of which you’ll want to use immediately.
So here I am, doing the inventory screen anyway because my mind did that thing where it started to fixate on the feature for no particular reason, and who am I to deny my subconscious whims?
All of life is about compromise. I started off making my mechs use the CharacterController, but shied away from it as that meant I had to reimplement lots of physics. I replaced it with a Rigidbody-based system, but that started randomly bouncing off the floor and jumping was dangerously unpredictable. In movement system rewrite number three, I seem to have ended up with… a mix of both.
It took me far too long to understand why this third approach works, but I think I’ve got it now. Since movement controllers seem to be a perennial topic in the commUnity, it’s time for me to add some words to the mix!
I’ve been putting off adding audio to Exon for, at this point, years. I didn’t want to tackle it until all my other systems were pretty solid — I didn’t want to shove in a load of work to manage audio sources and play effects if there was a risk that I’d be re-engineering half of it after the fact.
Well, things have now been stable enough for long enough and… Well, I got put on furlough by my employer. What else was I going to do with the extra time locked in the flat but suck up a major project?
Since long before I started work on Exon, I was gripped by one action-RPG ideal: that if your sword intersected an enemy, then it should damage them. I suspect this arose from the likes of Morrowind‘s secretly dice-roll-based combat, where visually hitting somebody was no guarantee of actually hitting them.
Exon is broadly a game of melee attacks, so obviously when I started building the game I immediately implemented a system that does exactly that: using physics colliders, sword blades deliver damage as soon as they intersect a viable target.
Objective achieved, job done. So why does this system cause me so much concern?
It’s a new decade, and Exon is officially six years old. That’s three times as old as my previous record holder, the WC3 total conversion Project Y4, which clocked in at two years. And it’s not even done yet! Not even close to done!
The Arena, however, is done. You can jump in, smash up some bots, and either win or lose. Which means it’s time to FEATURE CREEP YEAAAAAAAAAH! (It’s not feature creep if they were planned all along.)