Zuk
Member
- Joined
- Sep 23, 2010
- Messages
- 108
Well you probably want to keep the collision area the same for all characters or some would have a advantage or disadvantage (or you would need to balance that out with a stronger throw, etc.), so going with a fixed 16x32 for the sprites seems good to me.
You could make so characters can be up to say 18x34, but all pixels outside the centre 16x32 area are not taken into account for collision detection - so there is some room for single hairs sticking out or certain frames being slightly larger.
I currently have custom values for each character for their run/walk speeds, frictions, strength/throwing speeds, resistance to damage, ect... size could be one more thing that wouldn't be any harder to throw in and the other values could be set to handicap or help to offset size differences. I already calculate a character position and then offset the drawing of the sprite from there so it is always centered above. Some of the animations flux between 16 and 18 pixels wide so I did it that way.
I am not saying the game should run at 10FPS or something like that. The game obviously should run at 60FPS (especially if you are only calculating collisions every frame, which it sounds like you do) - usually I would even advice to run the update loop (collision, movement, etc.) on a much higher framerate (500 or 1000FPS) and only update the screen (render, flip) 30 or 60 times per second.
That all does not mean the sprites have to be animated at the same rate, you could easily just display a new animation frame every 6 screen frames, which would give you a sprite framerate of 10 FPS.
So, what I am trying to say is, keep the animations separate from the global update loop to allow assignment of custom framerates per animation. (In Penjin for example every animated sprite has its own timer to keep track of updating the animation, totally independent of what framerate the game is running at. So in Greyout I have some animations running at 10FPS, some at 15, one even at 8, while the whole game is running at 60FPS).
I see what you are saying there. Right now I have it kind of like you described. I have the game loop running everything on every loop and have been basing all the animations off of that magic 60fps. I have variables in the character structs that keep track of what animation they are doing, what cell in the animation they are on, what frame they are on, and how many frames that should be displayed before moving to the next cell. I translate the frame per cell definitions when it loads the character to the target frame rate. I never thought about running the main loop without drawing the screen every time, though, because I don't know how to track how fast it's actually moving. I think the screen drawing is probably the simplest thing going on logic-wise. It's pretty much (right now) just a depth sort and slapping about 30-50 sprites into the back buffer. I think all of the sprite stuff is hardware accelerated and not really bogging anything down.