Week 2

This week was dedicated to prototyping controls as well as an animation/state system for controlling the characters.

We had a couple control schemes going around over the past few weeks. While developing the control system, I was originally aiming for a scheme that we had discussed, but were not going with any more. This in and of itself was a non-issue, though it does show that this group depends more on docs than others that I have worked with. I will have to remember to check the documents on the project server periodically to make sure I am on the right track.
Still the control system is pretty easy to change and quickly modify. Unity's Input system is one of it's weak points, in my opinion. It is a deprecated system, that could certainly use some updates. It requires one to manually input each control, and in the case of having multiple controllers on one computer, one must put in each control for each controller, a painful, repetitive task, to say the least. Still, it is done. On the player controller side of things, I built the controls in such a way that the game logic is not looking for particular axis, but rather, the controller accesses objects that encapsulate the accessors to Unity's Input System. This indirection allows control input to be changed without having to access the code, most can be changed in the editor. This will help us modify and scale the controls.

As for the state system, I tried a couple ways of going about it, as well as testing the blending of animations into one another. I tried to keep in mind that we want to try making this work in a networked environment. I will be testing the feasibility of networking this coming week.

Basically the state system will control pretty much every action the player tales in the game. it will also will be responsible for controlling the animations and movement of the characters. The players will always be in a state, when they are knocked down, when they are idling, when they are in the air, as well as one for each attack that they are in. These states will control which state the player can go to from from that state, as well as what inputs take them to said state. For instance, the idle state will allow the player to jump, no other will allow the player to begin jumping, though I may change this to allow jumping to be queued after an attack(so if they hit up while an attack is executing, it will cause them to jump as soon as they are out of that state.) During an attack, the controls are being checked for an input for the next attack. At a certain point in the execution(lets say 50%) the input is not being queried any longer, and at a later point(lets say 75%) the state begins transition (blending animations together, etc). This delay between decision and execution is to allow some time for when we implement networking. This delay could be used to send the next state to the other player. This all theory, that will be put into implementation next week.The state system minimizes what data needs to be sent between clients, so hopefully, this will make it doable. At the same time, networking is certainly not necessary, so if we discover that getting the level of precision we need for a fighting game is not possible, we can scrap online multiplayer all together.

So yeah, controls, states, animation, and stuff. Hopefully the prototype I developed will allow Donny and Eric to test some of their controls and gameplay. We are trying both a brawler like SSBM, and a classic fighter like Tekken/Street Fighter, so we will see how this develops.