Any plans for multiplayer improvements?

  • >

    > Please note that you will require lag compensation (rewinding time) if you try to create a real-time shooter or something similiar.

    > ... pts/page-8


    > Ashley covered that already in his tutorial.



    I had implemented this, and other user's suggestions on how to work around it using functions.

    Bullets were easy to sync; one set of instructions were synced to all players. But because each player's platform position was inconsistent on each machine, none of that mattered.

    The big problem was that the player's position was never the same. Especially when jumping. There was a discussion about this some time ago.

    Disclaimer: I've never actually completed any multiplayer projects myself, so please excuse me if I'm missing something specific to your situation or saying something that was obvious to you already. My hope is to possibly give you an approach or idea that you might not have thought of to try.

    Position will always be inconsistent/different on every peer due to the limitations of latency, there is pretty much no way around this. The only thing you can do is fudge it with lag compensation and input prediction. All multiplayer engines need to deal with this in one way or another.

    One method that looked decent for me was to have all "real" (read: host synced) sprites invisible (top down projectile shooter). Every visible sprite object (on each peer's device) was tied to the invisible master one, but by doing it this way I could set up my own rules for how the object looked and behaved (interpolation and input prediction) from each peer's point of view. Then I could make any small tweaks I needed to hide the latency factor. On the host side for lag compensation, I allowed small "burst movement" after an input is received to catch up to the peer's local input prediction position. Because the host version was invisible, it didn't look unnatural to the player. On the peer side, I also added a tiny bit of consistent, simulated input delay rather than instant local input predicted feedback, so the discrepancy between host and peer didn't get too far apart.

    Most of that is done by the built in actions in the plugin, but those don't allow for much fine tuning, which is why I ended up trying to make my own.

  • Yea you can not avoid that.

    It's impossible to avoid that, that's why it's important to implement the time-rewind system.

    Here's a rought explanation of the issue you're experiencing:

    There's also a video where the actual developers from infinity award talk about lag compensation and how they "fixed" it to feel snappy.

    It's pretty interesting because they had an issue exactly connected to what oosyrag said:

    Minute 13 he's talking about the time-rewind ... on-Call-of

    It's your ultimate goal that the HOST, calculates at which exact spot the KILLER and the KILLED were standing at the time of the shot happening.

    So the host should basically calculate the positions back in time, trying to re-create the positions to check if the shot actualy hit something.

    And to make the game feel fluent for the players, you create the movement prediction.

    So the player actually moves visualy before he's actualy really moving (on the host).

    Same goes for shooting and so on.


    Although i have to admit that the official multiplayer plugin from scirra comes with precision issues when it comes to movement.

    Of course, it has to do some corrections in case your position is not in sync.

    But it happens all the time!

    So you're always being moved a little back and forth as a client, because it's always resyncing your actual position with the one given from the host (talking about 8-way direction movement here).

    Basically it's a very annoying micro-rubber banding.

    And this already happens while testing locally (host and client on the same machine)!

  • (...)

    Please finally consider the fact that multiplayer is a must have for every game creator.



  • I can suggest Photon Cloud for now. Really great plugin. Much easier to use also.

  • >

    > (...)

    > Please finally consider the fact that multiplayer is a must have for every game creator.

    > (...)



    With "creator" i mean game creating software such as construct and not a dev.

    So yes it is.

    There are people who want to create more than just iphone single-player games using construct 2/3.

    And even those can become much more enjoyable by adding an online multiplayer layer on top.

  • I'm going to be honest, I never even tried to use the multiplayer feature because I was told from the beginning it would be too difficult for most people to use. I doubt I'm the only one. I'm sure there are plenty of people who didn't even try it because they didn't want the headaches.

    There's got to be a way to make multiplayer easier for people. Problems don't get fixed by saying it's "too difficult." Everything is impossible until someone proves it isn't. If multiplayer was easier, then more people would definitely use it. And even if they don't, multiple players games made with C3 will be impressive and still a great selling point. Improvements really should be made to it.

  • I develop platformer stuff with the multiplayer plugin and in my experience, I have a blast with it.

    Whilst I appreciate the development that Ashley did for the code included in the Multiplayer plugin, I don't use any of the built in sync stuff. I strictly send messages back and forth between players and have tried different experiments in the past to see how different implementations of lag compensation feel. I'm not really well versed with the standards of lag compensation, I understand things like dead-reckoning, but currently don't comprehend systems such as rollback. I feel that I have more control when I don't use built-in "one size fits all" stuff, to allow me to fine tune when I want to send a message about the players state/input/etc.

    Don't trust my decision though, I may have missed out on an even better experience by not using the built-in sync stuff!

    The main bad things I experienced (strictly speaking from my experience) were: my games become CPU bound due to me making my own platformer engines (To give me the freedom to add more complex stuff such as half-pipe slopes/Sonic-esque wall&ceiling running), I mean I optimised my events as best I can but having more than 2 or 3 players can strain the framerate. On top of that, having all the other gameplay elements to interact with (what good is a game if your just running around and jumping with no actions or hazards). I mention this because, oddly enough, disabling the multiplayer events and having the players exist as local players on controllers didn't destroy the framerate as bad, so maybe my online implementation wasn't that great, but certainly felt good for two players! I wonder how it would pan out if someone tried it with the platformer behaviour.

    The other bad thing with my design was pings higher than about 70-80ms, which isn't too great; the game was functional but it didn't feel fair with things such as "Your opponent is 100 pixels behind you but still hit you!" kind of situations. (probably my failed lag compensation events, gimmie a break, I was only experimenting! )

    It sure as hell wasn't perfect, but it was functional, playable with the right ping, and I was happy with it, and I will continue to try to exploit all the potential out of this plugin in the future. Then again, what online games are perfect? Even in tightly designed online games, there's always moments of chaos where something feels unfair or unexpected, but that is usually caused by lag. I guess the solution to this could be to design your game to make sure to lock people into connecting with other players in a similar geographical location, or make your game only online with friends

    (not sure about this due to never looking into this with the Multiplayer plugin yet, considering you need to find a game in the signalling server)

    , then that can solve that problem!

    Networking is a fun concept to me, figuring out how to send data as lightly as possible, the whole ping/lag/latency/packet loss stuff and how/why it happens, it's all so interesting. It's Just as interesting as optimising the heck out of events, it's oddly satisfying to get things working really efficiently. But I could safely say, if I didn't have an interest networking and only knew the fundamentals like what an IP address is and what a server is, then I would most likely not touch Multiplayer in game development (and if I did, I know sure as hell I'd get frustrated fast, even if I had examples and guides laid out in front of me. Conceptualising how online synchronisation works can be incredibly confusing and stressful). I hope some of you guys develop an interest in the area. If you love it, it will feel less stressful to figure out in game development and more like "Ohhh how weird, lets figure out how that works. Ohh I seee, but then how does... woah... Internet u so crazy".

    ...or give me 2147483647 pounds and ill do a third of the events 4 u

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Perhaps there is an easier way to implement multiplayer but how much can it improve while avoid becoming a pre-built function and a crappy one size fits all solution?

    It is what it is IMO. Try making a multiplayer game in other game engines to get the rough idea of a comparison in complexity.

    You'll probably be surprised how similarly complex they are. It all boils down to the amount of practice and effort you put into your projects.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)