Why isn't RenderStepped good for FPS games?


So I was curious, is RenderStepped/RunService good to use for Roblox FPS games? Or should I make more complex framework? (Putting the camera at the CFrame of the head every frame)


This is actually quite contrary, for updating the camera, it’s ideal to run this every render step so the camera doesn’t hitch, and for the view model of the gun as well.

If you incorporate other logic with this though, such as gun logic, then you might run into performance issues. But solely for updating the camera alone, it’s definitely the ideal approach.


Actually, it’s great for some things!
However, like most things in life, in other cases, its quite awful.
This all depends on the task at hand, if it’s performance heavy, it will run every frame, leading to some lag. If you do use it, make sure to keep your code DRY (Don’t repeat yourself), and light performance-wise


Renderstepped is perfect for the camera, but what it isn’t perfect for is the camera sway / the viewmodel sway. People that use FPS unlockers would have extremely fast camera / viewmodel sway while moving at a slow speed, which breaks immersion and would leave a bad impression on the player.

I think.

Then those people shouldn’t use FPS unlockers and/or your sway logic is flawed. Use the time delta given in the event to ensure you have equal sway regardless of whether they are laggy, at a perfect 60 FPS, or running higher with unofficial unlocking.


My sway logic? I don’t make fps games. >->

Going about with the idea of “just don’t support the people that …” is a bad way to develop. It’ll slowly take you down the path of anything that’s unintended becoming a liability of the player instead of the developer. Code should work as intended irregardless of the state of the game, especially when someone is using something as measly as an FPS unlocker, don’t you think?

It a external feature that people use along with the roblox, You don’t need to support such a feature and should only be a concern if roblox supports it, which they don’t.

I agree, when the user is using the program as intended.

Even so, if you create the logic correctly using RenderStepped and actually utilising the parameters it provides correctly, it’ll work regardless.

I said your sway logic as you seemed to be referring to a specific logic that wouldn’t correctly handle different deltas between each frame. It’s a strange assumption to make if you were just talking about some hypothetical logic, but it doesn’t really matter. If the person uses the events correctly and makes use of the data it provides, there should be no issue.


It’s probably fine. Depends what you use it for. CFraming the camera? Yes, that’s fine.

1 Like

RunService is very powerful for FPS games, since you are able to update important things (such as gun position, camera movement, UI animation) per frame. Although, it is recommended to keep the functions lightweight and computationally simple.

If you do plan to implement RunService, it is recommended for you to use :BindToRenderStep() rather than .RenderStepped, since it’s usually useful to run a function before your screen renders for the next frame (such as custom camera movement).

Both .RenderStepped and :BindToRenderStep() has a delta time parameter when it calls your defined function. This is the time elapsed since the previous frame. With the delta time, you can get keep your values increasing at similar rates regardless of what FPS your player has.

1 Like

All run service events fire every frame, RenderStepped should only really be used for camera movements and anything you want to be in sync with the camera updates.