   My code become a pain.
  Hi all,i'm developping a little game this is a video of current state of game:">Current game progress youtube video Now i have a problem about organization of code. For example for cast spells with cast time i do something like:in the caracter class i will call castdirectdamage()bool cChar::CastDirectDamage(float cast_time){//TODO check target check LOS checkif(isCasting)return false;if(isJumping)return false;mCast_time=cast_time;mStartCast_time=mTime;mSkinnedMesh->PlayAnimation("PreCastOmni");isCasting=true;}then in update character i call void cChar::UpdateDirectDamage(){if(!isCasting)return;if((mTime-mStartCast_time)>mCast_time){mSkinnedMesh->PlayAnimation("CastOmni");isCasting=false;}}For jump animation where i need to play 3 different animation (jump_start,jump_loop,jump_end), my code is full of if(boolean) if if if if if Ok i did this cause it's faster to do and understand the things, but now i want more organization. I'm thinking about create a DWORD with bitmask for adding removing and checking flag with OR, AND and so. Or create enum for different state and then write a big big switch for all the case , but anyway i feel like this is not a scalable solution.Can someone give me an idea or so? Thx for your time.   
  I would implement the delay-time like this:Casting spell:if(isCasting || isJumping)return 0; //hehe, i know, not much change.delay= spell_delay;[other code]Updating character:if(delay > 0){delay--;if(delay == 0){mSkinnedMesh->PlayAnimation("CastOmni");isCasting=0;}}   ;  You can try to implement this by using a Finite-State-Machine for the different player-animation-states:Finite-State-PatternSo if you want to jump you need a state transition jump_start, then perform the jump-animation and perform a leave-state-transition jump_end. This is a more generic approach than implement everything with if-then-statements.Good luck,Kimmi   ;Quote:Original post by KimmiYou can try to implement this by using a Finite-State-Machine for the different player-animation-states:Finite-State-PatternSo if you want to jump you need a state transition jump_start, then perform the jump-animation and perform a leave-state-transition jump_end. This is a more generic approach than implement everything with if-then-statements.Good luck,Kimmithx, look really nice i will try this solution.   ;  I would use a process to do this. Very nice example of doing this sort of thing in Game Coding Complete. Its made mygame code so much neater and easy to understand.You can create processes for anything really, can chain them together and all sorts. I highly recommend you take a look. Its really too much for me to explain the ins and outs but its very simple once done. It basically moves all the update things to a different object along with whatever else is needed. You may have a process that casts a spell, it would have some initialisation and an update function that handles all the charging, any animations that should be played, launching the spell etc etc. When you want to fire a spell you just created the process and add it to some process manager.  the process should be able to kill itself if you stop casting etc (flag itself as dead, process manager takes care of it).I have one for reloading weapons which does loads of things very neatly (playing reload animations on my character and the gun, unscoping if I'm looking down iron sights, moving bullets (numerically) from total ammo to clip. Anyway, I am very impressed by its use and its saved me so much time and kept my code very neat.I can't really find any tutorial on it but it is in Game Coding Complete (I think the source is availible online).http://www.mcshaffry.com/GameCode/   ;  I definitely recommend the finite state machine approach. For my project, I had a massive Player class filled with special-purpose booleans to track what the player was currently doing and what special transitions he could make. Explicitly separating that out into states that were allowed to transition to other states really cleaned up my code. Now instead of having one huge file, the player has a nice simple file and there's (so far) 8 separate files each for a different state the player can be in, each under 100 lines of code. Very manageable.   