January - Backend Work

I'll first start with reviewing December, since it's integral to my work in January.

December Review

I set off on December with a pretty ambitious list of goals, but the primary aim was to refactor my code to be more generalized and thereby more streamlined for development.  But overall the month was pretty disappointing.  I only spent about 60 hours developing, which is nearly half the amount of time I spent in October.  Part of that was due to the holidays at the end of the year, but mostly I was just lazy.

Still, I got some work done that I’m proud of.

Adaptable Objects

I began working on a system which I’m calling “Adaptable Objects”.  Without going too in-depth, the core idea is this: I have a builder script attached to some object which contains initial parameters to decide what sort of object the object will be. It then adds all necessary scripts/components to make the object functional. The first component I worked on was the animation.  I built a script to automate pulling animations and building the object animator from a generalized blueprint.  So now objects have three animation types: static, cosmetic, and full.  I tested this by creating a quick plant object in Blender, created some animations, and imported it into Unity.  From importing, I hooked it up to a object with the same name as the Blender object. Then all I had to do was run the script with the proper parameters and the animation was set up. I didn’t have to build an animation tree or script an animation system. It’s all automated now.  For every possible object.

Next I worked on the movement script, which needed to handle any sort of movement type. This works in several modes: ‘Static’, ‘Transform’, ‘Rigidbody’, ‘Player’, and ‘Nav Agent’.  The reason for this is that each type requires different methodology to move the object.  With a generalized system, I can avoid that overhead. So I set up a general event called “Move”, and allowed it to be called from the adaptable object manager.  It’s a public exposed call, so any script can call “Move” on this object.  This event only has one function tied to it based on the specific mode of the movement script. For example, a ‘Transform’ movement just moves the position of the object.  The script also adds any necessary components, like a Rigidbody.  And this can be done during runtime, allowing an object to be switched from ‘Player’ to ‘Rigidbody’.  Think of rag-dolling physics for a use case here.

The movement script was surprisingly easy to set up, but it’s a system I desperately needed to implement.  Consider a scene with the player, the boss, and some rolling rocks.  With this generalized system, I can move any of these three objects with the same call, instead of having to send unique calls to each object.  Additionally I can ensure that any sort of movement is equal across all three objects.  I’m having trouble finding the right way to explain this system, but the general idea is that I’ve streamlined movement calls so that any object can handle movement without me having to worry about the overhead.

And that’s all I’ve done for the adaptable object. There’s still more to do, but it’s now a January task.

RGBA Texture Masks

The other thing I worked on this month— which wasn’t even part of the plan— was RGBA texture masks.  I plan on making a tutorial for this, so I won’t go in to detail of how it works.  But I find this system so amazing because it’s a technique I had never heard of before, and it allows for an absurd amount of reduction in image sizes.  If you’ve ever wondered why games today are so bloated in storage size, it’s because of image textures.  The boss in my game has a 2K texture, which takes up about 40 MB.  This is a unique texture, meaning it’s not reused anywhere else.  The arena is again a 2K texture, but since it’s much larger, you can see the pixels of the image.  In the final game it would likely need to be a 4K texture, which would take up ~90 MB (it’s not a linear 2x growth from 2K to 4K).  Now imagine every object in the game needing textures within this range of 2K to 4K.  For a small project this, it isn’t a big deal, but for bigger projects you end up with 50 - 100 GB in project size.  Think any recent AAA game.  But using an RGBA mask and a shader, I can get pixel-less resolution with a 64x64 texture, which is about 16 KB.  This has limitations, but it was absolutely revolutionary for me.  I can replace the ground texture (90MB) with a texture mask (16KB) for a 5000% reduction in file size.  This is of course exchanging memory for performance, but I’m a sucker for optimizations like this, and I hope my tutorial will better explain the nuances of this and how it all works.

January Plan

So that’s all I did for December.  It was still a decent amount of work, but I could have done a lot more.  My goal for this month is to hit 120 hours of work, similar to the amount of time I spent on this project in October.  That matters to me more than hitting all the tasks I want to complete.

Finish Automation and Adaptable Objects

The first thing I need to do this month is finish the adaptable objects I’ve been working on.  I still need to integrate the player code and AI code into this new system, which will require a lot of rewriting and refactoring of my code.  My idea is that the ‘Player’ code or ‘AI’ code will act as a component which can be attached to any object.  This component will serve as a brain to the object, sending commands to it.  Referencing my earlier example of the “Move” call, the player movement would be done through similar calls to the adaptable object manager.

Polish Player Controls/Mechanics

Once I’ve finished the adaptable objects, I plan on tweaking the player functionality.  I already have some ideas on how to make the controls better, and I want to implement better movement as well.  I played “Dark Messiah of Might and Magic” recently and I found it interesting how the basic movement works in that game.  The player has drag in their movement (something I won’t implement), but they also move slower when moving backwards.  It’s not something I had thought of, but it’s such a simple solution to preventing player speed.  Because ideally, the player can move fast, but can’t move fast all of the time in any direction.  I want the player to earn fast movement, rather than having access to fast movement all of the time.  I recognize that this goes against the conventional wisdom of game feel.  And, unfortunately, I think game feel is especially important in the FPS genre.  People expect fast, reactive inputs.  I can’t just ignore that preconception because of my design principles.  I have to find a way to compromise.  My hope is that slowed movement backwards won’t be too punishing.  With this sort of system, you can still move fast, but only while moving forward.  Skilled players could just always rotate around, rather than moving backwards.  This has the downside of moving your camera (potentially obscuring visual information), but a skilled player won’t be thwarted by that.

But overall I want to make the controls feel better while maintaining the balance I’m striving for.  I’ll likely set up a simple parkour arena to test out the player’s ability to build momentum and navigate the environment.  The ideal is to allow fluid motion without breaking the level design or combat mechanics.

That's All I Have Planned

It's not a big task list, but considering how much I overshot last month, I figured I should humble myself with my goals.