I learned the value of pair programming this week, at least i learned a new value to pair programming. I worked with Ron, who is the lead for out AI, and we did a lot of pair programming. When we first started to have some of our programmers work on AI, I mentioned the approach I felt would be best for implementing the AI character; however, I wasn't working on AI at all and so they ended up taking it a different direction. I think that even though I originally showed everyone the code and the way it was structured, the programmers didn't fully understand the strengths of the entities and components, and some might have even felt intimidated by the code base. But doing some pair programming helps to align everyone to the same vision of the game and the engine. I hope to do more of this to help instill more confidence in all of the programmers in going out into uncharted territories and build new systems needed for the game.
Having worked with Ron we ended up pretty much where I had originally envisioned the AI systems, being that there is a base Character entity that is used for both the player and NPCs. This Character object then has different components for handling movement, state changing, ability control, etc. The player has a PlayerInputController and the AI has an AiInputController that the movement state machine uses to move the player around. This may or may not be the ideal way to do this, as I'm no expert on AI, but I felt this would be a good approach as harnesses our movement state machine which was in place for the player with no code duplication. The AI will now not be able to move when he is knocked off his feet by the player, without the AI code needing to know that. Each AI state (the AI also uses states to manage which task is at hand, such as patrolling, chasing the player, searching for the player, capturing the player, etc.) The AI can just continually "press" the thumbstick the direction he needs to go to get to his target, and if his movement state is affected by some external force, it won't break the game. His movement wont override the forces, as the movement is completely separate in a different component.
Aside from the refactioring I also finished setting up the AbilityController allowing abilities to easily be mapped to different buttons. When the button is pressed, the controller will spawn a new entity for the ability. Each ability will have it's own components (if needed) if it is a projectile, a mine, or an AOE. By being an entity the ability can exist for just a moment to apply the effect and disappear, or it can persist for however long.
Currently I am working on some new movement states for putting the player in Limbo. I intend to work with Mavin on this as it will help him manage player jumps off of walls and such. There are times when the player needs to lose control of movement, and these limbo states will accomplish that. This will enable us to allow the player to move exactly how he wants, even in the air, -most of the time.- If, however, the player is thrown into the air by another player/guard, or jumps off of a wall, we may want to restrict or remove his/her control all together. These limbo states can then serve to manage the control restrictions, while still transitioning the player to a new state (perhaps a SittingOnGroundLimboState, when landing after being thrown, which requires the player's avatar to stand up before he can start running again.)
On a different note, I'm hoping to start doing video blogs in the future, that should help kill the Great Wall of Text that appears on all of my posts. :)
No comments:
Post a Comment