Dev Log v0.2

Sorry for the delay on this update, but I was squashing a lot of bugs before releasing v0.2. Unfortunately, there are still some bugs present that I need to work on. Luckily, thanks to my new in-depth debugging, I've identified the issues with each bug I've seen.

Here are the bugs I've found:

BUG REPORT #008

• When the AI enters the reflex state, it can get stuck in the animation and constantly loop. Considering the animation does not have the loop attribute, it must be the case that the animation is being perpetually triggered.

BUG REPORT #009

• The AI sometimes switches animations partway through an attack. For example, it has begun with the heavy animation (forecast) then switched to the standard animation (action). This is likely caused by the timing of switching animations, in which the forecast begins before the animation set has been altered.

BUG REPORT #010

• When swapping from the sword to the gun and crouching at the same time, the animation glitches out and gets stuck on transition. My guess here is that the sword and gun are triggering the 'transition' animation at the same time.

BUG REPORT #011

• I knew about this one (and I know the solution), but when sucking up debris, it is possible to launch yourself into the air. The simple solution to this is to disable colliders on sucked objects. I like that the debris spazzes out, so I can replicate that by randomly rotating the objects at high speeds.

BUG REPORT #012

• The gun only has 5 shots, not 6. This honestly confuses me to no end, as the code is pretty straight forward: set ammo to 6, if ammo ≤ 0 : canShoot = false. Perhaps the shot is being triggered twice sometimes. But it is consistently 5 shots. If the issue were random "double shots", then it would be an inconsistent ammo count.

Update Summary

This update was a bit more stressful than the first one. The game has become more complex, meaning there are more systems to manage. As one person, it's easy to have certain code slip out of my mind when I leave it for too long. I try my best to comment, organize, and debug to make up for this shortcoming, but it's still an issue. To try and address this, I'm going to go through all of my code and try to refactor as much as I can. This will take away time from new features, but I just can't keep trucking along without addressing this problem. It's not going to go away if I move past it. It will only get worse.

As far as my plan from the beginning of November, I made it about halfway through the list. I refactored code: generalized the state machine, generalized the animator, made the attack logic human readable, debugged everything, and completely reworked the player code (it was glorified spaghetti before). I also worked on an Audio Manager, creating a system to allow for sound mixing and to optimize the use of audio sources. In Unity, audio sources can quickly overwhelm performance. In an attempt to reduce this, I pre-instance a select number of audio sources which begin disabled. Other objects can call out to the Audio Manager and request an audio source. They use this source as long as they need it, then the source returns to the Manager. If too many sounds are playing, the Manager can reject low priority sounds (such as ambient noise, which isn't integral to combat).

As far as working on actual SFX, I only created the gunshot sound effect. I've never worked on SFX before, and diving into it for this project proved more difficult than I first anticipated. Finding the right sounds, mixing them together properly, and integrating them into the game world is quite the challenge. That said, I think the sound I made is pretty good. I decided to hold off on creating more for now, but I'm confident that I'll get faster and better as I keep practicing. I find it enjoyable at least, so that'll help me get past the learning phase.

Visual 2D effects proved equally challenging. Having done these before, I thought they'd be pretty easy to implement. I was wrong. 2D work has always been difficult for me, but creating FX was even more challenging. It's hard to explain; I just can't make them look good. Using the particle system never looks quite right, and it's not possible to export a Blender texture animation into Unity. By that I mean, if the texture itself changes within Blender, I'd have to bake each texture for each frame, which is absurdly suboptimal. So I simply made a placeholder orb for the particle system and avoided creating more complex effects. In the future, if I can't get it down, this might be where I finally start outsourcing. Luckily FX are one of the most disjointed parts of development, so it wouldn't be too detrimental to outsource, if I end up needing to go that route.

I also added one of the core features which was missing before: the offhand element. The player now has an offhand which is capable of sucking and blasting small particles. It can also be used to infuse the mainhand weapon to change the current attack. For the gun, an air infusion causes an air blast which (if aimed at the ground) knocks up the player and blows back any enemy/object. Although I didn't implement moving the boss in this round. Before I can do that, I need to implement a universal movement system which allows for outside forces on any object. This leads into my first goal for next month: a movement utility script.

Goals for December

Movement Utility

Currently, the player character, the AI, and rigidbodies require different code to be moved. This is due to the nature of Unity. At the moment, I have to check for a component type, then move the object based on which component it primarily uses. A better solution would be to have this functionality abstracted into a general class which handles movement. Ideally this would be complex enough to allow for any sort of movement to be funneled through this script: linear movement, accelerating movement, omnidirectional movement, etc. But having a wide variety of movement types will be the hardest aspect of creating this general script. Thinking on it, I have no idea how I would create a generalized method for moving an object on a curve. But it would be in my best interest to do so. Altogether, this script will be pretty difficult to achieve, but it will undoubtably be worth the effort. My current set up (which is the lack of any set up) is just too chaotic to be maintainable.

Refactor Player State Machines

The player code is still spaghetti. Just cut up spaghetti. I certainly improved it from last time, but code still needs to be ripped out into separate classes and I need to rethink how I am structuring the systems. At the moment, the function of the Player's state machine and the AI's state machine is completely different. Part of this is due to the complexity of the player's state, but it would be ideal to have the two state managers be similar in their design. At first I thought it would be too pedantic to make them similar, but I am realizing now that the juxtaposition of the two is constantly forcing me to reorient my mind palace every time I switch from the player code to the AI code.

Review, Debug, Trim, and Comment All Code

This is going to be boring and time consuming, but it needs to be done. I just don't understand my code well enough. I also need to trim out functionality which is placeholder or obsolete. It doesn't seem like much, but the extra code has become somewhat overbearing at the moment, especially when combined with the general complexity of my codebase.

Rethinking Biometrics (Senses Script)

My first idea was to have the Biometrics be a database of all info that an AI may need on any given living creature. However, the AI may also need information on a non-living object (which doesn't have a Biometrics script for obvious reasons). Instead, I should have a senses script which attempts to look for certain components on an object. All objects will have an instance of the generalized movement system, so the AI can check the Movement Manager for that instance. Then it can check for other things; like biometrics, hit_object logic, or other traits which may be unique to certain object types. If I'm thinking forward enough, I could design this senses script to be used on more than just the AI. I could use scriptable objects or pluggable code to enable certain logic based on specified inputs. For example, a boss's AI will be an extremely complex system of checks, but an automatic door may simply need to have a 'sense' which checks for the distance between itself and some incoming object. Obviously this can be simply achieved through a few lines of code, but that's not the ideal way to code. In that situation, I am making unique code (we can call it "AutomaticDoor" for example), rather than relying on some easily understandable, generalized system. It in the case of one automatic door, this solution isn't that big a of a problem. But if you imagine a hundred little cases like that, you can see how this "design as needed" approach will lead to dozens of unique scripts. And at the point that becomes a problem, it will be too late to refactor them into some generalized class. I'll be honest when I say that I didn't see this as an issue until writing this very paragraph, but now that I've noticed it, I can't ignore it. So this sense script will be paramount. Great, I've created more work for myself on a system no one will notice.

Finalize Player Action Functionality

Currently, the implemented actions of the player are not fully featured. For instance, you can't infuse debris into a weapon attack. The tornado does not work as it should. The air blast doesn't knock back the AI. So before I begin on the AI, I should at least complete these features.

Make the Mole King Smart

I really hope I can get to this before the end of the month. I want the Mole King to be able to predict any incoming attack and have a specific attack to counter it. I want it to be prepared for any sort of movement the player might make and have a counter for it. An easy example from the last round of testing: Corbin was able to jump on the Mole King's head and keep slashing him. Rather than removing this possibility, I should implement logic to allow the Mole King grab the player and throw them off.

I also want to implement a "learning phase" to the Mole King. I need to be honest with myself and say that it's highly unlikely I'll be able to achieve this in time, but it's worth noting as a goal I have. Using the last example: the player jumps on the head of the Mole King. On the first occurrence, the Mole King will take a few seconds to realize that it should grab the player and throw them off. But on the second occurrence, it should happen quicker. By the tenth occurrence, the Mole King should be readying attack before the player even lands on its head. This will require some advanced AI for understanding past and future (the AI will likely be designed to assess things on a moment-by-moment basis), but it would make for some very interesting depth to the fight. The player could purposely force the Mole King to ready that prediction, then abuse that to fake out the Mole King. It allows for cheesing of the AI, but in a way that is true to real life. In a real fight, feigning an attack which previously always hit is a great way to fake out your opponent.

I'm not even sure how I'd go about making the AI this advanced, but it's meant to be a core part of this game: intelligent AI. If you take a step back and look across the gaming landscape, you'll be surprised by how underwhelming most AI is for enemies. They rarely react to the player in interesting ways. Mostly because it's an incredibly hard feat to achieve. I'm not unaware of the challenge. But I'm willing to take it on.

I Should Probably Stop it There

There's more I want to do, but this list is already overwhelming. To avoid overpromising, I think I'll end things here. If I'm somehow able to finish all these tasks, than anything additional will just be kept as a surprise. Overall, my main goal for this month is to simply gain a strong understanding of all the systems at play. It's becoming overwhelming and I need to get a grasp of it all.

For a video update, you can check out my video here :