   Animating a Beat Em Up
  I'm in the process of designing how i'm gonna go about building a 3D fighting game for my portfolio. I hope to make the game play very similar to the fast-paced/frantic/arcade-style action seen in most 2D fighting games (Street Fighter/Guilty Gear) as opposed to the much smoother, more technical 3D ones (e.g. tekken/soulcalibur/DoA etc..)This led me to the point of trying to decide how best to handle character animation in the game (either frame-based or time-based).. I assume adopting a frame-based system would work well except that it locks the animation to the framerate which would mean the game wouldn't remain balanced in terms of speed, across varying hadware setups.. This is bad as I need the game to be able to play just as fast on one machine as it can on the next..On the other-hand I thought going for a time-based system would lead to issues of frame skipping (i.e. lag caused by processing some arbitrary effect for example, could force the game to skip frames of animation to catch up).. This would be bad since if i had very swift punch attacks for example which required only a couple of frames, the game may skip most (or at worst all) the frames ruining the entire animation..Maybe i'm jumping to unnecessary conclusions here but I'm just trying to understand what potential problem might be from both methods and hopefully get some feedback on how best to solve the problem..Maybe an absract-frame based system would work better for example..?If I could get some feedback here it would really help me!Thanx Gamedev![Edited by - ArchangelMorph on June 15, 2006 1:30:15 PM]
  Wow no replies?Is there truely nobody round who can help?   ;  First I'd just like to say that you have to be careful with terms like "fast-paced" and "technical" as they apply to fighting games. SF3:3s is widely considered to be very technical (although I personally feel that all the real technical elements are designed in a terminally retarded way :) ) - see for example multiple parrying, red parries, Dudley corner juggles etc. Meanwhile, SC2 has a round timer that (by default) runs out quite a bit faster, and rounds are generally over *much* faster in competitive play - at least the competitive play that I've seen :) The *moves* may be slow, but the *movement* is quite a bit faster and free-flowing than in typical 2d fighters, and actually much faster than you can do in tekken (unless you can wave dash or wtf-ever they call it in tekken).Anyway, sprite animation normally does work a lot better with frame-based timing, because of the frame skipping, yeah. If you do it time-based, then you'd better be able to get at least the "minimum intended" FPS on the low-end of your specified target machine, or frames get skipped. (Though on the other hand, any half-decently modern PC ought to be able to handle a "2D fighting game" just fine, unless you're planning some ridiculous physically-modelled particle effects or something o_O)On faster processors, frames get duplicated, and the animation isn't really much smoother as a result (positions are interpolated more smoothly, but animation frames can't be interpolated, and the frame duplication isn't "even" unless you run at an exact multiple of the "base" FPS).   ;  Sorry, I forgot to specify,I intend to build the game as a 3D fighting game using 3D models but with the "feel" of a 2D fighter..I'll ammend my original post now..Pele..   ;  Aha.Yes, do abstract it, then. Have the "physics update" accept a parameter to indicate time elapsed since the previous update; if you do go with a fixed frame rate, then you'll just always pass in the same value (after doing the appropriate amount of sleeping in the main loop) and you can always optimize later.   