Should I have a separate group for host and one for peer or just use is host?

Post reply
0 favourites
  • 7 posts
From the Asset Store
Footsteps SFX One
$5 USD
Footsteps SFX One contains 400 sounds of steps and jumps on different surfaces.
Sound Work 12's avatar
Sound Work 12

  • Hey there!

    I wonder which of these schemas I should use:

    1)

    • Have a group for all events that are host only
    • Have a group for all events that are peer only
    • And have a group for all common events which are exactly the same

    2)

    • Have a group for all events that are host only
    • Have a group for all events that are peer only
    • And have a group for all common events which are mostly the same and just use is host or is peer for the adaptions

    Example for 2): 

    On peer message
		ChatAppend("[" & Multiplayer.FromAlias & "]: " & Multiplayer.Message)
	Is host
		Broadcast message to other peers

    Should I strictly separate host events and peer events or should I save on the amount of events needed?

    How do/would you do it?

    Thank you in advance!

  • should I save on the amount of events needed?

    This pretty much never makes a difference, unless you personally like to.

    Do whatever makes the most sense to you.

    It is recommended to separate peer, host, and common events so that they are clear, easy to read, and easy to identify problems and debug. Separating groups make it very clear cut which events should be run by hosts and which by peers, since hosts and peers have very different jobs and are the source of confusion and misunderstanding for a lot of multiplayer issues that come up regularly. However, if another way makes more sense for your own organization, that could be reasonable.

    One thing that could be considered is that if the way your organize your events in a multiplayer project doesn't make sense to other people, it gets even harder to ask for help when you run into issues.

  • Okay what you say makes sense.

    I will strictly separate the events because if I have a bug one day that might allow people to cheat or mess up everything.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I often do combinations of both, where eventually most events semi common will be under 1 event system.

    Mainly because:

    Even with a small multiplayer system, editing existing events, become tedious and bug prone due to 'forgotten' edits, or incorrect edits, because you you have to do a lot of things twice.

    Having a singular system, with is host (or is not host), is, in my opinion, the slightly safer bet, because most events only occur once.

    So for me is is more about the slew of aftermath work when tweaking existing mechanics.... I prefer to just edit once, vs, 'oh, forgot that, needs another edit' .... which lends itself for misleading the developer into tweaking other elements, because the first edit didn't pan out as expected. (Forgot something)

    One tip, when combining events, make sure to update/add comments to indicate what the code does for who, but that goed for most of the events in any game really.

  • lennaert

    Thank you for this different point of view. I think this makes the most sense to me now.

    I like to safe time on edits and modifications. I do a lot of edits because I am kind of a of perfectionist.

    I will do that as follows:

    Host group:

    • Authoritarian events

    Peer group:

    • "Streamed" events

    (Semi) common group:

    • Events that share the same logic but behave differently for host and peers

  • Sounds solid

    I often use a Server group, to handle most, if not all connection related events.

  • Good idea.

Post reply
  • 7 posts
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)