Actually my system comes in 2 parts. The tree which is used only for lookup and a UpdateInputState procedure which is used in the main game loop. What it does is it checks DirectInput when its called, and if a key is pressed, it compares that input to the state tree to determine if it can proceed to the next state.

For example in UpdateInputState:

First thing I do is to construct the inputState from the input devices.

State tree:
Neutral
+---Up
+---Down
+---Space
+---Left
+---Right

key is the DirectInput keyboard array (just an example)

if (key[DIK_UP])
inputState |= 0x01;
if (key[DIK_DOWN])
inputState |= 0x02;
if (key[DIK_LEFT])
inputState |= 0x04;
if (key[DIK_RIGHT])
inputState |= 0x08;
if (key[DIK_SPACE]) // Used as an example of ''punch''
inputState |= 0x10;

At this point we should have an inputState of collected bits. Let''s say we have 0x02 (DOWN). I look at the state tree for the current state.

I compare the current states next state list against the inputState. If they match I switch the current state to the next state.

Not sure if I explained this properly. Basically there is a tree in memory that never gets changed once loaded. There is a procedure that goes in the main loop that checks input, if the correct input is found, it then sets the current state to be whatever the input that came in told it to be.

Also, yes I still am worling on the Swordplay Engine. I am making great strides with it as well. The last time I updated my page I was working on my 2 editors. The second of which was almost done. It is still almost done but I am closer to finishing it now. The main problem comes with my skeletal animation code. It almost works and I may be on to a solution. The other things I have doing have to do directly with what I was trying to explain above.

I have integrated the animation system with the input system. What that means is basically the input system tells the animation system what to do. So if you are in the Neutral state, it tells that animation system where the neutral animations are, how many frames, how long to display them, the special effects, etc. I am trying to finalize how everything fits together. When I am done I am going to have a system where you can totally define most of your game in data files and it will a completely automated system. The game loads the skeletons, the models, the special effects, and the moves then just does whatever the files tell it to do.

Everything is coming together but I just have to finish the skeletal animation system before I can really do anything else.

Oh yeah, sorry for the long post. I guess noone realy asks about the project so I go off on a tangent when the chance arises.


L8tr,

Kinfira
Lead Programmer
KinfiraSoft
Makers of Swordplay, a 3D fighting game engine.
http://kinfirasoft.8m.com

quote:
Well, the state trees - as you had said in the information given thru the links - would have function pointers on the leaves, and these funcitons would check the state of the fighter before attempting to execute. For example:


if (fighter.onground && fighter.freeToAttack) fighter.ThrowGroundFireball();if (fighter.airborne && fighter.freeToAttack) fighter.ThrowAirFireball();

Umm, I think it would be desirable to shift this to a more encapsulated method (if you are using C++). Instead of the app checking what moves the player can do, just say

fighter.ThrowFireball();

Then in the ThrowFireball() code, you check all the fighter''s current attributes and launch off the correct one (maybe in the future you will make fireballs more powerful if you stand still for a long time or something, and it becomes more managable).

Just my opinion.

wise_Guy, only thing about that is that the fireball action would be "static"...with the way thats explained you can just create a new animation, "script" a command movement that links to the animation and not have to recompile a thing for the main part of the program. A good example of this is m.u.g.e.n. (www.elecbyte.com).

Kinfira, thanks again for explaining that both here and on your website. I''m working on mine as well, hopefully it will all come together.

Amadeus (Geoffrey)
ronwc@pipeline.com

Ahh yeah you''re right. I hadn''t thought of scripting. Speaking of MUGEN, has anyone tried to make a 3D version? In my opinion, it would be easier for the end user because making a 3D animated model is easier (for me anyway) than making sprites.

When I get my skills up, I would like to attempt something like that! (yeah... right...)

I think that Kinfira is building that type of engine right now .

But, I''m also having some fun with developing this sort of game. With the extensibility it has right now it would do pretty well, you can load levels, have custom entities on the level, load and animate models. But I don''t have the same sort of system in MUGEN, where you can define fighters actions, that''s all in code right now. In the future though, who knows .

PreManDrake
http://www.fortunecity.com/rivendell/soldier/619

Actually the aim for my engine is a bit more generic. If I understand M.U.G.E.N. correctly no programing is involved. My engine will always require programming.

There are some things that cannot be done in a generic fashion which is why there is a need for programming. It will be possible to make a M.U.G.E.N. style product with my engine, but that is not my goal.






L8tr,

Kinfira
Lead Programmer
KinfiraSoft
Makers of Swordplay, a 3D fighting game engine.
http://kinfirasoft.8m.com