Ideas for the Multiplayer System

0 favourites
  • 1 posts
From the Asset Store
The official Scirra Multiplayer Signalling Server for helping peers find and connect to each other
  • I think more than one did this but i couldn't find it to put my vote.

    Right now the multiplayer is not very well fused with the construct2 workflow. I know it is a hard work and really difficult objective, and i'm sure you are already are working on it. But here are my ideas:

    My Ideas/opinions:

    Integrate the multiplayer with the rest of the Object Types. With the posibility to Sync groups of events that represents a player:

    "Assosiate SpriteX to peer": Construct already knows who is host and who is client, each peer have his own Nick. It is automatically binded to a peeriD. So it should be able to do a call like "SpriteX.multiplayerID(Nick,X)" so with this i know where is SpriteX for that PeerID, that "Nick." is automatically added if you have Assosiated that sprite. In this way all sync sprites that will be assosiated to a player will have autonomy without needing to say that in the events.

    We put all keys in one Group. Not dividing in host and client. For example a group called "Player Online Interaction"

    We do "Assosiate Group 'Player Online Interaction' to peer", in that group is all the Keys needed for the player to interact. Without saying "client" and "Host" because both knows who is who.

    With that we can sent keys if they are in that group. Example: If a peer Press "Left" it is automatically sent to Host, in the sync group ""Left" -> rotates SpriteX", the host just says "oH! Nick pressed "Left", pressing "Left" is to rotate SpriteX, so SpriteX with MultiplayerID=Nick rotate please".

    Reasons:

    • Why not sync keyboard directly?

    Because maybe the player have keys that doesn't affect the game for other players, like pressing F1 to show Help.

    • Workflow

    This is the most shocking aspect of the Multiplayer in construct right now, it is nothing like any other object in construct and it have no interaction with anything.

    • No need of 2 kind of collision checks

    well that. all sprites in the game have it's unique ID binded to his peer, so i don't need to check if it was a host or client, i just need to say "bullet collision with spritex with multiplayerID=nick" "MultiplayerID(Nick,points+1)"

    • Sync of Keyboard, mouse and touch in groups

    I didn't really get why is necesary to create variables to hold the keys that are pressing and then translate those keys in new events to represent that keypress.

    If i follow construct2 logic, if a key is pressed an event is triggered, in multiplayer there is Client and Host unnesesary, if i need 2 diferent player styles then it just in 1 Variable say "Im pacman" or "im gosht" or "im in the chat, so dont send keys now". There is no need to hold a variable to know every key was pressed, the Keyboard Object is doing it already. Example: There is only 1 event "if X key is pressed". It will not send any other key, because there is none event in that group needing it.

    • No need of extra events.

    Since there is no more need of sync variables and translating them again and dividing unnesesary groups, client will automatically transform all actions in events in the sync Group into "send what i pressed to host".

    • No other conditions

    To avoid lag bugs, in the client the events that have "key pressed"conditions will scape all other conditions, since they will be checked in host.

    • Speed up sync

    With this mettod, the host is the playing machine and client is a "dummy end", so all other variables, sprites and objects will be sync if needed, just like it is doing now but more flexible for the game developer to understand.

    this needs a litle more work on the idea but. its the idea

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)