• Advertisement
Sign in to follow this  

Animations and Models in a Game Engine

This topic is 1925 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey guys, first time poster. I just discovered this site, and it looks like a pretty incredible wealth of knowledge. smile.png

Anyways, I'm looking for some information on the use of animations and models when designing a game engine. I've been doing some Minecraft modding in my spare time (not the strongest engine, but it works fine for my purposes) and was able to import MD2 animations into the game. As you may or may not know, vanilla Minecraft hardly supports animations or models at all and rather says "Let's make a cube to be this creature's head and wiggle it around when he moves." Now that I have real animations in the game, I'm working towards putting first person animations with weapons into the game, but I really want to take my time and plan things out correctly.

How might I go about this? From what I understand, many games separate weapon models and hand animations. Are weapons typically designed as classes with information about animations contained within? What about other information about the weapon (damage, which animations to play and when, etc.)? Are there any examples or articles that might point me in the right direction? I really want this design to be as robust as possible.

Thanks so much guys!
- Andrew

Share this post


Link to post
Share on other sites
Advertisement

  1. Are weapons typically designed as classes with information about animations contained within?
  2. What about other information about the weapon (damage, which animations to play and when, etc.)?
  3. Are there any examples or articles that might point me in the right direction?
  4. I really want this design to be as robust as possible.


  1. Define what a weapon is. A weapon has logic. A weapon has appearance. Most of the time, the two representations are decoupled. The representation is an ordinary model and there could be some loose connection with weapon animation... but to my knowledge, everything that's vital is in the logic.
    Say you have a laser beam. A typically "model" information could be "point from which the beam starts".
  2. Damage, or cooldown is an example of key value which I suggest to store in logic (or at least, not in the model itself). I've also seen a few games which relied on the actual mesh animation to cooldown ("fire again as soon as the cooldown animation has finished"). I don't consider it good practice.
    Animations to play are stored in the mesh, but the logic drives them.
  3. When I'm out of ideas, I read stuff about system proven successful. I'm not saying I'm cloning them, but sure UDN has been very valuable source of inspiration to me.
  4. Having been in the "as robust as possible" mindset myself, I'd rather suggest to design it to support what you really need. And very little more.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement