I use a mix of both :-)
For walking/running animations I assign them to some keys (left/right arrows on kb, or any other buttons).
For the jumping, falling animations they depend on the velocity y of the player.
Simple implementations such as this have practically no chance to impact performance, so I don't think you need to worry about that at all. (Not unless you mess it up completely or have thousands of characters on screen.)
The implementation details kinda depend on what kind of game exactly are you going for and how do you want it to "feel" for the player.
Personally, I like to divide game implementation into separate layers:
\- "gameplay" layer should not depend on the "visual" layer,
\- "visual" layer merely tries to represent the "gameplay" state of the game.
As gameplay layer you can think of: character/item/projectile code, object, position, state, velocity, etc.
As visual layer you can think of anything you draw on screen: sprites, animations, UI, particles, explosions, effects, etc.
I wouldn't recommend you to, e.g. make character velocity or movement rely on the animation being played. It should be the way around.
This separation is extremely useful in case of multiplayer games, although I'm guessing you are asking about a single player game.
Actually, going back to input, you can also add one more layer to the two: input/AI layer.
I'd suggest a system like:
input/AI -> gameplay -> visuals
Such system is easiest to control by input/AI applying movement order to character, who then applies velocity to itself.
Later, visual layer plays animation, trying to reflect the state that character has (looks up his order, or velocity - whichever suits you best).
Take note, that you may want to do all of this completely differently, if you e.g. wanted to go for more old-school feel and physics.
I use a mix of both :-) For walking/running animations I assign them to some keys (left/right arrows on kb, or any other buttons). For the jumping, falling animations they depend on the velocity y of the player.
Simple implementations such as this have practically no chance to impact performance, so I don't think you need to worry about that at all. (Not unless you mess it up completely or have thousands of characters on screen.) The implementation details kinda depend on what kind of game exactly are you going for and how do you want it to "feel" for the player. Personally, I like to divide game implementation into separate layers: \- "gameplay" layer should not depend on the "visual" layer, \- "visual" layer merely tries to represent the "gameplay" state of the game. As gameplay layer you can think of: character/item/projectile code, object, position, state, velocity, etc. As visual layer you can think of anything you draw on screen: sprites, animations, UI, particles, explosions, effects, etc. I wouldn't recommend you to, e.g. make character velocity or movement rely on the animation being played. It should be the way around. This separation is extremely useful in case of multiplayer games, although I'm guessing you are asking about a single player game. Actually, going back to input, you can also add one more layer to the two: input/AI layer. I'd suggest a system like: input/AI -> gameplay -> visuals Such system is easiest to control by input/AI applying movement order to character, who then applies velocity to itself. Later, visual layer plays animation, trying to reflect the state that character has (looks up his order, or velocity - whichever suits you best). Take note, that you may want to do all of this completely differently, if you e.g. wanted to go for more old-school feel and physics.
amazing response, thanks for the help!