View source for How to Host a Game v2.0 by Omonubi

How to Host a Game, v2.0

Author: Omonubi


I have had several people ask me certain specifics regarding hosting, handling of file, etc., so, after some prompting from a visitor to my web-site, I decided to author a page on the ins-and-outs of hosting a game, offering what little knowledge and insight I might have into this arduous task.


This new version simply contains some more information on troubleshooting problems you may encounter while hosting a game. 


Currently, Stars! seems to be in a state of high demand for hosts, as there are many new players looking for just about any game to join, thanks mainly to the release of version 2.7 in stores everywhere by Empire Interactive (tm.) This means that just about anything a host can concieve of will fly.

The first thing any prospective host must do is to develop the concept of the game. This means deciding on how many players, the universe size, game parameters, victory conditions, and other details. Let's look at these individually. We are, of course, referring to choices made in the Advanced Game Wizard.


Game Name -

A good name is not a necessity, but can add a serious touch of flavor to the overall appeal and feel of the game. At places where there are many games posted at once, having a good name is like having a good advertisement. Be imaginative.


Universe Size - 

Controls the length of the game.

How long do you expect this game to last? Hosting can become addictive, and you may starts with one game, and then add another and another and....

This can wind up overtaxing your spare time (boy, don't I know this). For you, the host, this is the single most important descision you have to make.

Also, the size of the game is going to dictate the number of players (usually), which, in turn, is a direct indication of the amount of e-mail and player problems you are going to have to deal with. The more players, the more likely the game will be postponed due to corrupted files and other technical problems.

For short games: Choose a Small or Medium sized universe. These games are usually over within 100 turns.

For long games: Choose a Large or Huge sized universe. Remember that a Large size fits 12 players comfortably, and a Huge one, 16. These games, especially Huge, can run for hundreds of game years, depending on the players' abilities.

Tiny Universe: This is perhaps the ideal environment for "tooth-and-nail" game play, seperating the men from the boys. Games are quick and defeats are lethal.


Density -

Controls the length of the game.

This controls the number of usable worlds within the game. Game length is also altered by what is choosen here. The more worlds available to players, the more resources and minerals exist for use during the game, extending the lives of your players, production-wise.

Also, this factor controls strategic planning to a greater extent because the density of usable worlds also controls the positioning of starbases from which players organize their infrastructure.


Player Positions - 

Controls the length of the game.

The closer players start the game in relation to one another, the quicker the slaughter will ensue, though this is not always the case. Stars! players tend to be a little paranoid about these things, especially at the start of the game. Move the positions farther out, and the game's life will be extended.


Beginner: Maximum Minerals - 

Controls the length of the game.

This makes every world in the game start with maximum mineral concentrations, extending the game. If players don't have to worry about running out of minerals too soon, they will build their empire and remain relatively comfortable, unless provoked by another player. 

Note: A lot of players DO NOT like this parameter, being that it is pretty unrealistic.


Slower Tech Advances - 

Controls the length of the game.

This choice doubles the amount of resources necessary to achieve new technology. It gives players more time to utilize their existing technology before new tech. comes along. This usually means that players will build more ships of any particular class, creating delimmas when their "slots" are full (16 designs).

For Beginners: Due to the advanced planning of ship designs (what to build, when to build, how many), a host may not want to use this if designing a game for exclusively beginning level players.


Accelerated BBS - 

Controls the length of the game and STRONGLY recommended.

This feature advances the game by "advancing" the start time. Although the game will still start in the year 2400, all players will have built-up some minerals and population with this option. This speeds up the time taken to actually build your first vessels and to make contact with other players.

Most players prefer this option.


No Random Events - 

Evens the flow of the game.

This choice eliminates hidden mineral concentrations, the Mystery Trader, meteor impacts, and left-over tech. artifacts. If you want all players to be on an even par thoughout the game, this is the item to choose.

For pre-genned games: If you plan to start the game later in the timeline, be warned about the possibility of a meteor hitting a player's homeworld prior to game start. If this happens, you should immediately re-start the game.


Computer Players Form Alliances - 

For Advanced players only.

Computer players will only attack human players, not other AIs. The effectiveness of this parameter is decided by the number of computer AIs in the game. If you only have one or two, this will not make much of a difference in the game. However, with three or more AIs against Advanced level players, this parameter should deffinately be choosen, since Advanced players already know how to beat the AIs hands-down.


Public Player Scores - 

Alters game strategy.

If players know who is ahead in the game, they are more likely to immediately ally in order to stop the lead player. This leads to very interesting game play, revolving around alliances and back-stabbing.

Not having this option forces players to construct large information gathering infrastructures, in order to ascertain the strengths of their opponents.


Galaxy Clumping - 

Alters game playing strategy.

The clumping of planets switches the focus of the game over from controlling individual worlds, to controlling entire star clusters. This is more realistic.

However: Many players dislike the fact that planet names have a tendancy to print on top of other names, making it a real pain to quickly locate particular worlds.


Choosing the number of players -

You are allowed to place up to 16 players in any Stars! game, but you should carefully compare the universe size with playability and time frame.

Generally, a good set of guidelines:

Tiny - 2 players

Small - 3 players

Medium - 7 players

Large - 12 players

Huge - 16 players

Of course, by placing more players than the above guidelines, contact will happen more quickly, shortening the game.


VICTORY CONDITIONS


In choosing the victory conditions, a host has to consider what type of game he is proposing. Does that game require special victory conditions outside of the scope of the Game Wizard? If so, are regular victory conditions necessary?

If you do opt for regualar victory conditions, will the game be angled towards an offensive victory or a defensive one? Read on:


Owns "X"% of planets (Offensive strategy) -

Be carefull how high you put this. Players with restricted habitability ranges will, generally, not be able to own more than 50% of all possible worlds.

For the HE: Hyper-expansion will always have the advantage in a game with this victory condition. Perhaps this is one reason why HE is banned from most games.


Attain Tech "X" in "Y" fields (Balanced strategy) - 

Because tech-level acuisition goes hand in hand with resources, players desiring to meet this condition will angle their race towards more efficient tech production, as well as be encouraged to increase their size in order to harness more resources.


Exceed a score of "X" (Balanced strategy) - 

Once again, resources are the deciding factor here, forcing a combination of good production efficiency and terrotory acquisition out of the players. "Hyper-producing" races may run amok in a game like this, scaring the hell out of other players, and causing an early war or two.

Players could also win via this condition by manipulating other factors which can effect score, unlike the other victory condition two listings down.

Additionally, as with any "total" type requirment, a host should be carefull not to place unreal goals on a game that can not fullfil them. Having a higher score as a requirement to win in a small universe may be unatainable altogether.


Exceed the next player's score by "X"% (Offensive strategy - 

This is perhaps the most popular victory condition, as it forces players to eliminate any opposition. This will create many alliances and politic-ing as lesser empires try to get an edge and chop down the leading players.


Has a production capacity of "X" thousand (Balanced strategy) - 

This is very similar to the score requirement above, but it relys totally on the production of resources. Players will shoot for high production efficiency and conquest of worlds.


Owns "X" capital ships (Defensive startegy) - 

This really lends itself to keeping out of trouble for the player. Even though one can build capital ships, it is another thing to keep them intact in order to win the game.

Also, because of the long time necessary in order to achieve the technology to build these ships, games will run a long time.


Have the highest score after "X" years - 

Consider this carefully.

This is a bonus category which a player can score if they have the highest score any time after the year specified. This parameter should not be used in conjunction with the "Exceed next highest score by "X"%", since it already indicates that the player holding this category is ahead in the game. Because this is a relatively easy category to win, be sure to give other players a chance to win after one player wins this category. It should be used as an incentive to build quickly, but it should not decide the entire chances of victory.


Winners must meet "X" of the above selected criteria - 

Selecting this will give players more than one way to win, if you set "X" to less than the number of selectied categories. This will provide more ways to win and lead to interesting strategies that will effect one another as the game progresses. 

Making players meet the same set of conditions will lead to either a production game, with wars intermittent, or to a conquest game, with rampant death and destruction.

Note: It is never wise to select virtually all conditions with every condition needing to be met. This will lead to a game where, once one player firmly establishes a lead, many players will probably cede victory without further play.


At least "X" years must pass before a winner is declared - 

Simply put, how long do you want the game to go? Remember, one year in the game is usually equivelent to one turn played per day. Selecting 500 years means that the game will last at least 500 days of real time (more likely two full years).

Since you are the one running the game and doing all the work, be sure to choose a time frame that you can live with.


GENERATION TIMES


Before continuing in this process, a host must also decide upon the period in which turns are due. This is VERY improtant. How often do you plan on generating game turns? This is up to you, but most players enjoy a daily game.

You should choose a deadline for the submission of new turns based on your personal availability. When are you home? When can you get on-line? How often do YOU want to download the files, do your turn (if you are playing), gen the turns, and mail them out. How long will this process take each time?

It is vital that you plan out this potion of the game concept before signing up players. Players will want to know their deadlines ahead of time.

After you set up the deadline in your head, will you be able to process and send the turns back out in a timely manner? I generally allow three hours after the deadline within which to process the game and mail new turns out. This gives players a reasonable amount of time to do their own turns and get them back in (don't forget about internet delay).

If you will not be able to keep to this schedual - do not host a game. Nothing is quite so dissapointing as looking foward to recieving your turn and finding out that the host hasn't genned yet.

Once you have fleshed out all the parameters and victory conditions, and decided upon turn deadlines, you must post the game some place for players to see. Otherwise, it will be very hard to get new players.

Where to post: I personally recommend either this website (of course) or the Stars!Depot, which can be accessed from this site. Stars!Depot provides a place to post your game and they mail out a list of new games, weekly, via their huge mailing list. Sign up here and you will probably have far more players than you need. Of course, there are other web-sites that offer this service. Feel free to explore these other options.

Be sure to include some background. When posting your game, be sure to include all the information that you developed in the above process, including turn deadlines and rate of play. Also, you may want to add a brief description of the game, including special victory conditions, team setup details etc. (and don't forget your e-mail address).

If you plan to play in the game, state this. Many players prefer to know if the host is in the game and any special conditions that may go with this status. Try not to surprise your players this way.

Decide upon the method of file submission. This will be gone into detail later, but, once you know what types of encoding you want to deal with, post this information for players to see before they decide to sign up.

Have players submit their race files without password protection. This allows you some breathing room and it is highly recommended. First, if there are preconditions for your players (No HE, must choose a certain SRT, etc.) you can screen your players to make sure everything fits the game requirements. Also, some players never come back to start the game once it has started, and having the file unprotected makes it very easy to give control of the vacant slot to another player.


All this said, once posted, you will begin to sign up players.


SIGNING UP PLAYERS


This can be a fairly easy task, provided you organize everything.

Player requests to play / sends file: Immediately screen their race file to be sure it meets your pre-conditions. Then give them a position and a number for that position. This number should be the same number they will have in the upcoming game. Return their e-mail immediately explaining that they are in your game and what their number is. Place their race file in a sub-directory (which will identify the game) within Stars! and set the "r" number of the race file to the number you assigned that player (i.e., "game.r5" for player #5).

Keep a complete list of all current players and their positions at all times throughout the game. 

This type of organization is vital to keeping the game continuously on track. Without it, you WILL have some big problems should anything go awry.

Player requests to play / no file: Sign the player up as above, but put them down as having sent no file, and please ask them to send is ASAP. Once you get their race file, download it into the game directory and change the "r" number as described above.

Player requests to play / sends file but with a password: Your choice to simply accept this player as is, is up to you, but it is recommended that their file be password free. Some players get really nervous when others can see their "secrets to success". Do you want to take a chance on trusting these players to meet your pre-conditions?

In a case like this, sign them up, but request either the password, or a password-free race file and put them down as needing verification. If they refuse to comply, simply delete them from the roster and get another player. It IS your game, after all.

Player requests to play / game is full: This is common. You should take the first four players that ask to play, after you have filled all positions, and put them down as alternates. If a player should drop before the game begins, you can then sign up one of these alternates immediately, instead of having to hunt for a replacement. If a player drops as soon as you start the game, these players may still be willing to take over another player's race in order to play.

Player requests to play / trouble sending files: This is a real delimma since file transfer problems are nobody's fault. However, do you want to hold a game up for days, sometimes weeks, hoping that one player will be able to figure out the problem? If you can not resolve their problem within two days, it might be best to inform them that you will have to find another player.

A solution to this problem revolves around different submission methods, which are detailed later on in this document.


STARTING THE GAME


Once you have all the positions filled, and all the race files labelled correctly, move on to setting up the game.

Game location: You should place each game that you host within a different sub-directory inside of the Stars! directory. This will aid in your organization. When you create the game and save to your hard-drive, be sure to save it in the correct sub-directory.

Game set-up: Be absolutely sure that you set up the game, via the Game Wizard, exactly as you posted it, and don't forget to name the game. When you save it, consider an abbreviation for the file name, since you will be typing this name a whole lot of times.

Example: "Invasion of Your Privacy" = inv.xy

Should you decide on a minor alteration from the original post, be sure to make players aware of this.

File jargon: Once you have created the game, Stars! will create a game file (.xy file), a player file (.m file) for each player, and, if you have computer AIs, some history files (.h files).

The .xy file contains all the information regarding your specific game, including victory conditions. You will mail each player this file once, at the start of the game.

The .m file contains data for each player which they will use to play their turns. You will send this file to every player after every generation, including at the start of the game.

The .h file is a record of each player's past history, including score and scouted worlds. 

The .x file is the player's log file which will be created each time a player submits his/her turn. Each player will mail you this file each turn.

Sending the initial turn: When you send out the first turn, you will want to include a copy of any postings you made for the game, in order to put in writing the game set-up for all players. (Some players forget what it was they signed up for, or they didn't read the entire post the first time).

Restate turn deadlines and file submission methods that are acceptable.

Be sure to offer any hesitant players an out at this time. It is far better to have them quit now (while you have their unprotected file), rather than after they have protected their file.

Unless you deem otherwise, encourage players to password protect their files.

Explain to all players how the files are sent and returned. You will send the .xy file and .m file to each player, they will play their turn and then return their .x file to you. TELL THEM NOT TO DELETE ANY FILES FOR THIS GAME. I have had players in the past delete their .xy file after they played their first turn. They must have this file in order to continue playing.

Finally, attach their game.xy-file and their individual game.m-file. You should usually send these seperately. As stated above, you should have planned ahead of time for the type of file transmission(s) you will use, and what are acceptable from players. I use MIME and FTP upload/download for all my files. See the section of file encoding, below.

Downloading the first turn: Once you send the first turn out, players will begin to return their .x files to you. Download these files into the game sub-directory. When you are ready to generate the turn (after the deadline - never before), open the host program and select "Generate Now". Stars! will then process all of the .x files and create a new set of .m files for you to mail.

On the first turn, you may want to wait until you have heard back from all of the players in your game. This will help detect any technical problems that may develop before the game gets under full swing. If a particular player does not respond for more than 48 hours, feel free to replace that player with an alternate.

Continuing the game: From this point on, the game continues as a series of out-going .m-files and incoming .x-files. As long as you develop no technical difficulties, the game should always proceed on time and with very little delay. Players who are chronically late through their own fault should not hold up the game. Be firm on this point. You have many other players who are on time and ready to go.


FILE ENCRYPTION METHODS


This is probably the most confusing and overwhelming part of hosting a game. Unless you spend alot of time doing file transfers, your knowledge in this area is probably pretty limited.

File encryption is how files are processed to be sent over the internet and recieved at the other end. There are several widely accepted methods, and your choice to pick one or the other is simply based on what you prefer.

Currently, MIME, binhex, and UUencode are the three standard methods for attaching files to e-mail. You may have to obtain an encoding/decoding program in order to deal with some or all of these types. Specifics on how to handle this process vary so much that it is impossible to offer any help in this area. Consult your local ISP or a friend who knows.

Files can also be uploaded via FTP and WWW link, but you must have access to these features before you can use them. Again, ask you local ISP how to go about this.


The bottom line, as a host, is to choose a method (or combo) that is easiest for you to handle on a daily basis, since you will be encoding and decoding quite a bit. AOL has excellent automatic MIME encryption capabilities, along with FTP and WWW access, free of charge.


COMMON PROBLEMS


Now that your game is running, what if you experience difficulties? Forget "what if" - you ARE going to experience difficulties. I will try to list all I can think of here, but I am sure there are many things I haven't encountered yet.


Never give out other players' e-mail. This will kill a game as certainly as a power outage. Some people do not like having their e-mail address passed around (like a phone number), and this is the surest way to get them very angry at you. If one of your player's requests someone else's address, tell them to ask that player directly via the Stars! message box.


Player is downright rude: Some players seem to think that a host is some kind of computer slave, that has to bend to the will of the player. Remember, you provide a FREE service to other players. What you do is up to you. If they really have a problem with something you decide, that's their problem, right?


Consider all options before scrapping a game: Any number of things could happen to a game at any point, leading you to conclude that it might be better to just start over. Many players will simply drop from your game if you do so. This is because they may have signed up for other games since joining yours and they feel they are getting pretty overloaded. While most players will not drop from an active game because of this, they WILL drop if you offer to restart in order to get out of a game to play in these other games.


Player drops out - what to do? If (when) a player drops from your game, you must consider two things.

1. Is this player worth replacing? Players will usually quit once they are done in. Finding a new player to take over last place may be difficult.

2. If so, can I replace him? If there is no password on the player's file simply look for an alternate, or take one off your alternate list for this game. 

If the player's file is password protected you can not hand it over to another player - period. You have 2 solutions to this problem.

1. Bug the old player for his password. If this does not work:

2. Place the race on Computer Housekeeping. While this is not desirable, it at least makes it look like the player is still in the game.

DO NOT let other players know that a player has dropped and has not been replaced. If you do, they may "dismember" computer run substitute in order to gain new worlds.


Player misses a turn: This is no big deal. Simply generate without him/her.


Player misses several turns in a row: Alert this player that you are not receiving his/her turns. This may be a technical problem. If he does not respond, mail him again telling him that you will have to replace him if he does not comply - ask for his password if you need it. If this fails, simply turn his race over to computer housekeeping. Don't tell other players you have done this.


Player receives their turn corrupted: Once they alert you to the problem, resend their turn as soon as you can. If they can get their .x-file back to you before the deadline, then the problem is solved.

If you do not get their .x file back, you should hold the game for one full day until you do. This was not their fault and they should not be penalized for it.


Player opens file and receives stream overflow error: This is typically happens when a player has not been playing for a while and their race was not placed on computer housekeeping. To fix this, place them on computer housekeeping for the next generation, and the mail them their .m-file. This will return the file to a nominal size.


Host receives a player's turn corrupted: If, when you gen the turn, you are told by Stars! that a particular file is corrupt, you will have to hold the game until you can solve the problem. Have the player in question delete their .x file and redo their turn from scratch, then send it. This should solve this problem. 

If it doesn't, you will have to generate the turn with their race on computer housekeeping for just that turn, then send them a new .m file.

Sometimes, a "stream error" will be generated by a particular player's .x-file during the actual generation process. In my experience, I have never had any player complain as to the results from such an episode. Ignore it. Otherwise, in order to re-gen, you will have to pull out the back-up directory and move a bunch of files around.


As host playing in a game, NEVER exploit a weakness: The fastest way to get players not to trust you is to exploit a weekness only you have knowledge of. If a player is apparently not playing any more, don't send your fleets in to carve up his empire to your advantage. If an enemy leaves their file unprotected, do not examine it. These actions will quickly give you a bad reputation.


Never miss a turn: As a host, people will be depending on you to keep the game running, and bailing out to "go out to the bar" without explanation is simply just bad form. If you are not going to be able to generate game turns for a day (or however long), let your players know before hand. 

The same goes for technical problems. If you do not generate due to corrupted files (or whatever), tell the remaining players what the problem is and let them know that the game is on delay. This will save you from having to read a bunch of frivolous e-mail.


Upgrading to a new version: Stars! is constantly in a process of renewel and improvement, with a new patch coming out every 3 months or so. These patch files are designed to upgrade your copy of Stars! to remove bugs in the program and to make minor changes in game mechanics.

Generally, a patch will not function with previous versions of the game. As of this writing, the current version of Stars! is 2.6/7f. Any previous version of the game is not compatible with the "f" version.

These patches can be found at many Stars! website, including this one. Be sure to keep on the latest patch update, as many of your players will.

When a new patch becomes available, do two things:

1. WAIT at least 3 days before announcing to your players your intention to upgrade. This gives you time to discover any bugs in the new patch. If they exists, you will hear about it.

2. Once you have decided to upgrade, refer to the "read.me" file that comes with the patch as to exactly how to upgrade, and the order of the upgrade. Then pick a date for the upgrade and inform all of your players.


Netscape Navigator (tm): Apparently, many players seem to have problems sending MIME encrypted files with Netscape Navigator (tm). I advise my players to acquire another mail program, such as Pegasus Mail (tm), or to use an FTP. However, there is information out there on how to solve these encryption problems, without having to change one's mail program.


Re-generating a turn: DO NOT do this if you have already sent players their turns for the day. Many players may decide to drop if you offer to re-gen the turn after sending the files (due to technical problems), as this means that some players will re-do their turns in order to "change history".

If you do decide to re-gen, pull out the "backup" directory from your game directory, and make sure that you move ALL of the .h-files, .x-files, and the .xy file from the original game directory into the backup. Then delete the original game directory and re-name the backup. Easy.


Players are reporting copy-protection violations: This will happen if you re-name an .m-file as an .x-file. Believe me, it can happen. Sometimes, a tired player may send you their .m-file instead of their .x-file, but name it as their .x-file (common on an FTP). If this happens, the only way to fix it is to either re-gen the turn (unadvised - see above), or continue with the game.

This may be hard on the affected player, but it was their fault in the first place, and there is really nothing you can do about it.


I'm sure there are other problems you may encounter. If you have something you would like to add to this document, let me know. I'd love to hear from you.

omonubi@aol.com, or omonubi@earthlink.net


[editors notes] 

There is a small bug in stars which causes non-even HW distrabution in game where starting positions are set to something other than distant. Thus it is advised that hosts use only distant starting positions for all games thats they host.
[[Category: Articles]] [[Category: Hosting]] [[Category: Game Setup]] [[Category: Articles by Omonubi]] {{SFAQ}}