Of course Exon: Fragment is full of bugs; I’m only one man and it’s composed of flexible systems that can interact with each other in ways I could never have anticipated. Also people have deliberately been trying to break it rather than just playing it naturally… But hey, that’s exactly why I’ve released this chunk quietly: so I can get all that stuff sorted before launching into the rest of the game.

But what stuff I’ve got to deal with, ooft.

Fragment v0.02

The thing about Exon is that, for all it’s a top-down action-RPG, it has a lot of immersive simulation blood in it. You’re meant to be able to explore the world and find awkward ways into places, to bypass different challenges you might not be equipped to deal with (and/or want to avoid spending resources on). That’s why there are 3 different kinds of jump and the Harpoon can pull you across gaps too.

The downside is that this makes level design expontentially harder, because it means any gap or stepped surface can be exploited to escape the intended game zone. In most of the campaign this won’t be too much of an issue, because the places you visit will intentionally be open to abuse, but for the Gauntlet which is specifically an enclosed, linear course… Well. Let’s just say I’ve had to make some more decoration models to ensure the walls are a bit higher at key points.

I refuse to use invisible walls because the Gauntlet is meant to teach you how the game works and if it looks like you can get over something, it should be possible to get over it. Just might take a few iterations for me to get the balance right.

That’s only the first half of the problem, though. Because Exon is a truly three-dimensional game, its landscape is composed of three-dimensional collision blocks — you may not be able to walk through that rock, but if it’s not too tall you can get on top of it instead. This leads to a situation that is a lot more common than I anticipated, that of getting wedged between awkward surfaces. This is a side-effect of how I’ve optimised the unit movement systems and how they determine whether a unit is standing on the ground or not; it works great on proper surfaces but it falls apart when the world gets lumpy. (Previous versions of the system that did not have this problem had other movement problems, such as stuttering on smooth ground, so there’s no right answer; I’ve optimised the system for the most common situation.)

I’ve jemmied in a failsafe for this rather than going in for another total overhaul, because ultimately, it’s on me as a level designer to minimise the situations you can get into where this is a problem, by ensuring that places you’re meant to jump to are clear and flat and places you’re not meant to get through are too tall. However, I am ultimately a fallible human being and so won’t be able to cover everything, so I’ve put in a fun system to detect when the game thinks you should be falling but Unity’s physics system says you’re not actually moving downwards; this then forces you to be considered grounded so you can run or jump yourself out of that hole before the falling damage kicks in and makes you explode. (The falling damage may still kick in a little but you can take that as a signal you’re going somewhere you’re not supposed to be!)

This requires a whole world of fine-tuning, of course, because steep slopes engender similar behaviour to getting wedged: the slope slows your descent to below the rate at which the movement system thinks you should be going. Nor does getting wedged necessarily mean you’re not moving at all — in the world of floating-point physics, there’s always some infinitessimal increment in there. Life is pain!

The rest is more mundane issues with the saving and loading systems. Again, not unexpected; there are hundreds of components in the game and I had to manually instrument them all, of course I was going to miss a few values here and there.

The central locus of most saving issues is saving during an Arena match, which is something I’ve generally not done much myself because… well, there are no consequences for losing a match, so why bother? The thing about the Arena is that lots of properties are changed that don’t change in normal gameplay so I never figured I needed to save them at all. (Such as whether an item can be dropped or not — I hope you enjoyed “switching teams” by nabbing somebody else’s sword and shield, anyone who spotted this!)

There were also a few quirks involving bot combat behaviours, as things can get very confusing if a save is taken at the moment of death (for both the victim and the one targeting it). Now I’ve always had this thought at the back of my mind that I should simply disable saving during combat so I can completely forget this kind of issue. Laying aside for the moment that I don’t have a reliable mechanism of determining whether or not you are in combat, I reckon I still need to make the system fully able to save units in battle because while you might not be in combat, there is absolutely no guarantee that combat isn’t occurring somewhere else on the map (e.g. one of Ronkwer’s proxies is finishing off that Giant Rust Mite for you).

Then there were some very mundane things. The Arena clock never reset, as I noticed when one bug report saved game had it at 45 minutes (wow, somebody played a combined 45 minutes of Arena matches?!). The Uniturions in the Gauntlet could jump (even though they clearly have no suspension) and were thus able to jump out of the combat zone. The Harpoon could pull you through fences. Basic oversights.

On the plus side, everyone seems to love getting mashed by the train. Maybe I should give up my delusions of grandeur and just make a mech death simulator?

Anyway: that’s version 0.02 out and while it’s not got everything I want to tackle, it’s covered most of the howlers. Happy new year!