Frame dependant game. Using update vs fixed update.

If I wanted to make a fighting game where each action is dependent on frames is it possible using unity?

For instance if the punching action was designed to take exactly 20 frames and the game was designed to run at 60fps. How would I go about doing this? Coming from an XNA background my first thought was to set a target frame rate of 60fps and make the punch last 20 update calls. However I noticed that target fps is ignored from within the editor making it difficult to test things easily.

I saw some people mention that using FixedUpdate instead of Update means I can get time consistent updates. Would it be correct to say that I need to set both my target fps to 60 and my Fixedupdate step to (1000/60)ms? I also read that this can cause some stutter issues as the Fixed update is called so close to the normal update. Also if the graphics drawing is synced with the normal update this is also less than ideal to use FixedUpdate to do all my game logic.

Is there another way to get Unity to respect target FPS in the editor so I can do all the logic in Update()? Slight slowdown but keeping the actions coherent with the fps would be preferable over jumpy behavior using Fixedupdate.

I think fixed update just puts a higher priority on the line of code.
so that the lines of code in fixed update load first then regular update second however I wouldn’t bother with it unless you got a lot of scripts running at once.

now to your question about punching… I would use time.deltaTime witch would display the punching over a set number of seconds
here is the tutorial for time.deltaTime I think this will help you because what I think your trying to do is set a limit on how fast the punching action will take http://unity3d.com/learn/tutorials/modules/beginner/scripting/delta-time

If you want it to all be based on frame rates you should use Update()

You can also use animation events which will allow your skills to trigger or enable/disable at specific spots of the animations which are also based on the Update()

FixedUpdate() will not sync with Update unless they are manually set to the same timing AND the frame rate is perfect which you shouldn’t expect on all systems/devices.

So use Update() if you really need time to be accurate you can do this within Update as well with Time.DeltaTime

This is how you can set a Frame Rate to a fixed value:

Application.targetFrameRate = 30;

If you are having trouble with smooth game play you can lower it from 60 like I am trying out 30 on my current mobile game.

Unity’s Update() exact framerate is a tricky thing to manage. You can set it, but it seems that it’s not adhered to flawlessly. It may go high or low for a while, and will definitely go low if your hardware is struggling to keep up for any of many reasons.

FixedUpdate() does reliably run at a fixed rate, but altering this can have significant performance impact. I recommend not changing the fixed rate for game design conceptual reasons. It’s mostly for balancing game physics artifacts versus performance cost.

If you do choose to alter one or both of the above, they don’t need to be set to the same rate.

Since you want to conceptualize your game combat timing (and, presumably, character animation) in terms of “frames”, you could still use Update() for game logic and rendering, and FixedUpdate() for game physics, but abstract the timekeeping aspect so you can think in terms that are natural to the fighting genre. This would give you the advantage of highest possible framerate, for better visuals, when the game isn’t burdened, and consistent real-world timing, even if the framerate happens to drop for whatever reason (and with only very tiny artifacts, “punch” will just punch on the next available frame).

One way to do this: Write helper methods that wrap time-based concepts in terms of “cframes” (classic frames, a data type I just made up), where one cframe is 1/60th of a second. Everything that is timing-based would need to have a method of handling with cframe parameters instead of time parameters. Once the dirty work of abstracting this is done, you will rarely have to think of Time.time (the current system time in seconds) or Time.deltaTime (the current Update() frame duration in seconds) again. It will also keep consistent behavior from editor to deployed build.