0
\$\begingroup\$

Help me grasp the concepts of mobs and in game events that the world should control in terms of multiplayer games.

I want to create some test game in browser for players to run and shoot mobs. I want to use Cocos Creator for this.

I have some knowledge about client-server synchronization from Godot documentation - there it's pretty simple. You basically run another Godot instance on server side, headless, without graphics but with basic stuff like physics, animation etc. So in terms of making mobs that move truly in the game world Godot approach seems easy to grasp.

But in Cocos Creator and similar web game engines... They require separate server with socket.io connection.

Yes, it solves the problem of player positions and somewhat bullets positions. Because one client shoots bullet and sends updates to every other client via server.

But what about mobs? Monsters, enemies. I mean in Godot situation it's pretty simple. Server there is basically client and server at the same time. Mob moves in Godot server by engine rules, colliding, attacking and sending updates to everyone.

But with Cocos Creator I don't understand how server can calculate mob, it's position, it's navmesh behaviour, it's animation state etc.

Do everyone really recreate whole engine functionality on server to make monsters abide engine and world rules?

And if one of the clients creates mob - what happens when client disconnects? I assume mob simply disappears?

\$\endgroup\$
1
  • 4
    \$\begingroup\$ What would stand in the way of the server calculating mob position? It's a computer too, so it can compute anything the client can. It doesn't need to track animations since it's not rendering anything, so you can skip all that engine functionality, but it does need to track behaviour states, so that functionality will need to be present in the server. \$\endgroup\$
    – DMGregory
    Jan 10 at 19:57

1 Answer 1

1
\$\begingroup\$

There shouldn't be anything stopping the server from handling calculating mob positions, behavior, etc., unless I'm misunderstanding something about socket.io. When it comes to recreating the engine functionality over on the server side though, what you could instead do is separate that code out, and reuse the same code on your server as in your clients.

This has a couple of bonus upsides as well. For example, since a server would typically only send snapshots of the world to players 10-64 or so times per second, in an MMO usually on the lower side of that if not lower, having the same logic on the client would mean you could use that for both

  1. Interpolating - i.e., "filling in the gaps" between the server updates, so things look smoother, and

  2. Extrapolating - i.e., trying to "guess the future" and e.g. keep moving players etc. in the direction they are already moving, guessing that they'll keep doing that, to avoid the situation that used to be common in older games, where you had to shoot behind or in front of enemies.

As for creating a mob, typically that would only be done on the server, as it's its task to keep track of mobs and their positions, and so on, so when a client disconnects, that should not affect anything, as that data is still present on the server, and still sent out to all other players. If you do want a client to be able to create a mob and have that synchronized with everyone else, usually you would probably instead send a command to the server saying "Hey, create this mob for me", and if the server allows that client to do so, it would create it server-side, and start updating all clients about it.

As DMGregory mentioned though, when it comes to animations, typically the server wouldn't be calculating those, but the client would instead based on the information sent from the server calculate that locally on the client.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .