Multiplayer Discussion Kickoff Thread

[ElGranPepe]

How to propigate the events? From my light reading, this is the most troublesome part of network play, especially when you move beyond LAN parties (because of bandwidth). For RTS games, all the changes from all the objects from all the members must be synched every tick. The question becomes how to handle change requests. Does the change get propigated to the server, and sent to all the clients at the same time, or is the change done first locally, then the server is told what happened, and the server propigates remotely? Apparently, in the game development world, it's split as to how to handle this. I'm leaning toward all the change vectors (move requests, attack requests, build requests, etc.) go to the server, then sent to all clients (including the requesting client) at the same time, In my opinion, that's the best way to ensure that the game is synchronized across ticks :lol:  :roll:  :roll:  :roll:

[kamahl]

1)  MD5 hash all xml files, and compare with server's version.

2)  Create a temporary tech tree, downloaded from the server.  This would only be the XML files downloaded, it gets the models and textures from your tech tree.  (save bandwidth + loading time)

3)  MD5 hash XML files, send to server, and push most common version to all clients as per 2.

Also, rather than sending all the small details, why don't you just send the orders?
If you tell all clients "I'm sending Initiate #35 to build a library at coords 350,223.5"  It is should be assumed that all clients can work out the same thing for the results of this.  After all, We all have the same engine, and the same starting and finishing locations, why don't we just trust that each client will do the same thing?  When it gets to the "stopped" state at the end of the walk, you can send the absolute location, and move him slightly on all remote clients, but don't bother saying "moving here; walking around golem; walking around gold mine; walking back this way again;got there;" or "I'm here:  X,Y; now I'm here: X + 0.001, Y - 0.002; Now I'm here..."  It's just spam!

EDIT:  I got the game three days ago, and havn't looked at the source, but from light reading and starting to mod, this seems possible, and the best (or only) idea proposed.  

EDIT2:  I was thinking about the server today.  All the "server" really has to do is dispach new events.  I was thinking that we could use something as simple as an IRC room, with CTCP (or whatever it is...  You know what I mean) for game events, and normal messages for chat.  The AI can be split so each player supports an AI, or two if the game "host" (the one who started the game, and possible running a lightweight IRC server) has put that many AI into the game.  The rest (the stuff mentioned above) is handled by all clients, who compare their results on the channel.

[PJCAREYIII]

lodemia wrote:

"A modified client could move his forces automatically when it senses an enemy presence and fight the battle without any human intervention - if the cheater is good, he might devise algorithms to fight battles more efficiently than a human could manually - like moving forces out of the way right before having the dragons fire and then moving the forces back in immediately - stuff that is very difficult for a human to do efficiently. Or coordinating many different types of units all at the same time which a human might have trouble with."

To be totally truthful I think any multiplayer effort should embrace a client's customization ability; the only statistics that need to be regulated by the server are the number and statistics of each beginning unit and each upgraded unit, to prevent real, unfair 'cheating'. If a player can automate the defense of his or her bases, that is excellent; as long as there exists a ranking system to help a new player match his or her abilities with a similarly ranked opponent, the system should please a maximum amount of users.

[kamahl]

exactly,  but then, who would trust the defence of their base to an AI?  let them do it if they want.

[martiño]

Multiplayer is now part of the official glest project.

http://www.glest.org/glest_board/viewtopic.php?t=3051