Ok, I'm back - with a new feature preview: Online Multiplayer

Sorry I’ve been MIA from the forums for a while, but I’ve been super focused on trying to get online multiplayer ready for release. This feature is not 100% complete, but I feel like the design is stable enough at this point, and it works well enough that I can let folks start testing it out and start getting some feedback. This is not currently available on free accounts, and is not enabled on mobile/desktop (yet) however.

Although online multiplayer is very complex by its very nature, I’ve worked hard to try and make it as simple as possible to use in Flowlab. I’ll be making a multiplayer “handbook” once it’s a bit more finished, but here is a quick rundown of the updates that you’ll see right now:

New Stuff

edit: here’s a super simple example: https://flowlab.io/game/play/968865

  1. In the Game Settings panel, there is now a “Max Players” setting. If you leave this at 1 (the default), everything will behave exactly as it did before. With a setting of 2 or more players, however, the game will connect to other players at startup. A new indicator displays next to the plays/favorites that shows the connection status: “Awaiting” while trying to communicate with other players, and “Connected” once a connection is established.

  2. Objects now have a new setting in the properties panel with three options:

  • "Multiplayer: None": The default, this means that the object is not synchronized across the network. Most objects should use this setting unless they are moveable and their position is important to gameplay.
  • "Multiplayer: Shared": This means that the object's position will be synchronized across all players. Use this for an object who's position is important for gameplay, like maybe a moveable crate, or a ball
  • "Multiplayer: Player": This means that every player gets their own copy of the object when they join the game. If you add an object of this type to your level, then every time someone joins they spawn a copy of this object to control. If you don't want them to spawn automatically (e.g., you have a player select screen or something), you can spawn them manually, but only Player objects can spawn other Player objects - this means you have to have to add some type of player object to the level to spawn other player objects from.
  1. There are three new behavior blocks:
  • Shared Block This works like a Number block, except any value sent to this block is updated for everyone playing. This could be used to keep a value that needs to stay in sync (like a score) between all , or used as a message to trigger logic in every connected game at once. This block can be added to any object, it doesn't need to be a Shared or Player object.
  • Player Count
  • Simple enough, this just updated with the current connected player count whenever someone connects or diconnects.
  • Player Check
  • Poorly named, and possibly confusing, this only makes sense on objects of type Multiplayer: Player. Since these objects have a copy running on every connected computer, this can be used to make sure that a bit of logic only runs locally (on the computer controlling that object) or remotely (on all the computers not controlling that object).

    An example may help: If you wanted to have a player switch levels when touching a door, the normal way would be to just add a Collision trigger connected to Next Level. If you did this in a Player object, however, because it has a copy running on every connected computer, it would trigger the “Next Level” block for everyone, and everyone would switch levels. You could prevent this by using a Player Check block to make sure that the Next Level block is only triggered on the local version.

That’s pretty much the extent of the new available multiplayer interfaces. If I’ve forgotten or omitted something critical (I probably have), then let me know.


I’m not sure how much technical detail you guys care to hear about, but having a general idea of how things work would probably be helpful:

Two issues that were preventing me from working on multiplayer for a very long time were bandwidth (can get expensive for a game server running many games) and how in the world to deal with server side logic. The solution I eventually ended up with is that the games are all peer-to-peer, similar to the way multiplayer works on XBox. Instead of manually “hosting” a game like on XBox, the connected games just elect a host once they connect - and that host can change any time if someone leaves. This means that the game state only lasts as long as at least one person is still playing. Once everyone disconnects, the game will no longer be running anywhere.

The general architecture looks like this:

  • The full game runs on everyone's computer.
  • Opening the editor DISCONNECTS you from the game, you have to reload to rejoin. This is to discourage cheating, and to prevent someone from exploding the game while others are in the middle of playing it
  • Shared object types have their physics sychronized, but not their logic
  • For Player objects, trigger events (keyboard and mouse clicks/moves) are sent between everyone who's connected to keep all the copies synchronized and trigger the logic on all versions. For most logic this works the way you would intuitively expect, but some cases require more care. For example, if you have a Random block inside a Player object, every copy will probably generate a different value.
  • If the max players limit is reached, a new "instance" of the game is spawned and players will connect to that. For example: if the max players setting is 4, and 10 players connect, there will be 3 games running - two instances with 4 players and one instance with 2 players.
  • There is no limit to the number of Players, but there is a limit to how much data can be exchanged over your typical internet connection. This means that as the number of moving Shared and Player objects increases, the number of potential players in a single instance decreases. Only moving objects are synchronized, so when an object stops moving and goes to "sleep" it doesn't impact the bandwidth.
  • I have no idea about the actual limits here yet, I've only tested up to about 5 players so far, in a relatively small level (about 10 shared moving objects and players). That's nowhere near the limit, but there will always be a compromise between the number of moving, synchronized objects and the upper limit of connected players.

Known Bugs

There are a few:

  • Various connection & synchronization issues still be resolved
  • Shared blocks may not work properly inside Player objects - needs more testing
  • Emitting shared objects may not behave properly

I’m sure there are lots of cases I haven’t yet found, but I’m still working on testing and updating, so there will be bugfix updates coming. Please let me know if you find any bugs (bonus points if you can tell me how to reproduce them)

This shouldn’t affect any existing games, but if it did let me know and I’ll address that ASAP!


1 Like

@grazer make that only available for auto scroll

Id be like to manually controll everyones camera in certain situations, especially since you can already use playercheck to manually have an individual camera for each one.

Wow this is amazing! Definitely explains the wait, we were speculating something like this. Im hoping when this eventually works on desktop and mobile youll also fix some optimization issues on mobile so we can share our games more.

I cant wait to use this feature, this gives a whole new realm of possibilities. Thanks Grazer! :slight_smile:

P.S. As you said a guide would be nice for this, not sure how complicated its going to be, Ive done this on another visual engine and its fairly complicated, you do have the FlowLab YouTube channel, if theres a lot to it, could be worth a video perhaps.

Hey @PixelStudios - I’m aware of the mobile performance issues, and I’ll be addressing those hopefully pretty soon. I believe the issue is fill rate, since the renderer is using a blitter optimized for the web, which doesn’t work nearly as well on mobile. Desktop and mobile should generally perform much better than the web version once I address that.

Getting the exported versions to use the network shouldn’t be a huge problem, but I want to get it nailed down on the web first. With just one version to worry about, I can make and test changes and fixes much faster :slight_smile:

@grazer That sounds fantastic, paired with multiplayer I have so many ideas rushing through my head. Hopefully you could also work on a way for the game to fit on multiple screen sizes but Im asking for too much already. This is available for Indie and above right now for testing if Im not mistaken?

Yeah, if you subscribe to any version you should have access to it right now.

1 Like

@grazer Its going to be a long night, haha! Cant wait to hear more from this, especially community response once everyone wakes up.

1 Like

Whoa O: just noticed this

Well, I can probably mess around with the stuff, but a detailed tutorial would be fantastic.

Questions: What dictates the state of multiplayer? Can you choose or kick someone? If two people play, whose save is being used? Can I cache the Player 2 save data, like if they wanted to use their custom stats from their save file?

There’s a lot to play around with, so I’m eager to at least poke around with this. I’ve been far too busy to do much other than pop in the forums, but I could sacrifice some sleep to play around with this new feature.

@“Mhx Ar” Im sure youd be able to come up with your own way to kick a player. Im sure a better question would be ban a player, even then you could probably come up with your own way of doing that with save data, but IPs would be out of your control as far as I know.

Im sorry- WHAT

Okay- reading this- I see some tweaks that should be made:

Each player should be assigned a number, 1-whatever the max is.

a behavior which reads said number. (This could be used for things that dont have cooperation)

A trigger block that sends out 0/1 based on if you’re connected to a game or not, will not fire if multiplayer is off. (Could be good for players not using the browser version)

Random numbers will definitely need to be synced- because my game runs using mostly those to work- like enemy spawn positions.

We also need a behavior that manually turns on/off multiplayer

Attached player objects will not allow keyboard/mouse triggering
(Such as the gun object from SB3)


@Trigger2004 Agreed

@grazer I don’t know if I can just test this by opening two tabs but it doesn’t seem to be working at all, I even tried Crimson’s SB3 beta multiplayer and it doesn’t connect players or anything.

Here’s a gif https://imgur.com/a/tHINbup (it’s a large GIF so it may take a bit to load)

Alternative link: https://im3.ezgif.com/tmp/ezgif-3-04498bacc1.gif

Here’s a compressed version of the gif if you can’t load any of the above ones: https://imgur.com/a/2Zq45LS

Edit: I was successfully able to connect with @CrimsonBlackGames on SB3.

The test is not working on my computers either.

Oh boyyyyyyyyyyyyyy.

ehehehhe. Thanks for this :slight_smile:

If I notice some bug I will let you know.

You know it may be because you are using the same device? Same IP address? I still don’t know what dictates multiplayer. Hey @PixelStudios, did you try using your virtual machine as a second computer?