Construct 3 Multiplayer

I'd like to know if the construct 3 multiplayer system is good enough to create a multiplayer game like minecraft, terraria or something online, you know what Im talking about?

If you knows could help me I'd be greatul! - Dani10

Short answer: Yes. It is. (coming from someone with work experience in networking/distributed applications)

I did some experimenting, and I can say its multiplayer plugin robust enough for these sorts of games (and even for an MMORPG if you know what you're doing).

(For instance, I have a working demo where even if the server drops, another client becomes the server and the gameplay continues smoothly for all connected peers)

Multiplayer is always challenging and demands prior knowledge, a solid understanding of networking, multiplayer architecture, and extensive planning.

You can read more about Multiplayer in Construct here: construct.net/en/make-games/manuals/construct-3/plugin-reference/multiplayer

It has a robust set of features: UDP, Automatic data compression, Binary transmission, and specific datatypes.

And you can also opt not to use the built-in "Multiplayer plugin" and go full-on scripting to leverage the Web APIs (such as WebTransport) directly via JavaScript/TypeScript. Meaning, there's literally no limitation compared to any other modern web/browser-based approach.

--------

Some insights:

I recall watching a YouTube video where a developer failed to create his MMORPG using Construct due to performance issues. After seeing it, I concluded, "The problem wasn't Construct itself, but the multiplayer architecture he went with. Attempting to develop a real-time multiplayer game with hundreds of objects and players wouldn't fly, no matter the engine!" There's a reason most MMOs have tab-targeting combat.

For example, in a Terraria or Minecraft game, relying on the built-in Sync object for every map tile would be excessive and could lead to various issues. It's better to develop your own set of Messages that indicate when a tile is created, destroyed, or changed. You should also create custom functions to handle the synchronization of these actions across all clients. Additionally, you might need to implement another message type for transmitting larger map sections (Binary transfer) and, finally, allow each client to handle collisions and platforming locally for smoother gameplay.

Construct is very easy to use, but when it comes to Multiplayer, throwing things around without proper planning and using Sync object for everything without much thinking will cause you to hit a wall. You'll hear people saying that "Construct's multiplayer isn't robust enough". However, this is mainly due to the contrast between how easy Construct is to use and how challenging multiplayer can be. In more complex game engines, players tend to complain less about multiplayer capabilities because users of those engines are already accustomed to everything being difficult.

--------

edit: My last two cents. In general, if you fail to create your multiplayer game in Construct, you will likely fail to do so in any other game engine.

I need to update/polish/document my multiplayer template to make it easier for others to understand. After completing this, I might share the entire C3 project.

For now, here's a demo:

[info: hosts disconnects at 0:11 and 0:37. Net code speed: 1 sync per second]

In short, here's how the seamless host-switch works:

• Peers exchange messages about the name of the "fallback room" and which peer has priority on becoming the host. (sorted based on ping)
• If a disconnect happens, they try to connect to the fallback room with a delay equal to their priority on becoming the host. (so the client with higher priority can create the room first)
• Host and peers exchange custom messages to ensure objects are in sync.

For this to work smoothly, the project doesn't rely on the native Sync object. Network objects are part of the "Network objects" family. This special family have instance variables dedicated to my own network synchronization messages (network_id, peerid, local, posX, posY, sync_frequency, sync_last), and I interpolate their position (move-to, tween, pathfinding) based on my own given network_id to know which object is which.

(Sounds complicated, but it's relatively simple)

Here's how it's set up in the layout:

1. Invisible "Room Manager Object" defines the base roomName to connect to, maxPeers, and net_code_speed. On start of the layout, the game uses this object to know how to handle multiplayer for this given "region" in the game. In a dungeon, I can set it up for faster (example: 15 times a second) and 8 maxPeers, while in a city, I can make its net code speed lower (once every 2 seconds) and allow for 32+ maxPeers. (In the video above, the net code speed is set to once per second, creating a latency between peers... which is intentional (to save bandwidth). If I increase it to 30 times per second, the latency between clients becomes nearly imperceptible). This object also hold the fallbackRoomName that is kept in sync on all peers
2. Invisible "Network object/family" synchronizes the general position and behavior for a group of monsters. Which player are they targeting, HP of each child, etc. Synchronized using my custom messages, according to the settings on the "Room Manager Object". This object continuously sends messages about its position and actions (attack, die, etc.), which are queued/dequeued by the clients. It's the "brain" of things that have to be synchronized over the network
3. "Offline object" the client manages these. They stick close to the parent ("Network object") and try to follow its commands in a deterministic way (random seed shared between all peers). Since these are local to the client, their movements are fluid, and the player can interact with them "in real-time".

Since I want a more action-based combat, the host can temporarily make "Network object" local to the clients. With this, the client becomes the authoritative "owner" of the enemies targeting the player (pathfinding, quick reaction, etc), and sends messages to the host. This way, the action combat seems very fluid for the player while using very little network bandwidth (way less than the minimal Sync object's 30 times a second bandwidth profile).

It would be easy to add a central server (which could be an HTTP server) to persist major data across players' rooms... this would allow for a multiplayer gameplay/architecture similar to No Man's Sky, which feels like an MMORPG without many of the common downsides of the genre.