Yes, you read the title right. real time multiplayer in gamelab. If you were wondering what me and @Ravage were doing together, this is what it was. Unfortunately, I kinda need help completing this now that he's quitting for an unspecified amount of time.
Here is what I have so far
It works similarly to this slither.io remake on scratch but I have a few problems:
1) Rate limiting: Code.org's keyvalue rate limit is being hit frequently while running this.
2) Rewrites: Attempting to update the same keyvalue from multiple different users leads to a race condition and then overwriting.
3) Slow key values: Things are lagging, however, I am using entity interpolation to try and hide the issue, but it leads to unresponsive gameplay.
I am calling on those who are experienced and ambitious to help me. Especially @Varrience, @[WUT] Adam, @Letti42, and maybe even @Binary_Coder. I would recommend reading up on keyvalues beforehand with this. And on multiplayer architecture with this. I would also suggest learning about peer-to-peer networking if you can. We are attempting a truly revolutionary concept that would be the future of games. (Plus it would make a fun FCR game.)

    DragonFireGames changed the title to Real-Time Multiplayer in Gamelab .

    I made a slither io a while back and I wanted multiplayer so I called upon "cdos greatest minds" tho all I got was a quest for help from ioioioio

      DragonFireGames
      i tried something like this a couple days ago with my glob library and it worked but was shitty (cuz keyvalues slow lol)

      cuz its so shitty i don't think you'd be able to make a game out of it tho

          ackvonhuelio Entity interpolation. Apparently, according to @Ravage scratch's cloud variables are about as slow as code.org's, that slither.io game uses interpolation to fix that.

              It doesn't have any multiplayer tho

              DragonFireGames wdym interpolation, like sending the data in chunks? if so i’ve done that with a dumb game i was testing on replit but it works really well, not sure how achievable it’d be on code.org

                  Letti42 Read the keyvalues every second. Between each second slide the position of the entity between the old position and the new one to give the appearance of a smooth game.

                      DragonFireGames While I'm not sure how many exact there are i could probably find out, just going to be a pain in the ass since i have to move redeployments, I'd assume it'd be the same as the firebase rate limit, although perhaps they've set custom stuff on there end for the config model it runs in, from my extensive modification of those files with "firefly" or it's more like a request for the key then it returns some model which then gets passed in to load the data so it's gonna be a gut guess at the current time
                      it should probably be around 5,000 reads / 100 seconds
                      and 80 writes / 100 seconds
                      (depending on which version there running under may vary these numbers and how there being executed)
                      however i think according to the "read" stuff for CDO it seems to suffer a bit more which may be some form of reading it artificially so I'd say less than < 5,000 for reads CDO isn't really meant for real time multiplayer since your "socket" is using TCP vs what would usually be used as UDP connection......
                      if anything a real time card strategy game may be the furthest you will be able to get to "real time" without overloading the server with users if anything you probably could get away with some Pokemon-esk game.
                      Best of luck with your efforts

                      Awards

                      • â’¸ 1 from DragonFireGames
                        Comment: Great information here, I will make sure to use it.

                          DragonFireGames then yeah i've done that. you just need the movements of the player sent with keyvalues in an array in a timed buffer of, let's say 300 ms (about the latency of my other game). then that array of probably 7-10 ish movements gets received by the other players and is put into an array that is constantly updating the other players' positions but at a rate RELATIVE to what the timed buffer from before was

                          if that didnt make sense, tldr:
                          time the movements, send them, receive the movements and update positions
                          one movement can be represented by a mouse down event. should be enough to get that smooth gameplay

                              I'm going to pretend to know what you guys are saying and go along with it.

                              Awards

                              • â’¸ 6.9 from person
                                Comment: Yeah that's what most of us do
                              • â’¸ 1 from [WUT] Adam

                              I think you should worry about a smooth game play one you figure out the how to make it work first.
                              Ya know, focus on one thing at a time.

                                Letti42 That is almost exactly what I am doing, however it fails utterly and completely when changing directions.

                                    Chat