Tweet
Reposting the posts from the last thread for consistency.
----------
tfs99
----------
This CivIII discussion and list of suggestions began under DanS's thread: "CIV III must be built multi-player from the start"
Click here to read it: apolyton.net/forums/Forum6/HTML/000508.html
In short, I say "Absolutely!" Please post further comments and suggestions regarding multiplayer issues here.
SMC3
n ... Ted S.
[EOP]
----------
DanS
----------
To kick things off:
1) Compress game-state files -- originated by tfs99 (good idea) in the other thread.
2) Have a Civ 3 server that is hooked to a high-speed connection on the internet (we're talking T3 here). It need not be graphical in nature and therefore would not require high bandwidth (i.e., it would not cost Firaxis or Hasbro a boat-load of $$$). Dial-up accounts seem to have a hard time allotting bandwidth among multiple threads.
3) Please program the server in *nix and WinNT flavors, so Firaxis and Hasbro won't have to host everything.
4) A fault-tolerant communication engine to reduce connection cut-offs. Especially important for people playing on different networks (e.g., two European and two American players--we always had this problem with The Strategist; an honorable player, but he would get cut off once or twice in a day-long session).
5) Hybrid network/internet games. Some players on a local network, some on the internet.
6) Have an option to send game-state info in large packets. Again, for players in different parts of the world. I hate it when everybody waits for a 5 byte packet to go
through the global connections. If there is one snag, you have to wait.
7) Asynchronous play at the beginning. Have the server predict what can happen in the
next couple of turns, thereby allowing one player to be a couple of turns ahead of another, without either having to wait. It is hard to get through the first couple of thousand years, because most people hit the return key 9/10 turns, but then have long turns the other 1/10. Everybody has to wait for the one, so if you have 5 players, you will (very roughly) be waiting half the time.
8) Duplicate packets going to the same internet destination. Sometimes some "replies" come faster than others, due to different routing. Send out a couple, rather than one. Have both client and server have ways of handling this. Not recommended for the 56k hosters.
9) Have an option to reduce the number and size of packets when a <= 56k hoster is running the show.
10) Only send partial game-state information whenever possible to reduce bandwidth; combine game-state changes in a single thread.
11) Make the engine more predictive (i.e., smart). 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. The communications always break down. Windows only crashes once a month (for me, at least).
C'mon guys, let's think order of magnitude improvements!
[EOP]
----------
tfs99
----------
Delta Status Transmission: Great idea.
Token Ring Data Transmission: Another idea I had would be to 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.
Data would be constantly streaming into and out of every system. This way, data throughput would be maximized for the system as a whole.
The burden to receive and transmit data would be spread around the ring, rather than placed on the shoulders of only one computer. Albeit, throughput would be limited to the speed of the slowest connection, but it would not be limited to the rate of a slow host connection divided by the number of players.
SMC3n ... Ted S.
[EOP]
----------
tfs99
----------
Password protection:
Allow the assigning of an overall 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 MP games that have already started
4) Activating the Scenario Editor would also allow the evaluation of positions during tournament play if a game was not completed in the time alloted
[EOP]
----------
tfs99
----------
Play-by-e-mail:
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.
Right now the process to pass along an e-mail turn is cumbersome and error prone. Streamlining the process would increase turn throughput and encourage more people to give PBEM a try.
[EOP]
----------
tfs99
----------
This CivIII discussion and list of suggestions began under DanS's thread: "CIV III must be built multi-player from the start"
Click here to read it: apolyton.net/forums/Forum6/HTML/000508.html
In short, I say "Absolutely!" Please post further comments and suggestions regarding multiplayer issues here.
SMC3
n ... Ted S.[EOP]
----------
DanS
----------
To kick things off:
1) Compress game-state files -- originated by tfs99 (good idea) in the other thread.
2) Have a Civ 3 server that is hooked to a high-speed connection on the internet (we're talking T3 here). It need not be graphical in nature and therefore would not require high bandwidth (i.e., it would not cost Firaxis or Hasbro a boat-load of $$$). Dial-up accounts seem to have a hard time allotting bandwidth among multiple threads.
3) Please program the server in *nix and WinNT flavors, so Firaxis and Hasbro won't have to host everything.
4) A fault-tolerant communication engine to reduce connection cut-offs. Especially important for people playing on different networks (e.g., two European and two American players--we always had this problem with The Strategist; an honorable player, but he would get cut off once or twice in a day-long session).
5) Hybrid network/internet games. Some players on a local network, some on the internet.
6) Have an option to send game-state info in large packets. Again, for players in different parts of the world. I hate it when everybody waits for a 5 byte packet to go
through the global connections. If there is one snag, you have to wait.
7) Asynchronous play at the beginning. Have the server predict what can happen in the
next couple of turns, thereby allowing one player to be a couple of turns ahead of another, without either having to wait. It is hard to get through the first couple of thousand years, because most people hit the return key 9/10 turns, but then have long turns the other 1/10. Everybody has to wait for the one, so if you have 5 players, you will (very roughly) be waiting half the time.
8) Duplicate packets going to the same internet destination. Sometimes some "replies" come faster than others, due to different routing. Send out a couple, rather than one. Have both client and server have ways of handling this. Not recommended for the 56k hosters.
9) Have an option to reduce the number and size of packets when a <= 56k hoster is running the show.
10) Only send partial game-state information whenever possible to reduce bandwidth; combine game-state changes in a single thread.
11) Make the engine more predictive (i.e., smart). 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. The communications always break down. Windows only crashes once a month (for me, at least).
C'mon guys, let's think order of magnitude improvements!
[EOP]
----------
tfs99
----------
Delta Status Transmission: Great idea.
Token Ring Data Transmission: Another idea I had would be to 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.
Data would be constantly streaming into and out of every system. This way, data throughput would be maximized for the system as a whole.
The burden to receive and transmit data would be spread around the ring, rather than placed on the shoulders of only one computer. Albeit, throughput would be limited to the speed of the slowest connection, but it would not be limited to the rate of a slow host connection divided by the number of players.
SMC3
n ... Ted S.[EOP]
----------
tfs99
----------
Password protection:
Allow the assigning of an overall 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 MP games that have already started
4) Activating the Scenario Editor would also allow the evaluation of positions during tournament play if a game was not completed in the time alloted
[EOP]
----------
tfs99
----------
Play-by-e-mail:
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.
Right now the process to pass along an e-mail turn is cumbersome and error prone. Streamlining the process would increase turn throughput and encourage more people to give PBEM a try.
[EOP]
Comment