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.
When I decided that procedural generation was too much bother for not enough gain and switched over to hand-crafting scenarios, I figured that was the worst of my development headaches gone. After all, the more data that is static, the less you have to worry about while the game is actually turned on.
Then I realised that you’re still going to die a reasonable amount of times during the game. Then I realised that although the levels will be individually smallish, they’ll still be quite open.
What does death plus openness equal? Why, my dear, it means I must let you save and load your game, because fuck losing all that progress (to death or dinner).
For some reason, it has become a festive tradition that I replay UT2004. To the festive tunes of artists I never listen to at any other time of year, I will joyously frag my way up the singleplayer tournament ladder and… dream of how it could have been?
For the UT2004 singleplayer ladder has a “team management” mechanic that ultimately offers nothing but fires my creative juices right up.
Movement is very important in Exon. Beyond merely getting around you’ll need to keep moving to avoid attacks and get the drop on your enemies, and you’ll want to explore to find alternative routes and secret bonuses.
Although it is operated top-down, it is a game in full 3D — height is important for exploration and all the mild platforming that will entail. That, however, made the logic that controls movement very very very complicated.
Can you guess what’s coming? I think you can guess what’s coming. I just rewrote my core character movement system!
Being able to build big plaps of landscape is one thing, but earth is nothing without water.
Water is one thing I do not miss from my Warcraft III days. It was at a fixed level (give or take some dodginess), it didn’t flow in any particular direction, and it had very little impact on gameplay. The best rivers were pure decoration constructed from massively skewed waterfall models.
No, it’s time for me to break free and do rivers properly.
I mentioned in my last post that when I first tried to make hand-crafted levels, I lacked the tools to make it work; hence my slide into the clutches of procedural generation. So what’s changed?
Why, I’ve started to reimplement the Warcraft III terrain editor.
The Worm Ouroboros, that forever eateth its own tail. That’s my development cycle.
I spent a year and a half, maybe even two years, building Exon as a procedurally-generated dungeon crawler. Over that time I rewrote the level generator at least six times, edging ever closer to a system that would actually make nice playable levels and not be insane to extend and tweak.
Then I decided it was time to finally attempt natural cave levels to break up the bunkers, and the whole thing fell apart again. Feeling that the near-constant rewrites of the level generator suggested a more fundamental problem with my approach, I have decided to change direction.
Pretty much everything I do in Unity, I compare to what I could do in Warcraft III. One of the most surprising (to me at least) omissions was the ability to make custom materials. That is, being able to layer, blend and animate textures to create a final look for your characters.
In this strange modern worlds, such things require one to make shaders. That means a whole heap of extra programming work, and some pretty esoteric programming at that.
Then they invented lovely graph-based shader builders.
