Search Unity

  1. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Listen server models and performance for tick-based simulation

Discussion in 'Multiplayer' started by Victoria-F, Jun 26, 2023.

  1. Victoria-F

    Victoria-F

    Joined:
    Sep 27, 2013
    Posts:
    9
    Hi, I have a question regarding listen server models and performance in multiplayer games.

    I'm currently working on a fast-paced multiplayer FPS for Steam, with server authoritative players and CSP.
    The game is built on a deterministic lock step system, and currently runs on 32ticks.

    I am considering of using the P2P model with one client acting as the listen server.
    (Due to low budget, I want to stay away from using dedicated servers as possible.)
    The main concern I am having with this solution, is whether I could expect the average host machine to be able to handle the followings:
    - constant 32/64tick physics simulation (10 players in total)
    - rollback of ~10 ticks for lag compensation, every time a player fires a shot
    - sending packets to clients at a constant rate (which is roughly estimated to be 320~640kbps on max load)
    (Just as a quick note, the physics simulation alone shouldn't be that complex, since the only moving objects are the players themselves with no collision between them.)

    Do you think it is good practice to run 32/64 tick listen servers on the client machine, specifically performance/bandwidth wise?
     
  2. Lukeesta

    Lukeesta

    Joined:
    Jan 7, 2016
    Posts:
    77
    You are confusing some terms here:
    - Determinstic lockstep > Only inputs are passed between clients over the network, there is no prediction. This is mainly used for RTS games
    - CSP > What's used in shooters combined with a state sync networking model.

    I assume you are using the later based on the rest of your description and your question.

    Generally speaking if you use CSP in host mode with a small player scale the host has actually less CPU load than the clients. Why? Because the clients have to rollback and resimulate the predicted simulation while the host can simply run the forward simulation only. For lag compensation you don't want to actually rollback the entire game state. What you want is an efficient system to query raycasts against past positions of players. A very naive solution is a separate physics scene with PhysX and a ringbuffer to store positions, a fully custom made solution will perform much better.

    So:
    - CPU performance on the host is no more an issue than client performance if implemented correctly.
    - You can always run into issues if the host has a weak machine / connection.
    - If the host disconnects your game session ends or you have to implement host migration.
    - Ping for players will be higher since all traffic will go over a relay
    - 32/64 ticks is no problem at all on modern machines. Even 128 if you just have simple KCC movement and raycasts as shooters do.