Jump to content

  • Log In with Google      Sign In   
  • Create Account


Entity state and animation


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 Telanor   Members   -  Reputation: 1285

Like
0Likes
Like

Posted 09 May 2013 - 01:10 AM

I'm trying to find a way of separating an entity's state (running, attacking, blocking, etc) from its currently playing animation(s). I have a client/server network architecture and need to be able to have the server communicate entity state's to the clients. I'm also trying to set the system up in a moddable way, so that player-created mods can add new animations and states. It may prove too difficult to make it moddable though so I'm willing to give up on that part if needed. And the last part, I want to be able to play multiple animations at once in a layered/additive manner, so an entity would be able to walk and attack at the same time.

My initial idea was to just make a bunch of booleans: isAttacking, isBlocking, isWalking, etc and then have the animation system check those conditions to determine which animation(s) to play. It's workable, but not extensible. There would be no way for a mod to add any new states or animations using that system. Plus it could get rather cumbersome if there were a lot of states. So I was wondering if someone has any suggestions on a better system?

Sponsor:

#2 Dawoodoz   Members   -  Reputation: 290

Like
1Likes
Like

Posted 09 May 2013 - 03:53 AM

My engine's SDK show how to make procedural bone animation from math so that jumping forward and landing sideway cause the character to sidestep when landing to keep balance. "BoneAnimation" is the simpler example and "GiantMaze" allow colliding with things. Previously I tried following the laws of physics with ragdolls that fall to the ground like drunk people but even with a perfect balance system you would still have to break the natural laws with air acceleration to make it fun to play.


My open source DirectX 10/11 graphics engine. https://sites.google.com/site/dawoodoz

"My design pattern is the simplest to understand. Everyone else is just too stupid to understand it."


#3 Vilem Otte   Crossbones+   -  Reputation: 1354

Like
1Likes
Like

Posted 09 May 2013 - 03:55 AM

What about State Matchines? Let's just imagine a simple case:

 

Imagine an actor inside the world. It's staying on point A, it's state is IDLE. Now his AI determines he needs to go to point B, so he gets the path from AI. The state changes to WALKING and his virtual position is moved along the path to the point B. Once he reaches point B, his AI determines that his goal was successful, the state changes to IDLE back again.

 

Now the state-animation relation for each entity can be stored F.e. as:

State IDLE
{
      Animation "idle.anim"
}

State WALKING
{
      Animation "walk.anim"
}

 

Each of your entity type you will have stored state-animation relation. Each single entity will store its state (you don't need to use strings, use IDs instead of them - assigning them in load time based on the strings ... or store state names directly as IDs, but it's quite to harder to make that easy-to-describe ... nah I think you get this idea). Now upon processing your entity, you check it's state, update it and render it with animation based upon that state.


My current blog on programming, linux and stuff - http://gameprogrammerdiary.blogspot.com


#4 Telanor   Members   -  Reputation: 1285

Like
0Likes
Like

Posted 09 May 2013 - 07:33 PM

I had thought of that while making this post but dismissed it because it seemed pretty much the same as my original idea. But thinking about it again, there's no reason the state machine has to be a hardcoded switch statement. A state-animation list like you suggested, built at runtime, might work out. I'll give it a try. Thanks for the suggestion




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS