Apolyton CS: Civilization III: The List v1: Multiplayer

MULTIPLAYER
-Summarized By Threadmasters: tfs99 & DanS -
tfs99@sirius.com & dschmelzer@hotmail.com

Every one of us can remember playing games with our friends when we were kids. Whether it was kick-the-can, monopoly, or gin rummy, we all liked to compete and cooperate with our friends. Most of us played war games too and gained a special joy out of destroying our friends' armies on the battlefield. Of course, these desires stay with us as adults, so it is not surprising when we now want to play our favorite computer games with others. And just like the games that we played when we were kids, we expect the games we play to be multiplayer at the core.

This desire holds true especially for one of our favorite games, Civilization. We would like it to be multiplayer at the core and designed from the beginning with multiplayer considerations in mind. For instance, many players have been frustrated by the slow pace of multiplayer games, especially games in which there are more than two or three competitors. Quite simply, we hope that Firaxis will strive to make communications lag time a non-issue for the vast majority of gamers and will redesign the game engine to mitigate the structural time-wasting and pace-slowing elements in previously released turn-based multiplayer games.

The suggestions summarized below give a good overview of our current thinking on how this could be done. Some of these ideas could be expanded upon greatly if there is general direction given by Firaxis. Please feel free to contact any of us for a more detailed treatment of a particular idea.

1. GENERAL IDEAS    TOP

1.1) Asynchronous play at the beginning. If the actions of the players cannot affect the actions of others, asynchronous gameplay gives the game a jump-start. For example, one player could be a couple of turns ahead of another. (DanS)

1.2) Client/server architecture. The whole game runs on a Server, with its own AI, open source or not, and everyone just connects to it to play. If it's a solo game, you run the server on your local host, and connect to it as a single, local Client. If it's a multiplayer game, the host starts the server, and everyone, including the host, connects to the server to play. Your local Civilization III process becomes nothing more than a graphical client. All the actions are resolved on the server. For Firaxis, good separation between client and server code helps maintain modularity. (Rong)

1.3) Critical mass at official matching sites. Allow for play at all of the multiplayer hangouts, such as the Zone, rather than solely at official sites, such as AlphaHQ. (Kris Huysmans)

1.4) Flexible borders between pact brothers. After a pact has been signed, allow their common borders to be manually set by the pact brothers. This promotes efficient use of resources. (Aredhran)

1.5) Hybrid internet/network games. This allows for games with some players on the internet while some are on a network. (DanS)

1.6) Master password. Allow assignment of a master password for a multiplayer game. Access to the master password would allow: 1) Reassignment or elimination of passwords for any player in the game; 2) Conversion of any human player to AI control or vice versa; 3) Activation of the Scenario Editor to modify the map, scenario, settings, etc. to fix glitches in multiplayer games that have already started; and 4) Activating the Scenario Editor would also allow the evaluation of positions during tournament play if a game was not completed in the time allotted. (tfs99)

1.7) Observers. Allow non-participating observers to join the game and watch the action, if the observers are trustworthy, i.e., make it an option. (Mingko)

1.8) Open source server. Related to client/server architecture and Internet Play - Dedicated internet servers. Consider making the server open-source. (Bell and Rong)

1.9) Play by HTML. Preferably, the html page would be hostable on your own page, maybe on Firaxis' page. The game generates an html/JavaScript/cgi page that would allow you to have one location for your save file. People could check the web page and take their turns asynchronously (same as real time play, just frozen at end of turn until every player completes).

1.10) Simultaneous movement. Allow for CivNet-like simultaneous movement, which makes much quicker games. Do not lock squares. This also allows for games with larger numbers of players (much like UltimaOnline). (Titan Tim)

1.11) Smart clients/bots. Related to client/server architecture. Allow any kind of client that speaks the Civilization 3 communications protocol to be able to participate in a game. This would allow for novel artificial intelligence schemes through use of bots, much like in Quake. Also allow console commands for customization of artificial intelligence personalities. (Rong and Titan Tim)

2. INTERNET PLAY    TOP

2.1) [= 56k hosting option and ]= Cable Modem option. Optimization for different host speeds, i.e., with packet size and number, would decrease lag time. (DanS and Possibility)

2.2) Compress game state files. This allows for those with slower connections to substitute computer speed for bandwidth. (tfs99)

2.3) Consolidated packet option. Consolidating many small packets of information into a bigger one may help with lag time in games with players who are geographically dispersed. Also, it seems that dial-up connections have a hard time allocating bandwidth among several threads. (DanS)

2.4) Dedicated internet server(s). Servers are normally closer to the backbone, have higher bandwidth, and are less likely to have unreliable connections. The server does not need to serve graphics, only game state files. (Many)

2.5) Delta game-state transmissions. Only send partial game-state information to reduce bandwidth, whenever possible. Bandwidth on dial-up connections is valuable, especially for the host. (DanS)

2.6) Fault-tolerant communications. When the players are dispersed over several countries, continents and phone networks, communications never work perfectly. Please allow for dropped carriers and low-quality connections. (DanS)

2.7) Predictive game-state tracking. Make the hosting engine smarter. Make it able to predict, for instance, where the action is going to take place, and where the updates are going to need to occur. Substitute smart processing for large bandwidth needs. (DanS)

2.8) Server programming in *nix and Win32 flavors. This allows Firaxis/Hasbro to officially or unofficially release the executables to potential hosts. Firaxis/Hasbro would not have to shoulder all of the bandwidth needs. (DanS)

2.9) Token-ring data transmission: Have data travel around a "ring" of systems ala IBM's Token Ring Network. That is, systems would extract information from an incoming "token" filled with data directed to them from upstream. It would then create a new token, eliminating information that has been accessed by all other systems and appending any new outgoing information. This new token would be transmitted to the next computer downstream. And so on around the ring. The burden to receive and transmit data would be spread around the ring, rather than placed on the shoulders of only one computer. (tfs99)

3. PBEM    TOP

3.1) Allow . Allow the player to use to get back the previous dialog. Sometimes players inadvertently press "Save and Exit", rather than "OK" to start the turn. Instead of allowing use of , the player is forced to exit the game and start over again. (tfs99)

3.2) Asynchronous PBEM movement. At the beginning of games, allow PBEMers to take more than one turn, if there is no possibility of overlapping movement or actions. (DanS)

3.3) Automated Turn Processing. Provide a means for entering e-mail addresses for each player in a PBEM game. Also provide a way to specify an outgoing mail server, account and password. If PBEMs are conducted in a round robin manner (ala SMAC), this would allow the computer to compress the .SAV file, generate an e-mail message and post it to the mail server all in one click. Please include all game information such as email addresses and personal preferences in the saved game file. On the other end, the compressed saved game file should automatically boot the game, uncompress the file, save the file to a backup directory and execute the turn. (tfs99, Rong and Bell)

3.4) Automatic email notification. Related to automated turn processing. Once a saved game file is sent on to the next player, all other players in the game will be sent an email informing them of the successful transfer. Some may not like the extra email, so turning it off should be an option. (tfs99 and Aredhran)

3.5) HTTP handling of saved game files. Related to automated turn processing and PBEM server. A PBEM server using the http protocol allows for turns to be processed without all of the configuration and reliability issues of email. All saved game files will be transmitted using http. (Bell)

3.6) PBEM server. Game status on PBEM has to be explicit always. An e-mail game server would help in this regard. The players have to register the game, but once this is done, everybody in the game is able to check the status on a game by going to the email server web site. If the server receives no information on a game that is registered with the server, it sends out a message saying "the server hasn't received any turns in x days." Have an option where players can decide if they want an email sent to them informing them of the turn progression. (DanS)

3.7) Save option as well as save-and-exit option. Those who have several PBEM games going at once may want to process the game turns sequentially and stay in the game rather than exit. (tfs99)

3.8) Simultaneous PBEM movement. Instead of round-robin play, allow for simultaneous PBEM play. This would increase substantially the speed of PBEM games and would help players keep their heads in the game. (will)

4. HOTSEAT PLAY    TOP

4.1) Save option as well as save-and-exit option. Those who are playing hotseat may want to save a game just in case of a crash. In this event, a save option is necessary. (tfs99)


Apolyton Civilization Site Copyright © Daniel C. J. Quick All trademarks and trade names are the properties of their respective owners