FSGD Final Project Week 5: Player Controller, Animator Controller, and Miscellaneous

Hey, sorry for this kind of late post. I should’ve had this posted earlier this week, but I kept on postponing it in favor of working on the game. Because of this, our build for week 6 was really good I’d say. The game is finally starting to shape up. But before I get into week 6, here’s what I did during week 5.

For week 5, we wanted the camera and the player to not be so wacky. So, first, I turned off the ability to rotate on the x-axis because the player doing front flips looks pretty weird. Then I also had it where the player you are controlling wouldn’t be rendered. I managed to do this through a simple if check and a static ID in the game class.  And lastly, I had to fix how the crosse wouldn’t rotate with the camera correctly. This was due to a line of code that I forgot to get rid of from an earlier build that rotated the camera in addition to the player. This resulted in the camera rotating twice given it is attached to the transform of the player. With these changes, the game was actually traversable without the running animation of the mage going in front of the camera.

I also wanted to get a jump and attack going for the player. While I did get some of the code set up for a jump, I ultimately stopped because I didn’t have any interfaces that would allow for a good jump (detecting if you’re actually touching the floor before jumping, etc.). So I ended up just trying to get the attack work. I set it up where if you are colliding with a person, if you click ‘F’, you will make them trigger a stumble animation, and push them back a bit. But I wasn’t really pleased with the way the animation system was working. I wanted something more flexible. I thought of Unity’s animator controller, and I decided I would make something very similar.

I set up several different classes for the animator controller. An animator controller, which would hold all the possible states, update the blender, and update the current state. A state which would have an animation, doesItLoop bool, animationSpeed, and a vector of transitions. A transition would have reference to two states, the from state and the to state, while also having things like how long does it transition and parameters. A parameter is a certain condition that is needed to be met in order for a transition to happen. I only made one type of parameter, a trigger, but a bool and a float would also be acceptable parameters. What’s special about a trigger is that once it’s checked, and that check is true, the bool is toggled off. So the trigger consumes the bool.

This is mainly just the gist of it, but it provides me with a very flexible way to go from state to state while also controlling looping, blending duration, speed easily. For the most part, I had most of the architecture done for the animator controller by the end of the week, but I still had several bugs and functions to program for the stumble to actually work through networking and with the new system.

That was the main gist of week 5, but I also had some bugs that I had to fix from the previous builds. One was a pretty big one: throwing didn’t work over the network. This was because transform parent data wasn’t being sent to the client, so it thought the ball was still attached to the other player even though it was thrown. So I sent a parentIndex through networking to solve this error.

Also, I added a function to optimize some event handling: you can dispatch an event to a specific handler if you know the handler’s name. To get this to work, I added a hashstring table to the EventDispatcher class, which is a map that holds strings as the keys and uints as the value. This would store the indexing information into a vector of event handlers in the event dispatcher, so if I wanted to send an event to only “Game”, it would look up the index for me an then index into the vector. This was a huge optimization, so I wouldn’t send the event to the dozens of other components if I knew I only cared about Game getting the event.

But yeah, week 5 went pretty good. Week 6 would mainly be dealing with the animations and the attack.