koobas.hobune.stream
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.
Update runs every frame, so it's probably possible to have a counter in your scripts that counts the passed updates.
I don't see why you concern with fps... if your action takes 20 frames, it'll take 20 frames whether the fps is 10, 60 or 100.
$$anonymous$$aybe I understood you wrong and you mean that your action takes 0.333... seconds, so at 120 fps your action would take 40 frames?
jamora I think what he is trying to do is make his punching animation smoother, If his punching animation only takes 20 frames and the computer is running it at 200 its going to be fast but if the computer runs it at 20 frames it will be slow. I think what jkh13 is trying to do is put a fixed amount of time for the punch animation. or I could be totally wrong.
I am trying to achieve a system where the frame rate deter$$anonymous$$es everything ins$$anonymous$$d of time elapsed. In a fighting game actions are generally analysed by the frames that they are active ins$$anonymous$$d of the time they are active. $$anonymous$$ost fighting games have a target frame rate (usually 60fps) and the design of the moves and how long they last is based on this entirely. Also the graphics drawing would be synced to the frame rate as well. Small amounts of slowdown in the framerate are tolerable as long as the logic always adheres to the frames and never relies on elapsed time between frames to do any logic. The problem I am running into is that sticking all my logic in update is correct in terms of frames but totally screws up because the editor doesn't seem to want to keep to 60fps, the target fps is see$$anonymous$$gly ignored in the editor. I have stuck all the logic in FixedUpdate() ins$$anonymous$$d to counteract this as I assume FixedUpdate is called at a constant pace. I was also wondering if it is possible to get coroutines to work with Fixedupdate? as in can you yield until x numbers of FixedUpdate frames have passed?
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
this should also eli$$anonymous$$ate the need to put a max fps on your game
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.
How would I get this to work in the editor? I created a new GameObject at the root and attached a script that sets Application.targetFrameRate = 60; in the start() method. $$anonymous$$y FPS counter still records way over 60fps, it appears the script has no effect.
Hmm I never noticed that until now but it's not to surprising the Editor has a lot of differences from the actual builds.
So what is your frame rate when you set it to 60?
I just tried setting $$anonymous$$e to 120 and now it's like 150ish, but a $$anonymous$$ute ago it was 500+ with this setting.
Setting it to 1000 and it's going over 1300 ^^
Hmm I think the trend I'm seeing is that the Unity Editor does not respect the frame rate very well, I think it should work better in the actual builds then editor.
But when I use Application.targetFrameRate = 30; my frame rate is around 33 right now on average in Editor, it was going 40+ with the same setting earlier.
So frankly I have no idea what's going on but it's never actually been a problem with my projects. Is it really messing yours up or just bothering you that it's not consistent?
From Unity Documentation:
"Note that setting targetFrameRate does not guarantee that frame rate. There can be fluctuations due to platform specifics, or the game might not achieve the frame rate because the computer is too slow."
So yeah I guess there's a lot of different variables I wouldn't worry about it unless it's actually breaking your game.
You could also try using:
QualitySettings.vSyncCount = 1; with values 0, 1, or 2
This could maybe help you get more consistent or desirable rates.
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.
