How to Reduce Input Lag?

[WillyEdison]

I’m thinking about how to reduce input lag in our team’s game, WillyEdison’s Microgames. While input lag is not a major problem currently for the game, I would like to capitalize on that strength, make the most of it.

Since other posts on the forum have referred to it differently, in this context I don’t mean internet latency (ping; how long it takes for client and server to communicate), I mean the time between pressing a button and seeing the effect on-screen.

I have thought of using Stepped:Wait(), Heartbeat:Wait() (to be specific, task.wait(), which does the same thing), and RenderStepped:Wait(), as per the Task Scheduler documentation, however I would like to learn additional methods of reducing input lag to increase my knowledge. I also thought about increasing player character turn speed, which may feel a little bit slow at times.

What methods would you suggest?

[pullman45]

@WillyEdison

I mean the time between pressing a button and seeing the effect on-screen.

If the effect is solely rendered on the client, then there won’t be input lag unless a certain function in your code yields or a certain block of code is extremely inefficient (this rarely happens and is usually obvious as to what causes it).

Otherwise, if the effect is on the server then it certainly is network latency that causes the delay. I tested your game, and the only input lag I saw was with the pistol tool. If the bullet is owned by the server then that would in fact be a ping issue. Since you said your problem isn’t ping, that leads me to believe that your bullet does not exist on the server because that’s the only way you can avoid network lag.

There’s no general method to reduce input lag because it’s entirely dependent on your specific implementation. Any visual delay between an input and an effect on the client would be caused by a bottleneck that you introduced into your code.

@WillyEdison

I have thought of using Stepped:Wait()

I’m confused as to how yielding might reduce input lag. Seems like it would do the opposite.

[WillyEdison]

Thank you for your reply!

@pullman45

If the effect is solely rendered on the client, then there won’t be input lag unless a certain function in your code yields or a certain block of code is extremely inefficient

True, for client-only effects, there’s no network delay because we don’t wait for the server to receive the data, or for the server to update our visuals. But with computers, nothing is ever really instant. At its fastest, even client-only, when we press a button, we don’t see the change until the very next frame. This happens within milliseconds, at least according to the below video, and since Microgames doesn’t have glaring issues with this kind of lag, I want to push that advantage if I can.

As a source, I learned about input lag from Masahiro Sakurai’s game design video on the topic, he explains it well:

Down with Lag! [Grab Bag]

@pullman45

I tested your game, and the only input lag I saw was with the pistol tool.

Thanks for trying it out! I double-checked to be sure, and the Pistol’s bullet is currently owned by the server. Ping will always vary depending on how good players’ Internet connections are. That said, the Pistol is probably a good example of network lag, not input lag. Input lag doesn’t require a network connection at all - single-player games can have it as well.

@pullman45

I’m confused as to how yielding might reduce input lag. Seems like it would do the opposite.

At first, it would seem like yielding code would make delay worse. Why not run code instructions the moment they’re received? While this may slow the code slightly, it maximizes frame rate. Here’s how:

Roblox orders all the instructions via it’s Task Scheduler - a system that handles one task after another. According to their own guide on their developer page, it is best to do certain actions (like setting velocity) in Stepped/PreSimulation, then do other actions (like reading position) in Heartbeat/PostSimulation.

If we switched that order around - we make something move in Heartbeat/PostSimulation instead - then according to their diagram, we have to wait for the game to, on the next frame:

1. Read player input
2. Render the frame (we’ll have to wait for the frame AFTER this one to see the motion at all!)
3. Receive network data
4. Finally, update physics (our movement finally occurs)

Using Stepped:Wait() tells Roblox that it can handle other tasks for now, and come back to this once we’re in the correct portion of the frame. That way, we don’t wait for Roblox to do a bunch of other tasks first.