 |
|
robin
|
|
Reading, Berks, UK
Oct 2000
time: 05:13
|
|
Hi, i'm v.busy @ work @ the moment (doing some java for Telstar (record people)), but i thought i'd try & keep everyone informed on my current thinking. Development of the persistent cache (for another project), has made the requirement for a database redundant! We can now store/reload the state of the cache @ any moment, preserving all game data. XML will be used to define the structures involved, and configured @ initialization.
I haven't had time to implement any of this yet, but will get round to it @ some point this week...
|
|
| |
|
|
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001
time: 05:13
|
|
I sum up my understanding of the thread first:
Peer to peer and client server have been considered, and the latter seems to be preferred.
At init, the world or the part of it that is known to each player is sent to them.
The data that should be sent each turn are the commands that have been issued by players and AIs.
The communication protocol could be http.
The content protocol seems to tend towards serialization.
If that is correct, maybe we should update the page on the web with this info.
Comments:
Architecture: I'm somewhat familiar with client server, so I'll base my asumptions on this model.
Data sent: I think at least one thing has been omitted, which is the disasters. The actors are not only the civs but also the world. Gamedata may contain that info, or maybe not. Global events are also useful, particularly in mods, so they must be sent too.
Content protocol: I used RMI and it was way slow. Serialization can be used but the apparent simplicity of it is misleading. Using it "as is" (just add implements Serializable to your objects) is not efficient (better to use Externalizable) and causes problems when the object you'd like to create already exists on the other side, so you can effectively use that just to send "commands" which have to be reprocessed. I think that commands could also be sent via a string since we can format strings through xml. I would rather send text than serialized objects based on performance concerns, but it's been a while since I last dabbled with RMI (back when it was brand-new) and serialization. It would mean having a big parser that can interpret orders rahter than coding lots of event classes. That is not a very elegant solution so I am not clear at all.
|
|
| |
|
| |
|
|
|
Richard Bruns
|
|
NC, USA
Nov 1999
time: 06:13
|
|
Within this framework, is it possible for the server to share the computational load with the other computers? Could a complex set of calculations could be sent to one of the clients in order to run a larger or more detailed gameworld?
Alternately, could we have a seperate 'server' for each model? One computer might control the Ecology model, another could control all of the Technology model calculations, and so on. Tech orders and survey requests are sent to the tech server, ecology information and orders are sent to the ecology server, and so on.
I think that whatever architecture we use should have the ability to scale to massively multiplayer games. It seems that this sharing could enable large complex games to be run more quickly. Is it practical?
|
|
| |
|
|
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001
time: 05:13
|
|
Massively multiplayer games are usually client-server with one big server, which might in turn use a few machines to do the computation for it, but not the clients (because in massive multiplayer, they will keep disconnecting unexpectedly).
It is possible to distribute different models over various servers, but I am not sure it is interesting to think of that now. This is because this is mainly a performance issue and you cannot know where performance issues will lie till 80% of the code is done.
|
|
| |
|
|
|
tjawatts
|
|
London,UK
May 2001
time: 05:13
|
|
Hi
Here is something I could maybe look at! If there is still nobody doing it. I have just finished doing a project using RMI and stuff. I think it is probably easier to have some sort of central server (on one of the users machines). I would need to look at how I could integrate something into the games architecture but it shouldnt be so bad seeing as the game is already multiplayer in the fact that it has the AI players. Just need to be able to replace them with human ones!
Anyway I will have a good look at this thread (and code if I get it) later and then come up with some more ideas.
Tony
|
|
| |
|
|
|
jfelten
|
|
Proposed Multiplayer model
I have been corresponding with Mark Everson via e-mail about doing some coding and design for the multiplayer model, and he has asked me to share my thoughts on the matter. I’m glad to see there has already been some discussion of this, and some consideration of multiplayer format when designing the rest of the game. I apologize for the length of this post.
As I see it some of the basic design requirements are as follows:
Multiplayer games will communicate via TCP over a network
Multiplayer games should be designed to consume as little bandwidth as possible.
Multiplayer games will have a central server. This server can be 1 game players machine or it can be a centralized server on the Internet.
The centralized server will be responsible for all AI players’ logic.
A client, or and individual player’s machine or process, will be responsible for all AI logic involving a player’s civ. This would include automated civ management functionality.
A client will receive all information about opposing civs, whether AI or other players, from the server.
Every action a client makes will be transmitted to the server. The server will then be responsible for making sure information is delivered to other players.
A client also needs to be able to receive information from the server and update the state of it’s game.
A protocol will be developed to handle all client to server or server to client communications. The protocol needs to be flexible to handle future game functionality.
There will be assigned port numbers for both client and server.
We will add to this list as time goes on.
Design considerations
The multiplayer code should be independent of the rest of the code. In an ideal world, other developers developing such things as the interface and the AI code should not have to worry about how a multiplayer game works. Depending on how the rest of the game was designed it is not always this easy. I have not had a look at the current code, but I’m hoping that it is based on an event driven model, and that all I would have to do is implement a listener to listen for game events. If it is not designed like this then integrating multiplayer code will be more difficult because this would mean a lot of code modifications.
The multiplayer code should also be as efficient as possible when transmitting events back and forth between computers. We need to design a simple protocol for transmitting information back and forth between computers. While it is possible to serialize objects and transmit them, I would advise against this because of the “heaviness” of most java objects, and because they have a tendency to grow large as time goes on. I might use some sort of lightweight container class or a flyweight pattern. The information should eventually get converted to binary code, transmitted, and reconstituted when it is received. We also want to make sure that future game modifications and enhancements will be supported in multiplayer.
We also need to clearly define what the role of a server is and what the role of a client is. The server will be a central hub that all clients in the game talk to. The server should control all AI players and do all calculations necessary in a game. An example of a server action would be when a settler irrigates a land tile. The client machine would initiate the action, but the server should record the change in environment and retransmit the land change to other players. The server will receive all players’ actions, process them, and retransmit the results to all clients. The client will be responsible for two things: maintaining a player’s game, such as automating building and civ maintenance, and receiving events from the server to incorporate them into the game.
There has been some discussion about trying to distribute the processing load equally among clients and not having a centralized server. I would advise against this because of the difficulty in trying to sync all the clients up, as well as the security risk involved. In any kind of competitive event such as a game it is important to make it as difficult to cheat as possible. If the client is doing a process, which affects other players such as controlling an AI player, then it is possible to manipulate this process to your own advantage. The first rule of network computing is never trust the client.
Proposed Model
Here is how I might design it. There will be an interface called GameEvent that all classes having anything to do with a game action must implement. There will be another interface called GameEventListener, which listens for GameEvents when implemented. In the multiplayer scheme there will be both a transmitter to transmit events to another computer and a receiver to receive events from another computer. The transmitter will implement the GameEventListener and convert these events to the appropriate form and transmit them to the server. The server will have a receiver to process the information, make appropriate changes to the game, and transmit all results to all appropriate clients using its transmitter. The clients will then receive instructions back from through their receiver and process the information.
That’s enough to get started. Please give me whatever feedback you can.
Thanks,
John
|
|
| |
|
|
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001
time: 05:13
|
|
Hi and welcome,
There is some use of observers in the code (I'm talking mainly of the military model, since that's what I code), not listeners per se, but it'd be easy to migrate to a Listener architecture.
What object(s) would send the events though?
I agree that serialization is quite heavy, but I think we'll have to serialize some objects anyway . Which ones do you think would be good candidates? Which ones would you like to avoid?
I guess map objects need serialization, the rest can be transmitted as orders/events unless there was some randomness in their resolution (e.g. fights).
|
|
| |
|
|
|
jfelten
|
|
Before I can answer these questions properly I need to get a look at the code. I want to force as few changes to the code as possible.
Any change that occurs in a game will need to be communicated to another computer. This not only includes military, but also civ advancements, city growth, tile changes, etc. A common mechanism to monitor all changes in the game would be very helpful, not only for multiplayer issues, but throughout the game.
Is there a CVS or other repository that I can check the code out of? If not I will volunteer to set one up. Otherwise how can I get the code?
Thanks,
John
|
|
| |
|
|
|
Mark_Everson
|
 |
Canton, MI
Jan 1970
time: 00:13
|
|
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
|
|
La Ferté sous Jouarre France
Jan 2001
time: 05:13
|
|
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
|
|
Canton, MI
Jan 1970
time: 00:13
|
|
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
|
 |
New Zealand
Mar 2001
time: 17:13
|
|
Hi, John. Sorry I haven't given you a better welcome. Put it down to business and illness. Anyway, welcome aboard!
John:
quote:
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:
quote:
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
|
|
| |
|
|
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001
time: 05:13
|
|
quote:
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?")
|
|
| |
All times are GMT. The time now is 05:13.
Apolyton Time is 00:13. |
top of page
|
|
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is ON
vB code is ON
Smilies are ON
[IMG] code is ON
|
|
|
|
|
|
10-11-2000 07:47
). Just keep this in mind a bit... We really do need to get back to discussing it in general, as well as the system for implementing macros. Thoughts appreciated!
|