Open TheYellowArchitect opened 2 years ago
Just finished the second task, aka replicating the old packet transfer design: RPCs which host can only send to client, and client to host. It kinda sucks that code-wise it's not as simple as Forge's (Receivers.All/Other), but if it works, idc, its not overwhelming bloat.
MirrorCommunicationController
(imitation of NetworkCommunicationController
) spawns once, and here I shall dump the RPCs.
I ported the Position Interpolation
+ Input Synchronization
logic, to use Mirror's packets instead of Forge's (bless my modular netcoding, making netcoding logic a layer above and seperate from game logic)
The only difference from Forge's netcoding version, is the serialization/deserialization and packet sending/receiving. Yet...
I use KCP's transport for Mirror.
For position, I send a float timestamp
and Vector2 position
only when position has changed (so as not to flood the network)
Unreliable RPC, of course. And as seen in debug log above, the timestamps are perfectly delivered in expected time.
Input snapshots also are greatly delayed
So, here is what I think could be wrong on position interpolation:
Here is what I think could be wrong for input snapshots:
There is also some weird behaviour I noticed with my ported code. One is that levelsync/levelskip is sometimes bugged, even though the levelsync/levelskip code is ported 1:1 which makes me think I missed something. Something obviously important, as netcoding must be 100% stable, yet isn't. Some race condition bug. Also see the duplicate snapshot in the above video. Doesn't matter though, as jitter is unrelated to it, no way a duplicated packet can cause this.
========
Ultimately, I overestimated my abilities, thinking I can just port the entirety of my netcoding in a week, right before release. Crunching isn't enough.
Merely reading and understanding how Mirror works - and trying to twist it into my old netcoding architecture - took 2 full days by itself. And I just keep running into issues and annoying errors, which I fix but in a slow pace. At least, there has been some obvious progress. Sure, I could spend a week to port all RPCs (aka all the netcoding) as I have done for Position Interpolation
and InputSnapshotManager
but I am certain there will be further race condition bugs, or something else I hadn't calculated. I cannot imagine desync code running perfectly, that's for sure. And the goal of porting to Mirror is to run perfectly...
It just feels Mirror is made for a headless server setup, and that is against the design I had for Forge. Add that to my inexperience with a new netcoding framework (because anyone can know high-level netcoding, but each API is so different and it will take a few days to figure out each edge-case)
Anyway, I shall delay online multiplayer for now, until I figure out the 1/2 points above, aka why it jitters, before I continue.
It is kinda sad that I spent 5 days (5 days away from release!) because Forge has issues with Steam. I could have used this time to learn how to make a master server onto my own VPS server which I already have. Should be simple. Ah well. Until release, I will just polish the game, there are some serious bugs I need to fix.
Actually, I should test again, while disabling Unity's physics from the player character (rigidbody or colliders) to confirm whether the netcoding framework is to blame. Should be an easy test.
Double Damnation can already be finished fully online, on Steam and LAN Then, why is it not advertised as such on Steam? It even has desync as a feature, which exists in no other game in existence - this is where I spent most of my netcoding devtime (5 months?), yet why is it nowhere mentioned or promoted?
Because Forge Remastered(the netcoding framework I used) clashes with SteamP2P. The steamworks integration is buggy, but even worse, Forge Remastered has packet bugs (only noticeable at >0 ping)
Ultimately, on Steam, this means there is jitter for the client (Player2/Mage), and all packets are unreliable (unironically UDP) hence you can imagine the infinite bugs. On LAN, there is no jitter and all packets are reliable (except streaming packets like position and input snapshots), but there are still some packet bugs: One of the worse being code-wise that the host has to send a position snapshot each frame even if his position is exactly the same as the past snapshot, otherwise packet acks flood the network because of faulty timestamps!
tl;dr: High-Level Netcoding is complete. Low-Level Netcoding is bugged, and I must port to Mirror.
Forge Remastered is dead, so its not like devs gave up development but at least it was a complete, stable project, no. Anyway, assuming I'm hyped to return to do some huge update on Double Damnation, I will focus on Online Multiplayer, since all of netcoding game logic is complete, and its a damn shame the transport code below is bugged because of the netcoding framework. "Swapping" low-level should be possible. Porting in Mirror must be done.
==================
Mirror Tracker below, to complete and public release Online Multiplayer
===================
That last item may have surprised you. Believe it or not, coding more players is easier than having another player "share" the same entity. Seriously, generally speaking, all you need to do is sync a position (
Vector2
), and an animation/sprite (enum ushort
)And for this reason, I plan to release online multiplayer + 12 player mode, together, so its not "the exact same game with the exact same content, but with online multiplayer", but having an incredible unique new mode atop of that! A proper "ultimate" version.
WHEN? When I get the will and desire. The hype, so to speak. Explained here