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
-
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.
-
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.
- 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.
Details
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!
Thanks!
