 |
|  |
 |
|
DanS
|
 |
Kickball Capital of the World
Jan 1970 time: 00:14
|
|
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.
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]
|
|
|  |
 |
|
Rong
|
|
Euless, Texas, USA
Apr 1999 time: 05:14
|
|
I am not sure I understand what kind of server you are talking about. Anyway, I actually thought about writing a small utility in java to streamline the PBEM process in SMAC. Here are my design ideas, with the assumption that it'll be incorpated into the game.
Initial setup:
Everyone who is planning to host PBEM need to enter information for the outgoing (SMTP) mail server, server name, user name etc.
When the host is starting a new game, she will see a dialog box asking her the following:
* a unique name for the game
This is used in the save file name and subject line in the emails.
* each player's name, email, alias and faction, also the order in which they play
The host probably should always be the first one to play.
When the information is entered, it is saved in a file, probably the save file itself.
When the player finishes a turn, the program automatically saves it in the save directory with a file name
gamename_turn#_nextplayer.sav
then it'll zip it up, connect to the SMTP server to send the file to the next player, with a subject line like
Big Challenge Turn 12 File
and also a message to the whole group with a subject
Big Challenge Turn 12 Sent to Foo
Of course, this is all done automatically when you hit the "Turn Complete" button.
This shouldn't be too hard to implement, but it'd save PBEM players lots of trouble.
|
|
|  |
 |
|
Koyaanisqatsi
|
 |
of Maine paupers.
May 1999 time: 00:14
|
|
Rong: I think that's kind of similar to what they were talking about. Here's the image I got of how it would work from reading this thread. Everyone's game setup includes their SMTP, email address, and name. When you want to start a PBEM game, you connect to a server (should the front end be in the game, or a web site?) that acts as a host for the game. It stores the email addresses of all the participants, as well as the game turn and play order. When you hit the 'turn complete' button, the game zips the savegame and mails it to the server. The server then updates its info on the game and sends the file off to the next player. (Alternative I just thought of: Instead of using email to send the files, just use email to notify the players that the next turn is ready. That player fires up CivIII, hits 'Resume PBEM game,' and CivIII connects to the server and downloads the new savegame. This keeps people from having a large file mailed to them, and avoids the hassle of binary-ascii conversion and mail clients and such. Instead of PBEM, it's an on-demand file transfer. I think this might be a more efficient implementation, and would also insulate the player from the process [*cough* User error *cough*]) Lather, rinse, repeat as necessary.
The point of going to the extra trouble of using a server is reliability. That way, you can be sure that the game has been correctly passed, and you know for sure who has it and who should get it next. Also, it would insulate the players from each other somewhat, so it isn't necessary to give out email addresses and that sort of stuff.
|
|
|  |
 |
|
Possibility
|
|
Make the game have a special option for ultra fast hosts. When the host is settig up the game, he should be to tell it that he is a T1, T3, or cable modem host and the game should be optimized in the data transfers to account for the fast host.
Possibility
May the possibilities remain infinite.
|
|
|  |
 |
|
Rong
|
|
Euless, Texas, USA
Apr 1999 time: 05:14
|
|
Cross-posted from the AI thread:
It seems strange to me people are argueing over trivial things (no need to mention which ) while ignoring the most important improvement Civ3 needs: AI. Let me just throw some more ideas around.
I've been thinking about a "Client/Server" model of game play. Namely, 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 localhost, 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 civ3 process becomes nothing more than a graphical client. All the actions are resolved on the server.
What does this have anything to do with AI? Well, if they open up the network protocol, then we can write autonomous clients that connect to the server and play just like a human. You know where this came from if you've ever heard of "client side Quake bots". 
Benefits:
* Unlike OSxAI where you are limited by how Firaxis decides to do, here the option is in your hands. You can use your favorite language (Java, C++, Assembly), run it on your favorite OS (Linux, Mac, Be), play with different algorithms (NN, GA), save your AI data however you want (flat file, relational database, OODB), as long as your client speaks the Civ3 protocol.
* A well written, well tuned, perhaps even self-learning client can provide unlimited challenge, whether you play solo or multiplayer.
* For Firaxis, good seperation between client and server code helps maintain modularity.
Issues:
* The guy who wrote the first client should win the Turing Award. In another word, for a game of such complexity, a fully autonomous, smart client may be too hard to write. But who knows? Maybe some one out there is clever enough to pull it off. After that, it'd be a lot easier to follow the example and make minor changes.
So what do you think?
------------------
The radical invents the views. When he has worn them out the conservative adopts them.
- Mark Twain
|
|
|  |
 |
|
Kris Huysmans
|
|
Belgium
May 1999 time: 05:14
|
|
I found civ3 multiplayer must be possible at game zone and not at its own server.
because:
When you go to civ2 at game zone there are normaly around 10 players
When you go to alphahq.net there are normaly around 0 players !
|
|
|  |
 |
|
Kris Huysmans
|
|
Belgium
May 1999 time: 05:14
|
|
I play often quake and I must say the bots play total diferent then human players. And when bots win is this because they react faster then humans and they don't make any bad shot. I realy found that the smac AI is more human then the quake bots.
|
|
|  |
 |
|
TitanTim
|
 |
Niagara Falls, Ontario, Canada
May 1999 time: 00:14
|
|
All these ideas are great. All this talk of PBEM is interesting as well as using bots for AI.
With respect to bots, I must agree with Rong that this idea would greatly enhance the AI. The normal game AI should be released as a bot plus there should be a randomness ability included with any bot thereby allowing for a more 'human' opponent. I think that the next step for Civ3 would be a Quake-like approach: console commands, bots, client/server, etc. If possible, make the maps bigger and with more players (Ultima on-line approach). Mind you, we may be getting a little carried away (or maybe just me) but the ideas from everyone are great.
There has been a lot of talk about PBEM and turn-based movement but I think CivNET is superior to Civ2-MGE primarily for its excellent simultaneous movement. The reason that I think this is important is because it allows for faster internet, and especially, faster network play. Many of my friends and I play primarily by these means and we are torn between the superiority of Civ2 for play and CivNET for networkability.
To begin with, I think that anything but a 'unit queue' would be killing the idea (no freezing of map squares). I realize that something like this would be network intensive but it makes for a fast, fluid, and fair game. I realize that there are some issues to be worked out with type of play but I think it is vastly superior to Civ2-MGE (and SMAC?). Most of us just decide to forego playing Civ2-MGE at all.
------------------
TitanTim
|
|
|  |
 |
|
DanS
|
 |
Kickball Capital of the World
Jan 1970 time: 00:14
|
|
Damn, lost a post...
Titan Tim: thanks for your in-depth ideas. What do you mean by "console commands"? I'm not a Quake player...
Like you, I think Civ2 MPG is unplayable in the traditional sense after a while (some games have evolved into arena, scenario, and diplomatic games to cope). Unfortunately, I haven't played CivNet, but IIRC, it did not rely on square locking. I have only heard it creates some "interesting" gameplay. Does it distort the multiplayer experience to a great degree?
In the event that BR wants to start locking squares, what would be the order of battle you would like to see? For instance, which units go first, whom do they attack, surviving units, etc. We could draw on the experiences of the board gamers and SMAC players out there.
|
|
|  |
 |
|
will
|
|
Arlington, VA, USA
Jan 1970 time: 05:14
|
|
I think the key for making PBEM work in CivIII is to allow for simultaneous turns. The current round robin system on SMAC seems to result in one turn per week, if that. Turns come so infrequently that I start forgetting to look at my PBEM account every day. When a turn does come, I miss it for a day or two.
With simultaneous turns, we wouldn't have to worry about the cycle taking so long. Each player could download the game file at leisure, process the turn, and return it to the game host. Even if the slow guy on the list takes three days, the game would move twice as quickly as the typical SMAC pbem.
It seems that simultaneous turns are practical, since CivNET and one variant of SMAC use them. The big complaint seems to be that processing time makes them impractical for live games. Since the pace of pbem is so much slower, processing time should be less of an issue.
|
|
|  |
 |
|  |
All times are GMT. The time now is 05:14. Apolyton Time is 00:14. |
top of page
|
| archivepost |
|
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
|
|
|
|
|
|