Multiplayer Coding/Issues

[Mark_Everson]

Hi John:

Thanks for the detailed discussion on where you think multiplayer should go. I'll respond to your last post first just because it's simpler for me.

First of all, I went ahead and just sent you the code, so you can see how things work on your own...

Secondly, you say that "any change that occurs in a game will need to be communicated"... I'm assuming that you have read my post of 05-04-2001 00:53 above, and basically agree with it. If not, please look at over and tell me what you agree with and disagree, because I look at that post as a high-level view of what we are trying to do in terms of multiplayer design. One of the things in there is that each client's copy of the game world does not necessarily have the correct or complete information. So clients, and the players associated with them, shouldn't IMO be sent every change, only those that the player would know about. I think this approach is important because Clash as designed is a very data-heavy game, and not having to send every little change along every turn will help a lot with bandwidth for MP. Also, because the player does not have absolutely perfect information on the game world, it reduces the players benefit from micromanaging things to a ridiculous degree. We can discuss this further, but I wanted to bring up this important point and make sure you and others were aware of it ASAP.

I think you're setting up a CVS repository would be great. Gary has spoken about doing the same thing, but I'm not sure how far he's gotten with it. Can you start a new thread on "CVS Repository" or some such for you guys to discuss it and work out details?


Now, on to my comments about your much larger previous post:

I'm in substantial agreement with you on many of the details, so I'll only say something when responding to a question of yours, or wanting to put forward a point of view of my own. By way of a disclaimer right upfront, I've never done any network programming, so on the technical side my knowledge is limited.

I have to say that the Econ model is not terribly event-driven. But that said, there will typically only be a few interface elements where the player actually issues orders that will need to be modified for the benefit of the MP code. So the player's economic activity will simply generate a stream of orders that can either be immediately sent to the server by your listener, or can be stored, and sent when the end-of-turn action is processed by each player/client.

I think your proposal about the server handling all the AIs except those associated with player civs is pretty good, but might potentially lead to some problems. For instance, in a timed MP game, unless the serving computer is vastly better than all the others, the player with the server computer could be put at a disadvantage because their computer is called upon to do a lot more. Giving them less clocks to be used for their own civ's AI. Or, alternatively, if the server computer has the same amount of time to think as everyone else's then there would need to be a substantial amount of time when each turn ends that the server computer needs to use to think up strategies for all the AIs. That perhaps-substantial lag could be annoying to the players. I don't know that your approach isn't the best anyway, but these are some initial thoughts we may want to consider when we decide how to chop up which AI is done where.

IMO we only need to use serialization support when so many things in an object change at once that it's more efficient to send the whole object than to perform a few updates of object parameters. So I basically agree with your point, but think there may be exceptions where we need serialization.

Thanks for being willing to take a stab at this, and I'm looking forward to seeing this area make progress!

[jfelten]

Thank you for the code. I am able to compile and build the game without any problems, have have not made it run yet.

After looking at the way the code is done, I am somewhat relieved. The observer model implemented in the code should work for me, which means I should be able to build the network model on top of existing code with few modifications.

I am starting my design now keep everyone appraised of my progress. When the design is reviewable I will post a message.

I'll set up a CVS server on my linux box and check the code in. I'll make a seaprte thread for that.

John

[jfelten]

Clash of Civilizations Multiplayer Architecture and Development Plan

This is an update on the status of the Multiplayer class design. Based on how other games are set up and other networked applications I have come up with a basic design. I would like to put it up for review. Two key requirements are that the multiplayer code be independent from the rest of the code (ie good encapsulation) and be flexible to accommodate future code changes.

Design Overview:

The clash multiplayer design will be based on simple message based architecture. By this I mean that information will be sent between computers in discrete packets that are individually transmitted and received. Each message will have a header that has a client id, and an object id. The message will contain the value of what is being transmitted. An observer class will trigger network events since most game objects extend the Observable class. For example every time ClashMap is changed, there will be a central server to process requests and keep the overall state of the game. Clients will take care of all player input and graphics. Any client will be able to act as a server. There seems to have been some debate over whether the game should be peer to peer or client server so I should probably explain why I chose to go with the Client Server Model.
Client/Server advantages: easier to code, secure (cheating harder), centralized synchronization, more efficient with bandwidth
Disadvantages: server computer must carry disproportionate load, server is single point of failure
Peer to Peer/Distributed
advantages load: spread over many computers
disadvantages: harder to code, insecure (untrustworthy clients), uses more bandwidth

I chose to go the client server route mostly for security purpose and because it is easier to code. Although I like the idea of distributed code, there are too many issues for me. If we want to go this route later it will be possible to use the Network classes I develop to do so. I am not using RMI or any other distributed protocol.
One thing that is still not worked out yet is how to convert game object changes to transmittable information. I plan to use serialization first because it is easy and lets me focus on the overall network design. I have a feeling that performance will be lacking, so I will develop more efficient methods afterwards.

Class Design:
New package game.controller.network

Interfaces:
ClashNetworkReceiver - defines an implementation independent networked receiver for game information
ClashNetworkTransmitter - defines an implementation independent transmitter for game information

Classes:
ClashGameReceiver – An implementation of the ClashNetworkReceiver interface that receives and parses socket and data streams containing game information
ClashGameTransmitter – An implementation of the ClashNetworkTransmitter interface that assembles and transmits socket and data streams containing game information
ClashProtocol – This class describes how to decipher a transmitted message
ClashNetworkService – This controls the various threads that send and receive data
ClashMessageQueue – A Queuing class that holds information for processing and transmitting
ClashServerManager – This class manages Server activities
ClashClientManager – An observer class which handles transmitting necessary client information

Obviously this list is not complete or final.


Use Cases:
There are so many, and they are difficult to describe all in writing. I figure I owe at least one or two use cases to illustrate what I am talking about.

Use case 1: Player X irrigates a map square. Player X’s Clash instance sends this information to the server computer. The Server computer then sends updated map information to all other client computers.
The ClashClientManager observes that the player’s map has changed. The ClashClientManager converts this object change to the appropriate form described by the ClashProtocol object. The ClashClientManager then uses the ClashGameTransmitter to transmit this change to the map. Depending on how bust the transmitter is it may or may not place the object change in a ClashMessageQueue to await transmission. After the ClashGameTransmitter transmits the information, A ClashGameReceiver on the server machine receives the object and deciphers it using a ClashProtocol object. After the receiver deciphers the object, it passes it to the ClashServerManager, which updates the server game information. Periodically, the ClashServerManager uses a ClashGameTransmitter to transmit information back to all clients. The server has a list of all connected clients. A separate thread runs which sends out information to all connected clients.

That should be enough for discussion purposes. I’ll leave to Mark to decide how to procede. The options are:
1.) I keep coding to get a workable prototype based on serialization.
2.) We discuss this design in the forum until all designers are happy and then produce the workable prototype.

Thanks in advance for any feedback,

John

[LDiCesare]

Your plan sounds good to me.
I agree in particular that RMI is SLOW, and serialization is quite inefficient in terms of size but easy to implement. It should be possible to migrate from Serializable to Externalizable when performance gains are needed. I remember gaining factor 4 in size of data by just doing the serialization work "by hand" the Externalizable way, but that's quite old.

[Mark_Everson]

Thanks for the clear proposal John! As far as I'm concerned you should go for it! BTW I'm going to be out of circulation for almost two weeks on vacation, so you, Laurent and Gary should just reach agreement among yourselves on what seems sensible.

I'll just criticize when I get back

One thing I want to highlight though, because its an important concept, is that IMO we mostly only want Orders to be what the clients send. So in terms of your example, there is no 'player irrigates and that info is sent'. Rather IMO Nothing like that should happen, since orders are only really implemented at the end of the turn, on the server. The reason pretty much orders only should go to the server are:

1. the simultaneous turn system (with ticks for military movement) guarantees the player doesn't have all info when the orders are given. You never know if an attack on an enemy TF you plan will take place or not, since the TF you are trying to attack may withdraw before the attack takes place. This also allows for Real fog-of-war effects!

2. the same thing happens in the Econ model, since orders like irrigation don't take effect until the end of turn.

3. Orders are generally more compact than results, so I think we can save some BW that way.

I just wanted to bring this up clearly before you get too far along because we could have a real train-wreck if you assume things work action-by-action as they do in civ.

[Gary Thomas]

Hi, John. Sorry I haven't given you a better welcome. Put it down to business and illness. Anyway, welcome aboard!

John:

Thank you for the code. I am able to compile and build the game without any problems, have have not made it run yet.

Did anyone explain that you have to have a class directory on your classpath, with the game subdirectory containing the class files in a structure reflecting the packages, and you also need a resources subdirectory containing UnitBuilder.xml and a tiles subdirectory with the unzipped tile gifs in it? Also that directory should have logo128.gif for a prettier startup menu. So you have a class root directory (called /work/clash/ClashD5/class on my system - I try to pretend that this is work, but my boss is unconvinced) with:

game and its subdirectories
tiles
resources

If you lack any of these files let me know.

Laurent:

I agree in particular that RMI is SLOW, and serialization is quite inefficient in terms of size but easy to implement. It should be possible to migrate from Serializable to Externalizable when performance gains are needed. I remember gaining factor 4 in size of data by just doing the serialization work "by hand" the Externalizable way, but that's quite old.

I agree. I am quite a fan of Externalizable, especially if the data is encapsulated in a zipped XML file. Such files can be very small.

I also agree with Mark. Each player will send a message at the the end of the turn only. After server processing, each will get an identical update message from the server, outlining changes.

By the way, where do we get a server?

Cheers

[Gary Thomas]

I am a great believer in naming things. In the tech package, which is written and tested but not yet incorporated into D5, everything is named. The system depends heavily on a NamedObject class and an associated NamedObjectList.

Which brings me to the point of this post.

When an order is sent to the server, it will, in effect, be something like:

Move unit "fred" of civ "Romans" from its present position to map square 8, 15

My point here is that it should not be necessary to send the "fred" task force object or the "Romans" civ object to the server. It should be sufficient to send the name. With care, we can use this type of shallow serialization for most orders.

Cheers

[LDiCesare]

Originally posted by Gary Thomas
Move unit "fred" of civ "Romans" from its present position to map square 8, 15

My point here is that it should not be necessary to send the "fred" task force object or the "Romans" civ object to the server. It should be sufficient to send the name. With care, we can use this type of shallow serialization for most orders.

YES! If only I could convinve people at work that naming their objects would let other people work on them ("Why do you need a string when you have 1000 APIs?")

[Gary Thomas]

YES! If only I could convinve people at work that naming their objects would let other people work on them ("Why do you need a string when you have 1000 APIs?")

You think you have problems? Where I work they use four byte, system generated, integers as their "unique ids". To my knowledge nobody has ever used these ids for anything. Every object has some other, useable, identifier. Unfortunately all the database links use these bloody "unique ids".

Cheers