Multiplayer tutorial 1: concepts

Introduction

Developing multiplayer games is difficult, even though Construct 2's Multiplayer object takes care of many of the complexities for you. In the same way the events to every game are different, the way multiplayer messages and data are handled will depend on the type of game you are making. As a result the Multiplayer object has relatively abstract general-purpose features so you can make best use of it for your particular game. To make best use of these features it is important to understand how multiplayer online games fundamentally work, the problems that arise, and how they are resolved.

If the features are used incorrectly, your game could end up being unnecessarily laggy, have strange and difficult bugs, or make it possible for players to cheat. While you may be keen to start designing your multiplayer games as soon as possible, it is strongly recommended to read through the complete set of multiplayer tutorials before starting. Additionally this should be considered an advanced feature: beginners may find it very difficult, and intermediate users may find themselves stretched.

If you're ready to begin learning how multiplayer games work, read on!

I notice this does not address the subject of host cheating. Preventing the clients is nice and all, but, for example, say the host hacks their client, they could now send whatever they want to the peers.

Now you could say that anti-cheating measures and checks could be implemented, but then you could apply that same logic to each client as well.

Also, not to spam, but addressing the "Lag Compensation" techniques. I'm sorry but if a player has a bad connection in a shooter game, too bad for them. Newer games in the Call of Duty series have notoriously infuriating lag comp which is responsible for all sorts of nonsense.

In my opinion it's a technique that is often overused and should not be looked as much as interpolation or other ways of synchronizing between peers.

"By default updates are sent 30 times a second"We will be able to modify this, correct? Or send out updates only when needed? It'd be wasteful to constantly spew out that much data for something like a grid/turn based game, where movement may be as low as 1 grid square per 100ms, or not at all when a player is AFK.