6
\$\begingroup\$

I'm building a prototype for a fighting game (not vs, something like Final Fight). I'm trying to define the data for the player combo tree and had a look around looking for inspiration and have seen games like Street fighter that base its combo timming on frames instead of time. The game is locked at a fixed frame rate too.

My question is, my game is targeting Windows, so, there are a lot of processes running in a computer. If I base my combo timmings on frames, can't a cpu spike produced by another process break my game?

A solution to fix this is to check every Update() how many real logic frames have passed (based that we want our game to run at 60 logic frames) and run the combo system all these number of frames at once. But not sure if this would work.

Beside all this, another problem is that Unity does not provide a separated thread for rendering and logic that could be configurable and accesible by the developer (It does not even have a frame rate independent input system shame).

Well, what do you think?

Cheers.

\$\endgroup\$

2 Answers 2

Reset to default
5
\$\begingroup\$

Locking at 60 fps is certainly viable. From what I've seen, just as you've said, it appears fighting games typically describe timings in number of frames, even as most fighting games have transitioned to 3D (where it's rare to rely on discrete frames of animation). The drawback of doing this logic in Update() in Unity is that the game will slow down if the framerate dips below 60 fps.

If you want to, as you've put it, separate "logic" frame rate from "rendering" framerate, you can do your logic in FixedUpdate() instead of Update(). The physics system (which governs the rate of FixedUpdates) can be configured to whatever framerate you want to use, and won't be slowed down by rendering, although with enough of a load on the CPU, the FixedUpdate rate can fall behind its target, too.

\$\endgroup\$
5
  • \$\begingroup\$ Yes, I though about the fixed update too. The problema is, that if you want to apply some kind of physic behaviour to your game, you can be running physics too frecuently. On the other hand, using FixedUpdate doesn't assure you that you will get a call every 1/60th either. So, we can hit same problema. Perhaps, as I said, a combo system that could be advanced more than 1 frame could do better. Have to investigate this though. \$\endgroup\$
    – Notbad
    Apr 28, 2016 at 7:49
  • \$\begingroup\$ 60 frames per second is definitely not too frequent for the physics engine to perform well :) KarBOOM actually runs the physics at 120 frames per second so as to handle slow motion nicely. How many physics objects do you want in your game? And how complex? \$\endgroup\$
    – Jibb Smart
    Apr 28, 2016 at 7:53
  • \$\begingroup\$ I haven't defined that at this time yet. It depends on the way I choose to do things. I'm evaluating to throw unity phycs away and try to implement a simpler method with just AABB. It is nice to see games like KarBOOM with such high physics rate :). \$\endgroup\$
    – Notbad
    Apr 28, 2016 at 8:04
  • \$\begingroup\$ Thanks :) Yeah, Unity physics can seem like overkill if you only need AABB. And if you do decide to add physics stuff later, you might not want it running at the same rate as your AABB system. And AABB shouldn't be hard to implement. So, in the end, the answer you're probably looking for is: "Yes, counting how many 'logic' frames have passed since the last 'update' and doing them all at once is a good solution." Incidentally, that's how FixedUpdate() works internally. \$\endgroup\$
    – Jibb Smart
    Apr 28, 2016 at 8:20
  • 1
    \$\begingroup\$ Will have to play a bit around this :). Thanks for the nice talk. \$\endgroup\$
    – Notbad
    Apr 28, 2016 at 8:25
0
\$\begingroup\$

Instead of checking how many frames have passed, try checking how much time has passed instead. In Unity, you can check how long the previous frame took to complete with Time.deltaTime. Delta time for 60 frames per second is 0.016666 (6 continuing). So, add delta time to a float variable every frame, then check if it is greater than X (where X would be about 0.3333 for 20 frames at 60 FPS). That way you won't have to worry about the framerate. It is almost never a good idea to tie your game logic to the framerate.

TL;DR: In short, don't add 1 each frame and check if it's greater than X, instead, add delta time (each frame) and check if it's greater than 1f / [target framerate] * X. (X is number of frames)

\$\endgroup\$
1
  • \$\begingroup\$ Well, we are talking about two different concepts here. Tie logic to framerate and measure combo timming in frames. It is a totally differnt concept. As I suggested, you can, every tick check the elapsed time and vonvert it into frames to apply the combo logic. That is, more or less same thing you suggested. \$\endgroup\$
    – Notbad
    Apr 28, 2016 at 7:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .