In my FPS game there is an automated lock system. If you stare at an enemy, your weapon locks onto the enemy as long as your aim is hovering approximately around the target.

If my player sets frame rate high (say they changed frame rate from 60 to 140+) they have smooth frame rate in which allows them to change their view more smoothly. My players can now hover their aim onto an enemy more rapidly.

Problem is, if my game were to run at 60 ticks per second while the player set the render system to render 140+ frames per second, my game's tracking system will be a few frames behind what the player looks at.

So I am wondering, should my game's logic run at the same rate that the rendering system is rendering the game? Or can I solve this synchronization issue in another way?

  • \$\begingroup\$ I've edited your question to remove "what tick rate should I use" as that involves a fair bit of opinion and is a good way to start a 30 vs 60 vs 120 vs no-locks flame war. ;) I think solving the aiming issue you describe is the heart of the problem. When you say a high-framerate player can "aim onto an enemy more rapidly." do you mean their turning rate is controlled by their framerate? (ie. a player could look around more quickly at higher framerates) Or just that they have more precision of intermediate frames to stop/shoot while still rotating at the same rate per realtime second? \$\endgroup\$ – DMGregory Apr 8 '18 at 15:32
  • \$\begingroup\$ Also: for an overview of some of the reasons you might not want to couple your simulation update rate to the rendering rate, see this earlier Q&A. \$\endgroup\$ – DMGregory Apr 8 '18 at 15:33
  • \$\begingroup\$ @DMGregory the higher your frame rate, more precision you have at where you are looking at. Now I think about it, it shouldn't be the case right? If I bind player's rotation rate based on the frame rate (because it is a first person shooter) higher frame rate player has an advantage. but then again, if I bind rotation rate to the game logic, no matter how fast your computer can render my game, you will FEEL like game is not responsible because rendering system will do interpolation of the movement rather than processing your mouse movement based on your next mouse movement after each frame. \$\endgroup\$ – Blue Bug Apr 8 '18 at 15:59
  • \$\begingroup\$ I'd question the assumption that the player will feel like the game is unresponsive in the latter case. The key to responsiveness is the tight loop between input and observable feedback. If I can move & click my mouse and see a visible change to my perspective and a muzzle flash this frame, then it feels very responsive, even if the physics kick from the recoil doesn't hit until the next physics step. A lot of the art here is separating the feedback you can offer the player instantly without biasing the simulation from the parts that need to be done at fixed steps for consistency & fairness. \$\endgroup\$ – DMGregory Apr 8 '18 at 16:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.