Game Garden / Animation Blending

This quarter I came in with a bloated head. My expectations were high to push myself, even when they were cut back after half a quarter of struggle. Looking back at my project proposal I can’t believe I did this to myself. After a few days of watching particle effects presentations, over, over, and over, I felt I was over-shooting what was needed to pass with flying marks. Then I remembered, I’m in a competitive market and it’s great that I’m pushing myself more and more every quarter to meet the bar of commercial computer graphics.
From the get go I was trying to get started as early as possible. My first objective was to setup the data-driven environment and collision detection system. You saw this in the billiards project. This introduced the EnvironmentParser, EnvironmentItem, Object, Physical, Anchor, and environment.txt architecture. The way it worked is that several files were referenced in the environment.txt file and were of two types, Physical or Anchor. Physical objects were dynamic that had mass, velocity, and gave off forces. Anchors made up the scene used to describe unmovable environment such as the ground we stand on. The idea was that these would be linked by the Object class have different collision qualities and update functions (if they had them at all). I also made shape privatives that would make up the structure of the items being drawn in the environment. These ended up being MPolygon, MSphere, MBox, and Shape. The ‘M’ prefix was to stand for model, though they didn’t end up getting used much in the final project submitted.
With the framework to build upon, I pursued creating the structure of the model, the script to read in the model, and the technique for moving from one animation to another. It was then that I hit a rut that took weeks to get out of from. The first problem was how I build the model. If I were to use a data driven model I had to pass data all the way to the end effectors. If I were to use a tree I would get an ugly traversal that would make back talk a pain. Instead I opted for a map for quick access and elegant data handling via one master class for the entire model. The second problem was how I was I going to get the model to move from position to position, animation to animation smoothly? Inverse kinematics had an appeal from the start because of their recent use in videogames. Though its traditional implementation, which uses the Jacobian matrix, was trashed due to my underdeveloped physics and the lack of need for something so complex.
I then was directed to a paper on a fast inverse kinematics system built for real time (see my response for more info). It provided a method of building the skeleton out of normalized segments, splines, and variable length segments that contain a one-degree joint such as legs and arms. Using this skeleton, I created the BodyPart, Limb, Joint, and Hinge classes and started on my scripting system. The abstract class body part requires an axis-angle direction (theta, x, y, z) and an id tied to it. Limb added a scalar for length, and Hinge extended Limb further with a sub-length and scalar value for extended and closed. This allowed me to break animations into stances built by sub-hierarchies, and even allow me translate in between them with a simple quaternion slerp. Finally the individual animations were simply described as a list of stances. I marvel at its simplicity and effectiveness.
The animation was only half of the assignment. The way this all fit into the game theme of the project was that these animations are a result of a state based. The idea was to describe the different verbs of the active avatar and use an identification to access the correct animation. This is the part that needs the most work. I used a hack of a collision system based upon boxes of four points. Player control was poorly implemented, though the running and jumping controls feel pretty good. This is where I plan to expand upon next. I want to take my effective animation system that I built from the ground up and prepare it for a more defined script that I hopefully could churn out levels, new models, to even being integrated with a GUI to make a full fledged tool. The shortcomings of my near-sighted implementation did not allow me to make my character to wall jump (result: upward teleportation), or do the rocket burst I hoped so much to get into this demo.
Ultimately I have put my all into yet another project and learned every step of the way. That is how computer graphics should be learned, by just doing it. So, in conclusion, I have succeeded. It didn’t come easy, but there is much to learn and much to do to get where I would like to be. I just await the opportunity that will let me add textures, and graphical models around my different limbs. The more I learn the closer my game’s existence is getting.

Mid Quarter Update

It’s hard to get out of the planning phase. I’ve thought, rethought, and re-re-thought the idea of taking a basic game level and adding verbs to a skeleton model. The scope of the project has stayed the same since it offers a basic goal to complete and a large amount to expand upon. To a certain level I have a better description of what I need to do and have performed the most of the necessary functions in previous projects. However, I still don’t have experience with setting up my dynamic environment, handling an articulated figure, using more a advanced collision detection method than box collision, or using Benzie curves to make my quaternion rotations look smoother. Most of this material is being covered and turned in within a week, so I still give myself four weeks to get past those hurdles.
The big problem I came across was working with Cocoa and trying to setup a windowing system and a reliable timer. I decided it’s best to stick with C++ and I solved my timer problems rather shortly. After the rigid body dynamics assignment is complete the software-design of the project will be set and coding will start. A prototype will be made that performs all verbs, but won’t use the proper model. Then, after another assignment, the model will be implemented. From there the sky’s the limit, but only after everything works perfectly.
Everything is to schedule otherwise.

Project Proposal

One of the great elements of a game is how it feels with the controls. These days it involves lots of blending between animations, but also a lot of procedural actions like wall jumps, hanging, etc. So inspired by this wonderful Gamasutra article on game feel (http://www.gamasutra.com/view/feature/2322/game_feel_the_secret_ingredient.php) I have decided to do a “garden level” similar to Miyamoto’s incarnations with previous Mario games with my protagonist that I’ve been developing. The level will use a base stick model to perform the necessary verbs a full model could use in the future. My verbs would include: running, jumping, wall jumping, a rocket burst (important to the game design), a wall cling, and maybe even some slope running if I get that far. The idea is to develop the garden as far as I can in a frustum perspective so that I can maintain a depth of field in what will play as a 2D title.

Now to the technical details:
The level is likely to be hard-coded. This is since I am unsure of how exactly the messaging for each action will work.

The model is likely to be hard-coded. This is because I have no model experience.

The camera will initially be fixed, but if time allows, will zoom more onto the avatar to see the animations more clearly.

Finally I wish to program the system using Objective-C and Cocoa. This is so I can create an executable in OSX without using the command line to run it.