So I have a level editor for Exon. It’s still a bit sketchy around the edges, but it does the job: I can place decorations and modify terrain and live happily ever after.
But in a singleplayer RPG, decorations and terrain are only half the battle. These things have no life but the life I build into them, and that means I need a level scripting system.
Can you see where this is going? Oh yes.
The wonderful world of Unity editor tools is one of the most complex and irritating worlds I’ve ever had the pleasure to explore. Alas, it is one that I have to explore because I want to make it very easy to build levels for Exon. I want it to be as easy as farting out Warcraft III maps was, back in the day. Once I’ve built the engine and all the relevant bits, I want to shut Visual Studio down and never write another line of code for the rest of my life.
To get even close to that ideal, I have to go through a whole WORLD of pain — and the realisation that maybe, just maybe, one bloke in his bedroom can’t hold a candle to one of the greatest engineering marvels of the videogame world. Whatever happens here, nobody will be building the next DotA inside Exon.
I’ve made no secret of the fact that Exon‘s core loop is based on Westwood’s classic and criminally-underrated action-RPG Nox. This manifests itself most clearly in the movement system: hold the right mouse button to cause your hero to walk towards the cursor, leading them around the world like a little mouse following the cheese.
Similarly, I took the melee attack system, where each click causes a single sword slash, damaging whatever has the poor fortune of standing in your blade’s path.
Except then I realised that, actually, I didn’t. Nox has a more complex and interesting “stamina” system controlling its attacks than my naive cooldown attempt, and it contributes immensely to all the feelings I had been struggling to recapture.
I might spend most of my time gushing over story-driven role-playing games and shooters, but I’m still partial to a real-time strategy every so often. I like building up a base and training all the little people and sending them off to conquer in my name.
The thing I don’t like about RTSes is that they’re all designed to be played against other people in fair and balanced short-form matches, whereas I like sinking into stories and experiencing them at my own pace. I want an RTS without that multiplayer pressure, one that has the time and space to ride all the way into the sunset.
I’m too busy building Exon to even consider a different project, let alone one of such magnitude, but it’s fun to think about these things now and again. So let’s talk about the RTS that I’ll never make…
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!