|
| ||
| Views: 6,908,952 | Homepage | Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search | 04-24-24 05:01 PM |
| Guest: | ||
| 0 users reading Netplay suggestions thread | 1 bot |
| Main - Development - Netplay suggestions thread | Hide post layouts | New reply |
| Arisotura |
| ||
 Big fire melon magical melon girl Level: 56 
Posts: 859/887 EXP: 1343018 Next: 55158 Since: 03-28-17 From: France Last post: 23 min. ago Last view: 2 min. ago |
| SIGMA |
| ||
|
Member Irregular Level: 11 
Posts: 25/25 EXP: 5982 Next: 3 Since: 01-16-18 From: Internet Last post: 393 days ago Last view: 79 days ago |
This may be a bit of an insane suggestion, but if you are able to get the state to be deterministic across all instances, making sure that the same inputs recreate the same state on all instances, perhaps, if feasible, it might be worth implementing rollback netcode?
I will link down to specifics to it down below but essentially, as opposed to making each client wait for missed inputs, you could perhaps implement input prediction and then correct the prediction with the correct input later if it's wrong by rolling back the game state to the correct input. Usually, simple input prediction which predicts that what the player was doing X frames ago is what they will be doing X frames later is surprising accurate. At the most worst connections (250ms+ ping), the result would be teleports (Player jumps -> Prediction is incorrect -> Player teleports to the ground). However, by delaying the inputs by an X amount of frames, this will nearly eliminate the issue and drastically reduce the number of teleports happening. However, a few issues with this would be that you would have to store the state of the game each tick and perform a rollback within a single frame, which can be tricky to make performant considering the fact that you already have to recreate the network on each client for melonDS. Here are some other links to it which explain this networking in detail: GGPO website: - https://www.ggpo.net/ (I recommend reading the "Fight The Lag!" article) Three-part Blog series explaining how rollback was implemented for the Mega Man Battle Network series using the mGBA emulator: - https://open.substack.com/pub/tangobattle/p/adding-rollback-netplay-to-a-game?utm_campaign=post&utm_medium=web (Part 1) - https://open.substack.com/pub/tangobattle/p/adding-rollback-netplay-to-a-game-c90?utm_campaign=post&utm_medium=web (Part 2) - https://open.substack.com/pub/tangobattle/p/adding-rollback-netplay-to-a-game-3ca?utm_campaign=post&utm_medium=web (Part 3) Some rollback netcode libraries: GGPO-X (Improved version of the original GGPO): - https://github.com/thomashenry79/ggpo-x (C++) GGRS (Rust version of GGPO): - https://github.com/gschup/ggrs (Rust) I do not know if this is possible to implement at all, but if it's possible to make the state for each client deterministic enough that it's possible to recreate the same exact game state based on the same series of inputs, then it may be worth trying. |
| Generic aka RSDuck |
| ||
|
Big fire melon Administrator Level: 44 
Posts: 535/593 EXP: 587653 Next: 23632 Since: 10-12-19 Last post: 3 days ago Last view: 2 hours ago |
we already have to make sure emulation is pretty much determistisic for the planned delay based approach.
Rollback is probably too expensive. It is already necessary that everybody emulates all other instances. Now multiply that with having to potentially having to emulate multiple frames within of the time frame of a frame. What makes it even worse, is that while multiple separate instances run inside their own thread, so minus the synchronisation overhead the workload can be distributed across multiple processor cores. The same can't be said for rollback, as the emulation of every frame depends on the frame before it. ____________________ Take me to your heart / never let me go! "clearly you need to mow more lawns and buy a better pc" - Hydr8gon |
| Main - Development - Netplay suggestions thread | Hide post layouts | New reply |
|
Page rendered in 0.039 seconds. (2048KB of memory used) MySQL - queries: 27, rows: 80/80, time: 0.027 seconds. ![[powered by Acmlm]](img/poweredbyacmlm.png "powering nostalgia")
Acmlmboard 2.064 (2018-07-20)© 2005-2008 Acmlm, Xkeeper, blackhole89 et al. |