Construct 3 suggestions & ideas

Suggest and vote on ideas for Construct 3! Please note this is only one aspect of planning. We do not guarantee any features here will be implemented, even if they are top-voted ideas. The aim is just to collect feedback. Remember to search for existing submissions before adding an idea, describe your ideas as comprehensively as possible, and vote for plausible ideas that are well thought out. Please see our full guidelines on suggesting features.

46 VOTE

Multiplayer plugin (Interest Management) - Toggle/pick who to Sync with.

If we had the ability to enable/disable the syncing of objects, and choose who syncs with what data set, then we'd be able to implement some type of interest management for our multiplayer games saving on bandwidth.

In order to create a secure multiplayer game with the multiplayer plugin, we would need one client, that is always running, to act as the server/host. Right now, there is no way to manage having a single host run the game efficiently on multiple layouts or really large layouts, due to the Sync function always being on and active for every peer, regardless of which layout they are on or how far away they are from other peers, using up bandwidth unnecessarily.

As a result, multiplayer games made using the multiplayer object limit themselves to peer-to-peer hosting which is open to exploits, or to peer-to "dedicated host" where the host can only run one layout per browser tab. This doesn't work well if you need many empty/open rooms at a single time, and it just seems kinda silly.

I think the lack of flexibility around the Sync feature is the main reason why the multiplayer object has yet to be used seriously.

If we can toggle Sync, and choose which peers to sync data with and when, then we can target certain groups based on their layout or distance, and circumvent these issues, enabling us to create open world multiplayer games.

  • Boris Aziz
  • Sep 12 2017
  • No status
  • Attach files
  • Guest commented
    07 Mar 22:59

    This would be amazing

  • Everade commented
    20 Mar 15:37

    We also have the restriction for not being able to sync data from peer to peer directly.


    Best example for that is trying to create a non-authoritive Host scenario.

    Currently the only way to do this is to indirectly relay all syncs such as:
    Peer sends data to Host.
    Host Broadcasts this data directly to all Peers (not taking over control, just broadcasting the recieved data)

    That means Peer are incabable of Broadcasting any data directly to (all Peers + Host) and always needs to relay everything through the host, even if it's not required.

     


    Current Multiplayer Plugin Restrictions:
    -  the SET CLIENT INPUT STATE event is directly bound to Peer -> sends to Host.
    -  the SYNC event is direcctly bound to the Host -> sends to All Peers.
    -  the ON CLIENT UPDATE is bound to Peers only (of course, given the current plugin design)
    -  the BANDWITH PROFILE event is fixed to 2 specific options. No room to play


    Even though Peer Broadcasting may increase the individual bandwith requirements, in most cases it cuts latency in half. This really depends on your game design, and personal aproach on what fits best to your multiplayer scenario and should not be restricted.



    Conclusion:
    NetCode optimisations are impossible to be properly done based on your personal needs.

    We're being limited to very strict events, which have been designed for THAT specific autoritative Host scenario.

     

    Giving us the above mentioned improvements would allow us to:
    - Properly manage who syncs data with whom (reduce unecessary packet spam)
    - Cut down on latency between Peer to Peer if it fits better
    - Allow for direct Peer-to-Peer (non-authoritive Host) scenarios
    - Create hybrid Host-Peer&Peer-Peer scenarios (like most modern multiplayer games to-date)

     

    Wouldn't this make the Plugin more complicated overall?

    I would say Yes and No.
    For some people it may make more sense with Peer to Peer scenarios so it takes away on the *Host must control everything* idea which simplificates a lot.
    And a proper Guide update would easily help anyways. The existing ones are already pretty straight forward and good.

    But mainly, i think, multiplayer is not meant to be easily done and the current state does NEITHER serve beginners nor professionals.
    If someone puts some interest into it and actually learns how it's supposed to work, it think it's absolutely ok and still *easy* to achieve.