LÖVE

Hi guys,

I'm currently developping a multiplayer game with Love and I'm currently starting to prototype the master/slave architecture, but I must admit that I'm more a graphic developper, and it's the first time I work on that.

So the idea behind this topic should be to get some advices on what are the good practices to follow, or what are the common mistakes to avoid?
Here are some characteristics of my game :
- Top down view in quite small levels.
- Up to 4 players.
- IA controlled entites.
- No dedicated host (at least for the first version), one player will host.
- Should be possible to enter/leave a game at any moment (except for the host, if he leaves the game stops).
- Simple interactions with doors, switch, traps, etc...

For instance, what are the common practices for IA pathfinding? I was thinking to leave it to the host (as there's a bit of random to get more natural movements), and send the computed path to each client.
If you have some good readings about this topic, don't hesitate to share!

Thanks!

As for path-finding. If your game is tile based read about Djikstra or A* ("A star")

-snip-

It seems risky to me to rely on generating the same random numbers on each machine by matching the seed; it only works if each machine implements the exact same random number algorithm (which as far as I know is not a garuantuee?)

Fenrir wrote:- No dedicated host (at least for the first version), one player will host.

I would implement the server in plain lua+luasocker, using UDP as a protocol, even if your final game will not use the dedicated server (i.e. one of the clients will act as a server). The reason is that it will guarantee logic separation: things will work if you decide later to make a dedicated server, and the "hosting client" will not have an advantage (except for lowest network delay).

I would implement the server in plain lua+luasocker, using UDP as a protocol, even if your final game will not use the dedicated server (i.e. one of the clients will act as a server). The reason is that it will guarantee logic separation: things will work if you decide later to make a dedicated server, and the "hosting client" will not have an advantage (except for lowest network delay).

Well the logic separation is actually what I'm currently working on, and as I'm keeping in mind that it should be nice to have a dedicated server, I'm trying to design it the most autonomous way possible, but I don't want to add a new layer of complexity right now by doing it in a separated software.

As for path-finding. If your game is tile based read about Djikstra or A* ("A star")

Pathfinding is already implemented, I was just wondering how to manage it in a server/client architecture.

For instance, let's say I compute the IA paths on the server and send it to all clients, it raises to me some questions :
- Should I send the whole path when computed and let the clients apply it without sending back IA positions for validation ?
- Or should I just send the current IA position at each frame without sending the whole path ?
Is there any recommendation on packet size or frequency I should rely on ?

Thanks!

miko wrote:

Fenrir wrote:- No dedicated host (at least for the first version), one player will host.

I would implement the server in plain lua+luasocker, using UDP as a protocol, even if your final game will not use the dedicated server (i.e. one of the clients will act as a server). The reason is that it will guarantee logic separation: things will work if you decide later to make a dedicated server, and the "hosting client" will not have an advantage (except for lowest network delay).

I agree for the most part. Using plain Lua will also allow you to host the game on computers without a graphics card (internet server) and is much cleaner. You'll also be framerate-independent etc. But I would not use UDP. The only reason I can see for using UDP is when you're streaming huge amounts of data (VOIP, Webcams, Streaming video). UDP is unreliable, so you can never be sure if the packets arrive or if they are in the right order.
Usually, in a LAN case, the packets will probably arrive in order, but just to make sure, I'd go for TCP. It'll save you a lot of trouble later on, and you'll only have 4 players, so speed should be less of a problem in your LAN/WLAN.

Fenrir wrote: - Should be possible to enter/leave a game at any moment (except for the host, if he leaves the game stops).

This will probably be the most difficult part. I've made a multiplayer game once where it was possible to join at any time and noticed that it made things much more difficult.
One solution (that I didn't use at the time, but should have) would be to have a table called "gameState" on your server, which holds all the necessary information about the current round. Whenever something changes, the change is sent to all players AND written to the table.
Then when a new player arrives, the table is serialized (either fully, or compressed or similar) and sent to the new player. The new player can then reconstruct the current state of the game from this server.

My main advice would be: make a solid multiplayer framework for the game first. Don't get much into gameplay before you have managed to detect and handle issues like:
- joining/leaving of new player
- no response from player (timeout - kick player)
- no response from server (timeout)
Once these work well, you should start to build the gameplay ontop of this. If you do it the other way around (coding player movement before the multiplayer part, for example), you'll most likely have to skip back and forth and change things all the time.

Fenrir wrote:Pathfinding is already implemented, I was just wondering how to manage it in a server/client architecture.

This turns out to be somewhat complicated especially for games with more than 2 players.
I suggest taking a look at:
https://developer.valvesoftware.com/wik ... Networking

Fenrir wrote:For instance, let's say I compute the IA paths on the server and send it to all clients, it raises to me some questions :
- Should I send the whole path when computed and let the clients apply it without sending back IA positions for validation ?
- Or should I just send the current IA position at each frame without sending the whole path ?
Is there any recommendation on packet size or frequency I should rely on ?

Usually, you want all the computation and game rules to be done on the server in order to prevent cheating.
On the client side, you send all of your input commands to the server and perform "prediction".
Prediction is necessary because you want the clients to APPEAR to move/shoot as soon as they press a button instead of waiting for confirmation from the server.

I suggest taking a look at:
https://developer.valvesoftware.com/wik ... Networking

Thanks it's exactly what I was looking for, it will probably save me some troubles.
About the protocol, as I'm using Love 0.9.0, I was planning to use the available lua-enet module, it seems to be a good mix between speed and reliability.

After reading Valve's paper, I think I'll go for providing step-by-step data to the clients (and not a complete path for instance). So the first step will be to build a good state database to be able to produce full or partial snapshots of the game state and managing lag compensation (it will be a lot of fun... :/).

Thanks!