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.)
My favourite joke format at the moment is this: “It’s only X if it comes from the X region of France, otherwise it’s just sparkling Y.” In this case, “it’s only artificial intelligence if it’s from the AI region of France, otherwise it’s just sparkling if statements”. I can dunk on AI hype, you see, because I’m programming AI for my game again.
I’ve done quite a bit of AI programming already. The bots have fairly well-developed situational awareness — if they see an item they want they’ll move to pick it up; if they see an enemy they will attack; and if they are fighting they’ll use their abilities.
What they lack, however, is strategic awareness. Seeing as the Arena will have bonus objectives, and the same logic will power boss fights and full characters in the campaign, bots are going to need to that extra layer of intelligence.
So, a few months ago, I paused work on Exon’s main campaign to focus on building the Arena. This approach came with some risks but I decided to swallow them because this felt like it would be the fastest route to something genuinely playable.
I was right, because that was about three months ago and for the last few weeks I’ve had it out at local game dev events and being played by real human beings. It is by no means a finished game, but it is a fully-functioning, self-contained scenario that stresses the breadth of the game’s core combat mechanics. A vertical slice. Objective complete!
It’s funny because my mechs’ primary attacks are vertical slices.
I was at a game dev meet-up about a month ago now, where my pals sassed me silly for not having shipped a game yet. They’re right to do so — although I vigorously resist accusations of feature creep (it’s not creep if it’s all part of the original plan), it’s true that I’m making something rather large that isn’t going to be releasable until it’s “done” (this is the true curse of building narrative-driven things).
About a year ago, I set down my plan for the first release: a self-contained prologue to a bigger campaign, which would be short enough to manufacture in a sensible time-frame, but broad enough to stress out most of my features. “Sensible time-frame” is, of course, relative and it’s still got a long way to go.
So I asked myself: what’s the minimum viable game? What is the purest, simplest expression of top-down mech action that I can build and put in front of people?
When I was looking for pointers on how to do saving and loading, I was frustrated at the lack of depth in the tutorials that I found. I couldn’t find anything that went beyond explaining PlayerPrefs and serialisation. I mean, yes, duh, I have to read and write the data — but how should I structure it? How should I find it? What’s the best way to put it together again? What did you see?!
Thus, having recently finished a fully armed and operational saving and loading system in my own game, Exon, here is a complete run-down of how it works and why. Although I would expect saving and loading to be personal to the architecture of a particular game, I feel like I’ve ended up with a very flexible and generic system, so hopefully this dump will give future people a decent idea of how to approach this most important of features. Plus some reassurance — it’s actually not that scary!
So, I’ve been fairly quiet recently because 1) developing saving and loading systems has been a long invisible slog and 2) I’ve been replaying Morrowind (oops).
But with all the data that comprises a “campaign” in Exon being successfully written to disc, it was finally time to start trying to load it. Since I’ve told you the story of decomposing the world into text files in more than enough detail, it’s time to begin the story of reconstructing it…
Right, so my last dev diary was mostly theoeretical — how can one ensure every prefab and pre-placed object in Unity has a unique identifier that can then be associated with saved data and used to reassemble the game world later.
Having implemented said indexing mechanisms, there are a few gotchas to report, but it is overall working as advertised. Which means I have begun phase two: actually writing the data out.