Skip to content

xaroth8088/NetworkStateManager

View on GitHub ↗Related repositories →

A lightweight framework to add server-authoritative, client-predictive physics to Unity

active 2023-09-092025-05-25 (UTC)

Complete coverage26,547 / 26,547 hourly files (100%) · 2 absent upstream2023-08-152026-08-25 (UTC)
Events
158
Pushes
104
Pull requests
6
Issues
28
Stars
1
Forks
0

Activity over time

Daily event counts in the loaded window

Line chart, 625 days from 2023-09-09 to 2025-05-25. Pushes: 104 total, peak 20 in a day. Pull requests: 6 total, peak 2 in a day. Issues: 28 total, peak 19 in a day. Comments: 2 total, peak 1 in a day. Stars: 1 total, peak 1 in a day.

  • Pushes
  • Pull requests
  • Issues
  • Comments
  • Stars

Stars, PRs, issues and forks are under-captured in the later part of this window. GH Archive progressively stopped capturing non-push events during 2026 — −95% or worse by the end of the window. Every series here except Pushes fades for that reason, so a decline above reflects the archive, not this repository. Pushes stay reliable throughout, so read them, and the contributor counts derived from them, as the real signal. Data health has the measurements.

Top contributors

Pushes, PRs, issues, reviews and comments — stars and forks excluded, so this is contribution rather than popularity

ContributorContributionsPushesPRsComments
xaroth808814010462

Recent activity

Latest issues, pull requests and releases

  • Issue comment#24xaroth80882024-07-31 20:00
    Figure out the right behavior for NetworkStateManager when it receives an RPC before it's ready to process them
  • Issue comment#38xaroth80882024-07-18 16:29
    If an input has a side-effect (e.g. starts an animation; schedules an event; etc.), then that side-effect needs to be able to be rolled back during a replay scenario
  • Issue#38xaroth80882024-07-18 05:37
    If an input has a side-effect (e.g. starts an animation; schedules an event; etc.), then that side-effect needs to be able to be rolled back during a replay scenario
  • Issue#37xaroth80882024-07-15 11:39
    Saw an instance on a shoddy network connection where the client requested a heavy, the server saw the client request it, but the client itself didn't (!), which led to a desync
  • Issue#36xaroth80882024-07-02 20:11
    Race condition
  • Issue#34xaroth80882024-05-31 17:39
    RPCs should be stashed when received instead of acted on immediately, and then processed in bulk in the frame
  • Issue#33xaroth80882024-05-31 17:35
    In SyncToServerState, if the state is in the future AND there are no events in-between now and the target, we can safely skip the first TimeTravelToEndOf() and directly apply the server state to the scene & jump the game time there
  • Issue#32xaroth80882024-05-31 17:33
    In SyncToServerState(), if the server's frame is exactly the same as our frame in that spot and there's no changes to the events, then we don't need to replay at all
  • Issue#31xaroth80882024-05-21 23:30
    Unit tests (first pass)
  • Issue#30xaroth80882024-04-21 00:28
    Maybe make a component that uses reflection to see what other properties are on the component, and which can be used to auto-collect gamestate information
  • Releasexaroth80882024-04-17 21:42
    0.0.8
  • Pull request#29xaroth80882024-04-17 21:40
  • Pull request#29xaroth80882024-04-17 21:40
  • Issue#28xaroth80882024-04-17 13:38
    The host can collect multiple inputs from clients before acting on them
  • Releasexaroth80882024-04-16 20:59
    0.0.7
  • Pull request#27xaroth80882024-04-16 20:55
  • Pull request#27xaroth80882024-04-16 20:54
  • Issue#26xaroth80882024-04-16 19:24
    Abstract VerboseLog() into its own thing, use everywhere
  • Issue#25xaroth80882024-04-16 19:22
    figure out what to do if the initial game state never arrives to the client
  • Issue#24xaroth80882024-04-16 19:21
    Figure out the right behavior for NetworkStateManager when it receives an RPC before it's ready to process them
  • Issue#23xaroth80882024-04-16 19:20
    In NetworkStateManager::ClientFixedUpdate(), figure out what we want to do when the client hasn't heard from the server in too long
  • Issue#22xaroth80882024-04-16 19:19
    On the server, instead of immediately forwarding player inputs maybe gather up all incoming inputs over some span of time and then send them in batches, to reduce RPC calls
  • Issue#21xaroth80882024-04-16 19:19
    In NetworkStateManager::SetPlayerInputsServerRpc(), exclude the client that sent its input to the server, since they've already got it
  • Issue#20xaroth80882024-04-16 19:18
    prevent a client from sending input for a player they shouldn't be sending input for
  • Issue#19xaroth80882024-04-16 19:17
    In NetworkStateManager::HostFixedUpdate(), there's an opportunity to be slightly more aggressive by skipping sending anything if the entire state frame is exactly the same (except for the realGameTick, of course).

Totals cover only the window loaded into ClickHouse and count events, not GitHub's lifetime totals — 1 stars here means stars gained during the window, not the repo's star count.