Adding GetMyMaterial(void) & GetMyMaterial(PhysicsBone mb*) to GameObjectBase. They'll just return something by default, probably the symbol to indicate that strikes pass through this object.

Material in this instance is referring to how items react to being struck, and inversely how the strike reacts to hitting the item.

GameObjectBase -> Simple Object Class. Attaches itself to the root node, names itself. Very limited abilities. Can make something appear on the screen, can load physics data. Can react to objects colliding into it, supports armatures and armature collisions. Is aware of the world and by proxy is aware of all things in the world.

SimpleObject : GameObjectBase -> A simple object subclassed from GameObjectBase. Supports animation, intended for simple objects with limited purpose, such as trees, bushes, ect with only one animation.

ActiveObject: GameObjectBase -> An object that contains a library of animations, keeps track of its state. Capable of many different animations based on its State variable. States are handled via a Char (probably due to be lengthened) state var. For instance:
#define PS_IDLE 0
#define PS_WALK 1 // 01
#define PS_JUMP 2 // 10
#define PS_WALK_JUMP 3 //11
#define PS_STRIKE 4 // 100
#define PS_STRIKE2 8 // 1000
#define PS_STRIKE3 16 // 10000
#define PS_STRUCK 32 //100000
Various states are defined as bits in the State variable. States can be mixed by turning on multiple bits to achieve things such as the running jump attack. These various states correspond to an array of pointers to animation states that are the appropriate animation.

AIObject : ActiveObject -> Object with internal AI. Has second AI state variable that works on similar principles to standard State Variable. Is aware of the player.

PlayerObject: ActiveObject -> Object that is aware of keyboard input and reacts to it in various ways. Camera will follow this object, and react to things this object does.

I'm coming to the conclusion that forward planning would have been helpful. Unfortunately, I've realized this at the point where I end up doing backward planning.

Reworking the BaseObject class with code from the player class, resulting in headaches.

NOTE:
Make all movement/falling/movement relative to time passing from frame to frame, or else animations won't synch properly.

ParticleSystems can now be easily added, and will remove themselves if they have limited duration.

For some reason program freezing on shutdown, resulting in severe irritation on my part. Seemed to start immediately after changing the WORLD variable from a straight value, to a pointer, and started using the New keyword. Not sure what this has to do with it, but should probably ask Andrew for his opinion.

Particle effects make things look cool.

CEGUI is fairly well cemented in my head. Need to figure out what menus contain, etc, and think about how to make them operate.

On other notes, Can add particles willy nilly to scene. Need to make SceneMgr more helpful though.

1. Character can move
2. Swings an apendage in what could be considered a weapon like manner.
3. Recieves callbacks from the collision detection handler when particular sections of it hit particular sections of the enemy.
4. Character can jump.
5. If I bothered to make proper animations for it, character could jump_strike or run_strike with minimal code additions.

Going to add functionality to World class to let it create and handle particle effects.

Managed to get CEGUI up and running. Still need to teach self how to add functionality to all the buttons, but nevertheless, I feel the hard part is done.

/dance

Collision detection looks like its working. Knowing programming it probably really isn't, but I'm going to delude myself into thinking it is.

collisions = headaches

Working on getting collision detection working. I've got some good ideas in my head on how to make things work, need to learn how to write a maya exporter as well, hopefully won't be too much trouble.

If I can get collison detection working I think it'll go a long away from taking this from a collection of things that work into a game.

Particles

Working on particle systems now. Shouldn't be too long. Jumping and various animatory stuff is mostly finished, need to put some work into making sure animations blend better though. Odd quirk is occuring where the player is inifitely swinging if they change their state frequently while swinging. Fortunately I know what's wrong, just not how to fix it.

Really need to suck it up and do collision detection though. It's important to be able to hit the terrifying denizens of the underworld.

Jumping Works

I am now pleased. Proceeding to making slimeball have arms and also, swing. Preferably with the ability to hit things.

Jumping Slime

Slimeball jumps. Moving jumps are unfortunately resulting in bizarre and unpleasant effects, linked to the fact that the slime moves on its local axis, but the world runs on the global axis.

Should not be this difficult.

For those who hadn't inferred, Slimeball is my stand in model for figuring out how to make everything. He'll probably grow arms at some point.

Jumping hates me. Will reattempt after sleep.

Irritation/Windfall

Lost some code somehow. Irritated, but in the process of rewriting the code figured out how to deal with other issues I'd been worried over. Should sleep, but I want to see my slimeball jump.

Mild Excitement.

My test model walks on the ground!
And like, stays on the ground. This is important I'm told.

(I really need to work more on this project)

Designing...

Wrote out design document, although large parts are empty.

Minor Progress

Put together something to handle the animations/state issues, but not that fond of my system so far. It still feels overly clunky to me. I think I'll handle walking around terrain next, and not being able to walk through walls.

Family = No Progress

Primary Goal completed, secondary goal, not so much

Camera control is working nicely, and I'm not even disgusted with how I coded it. Next goal is figuring out how to get the twisted animation/state machine/general madness in my head into a coherent smoothly blending animation machine thing.

The above paragraph made sense in my head at least.

Plans for the weekend

Going to try and get a character moving about, with decent camera control abilities this weekend. If time allows, also going to try and work out a system to get mesh animations set up in a fashion where the character can smoothly break into a run, walk, stand idle, ect.

That's the general idea for the rest of the year, set a goal each weekend, and make sure it gets completed. Probably ought to also make a rough sketch of everything I need to get done to make sure there are less than 60 things.

Really concerned about art situation, considering the artist/programmer ratio. Considering ways to change art style to allow simpler models (so I can do them myself if need be) yet still look good. Definitely going to need to become an expert on shaders, or at least an above average.

Worries for another day though.

Progress.

Scribbled out a quick design document describing main characters in the game, the worlds, gameplay concepts and ideas.

Reaper's Tale

This blog is a progress recorder for my senior project at Shawnee State University's Digital Gaming and Simulation BS degree. The project is intended to be an action/adventure style game, starring the newly appointed grim reaper, on a quest to regather the power of death from other death gods, before they can destroy the reaper.

Current short term objectives:
1. Figure out a basic format for a design document.
2. Design design design, changes on paper are easy, changes in code are painful and error prone.