Recommended changes to make this repo work!

[austinh1]

Hello!

I super appreciate @nykwil and @robbgray's work on this repo: without the progress you all made here I would have never gotten a game up and running in Unity using GGPO!

I wanted to make a post here to let everyone know about the changes I needed to make in order to solve all the various issues I was running into. I'm planning on at some point creating a repo (crediting the work here of course!) of my own that should hopefully work out of the box, but until then here's a list of changes I recommend in order to get the UnityGGPO repo working for your game:

• Game and player structs need to be changed to classes
  • The structs weren’t maintaining their values after an update had occurred, changing them to classes fixed this issue
• GameManager Update() needs to be changed to use FixedUpdate()
  • Input needs to be polled so that it works with fixed update (Rewired has an option for this)
  • Code within IsRunning should run Runner.Idle(0) and Runner.RunFrame(), so “now” and “next” related code can be removed -- we want to run both of these every fixed update
    • Parameter for ggpo.idle doesn’t get used from within GGPO
    • Fixed update can be changed to from running at 50fps to 60 in Unity's settings
• OnEventEventcodeTimesyncDelegate should record frames ahead and then RunFrame should be skipped that many times
  • During skipped frames, input needs to be captured so that it can be used on the first available frame
  • Thread.sleep doesn’t work in Unity: once the sleep ends Unity will perform any missing Updates
• Game simulation needs to occur outside of Unity and not use floating points in order to ensure determinism. Inputs from Unity to the game simulation should only be device inputs and fixed update
• In the player settings Run In Background needs to be checked so that two Unity clients can communicate with eachother even when not focused

These were the big things I changed, but it's not an exhaustive list and there might be items I forgot to include. If anyone happens upon this repo and needs more advice on how to get it running correctly, feel free to contact me here on this discussion forum, I would love to help!

[nykwil]

Do you have a pull request or a branch I can take a look at? Could be what I need to jump back in hit some things on my to-do list.

…

On Wed, Dec 13, 2023, 11:53 a.m. Austin ***@***.***> wrote: Hello! I super appreciate @nykwil <https://github.com/nykwil> and @robbgray <https://github.com/robbgray>'s work on this repo: without the progress you all made here I would have never gotten a game up and running in Unity using GGPO! I wanted to make a post here to let everyone know about the changes I needed to make in order to solve all the various issues I was running into. I'm planning on at some point creating a repo (crediting the work here of course!) of my own that should hopefully work out of the box, but until then here's a list of changes I recommend in order to get the UnityGGPO repo working for your game: - Game and player structs need to be changed to classes - The structs weren’t maintaining their values after an update had occurred, changing them to classes fixed this issue - GameManager Update() needs to be changed to use FixedUpdate() - Input needs to be polled so that it works with fixed update (Rewired has an option for this) - Code within IsRunning should run Runner.Idle(0) and Runner.RunFrame(), so “now” and “next” related code can be removed -- we want to run both of these every fixed update - Parameter for ggpo.idle doesn’t get used from within GGPO - Fixed update can be changed to from running at 50fps to 60 in Unity's settings - OnEventEventcodeTimesyncDelegate should record frames ahead and then RunFrame should be skipped that many times - During skipped frames, input needs to be captured so that it can be used on the first available frame - Thread.sleep doesn’t work in Unity: once the sleep ends Unity will perform any missing Updates - Game simulation needs to occur outside of Unity and not use floating points in order to ensure determinism. Inputs from Unity to the game simulation should only be device inputs and fixed update These were the big things I changed, but it's not an exhaustive list and there might be items I forgot to include. If anyone happens upon this repo and needs more advice on how to get it running correctly, feel free to contact me here on this discussion forum, I would love to help! — Reply to this email directly, view it on GitHub <#15>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHU46A6HIHSSCZUHKMHFJLYJHTQVAVCNFSM6AAAAABATSFKDSVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZVHE2TONZQGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[austinh1]

Hey there! I unfortunately don't have a branch as I only used this repo as a basis for the code I've written (a lot of it is much different now unfortunately), but if I grab some time soon I can put up a PR with some of the changes. Stuff like simulating outside of unity and buffering input when we're skipping frames due to drift I wouldn't include (due to it being a good amount of work!), but I could probably whip up a branch with some of the changes.

That being side I do have a fork of UnityGGPO here with some changes: https://github.com/jollycrouton/UnityGGPO. I added support for the sync test and I also added support for Steam networking that goes hand in hand with a fork of GGPO I'm working on with a friend here: https://github.com/JacKAsterisK/ggpo_steam. Both are entirely WIP though!

[cloopadoop]

@nykwil yay, you're still alive! If you ever wanna hop on a Discord call we'd love to talk through what we've been working on.

[austinh1]

@nykwil I have a branch ready for you to look at! Could I grab permissions to push my branch to this repo? If not I can do a PR through our fork, it'll just take me a bit to get that ready

[nykwil]

A pull request is best. Thanks I'll have some time this week to take a look.

…

On Tue, Dec 19, 2023, 12:00 p.m. Austin ***@***.***> wrote: @nykwil <https://github.com/nykwil> I have a branch ready for you to look at! Could I grab permissions to push my branch to this repo? If not I can do a PR through our fork, it'll just take me a bit to get that ready — Reply to this email directly, view it on GitHub <#15 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHU46G2AGJ4WVPB2H2TMELYKHI23AVCNFSM6AAAAABATSFKDSVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TSMBQGU3DC> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[austinh1]

Sounds good, I have the PR up! Wouldn't necessarily immediately merge this in as I haven't tested those changes outside of running locally just to make sure I haven't broken anything too much. Just wanted to give you an idea of what the changes I mentioned above would look like. Would still need the following to solve all the issues, though:

• Input polling for use in FixedUpdate in Update (or however you'd like to solve this issue).
• Caching inputs from frames we skip to correct for frame drift
• Separation of game simulation from Unity
• Removal of floating points to be replaced by fixed point types

Just a note on the change from Update to FixedUpdate: I actually am thinking about modifying mine to use a game loop outside of Unity entirely, but FixedUpdate does a good job for now. I left FixedUpdate at running at 50 fps, but that can be changed in the settings via Fixed Timestep.

Also, you can find my additional changes on our fork for adding sync test to the project, wasn't too bad. Would recommend using normal player inputs rather than random inputs however.

Either way, good luck! If you need any help at all, don't hesitate to reach out. Thanks again for all the work you did on this repository, it really helped us get a good start at implementing GGPO in Unity!

[austinh1]

Just for anyone coming across this forum post, I discussed the issues further and thought that a description of problems I was running into might be beneficial for anyone trying to use this repository, so here's a list of problems I had run into in the order I experienced them:

1. VwGame.Framenumber would revert back to 0 after Update is run in RunFrame. You can test this just by putting a breakpoint before and after Game.Update.
2. Render FPS in UnityGGPO is not locked to 60fps, this is because GGPO.Idle does not respect the parameter it has. Currently it expects GGPO.Idle to wait for the time given to it, which it doesn't do because it doesn't even look at the paramter provided. You can just run the game with two editor windows connected to see that the framerate at the moment is not 60fps.
3. After fixing the above issue so that it does actually clamp the framerate to 60 (by using thread.sleep or other methods), the game logic loop is still not separated from render rate. You can test this by calculating FPS for every time RunFrame gets called and displaying it: you'll see that if the computer can only run at 30, then the game logic update only runs at 30 as well. We want the game logic loop (GGPORunner.RunFrame) to always run at 60 no matter what the render framerate is.
4. If you look at GGPONetworkStats' remote frames behind and local frames behind you'll see that the distance between the clients is really large at the moment and never improves. If you completely comment out the thread.sleep in the timesync delegate and test again, you'll see that the behavior remains the same, implying that thread.sleep does not have any effect on this issue.

[nykwil]

@austinh1 it would be cool if you have a chance to look at my latest changes see how that works for you.

[austinh1]

Yeah, I'll take a look soon! I might send my feedback to you on discord to make sure we don't clutter up this discussion board 👍