Seeing as this makes only the fifth post about programming in this project's lifetime... I probably should have posted more often throughout the years. I guess the main reason I haven't is because there's never been much good progress to report. Until just recently of course, with the release of Demo v0.2 marking a turning point in the project. So I figured now would be a good time to look back on some of the hurdles in the years between v0.1 and now--a summary of sorts outlining the major obstacles and setbacks, and how we've dealt with or are still dealing with them.
I already covered the camera (and other engine issues) in a previous post, but thought it worth mentioning again because the camera was quite an obstacle. After the original demo was released and it became apparent that the engine needed rewriting, I really wanted to rethink the way the engine was going--and playing Demo 0.1 and 0.2 side by side really demonstrates why. Hopefully the smoothness and playability of the second demo compared to the first speaks for itself here (especially if you're using a dual-stick gamepad, which was what we really designed the new camera for), so while it took a long time to decide on the new camera it was a very important move.
The Character Controller
For those unfamiliar with Unity terminology, the Character Controller is a native Unity component that provides a basic collider for your character that handles smooth interaction with slopes, solids and so on.
Unfortunately, Unity's CC is pretty much complete garbage. Anytime I have an issue with it and look online for the solution, I find discussions that mostly consist of two parties: those who say don't use it, and those who want to use it anyway. While it's a decent plug'n'play solution it's terribly inflexible, bad on performance, and comes with a number of undesirable quirks and behaviors--some of which are still present in the latest demo release.
I tweeted awhile back that I was working on using the Super Character Controller by Roystan Ross (the one behind the Super Mario 64 HD demo), but for the life of me I couldn't get it working; no matter what I did or how, Tuttle simply fell through the ground or popped through a wall at the strangest of times in the strangest of circumstances.
In general, struggling with the character controller and weighing options (or the lack of) has been a major time sink over the years. So, in the interest of progress, I'm just sticking with Unity's CC for now in the hopes that someday they'll improve it or, more likely, I'll take another stab at the Super CC and get it working next time. I generally worked the engine to more easily convert to the SCC should I try again in the future, and one major positive from this was implementing the "Super State Machine", which brings us to...
The Engine Structure
Prior to TLT I'd never worked in 3D, C#, or any project this massive and complex (nothing like jumping in the deep end!). This also means I'd never had much experience in how to properly organize and structure code, which in the first demo resulted in a monolithic and poorly-made player script that was ridiculously difficult to work with--even at such an early stage. Separating types of functionality over multiple scripts and using a proper state machine as provided by the Super Character Controller did wonders for cleaning up the code and making it infinitely more manageable and easily extendable. I could blab on in boring programming terms what all advantages this provides, but I'll spare you that and just give numbers on the lines of code for the prime player script:
Demo 0.1: 500~
Demo 0.2: 170~
That's not taking into account the various other scripts that complete the player (like the camera and input functionality (and of course animation logic has mostly moved to Mecanim)) but for working in the prime player script you can see how much cleaner it is now.
Properly structuring the engine has been a major dilemma, and while I'm still learning as I go and no doubt making mistakes along the way, I have far more confidence in its new direction. This was a huge step.
I've complained before about the woes of working with Unity's Mecanim animations engine, and while it is a constant struggle, Unity is actively trying to improve it with each update and you can see by the new demo that things are coming together a bit better. And I'm hoping when I move onto things like Tuttle running and attacking at the same time it will really save me some big headaches. Getting animations to work properly has been a constant issue since the first demo, which also pertains to...
It's really quite amazing how terribly Blender (our 3D modeling program) and Unity get along. Countless hours have gone into sorting out issues between the two with animations, textures, shaders/lighting/shadows, and just... pretty much everything. fAB makes it right in Blender and then Unity does strange things to it. No doubt some issues are due to our lack of experience in working with them together, but it certainly hasn't been easy any way you slice it and makes me long for the days of working with 2D games and sprites. A sprite is a sprite; no program is gonna mess that up when you import it. XD
A proper input system is something else Unity severely lacks, with a lame input manager to begin with made worse by offering no way to let the player customize it outside of Unity's startup window (which we have (and want) disabled). I've made attempts at rolling my own input system in the past to varying degrees of success, but it usually comes back to still relying on their native manager for at least joysticks. And with things like their new UI system supporting direct interaction with their native input, I've decided to just go with that for now with it in mind that Unity will more than likely release their new input system before TLT is complete.
All of the above issues and more have been major stumbling blocks for ages, made worse and slowed down by my lack of time and other personal issues making for little gamedev enthusiasm in recent years. But despite these setbacks we're still here, still working, and for the first time in years I feel good about where the engine is going. I was bubbling with enthusiasm when the first demo released and the project ground to a halt soon afterwards, but hopefully this time we're on the right track with most of the aforementioned items resolved to some extent, and things can continue to move forward. Even if it's just one TLTuesday at a time.
Finally, I've come to realize that programming dev posts are probably pretty boring by nature (especially walls of text like this), so if you stayed awake through that then congrats and thanks for reading!