Showcase Sharing an opensource delay-based rollback netcode project with some success in internet tests

-----Oct 26th 2023-------------------------------------------------------------------------------------
Kindly note that v1.2.7 gets a freezer buff feature update and a new multihit fireball skill for GunGirl, as shown in the video below. I've played a few internet battles with my friend in Shanghai and the experience was great, all updates are verified by framelog comparison after each internet test battle

-----Oct 13th 2023-------------------------------------------------------------------------------------
Kindly note that v1.2.5 gets a neat update for rollback chasing and dashing delay, pushing synchronization experience to a higher stage again! Moreover, all updates are verified by framelog comparison after each internet test battle
-------------------------------------------------------------------------------------------------------------

Hi all, it's a great pleasure to share my project https://github.com/genxium/DelayNoMoreUnity here to show that with relatively simple principles and small amount of codes, Unity can help build a multiplayer Platformer game that works well in internet. There's a thorough introduction to "build & run" as well as the underlying algorithm in README hence I'd like to skip it.

I feed on every star/folk/clone to fuel my future update, please take it if you find it useful

Here's a part of a recorded play between a celluar 4G Android and a Wifi Android via internet, with successful UDP holepunching it was a smooth 60 fps experience for me (full video is here, it's a Chinese netdrive service, please don't click if you're not happy with that).


The project has implemented the below notable features by far.

• Automatic correction for "slow ticker" (including a lockstep-ish approach), especially for "active slow ticker"
• Peer-to-peer UDP holepunching whenever possible, and will fallback to use the backend as a UDP relay/tunnel if holepunching failed for any participant (kindly note that UDP is always used along side with WebSocket, where the latter is a golden source of frame info)
• Frame logging toggle for both frontend & backend (i.e. backend/Battle/Room.frameLogEnabled), useful for debugging out of sync entities when developing new features

There're also upcoming features already implemented in the old project and will be available very soon (you're welcome to view them in the old project's Github repo).

• Basic fireball and melee bullets, as well as the associated "pushback", "blowup" and "get up" movements
• Backend dynamics toggle
• Recovery upon reconnection (only if backend dynamics is ON)

(recording of old project, also using UDP holepunching and via internet)

 

Sharing a recent update on the project, now it's supporting

• Basic fireball and melee bullets, as well as the associated "pushback", "blowup" and "get up" movements
• Rollback compatible NPC patrolling and vision reaction

Please checkout the latest screen recording as follows.

 

Here's a recent update of the project, covering a few new features

• Slope movement
• Multihit bullet, which in turn covers a few types: simultaneous emission, sequential hit counting from emission, and sequential hit counting from previous hit
• More robust inter-character pushbacks

YouTube automatically made the video a Short thus couldn't be embedded in the forum
https://youtube.com/shorts/r5djIdTikpk?feature=share

 

Latest updates (v1.1.7) to the project, added

- Rollback compatible static and dynamic traps, including a WYSIWYG notation support in Tiled editor


- Frame logging support for hard- & soft-pushback frame logging, here's a case once I used it to successfully spot and resolve a rollback issue due to an order-sensitive logic


Please checkout https://youtube.com/shorts/-nFXM-w5N-o?si=vCBiOPUkrcX4BJOG for a merged video demo of it! All individual video parts can be found here. Kindly note that all parts of the merged video are recorded from peers connected via INTERNET, even for a peer using Unity IDE Simulator.

 

This piece of work is absolutely fantastic! The attention to detail, creativity, and skill demonstrated are truly impressive. Great job!

 

good good project !
dddd
Just go DONGGUAN now

 

Latest updates (v1.1.9) to the project, added

- Rollback compatible slip-jump (i.e. slip down from a monodirectional platform)

Here's a video compilation of all the supported game dynamics by far

 

nice

 

Latest updates (v1.2.4) to the project, added

• Some visual effects for bullets
• Background music and sound effects for some interactions (all from opengameart)

Here's the demo video recorded in Cellular 4G v.s. Wifi internet environment.

 

Kindly note that v1.2.7 gets a freezer buff feature update and a new multihit fireball skill for GunGirl, as shown in the video below. I've played a few internet battles with my friend in Shanghai and the experience was great, all updates are verified by framelog comparison after each internet test battle

 

Looks pretty awesome, quick question about the delayed input. If I correctly understand input are only collected every forth frame, then applied to the next 4 frames after? If so, does this cause a delayed start/slow down when stopping?

 

Yes, but only theoretically.

First of all if you're concerned about a sensible delayed start/slow down when stopping, it's mostly due to _processInertiaWalking instead of the batched input. You can tune InertiaFramesToRecover of each character to try if some other values fit your need most -- but mind that a smaller InertiaFramesToRecover makes "turn-around & abrupt start/stop" more prone to teleportation during internet play.

Secondly, you can also control the granularity of batched input by tuning INPUT_SCALE_FRAMES, basically the batch size is just (1 << INPUT_SCALE_FRAMES) so changing it to INPUT_SCALE_FRAMES = 1 gives you "1 input per 2 frames" -- but as a reasonable good fighting game player I tried INPUT_SCALE_FRAMES = [0,1,2,3] myself, only INPUT_SCALE_FRAMES = 3 is sensible for me, which complies with popular theory that only some professional athletes are capable of tell signal delays at 10ms resolution.

That said, the best values are always defined case by case, so I made them tunable.

 

Is the idea of the batched input and delayed client-side execution to help keep the client more in line with what is executing on the server? For example, my FixedUpdate runs every 16ms, so I would collect the input on frame 1 and send it to the server, then on frame 4 get the next input/send to server and start executing the input collected in frame 1 for frame 4-7. This would cause a delayed execution of 64ms which I guess you would disguise with some animation or something. Movement is easy enough to slice over 4 frames but how would this work for other actions that are instant (an attack of sorts or healing)? Would you only execute the action client side on frame 4 and nothing for 5,6,7?

 

The intent for batched input is mainly for saving bandwidth. The ease of syncing game dynamic progression (as well as rollback) is a by-product which you can achieve by many other ways.

In terms of delay, again you'd have to try it yourself, I met so many claims that sth should be executed "immediately", while they actually are not aware of what time resolution sensing an average human has. Somebody might be able to sense 10ms delay, there's no point to argue over that, if you're really just worried about that, it's always possible to tune the constants to a "no delay" config -- but make sure that you have someone else to test whether a tuning is really improving their gaming experience.

I personally like the present tuning to exploit the difference between human time resolution sensing and what modern computer/phone can do, to provide a polished/disguised game experience.

 

Ahhh so batched inputs are sending 4 sets of inputs (1 per frame) at once? Then these are just replayed delayed on client (in your case). Or are you sending a single input and apply it over 4 frames?

I'm just seeing how this compares to mine which seem pretty smooth but I'm sending packets each FixedUpdate (16ms)

 

No for the first guess, by INPUT_SCALE_FRAME=2, the client side actually only recognizes 1 input per 4 frames (64ms), while "sending" is another story, for now I checked whether or not the current input is different from the previous, if yes then it'll send "immediately", otherwise would cache and send when holding threshold is hit.

For the question, if you're just using fixed intervals, my approach only generalizes what you're doing, there's no comparison -- I can always fall back to fixed intervals which I've tested to be very prone to large internet fluctuations and it's just more difficult to get a smooth graphic output. Again don't just think of it, have a try by running it. There's no word more convincing than evidence, my prediction of your question is: you couldn't feel any difference when playing them.

 

Thanks for the explanation, I think I'll look over your code some more and see if this is something I can implement in my game. Movement is so tough to get right, I'm happy with what I have now but can see some advantages with your approach once i get into rolling back events and such.

 

Np, it's quite nice to me that you really got the essentials of what's important.

Here's my 2 cents: you might find some of my animations not smooth enough compared to some others' demos, that's totally expected because for many moves (including attacks) I set a relatively safe "inertiaFrames/startupFrames" -- which means visual delay -- they were not there if you watched the early videos.

For playing over the internet, it's almost trivial to be smooth if you have good network to send 1 packet per 16ms uniformly, and all players receive at that rate uniformly -- in that case you can tune the graphics to be 10 times smoother than what I showed here.

However that kind of smoothness is very fragile if you test it under controlled LAN with occasional large delays or packet loss (and would be even worse if you use TCP only). What I'm battling against in this project is actually the bad network cases -- of course I admit that my animating skill is like sh*t hence the outcome is looking worse than what the algorithm is offering

Besides bad network, client side local lagging is also a headache, see https://github.com/genxium/DelayNoMore/blob/v1.0.13/ConcerningEdgeCases.md for more information.