Multiplayer Coding/Issues

[Mark_Everson]

Hi Robin:

Just a few quick points on your suggestions:

1. I think your Conflict class and its related classes are unnecessary. Your unitPositions gives all the info that is needed (at least from the client), and I believe Conflict doesn't add anything. Each client won't know for sure where conflicts are, since another player on a different client has freedom to move any of their units to a new position each turn. So IMO conflicts should only be resolved on the server when it has all information.

2. There aren't cities in Clash quite as there are in Civ. The economic units and territory are handled in provinces. The people are basically everywhere, rather than assumed to be squeezed into cities. Just wanted to bring this up so you know.

[robin]

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...

[Mark_Everson]

Hi robin:

I'd like a few more details on your persistent cache idea, and how it compares and contrasts with just keeping the game data in memory as java objects like we have been doing. I know you're busy so it doesn't need to be right away! Thanks, -Mark

[Mark_Everson]

We haven't been thinking much about multiplayer needs in the current code (At least I haven't ). 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!

I sent a note similar to the above to Gary, who inquired about what the ways we were thinking of handling MP were. Since I'm not really qualified on the topic, I'm just going to bump up this thread so Gary and whomever else can take a look and comment on what has gone before.

[LDiCesare]

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]

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?

[Mark_Everson]

Thanks for the comments / analysis.

quote: If that is correct, maybe we should update the page on the web with this info.

I agree. But we should wait about a week to see if anyone has other suggestions first. I also agree pretty much with all of what you said.


Let me see if I can tersely sum up what we're trying to achieve from a gameplay end:

I. Everyone has their own client-side game that has a world model in it. _a. That is what is used for the player interrogating the game on choices.
_b. The player enters their orders using the client (duh!)
_c. Orders are all that is sent to the server at turn end.
_d. Server returns whatever the player needs to know of the game world.

II. The Server has the only Complete and Correct version of the world.
_a. Generated every turn after cranking thru all orders and events

III. The world players have is frequently not 'right' for several reasons.
_a. No godlike knowledge of things down to the last detail
__1. depending on a setting, player knowledge can be very far from correct
_b. Impractical to send complete current world every turn
_c. Player can upgrade world view in client (and so knowledge of world)
__1. thru exploration - more of map is uncovered and updated from server
__2. thru obtaining maps and info from other players
__3. thru 'surveys' of own civ like the domesday book (Richard's idea)
_d. If we want to, this even allows for cases where player only knows what a ruler would know. No instant knowledge of what explorers/TFs far away are doing. FE updates from explorers/TFs you send out could only be implemented when the message/map/explorer returns. This is probably not best for default game, but could be an advanced setting.

That's all I've got time for now, comments?

[LDiCesare]

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.

[Mark_Everson]

I'm bumping this up mostly so that Gary will see it, and can include the idea of us moving into multiplayer at some point when he thinks the type of deep code architecture thoughts that are beyond me

Also we need a coder to start working in this area since all the previous ones haven't worked out, and I still believe this is a good way to do some of the more advanced testing before a really good AI is available. So if any lurkers are interested, please let us know!

[Gary Thomas]

Are you really thinking about getting a server to run a massive multi-player game?

Wouldn't it be better to set up a peer to peer system so a few friend s can have a game?

Of course, ultimately we want both.

By Demo 6 or 7 we might be in a position to clearly separate the user interface from the game engine. Then we might be able to code for multiplayer games.

Cheers

Gary

[tjawatts]

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

[Mark_Everson]

Hey Tony -- this does seem like a good area for you to get into! Why don't you read the whole thing over carefully. I'll send you the version of the code I have to allow you to get a look at things. But its Not current, so don't look at the level of details. Then when you've seen everything you can put up a prelim. plan and we can discuss it.

It'd be Great to get this going for demo 6.

-Mark

[jfelten]

Proposed multiplayer model

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]

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