Best practices with Events?

0 favourites
  • 5 posts
From the Asset Store
Best car suspension with spring effect and very cool terrain generation.
  • Hello there.

    I'm wondering about what the best practices are in regard to performance and development efficiency with the eventing system for a multilayer game.

    Currently in my game people can set up a room, connect to a room and create their character.

    I'm using a single layout and a single event sheet for this as I thought things like reconnecting might be easier with a single event sheet. I use groups that I enable or disable to change the state of the game like signalling, hosting, character creation etc. .

    But now I'm wondering if I should instead use different event sheets for the different states. Like one for the connection, then if connected go to the lobby layout (and event sheet) and then if the game is started to a different one.

    Also I wonder if it is better to have a group for being the host and one for being the peer (like in the multiplayer tutorial) or instead simply check "is host"...Do This..."else"...Do That... .

    How do you do it? What do you think is more efficient while developing and performance wise?

  • I'm using a single layout and a single event sheet for this as I thought things like reconnecting might be easier with a single event sheet. I use groups that I enable or disable to change the state of the game like signalling, hosting, character creation etc. .

    Multiple layouts does not play well with syncing. It can be managed (I think), if you're really really familiar with the concepts of how objects are created and destroyed from layouts and syncing and you have a good understanding of the information that gets passed between clients. Basically I wouldn't recommend using layouts in a multiplayer unless you really know what you're doing, and if your game really needs it (running into vram limitations for any given layout).

    But now I'm wondering if I should instead use different event sheets for the different states. Like one for the connection, then if connected go to the lobby layout (and event sheet) and then if the game is started to a different one.

    Event sheets are for your own (developer) sanity only. It doesn't make a difference to the user or the engine if you use a single event sheet or separate your sheets. Do whatever makes the most sense for yourself organizationally. Separate layouts for connecting and gameplay I feel is a personal preference as well, it doesn't really matter besides the previously mentioned headache of changing layouts with synced objects.

    Also I wonder if it is better to have a group for being the host and one for being the peer (like in the multiplayer tutorial) or instead simply check "is host"...Do This..."else"...Do That... .

    I definitely use groups. Unless you don't like using groups for some reason. Similar idea to event sheets. If you're going to be putting is host/else all over the place, why not just use groups? The people swimming in the pool will never know if you used a hose or a bucket to fill the pool, but why would you use a bucket if you had a hose?

    How do you do it? What do you think is more efficient while developing and performance wise?

    Nothing in here has anything to do with noticeable performance. As always for performance, if you can't find a way measure it yourself, it's probably not worrying about.

    As far as development efficiency is concerned, do whatever is most comfortable for you. But do remember that things like groups and event sheets are there as tools to help you stay organized. They only work if they make sense to you though, no point using them if they only make things more complicated for yourself.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Thank you for your detailed reply!

    Okay I see. So it is mostly up to me.

    I will continue using a single layout and groups for now and hope that I will not realize one day that I should have used seperate event sheets instead. :D

    I have a last question though. When using nested groups, if the main group is deactivated on startup and a group inside it is active on startup, does it mean the active group inside the inactive group is inactive as long as the upper level group is inactive? Maybe a stupid question but the fact that this nested group is not greyed out in the editor made me wonder.

    Thanks again :)

  • I've never tried nested groups. I imagine a quick test shouldn't be too hard.

  • Ah yeah that makes sense. I will test it later when I'm home. Thanks again!

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