Online Racing Game

[Przemator]

I would like to write an online racing game for up to 20 players connected to the server. The game should resemble something like Turbo Sliders, GeneRally or NSGP. I made some research but I still have certain doubts.

1. Networking: I saw there is luasocket, or lua-enet, or sock.lua. Which one would you advise to use? Would it be possible for the connection to run on a separate thread? What is the common practice?
2. Main Loop / VSync: I would like to really focus on responsiveness and instant feedback. The VSync seems sub-optimal to me, as it waits every frame until it gives back control to the game. So player input can be delayed by 1/60th of a second. I would like for player input to be handled instantly. Do you know any custom implementations of VSync for Löve? I know that years ago there was this method of using front and back buffer, where you would draw to the back buffer and then flip the page in order to avoid tearing.
3. Physics: I would like to have some basic physics that would work online. E.g. I would like for the car to spin after being hit by another car. I played around with love.physics Box2D and googled for top-down car physics implementations, but there just isn't a good enough joint to simulate a top-down car wheel. Plus, Box2D is heavy, and in order to fight lag, I will have to constantly simulate the remote cars in order for things to appear smooth. Any suggestions as to löve compatible physics libraries?
4. Map: For track design, I saw there is this Tiled software, with Simple Tiled Implementation for löve. Do you recommend it? Or is there something better?
5. Cheating: What is the common practice to make cheating more difficult? As it will be an online game, someone could unzip the löve repository, change some parameters and have a faster car. Or he could upload fake results to online leaderboard. How to prevent it?

Thanks for your input. If you are a forum veteran, you probably have the answers in your head, and I would need to look for days to find the answers.

[ivan]

2.VSync can be disabled from conf.lua. Network latency will be a much harder problem to deal with.
3.Box2d is considered "heavy" because its API is large and detailed - not because it's slow.
You may have to use several joint types in conjunction to make something that resembles an overhead car.
Either way, Box2D is very fast and can handle stacks of several hundred dynamic bodies/fixtures without any lag.
5.The "right" way of preventing cheating is to run the game logic on a server.

[Przemator]

Thanks for your reply, ivan. My comments:

2. I know VSync can be disabled, but in the end I would like to avoid screen tearing. So I was wondering if there was anyone here who had some experience with this.

3. I dedicated a lot of time to make Box2D work in the past. The problem is, the top-down wheel has sideways friction, but not forward/backward. So the proposed implementations kill off lateral slide by constantly applying linear impulse. This, however, cannot work if you have 4 wheels on the car and they are interconnected. I also experienced that Box2D was really struggling when I made a track with hundreds of walls. Box2D is also an engine that builds its stability over time. If you make constant discrete changes, it breaks. And if I want to simulate a client who has not received packets from the server for a few frames, as soon as he receives them, he will have to revert back to previous state and re-simulates last few frames. So you either do it by a) resetting objects in the world (which leads to unexpected behaviours) or b) make a copy of the world for the last few frames (could take a lot of memory?).

5. Sure, you're right, if the server has the master simulation, and the clients only a proxy of that, then it will be fine. But what if the guy hosting the game is the cheater? Also what about uploading best laptimes or results to the website? Normally you would put some kind of passphrase in the code that would be validated by the website. But with löve it is very easy to see the source code.

[Beelz]

Here's a link to a Box2d top-down car tutorial. It is written in C#, but the methodology is the same. I reproduced it a few years ago(in v0.9), but I have a new computer now so those files are long gone. Anyways, I hope it helps you if you decide to use Box2d.
Link

[ivan]

3. I dedicated a lot of time to make Box2D work in the past. The problem is, the top-down wheel has sideways friction, but not forward/backward. So the proposed implementations kill off lateral slide by constantly applying linear impulse. This, however, cannot work if you have 4 wheels on the car and they are interconnected

You could just draw the wheels independently instead of trying to simulate the entire car in Box2D.

I also experienced that Box2D was really struggling when I made a track with hundreds of walls.

Box2D can easily handle hundreds of colliding/dynamic objects - for static bodies (ie: the racetrack) the performance would be even better. Making Box2D work well over a network would be hard though.

But what if the guy hosting the game is the cheater?

You would need to host the logic on an "official" server.

[Przemator]

Thanks for the link, Beelz, I will give it a look. I can recommend a really nice and clear tutorial which I used in the past. However, the end effect is not perfect.

You could just draw the wheels independently instead of trying to simulate the entire car in Box2D.

How would you make a car turn, if it had no wheels? A car turns only when it is moving and the wheels are turned. At a certain point the wheels lose traction and the car spins or drifts. That's what makes it fun and realistic. If you fake the wheels, you will not be able to reproduce these effects.

Making Box2D work well over a network would be hard though.

That's why I'm asking for any suggestions if there exists a different suitable physics engine.

[ivan]

For overhead cars, the wheels spin in the Z-axis which is not possible with Box2D.
Przemator, you can still use Box2D to handle the collisions, but for things like steering, acceleration and turning you have to roll out your own code.
The point is that you can still draw the car's wheels as they are "supposed" to be - without actually running the underlying physics.

[Przemator]

Well I don't care about drawing the wheels. And it's hard to build a physics layer on top of Box2D. Plus I really need this to work over network. This means the client will run his own simulation and periodically correct the placements of the cars to catch up with the server. In Box2D, if you reposition a moving object, set a new momentum and torque, it breaks the simulation, as Box2d is accumulating information over several iterations of the loop.

[ivan]

if you reposition a moving object, set a new momentum and torque, it breaks the simulation, as Box2d is accumulating information over several iterations of the loop.

Bodies have no "accumulating information" aside from their position and velocity.
I think you meant that Box2D uses "sub-stepping".
Box2D is deterministic by design as long as you use a constant time step.