Developers Log. Prototype Date 24 - Game Demo Day - The Dry Run

Today we demo everything, that means we had to get everything to a "that will have to do" state. The game is coming along and is looking pretty good. We made a few strides with streamlining the way we get animations in, so that is good. The wall climb logic is mostly done (well, as done as it will get for the pitch this Tuesday.) The wall run is pretty much done too, but the wall jump needs some loving.

I still want to work with air controls, I have spent no time with them, so they behave just as they do when the player is on the ground, and it doesn't feel right to me at all.

I've started sketching out an actual state machine. It's something I probably wont have time to get in by Tuesday, but it's definitely the model we will want to follow for the game if it is picked (and I sincerely hope it will be.) We have so many animations and transations and movement controllers that it will get out of control without states passing around to each other like a perfectly build machine. It will be very sexy.

One of the most disappointing bugs to be discovered last night was that somewhere over the past few days a bug was introduced that kills multiplayer. The game closes on the xbox, which in turn closes my debugger so I cannot even trace the error back to the cause, so I'm going to have to do this the painful way. Grrr. I really want to have this done by Tuesday, so that will probably be my first focus this weekend.

Developers Log. Prototype Date 22 - Abilities and Movement Controllers

The biggest woe of the week was finding out that our physics engine, JigLibX, is failing on the xbox. The .DLL was causing the xbox to crash. After an hour and a half of trying to fix it, I decided to switch physics engines. I could have left it, as it worked fine on the pc, but I really want to show the avatars performing the actions. So I bit the bullet and set off to change out the physics engine. Fortunately I had created a PhysicsBody class that served as a wrapper for the physics controls on the player (managing movement, gravity, dimensions, etc.) This was the only class I had to change, essentially changing where the wires are plugged in, to get the new engine to work. Unfortunately, I first tried Jitter, which didn't work so well, and so I finally settled on BEPU Physics. Third time is the charm.

On top of getting a shiny new physics engine, I decided to change movement from being directly contained within the Player class, to being inside of a MovementController. I then split this into 4 classes: GroundMovementController, AirMovementController, WallHangingMovementController, and WallRunningMovementController.

Each of these controllers constantly monitors when it should start applying movement to the player physics body. This prevents convoluted code within the player class, each condition requiring conditions and flags that would be must be switched on and off. Instead, each controller has clean and manageable code that uses the StateManager to detect when the player is against the wall, on the ground, in the air, or etc. Each controller also has its own stats for movement, how movement is changed (for example, on the ground the velocity is set each update, whereas the air controller preserves velocity, altering it only a fraction of the amount, thus preserving momentum, but still giving the player some control, but less than when on the ground.) This enables us to change mechanics for movement easily without effecting everything else, or wading through dozens of variables, each for the various conditions.

Lastly, I have implemented the DoubleJumpAbility, WallRunAbility, and WallHangAbility. I'm not finished with wall run just yet, and also need to add an ability for when the player wishes to pull himself up off of a ledge. Everything is going very smoothly following this architecture, and I feel I have been able to accomplish a lot in a short amount of time, which is absolutely necessary because I have so little time left before we demo the prototype :X

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.

Developers Log. Prototype Date 14 - JigLibX and XNA 4.0

*Edit* The following left me with a few xbox 360 exclusive errors that were not apparent when I was running on windows. After jumping through a few more hoops, I was still unable to get it to run correctly on the xbox, and switched to BEPU Physics. So these steps won't actually get JigLibX running on XNA 4.0 for the xbox.

Having looked through a few of the top 3D open source XNA physics engines such as Jitter, BEPU Physics, and JigLibX I felt that JigLibX was the best fit for what we needed. I particularly liked the component style of framework, it meshes well with XNA. There are several other implementation styles and core mechanics about it that I liked, so it was selected to be the physics engine for Ninja Royale's prototype.

The major issue with JigLibX is that it hasn't had an update since XNA 4.0 came out, so the version downloaded from the website wouldn't work with the project we have. Here is how I solved this problem:

Get the latest from JigLibX's SVN. You can find the SVN here. noone88 (The original author I believe, certainly the main contributor) ported the project to XNA 4.0.

The project I downloaded still didn't work. Visual Studio was having problems with converting the project, so I had to edit the file JigLibX Xbox 360.csproj using a text editor (open with -> notepad, for example.)

The first line to look for, found near the top, is this

<XnaFrameworkVersion>v2.0</XnaFrameworkVersion>

Simply change the v2.0 to v4.0 and voila!

Okay, so not voila just yet, but almost. Just find these two lines, found close to the bottom:

<Import Project="$(MSBuildExtensionsPath)\Microsoft\XNA Game Studio\v2.0\
   Microsoft.Xna.GameStudio.Common.targets" />
<Import Project="$(MSBuildExtensionsPath)\Microsoft\XNA Game Studio\v2.0\
   Microsoft.Xna.GameStudio.NestedContent.targets" />

You can either remove them, or comment them out (I chose to just comment them out). I was unable to find anything similar from my XNA 4.0 install, so I commented them out and everything seems to work just fine. [*Note, to comment them out, simply surround the lines with the opening tag "<!--" and the closing tag "-->" excluding the quotes, of course]

Developers Log. Prototype Date 3. - Games we can learn from

Here is a list of five games that have ideas, controls, or gameplay mechanics worth looking at for either a single player or multiplayer game (or both.) I wanted to look into both, not yet being decided on the exact game we will be making:

1. Mark of the Ninja - A interesting 2D ninja stealth game being developed for XBLA. If we go single player/co-op this is worth studying. The pace and puzzles are really intriguing. I especially like how it seems that there are several ways to move around the map, going past the guards through the front door, finding a way to go above, or through a vent beneath.  Video

2. Splinter Cell Conviction: Co op - A great game that capitalizes on stealth co-op gameplay. Splinter cell is also great for integrating multiple entry paths to an objective, offering a unique experience for each player, which adds to the life of a game. Video

3. Assassin's Creed - An amazing example of fluid controls. the game is set up in such a way that a completely new city is easily navigated using the acrobatics in place one the player has mastered the controls. By repetition the player learns what can be used to grab on to, swing from, slide down, or safely jump off. The player can master the controls and feel awesome as he/she travels about accomplishing goals. The fluidness of both the controls and the level design is important to study for what we will be making.

4. Mario Kart Battle Snes/N64 - Both of these versions offer amazing gameplay on just a few levels. The randomness of the item pickup adds to the re-playability, as each round is different. Items are given out at a fast enough pace that the player is expected to miss attacks more often than not, making successful hits give a feeling of mastery and accomplishment.

5. Ninja Gaiden - Originally I hoped to observe controls with regards to movement and wall running and such, but ended up being mostly intrigued by the camera. Unlike in Batman: Arkham City the camera doesn't just follow the player, but it acts more like a movie. The player can control the camera, and set the angle which he/she wishes to view the action. Left on the joystick is always left relative to the camera, and not the player. This works very well and feels surprisingly natural. Both control styles work, and we will definitely need to experiment and see which we like better.

Developers Log. Prototype Date 1. - First coding

Ninja Royale was picked as one of the eight games to be prototyped, which is awesome! One of the main points we discussed as a team after having talked with Rodger and Bob about the game's potential, and things to be cautious of, was the importance of not being married to any one idea just yet. While the original pitch was a ninja-arena-battle game with avatars, we want to be sure to be open to, and testing, other game aspects. Certainly being cautious of the multiplayer deathtrap of indie games, we explored ideas with single player and co-op, both with and without stealth mechanics. Rodger's idea of creating a game with such tightness and polish that players could master and create strategy over, effectively creating a sport was a big hit too. (As a highly competitive League of Legends player myself, I definitely enjoyed this suggestion.) The addition of skill trees or skill sets was interesting as well, and something I hadn't thought of much before, but is most certainly worth exploring. Such concepts as a ninja being expert in stealth, agility, or distraction etc (or even non-ninja classes) is very intriguing and will require further thought.

Jumping in head first, Adam and I went to the EAE lab after our cs3130 class and got a simple avatar running around. I just downloaded a simple code sample and ran it, nothing too code heavy, but I wanted to get the experience before heading to work. (Sadly, my Xbox is currently sporting the "Red ring of death" fashion statement, so I won't be able to test avatar code within the comforts of my own home.) I just barely finished a Player class that contains all of the logic for setting up a player viewport. I am rather pleased with the code, as it is very crisp and dynamic. I could easily add a method with just a few lines of code that would allow for players to leave or join the game at anytime, instantly changing up the viewports on the screen. While this doesn't seem practical for our game idea, it's nice to have such possibilities come to mind having a clean foundation for our player objects.

Carrying forward that will be a major focus of mine, keeping a clean modular architecture. I feel this is key in allowing us to easily expand and grow our code base, being most optimal for when five or so more programmers start working on the game as well. Additionally, this serves the prototype phase very well, allowing us to remove gameplay code that ends up not being what we want, without bringing the game to it's knees because the code was so heavily woven within the game's engine.

The next phase, now that my split screen code is setup (supporting 1-4 players) is to give each player their avatar to be played. I anticipate having this done by Thursday so that I am able to go test it (and fix anything that doesn't work correctly) in the lab.