November - Moving Forward

I just released a rough prototype last night for testing.  It's rough, but I promised in my last dev video that I'd have something to show by the end of October, and I wanted to stick to my word despite my hesitation to share the unpolished, unfinished prototype.

I got some good feedback from my friends on the project, and overall, sharing the prototype has given me a boost of motivation to continue working.  So, here's my plan for November.

Clean Up

Obviously I need to polish the current features and clean up my code. I should start with that before moving on. Approaching this deadline, I was allowing myself to be sloppy, but I can't continue on that way. I need to take a moment to refactor and comment.

The State Manager's need to be given a unified parent class of "StateManager".  Reason for this, the Biometrics on each State Manager cannot be accessed without first accessing the Manager (since Biometrics aren't Mono Behavior).  So whenever I want to get a Biometrics, I have to first check whether the target object is using the Player_StateManager or AI_StateManager.  If they come from the same parent class, then I simply need to check if they are of type "StateManager".

Not all player actions are sectioned out to states yet.  I'm still not quite sure how to build the states for the player.  It may be necessary to have multiple types of states.  I already have a weapon state, so I may need a movement state as well.  I could tie a "Living" state to the Biometrics... Maybe all these sorts of states should be tied to the Biometrics.  Movement, life force... all attributes which are shared across all living creatures may as well have their states on the Biometrics.  Something to think about.

The states need to have one base state.  As it is now, I have an AI_BaseState and a PlayerWeapon_BaseState.  This isn't causing any issues (yet), but it would be wise to have a general BaseState which all states inherit from.

I want to create a Utility script for running coroutines.  Since most scripts do not inherit from MonoBehavior (because they don't need to), they rely on the Manager to call coroutines.  This works, but it makes it impossible to stop specific coroutines.  If I had a coroutine that I wanted to stop, I couldn't use StopAllCoroutines and using StopCoroutine may end the wrong process.  I'd like to create a Utility script which can run coroutines and provide them with ID's.  These ID's are fed back to the caller and can be used to stop the coroutine.  Example: player begins reloading, so coroutine is fired to wait for the animation. But then the player cancels the animation.  Now we need to stop that coroutine, since the animation is canceled and therefor the aftereffects should be canceled as well.

I need to create an Audio Manager which can handle a select number of audio players. These players can be parented to objects on the fly in order to play sound effects.  There will be a soft cap and a hard cap of audio players.  This system is needed since audio players can negatively impact performance.  If every object which needed to play sounds had its own player, the performance could take a large dive.  With this system, I'll also need a scriptable object which houses audio files for any GameObject which needs to use audio. For example, the player needs a list of SFX for their actions.  I can streamline the setup of these ScriptableObjects by using strict naming conventions.  If an action called "Walk" has the sound effect "Player|Walk", then I can use a method to find that SFX within the assets folder an assign it to the scriptable object.  This would obviously only be done in the editor, not during the actual build of the game.  Since SO's changes are permanent, that won't be an issue.

I'd like to experiment with modifying FBX animations (directly from the import) to change animation attributes.  I could do this for things such as mirroring animations, but also for streamlining animation imports.  Since it's not essential, it's not a priority.  I'll get to it if there's time.

Player

From there, I want to perfect the player controls and get all inputs set up.  As it is now, the player controls are still janky and I don't have the elemental abilities set up.  I want to begin with just one: air.  Once I have the player set up and feeling good, I can turn my attention back to the Mole King to improve upon his AI and attacks.

Biometrics Depth

Before move on to the Mole King though, I need to add more depth to the Biometrics script to track more variables.  The AI will heavily rely on the Biometrics to inform their own actions, so it's important to give the Biometrics plenty of data to allow more complex AI behavior.  I want to add a generalized "Vulnerability" stat, which raises and lowers depending on the current action.  Keeping it generalized will allow me to keep the Biometric applicable to all living characters.  If I had a stat like, "isJumping", then that stat would be useless on an enemy which can't jump.  Instead, I could say that jumping makes a user more vulnerable.  This could then be combined with a "Momentum" which tracks how much faster the target is moving from their baseline.  So now, instead of having a particular case for when the player is jumping, I have a modular case set up for high momentum and high vulnerability.

Mole King

Here's hoping that I can actually make it this far this month.  If I can, then I have a chance of pitching to publishers by the end of November. Which is crucial. I wanted to pitch now (before the holidays), but pitching in November is at least better than end of December.  Not only will I be bogged down by family events, but every publisher will be too.  At least at the start of December there's some down time where they may be able to look at my game.  Maybe if I'm lucky they'll be in the holiday spirits and be biased towards liking my game.  Or maybe end of year is a terrible time to pitch a game.

Anyways, the Mole King.  I need to add more animations and attacks to add depth to the combat, as well as polish the existing attacks.  With the player mechanics fleshed out, I can focus on crafting attacks which force or prohibit certain actions from the player.  I also need to add a layer of intelligence which is able to understand how the battle is going based on the attacks being used.  At the moment, the system in use involves random selection with bias from the player's actions/state.  This is a good start, but it would be even better to take performance into account.  If the same attack is failing to ever hit the player, then the AI should avoid using it and find the attack which lands the most.  There would need to be some balancing here to avoid the AI spamming their most powerful attacks.

More Art Assets

There are plenty of 3D models, FX, and SFX which needed to be added throughout all these tasks, but I figure I don't have too much to say about them.

With the FX for the air, I'll need to do some research into Unity particle systems and try to create some decent effects using Blender's shader graph (because I certainly can't draw effects).

For SFX, it's going to be difficult, but I have a few ideas of how to create sounds.  It'll take a lot of experimentation to get some sounds I want— air is going to be especially difficult— but I have some ideas.

As for 3D models, that'll be pretty straightforward.  Really, all I need to add is terrain.  I might want to place crashed airplanes but that's completely unnecessary for the prototype.  My goal is to have a satisfying encounter with the Mole King, and I do believe some level of art polish is needed to improve the experience.  But environmental stuff like planes is probably too far.

The only other thing I want to add is the player's body.  This will absolutely be essential for the game as whole, but I'm not sure it's necessary for the prototype.  Obviously I'll need the hand for the elemental animations, but I may not need the right hand or the body yet.  If I have time, I can work on that.  But if I don't, it won't be a major flaw.

That's all for now.  These are just my ideas on what needs to be done.  I'm not certain I can tackle all these tasks by the end of November, but that's the goal I've set for myself.