Developers Log. Prototype Date 15 - Players, Cameras, and Abilities - Oh my!

The previous blog was short by design; I wanted to keep it short and simple in the event that someone stumbles upon it, via their favorite search engine, in search for help in getting JigLibX to work on XNA 4.0. Much more has happened the past week or so than just getting JigLibX integrated, and I want to briefly overview that here.

First, we are not only just loading each player's avatar now (tested with 2 signed in players, but should support up to 4,) but we have custom animations working. These were huge choke points that were great to get passed, now the animators can start animating and see their work.

The Player class reads controller input and plays animation when different buttons are pressed. Additional advancements for the player are a Camera class that is self governing, draws just the viewport, renders each object on the screen for it's perspective, and follows around it's target (the player) with some nice smooth motions to keep crisp feeling with the camera. (Oh yeah, the player moves about now too.) The camera still lacks in logic to prevent a wall from cutting off sight of the target, but I don't anticipate having time to implement that before the prototype is done. It's not that it will be painfully hard to do, I just have too many other priorities to get done in too little of time.

I then created a PhysicsBody class which is entirely responsible for the Player's position, rotation, and collisions . A physics body can have more than one JigLibX physics body, so that we can build our avatar's collision system with multiple simple collision bodies. This will be useful for detecting when a player can grab a ledge, run on a wall, etc, as we need to be sure certain proportions of the body are in specific spatial locations.

Lastly I created an abstract Abilities class that is a GameComponent. All abilities (from jump, to grapling hook) will be an Ability and can thus have Activate called on them. Each component is self governing, so that it knows how to behave pre-activation, during activation, and post activation. This enables us to have a powerful base for iteration as well as modification. Keeping the code modular we can throw away code in the iterative process without breaking anything else. I built a Jump ability and got that working very easily. I am excited to move forward with this.

Currently I am working on a StateManager that will clear the states each update, and whenever a state is asked for, it will be determined with a small raycast. The state will be stored to keep the number of raycasts limited to at most 5 (currently, for the 5 directions I am checking) each update. This is important for all of the acrobatic abilities we will have, (wall runs, wall jumps, etc.)

The other pot my hand is in is getting a debug drawing working for each collision body so that I can see what is going on. I hope to also be able to draw the rays I am casting, with color coordination for if they are detecting a collision. This is mostly for me to be able to verify all my code is working exactly the way I want, and see any ways to improve upon it.