Bungholio's Deity Checklist A guide for what is involved in being a Deity. 30 January 2006 - 4pm - Written by Bungholio - empire_bungholio @ verizon.net * * * * VERY PRELIMINARY VERSION * * * * (put a table of contents here which would then double as a checklist form. Then players could just run down this checklist, and if they need further info on any item they can go to the detailed descripion below.) INTRODUCTION: This guide is some notes that I decided to jot down, then expanded on, to help myself in future game deity'ings, and for other deities. This guide was written as a list of suggested recommendations, not as a requirements document. PLANNING: Plan out the game. Planning weeks in advance of when the game should start, you should have a good idea of what kind of game it will be, as far as having the version report and map size / settings. Practice building the game. Log in, play a few updates. See if it is working out how you thought it would. Make sure you have a reliable internet connection for the game, and that the game is stable on your system. I'm using the Win Binary on a Win2k box. I am hosting my games from a spare "old" PC. It's a Celeron 366, with 384Megs of 66MHz SDRAM. It's a good idea, if using one of your old PCs as the server, to bust out a can of compressed air and make sure all the fans, vent holes, and heatsinks are clear of cobwebs and dustbunnies. My game server PC is a dedicated PC for the game server. Empire does not need a whole lot of modern day system resources. With 20 players in a 190x92 world (in PZ2), updates processed in under 3 seconds on my server system. I even put a 500VA UPS on my server system, my DSL modem, and the router to prevent small power glitches from hosing the game. Check with your ISP to be sure that hosting a server is not a violation of your TOS (Terms Of Service), although the amount of traffic that is used for empire is like nothing relative to the amount of data that a service such as Kazaa can send out (not that I'm saying that this makes it ok). Configure your firewall/routers to forward all incoming packets for the PORT that you plan to host your game on. One note I thought I'd mention, I set up my router to route all incoming 6665 packets to the server, then one day I checked in on another game using 6665 from a different computer from the server computer and then my router started routing all packets to this other computer, thus preventing players from logging into the game. Very strange. Perhaps you will be luckier? For me, I plan on picking a different PORT number than ones that other current games are using for my next game. Got an idea for a theme for several games? It could help to get some brand recognition if you can get some common name to call your game series. For example, somehow I came upon PettingZoo and sheep as my primary icons for my game. If you got a cool game series name, find some ascii art for your MOTD, or jpeg's for your game webpage, it definitely helps inspire the masses when they have a visual, as empire (for non-winace-users) is *such* a graphical game (sic) that anything helps. BACKUPS: Backups are copies of the whole "data" directory and all subdirectories and contents within. Practice making backups, and practice doing a restore from a backup from a few updates ago and verify its integrity. Practice making a mock anno saying "sorry folks, due to failure x, I had to do a rollback. The rollback occurred at 12:34 today, from the backup from 10:30 this morning, due to the short notice and the update in a few hours, tonight's update is CANCELLED", etc. You need to be ready to do a rollback at any time in the game, as stuff beyond your control will happen. When you do a rollback, say so of what you did in the annos and the MOTD. Players like to know why they have to repeat work they did, so be as informative as you can as to what happened and what steps you are taking for corrective action for next time to minimize or prevent the failure from occurring again. In PZ2, I had to do TWO rollbacks/restores. The first one because I had a double update occur early on because I adjusted the server clock with-out restarting the server. Luckily, I was on when the first update fired a few minutes before the scheduled update time. Shocked at what happened, I did a quick manual backup. Then a second update occurred at the scheduled update time. Floods of angry flashes and telegrams came in. I made a broadcast to all players that I had to do a restore to the snapshot right after the first one of these updates, and that the game will be back in about 10 minutes. I restored the data directory, did some quick checks, and made an anno saying what happened. The second mishap occurred midafternoon on a Sunday. For some crazy reason, the server PC clock jumped ahead exactly 2 years. Not knowing what would happen if I just fixed the clock with data and timestamps on things from 2 years in advance, I made the decision to do a rollback from a backup earlier that day. I disabled updates for that day, made a special MOTD to notify players of the rollback, and made a game anno. Having to do rollbacks sucks, and will always really upset at least one player 'cuz another player was able to take advantage of intelligence obtained, or someone just happened to spend all morning super optimizing their economies at the expense of an angry spouse, then to only find out that all that work was erased and the spouse is still mad. Offer your humblest appologies as best you can. Here's how I do my backups: I set up a windows scheduler with 6 different entries (for 6 backups per day) : under the 'task' tab, set one of these as the task: xcopy /I /E /Y C:\home\wolfpack\emp4\data c:\empire_backups\data-0130 xcopy /I /E /Y C:\home\wolfpack\emp4\data c:\empire_backups\data-7130 xcopy /I /E /Y C:\home\wolfpack\emp4\data c:\empire_backups\data-1230 xcopy /I /E /Y C:\home\wolfpack\emp4\data c:\empire_backups\data-1730 xcopy /I /E /Y C:\home\wolfpack\emp4\data c:\empire_backups\data-2130 xcopy /I /E /Y C:\home\wolfpack\emp4\data c:\empire_backups\data-2130 on the 'schedule' tab, set the following: schedule task >> daily Start Time >> the time for this backup schedule task daily - every >> 1 day This scheme will copy the data directory to a different timestamped backup directory 6 times a day, at the end of the day, click on the c:\empire_backups folder, highlight the data-xx30 folders, right click, and winzip them up as that day's data-todaysdate.zip file. You do this daily, and you'll have a whole game history you can quick and easily unwind incase you need to get that power report you missed capturing or need to find an old announcement weeks later. It's also not a bad idea to copy one of these backups to floppy or to another computer once a week in the event of a hard-drive crash, at least then something is salvageable. COORDINATING WITH WOLFPACK: When you think you have a decent scenario set up, and you've play tested it a bit, send an email to wolfpack to say "hey, I'm ready to run a game. Here are my game parameters and I'm thinking this will be a blitz/test/informal/minor/medium/major style game." Don't be afraid to be humble, but also be ready to expect the unexpected. (My first game, I was hoping for 6-8 players, but I only had 4 players. So my second game, I was thinking about 10-12 would be a good turnout... I got 20!) Keeping in good communications with wolfpack can only help you. Empire is a community. Our player base is somewhat limited. These guys in wolfpack are there to provide leadership for the game community. Showing them respect and your willingness to cooperate up front will be rewarded in the long run should you have server problems, questions, need a server bug fixed asap, or just having them keep you informed of any new server bugs they discover (well before they are made public even on sourceforge I might add.) Of course you are welcome to do whatever you want to do, as Empire Server is freeware. If you're just playing around with local friends, then a lot of this is probably quite excessive. MAKING THE GAME ANNOUNCEMENT: Wolfpack recommends you post your game announcement to rec.games.empire and send an email to wolfpack so they can add it to the wolfpack website. Depending on what type of game (blitz/test/informal/minor/medium/major) you plan on having effects the extent of the details you should consider including in your game announcement post. You should consider including the following details in your game posting: For just a blitz game, just a simple: HOST PORT version report update frequency & time it resets/begins For a test game, just a simple: HOST PORT version report update frequency whatever is special in your test game For an informal game, just a simple: HOST PORT version report update frequency anything special in your game deity involvement start date For a minor game (10 or less players), just: HOST PORT version report start continent size, expansion islands update frequency & time anything special in your game deity involvement start date / first update number of players you are looking for how to register or just 1/1, 2/2, 3/3, etc For a medium game (10-25 players), just: HOST PORT version report start continent size, expansion islands update frequency & time anything special in your game deity involvement start date / first update number of players you are looking for win conditions holiday schedule game webpage how to register what you will do with unbroken countries For a major game (25 or more players): HOST PORT version report start continent size, expansion islands update frequency & time anything special in your game deity involvement start date / first update number of players you are looking for win conditions holiday schedule how to register what you will do with unbroken countries game webpage info some historical information other stuff even I don't know (ask wolfpack for more help) For the "HOST", this is the IP address of your game server. Do you have a static IP or a dynamic IP address? If dynamic, how do you plan to let players know when your IP address changes? I use a dynamic IP address mapper service, at dyndns.org to map sheepfarm.game-host.org to my DSL modem's IP address, for example. For the "PORT", this is the port number that your game will use. Usually 6665 is a good default choice. For the "version report", post your best expectations of what you think the game's version report will be. Mapsize is probably a variable dependent on the number of players, but you can say something like "40x20 times the # of players" to give potential players an idea of what to expect. A 20x10 times the # of players is a small/tight map. around 40x20 per player is about mediumish. 80x40 and higher is a large scale map. These figures are based on an island continent style map (vs. an all land map). For the "start continent size, expansion islands", anything from the parameters you used for fairland to "all start continents to 75 sectors, with 10 mountains. expansion islands are available" is sufficient to let players know that there are expansion islands out there (maybe with deity mils? maybe lots of them? maybe just a few? you can't hand them a bmap, they have to risk something to find out if there is anything there to find, and maybe or maybe not it will pay off). For the "update frequency", this is how often you plan to have updates, like every 30 minutes, 15 hours, 24 hours, 32 hours, etc. or like 'the first week will be every 21 hours, then we will switch to every 28 hours for the next 2 weeks, then finally to every 42 hours'. It is *much* better to try to get the update schedule pre-defined in your game announcement so that players can then decide if they are available to play on their schedule. Changing the update schedule from your original plan will indefinitely upset several players, so to try to avoid it, overloading them upfront on too much information will only CYA. For the "anything special in your game", this is where you get to write a nice essay on what makes your game different from the plain vanilla default game. Anything from ships/planes/units got modified, to starting with tech 80, to pre-diplomacy teams will be formed, code changes you did, starting tech, and more goes here. Anything that doesn't show up in the version report and is noteworthy for the theme of this game goes here. For the "deity involvement" section, this is where you say whether the deity will be playing or not. Having the deity play is strongly discouraged, due to player suspiscion of deity cheating. If the deity *has to play*, make sure you then announce all the details of the game that the deity has had in the world creation that may help the deity's exploration. For non-playing deities, you should give them an indication of whether you will be checking in 4+ times a day to ensure the game is running smoothy or if they need to email you if a problem comes up, to your plans to posting game status to RGE and updating the game webpage often. It doesn't need to be all that wordy, you just really should make a note of it if your plan to be an unattentive deity so that the players know they need to send you an email when there are problems. For the "start date / first update", this is where you say what date you plan to have the game opened, and what date/time is the first (planned) update. For the "number of players you are looking for", this provides a guidance to the readers of your game announcement so that they get an idea of how many players to expect in your game. Do you have a minimum number? Will you size cap it at a certain size and put the rest on wait-list? For the "win conditions", this is another touchy subject you need to carefully handle. If you choose to announce it, you better plan on sticking to it. Players base their initial strategies on this if it is announced from the beginning. This is one of the toughest choices as a deity, saying you win, you win, you win, oh, you don't. Definitely the most thanklessest part of being a deity if you don't announce the plan before the game starts. Even if you announce the win conditions, be ready for the player base to rebel and turn the whole world into glass so that nobody wins, players can be that anal about it. Nobody like to lose. Again, a touchy subject. In my PZ2 game, I put the responsibility into their hands by saying the win conditions are "None. This game is a free for all. If you wish to ally with everyone then so be it, however lame and unhonorable as it may be, not that I am judgemental or anything (LOL!).." But this could backfire on you too, at least then the players should feel some shame if they cannot mutually agree upon a reasonable endgame condition. For the "holiday schedule", this is where you need to grab an international calendar and see if there are any major holidays coming up during the time that you expect the game to run. If there are any holidays during your game time (games *typically* last 25-40 updates) pre-decide what you want to do about them and put it in your announcement. It is much easier to just post this kind of info before the game starts than to have to try to host a 'game vote' and remind players to vote, then compile the votes, and post the results (trust me). Especially if the holiday occurs after the first 2-3 weeks, players will enjoy the few days of rest. You'll need to decide if you will just disable updates or totally shut down the server during the holiday. Or if you are planning a weekend getaway during the game, just post it here, maybe then the players can say hey, that would work out great so the wife and I can go visit aunt Gertrude that weekend and go to the quilting museum! You get the point. The more info upfront, the better. For the "how to register" section, either players email the deity with their login info so that you can build the world, or they just claim an unclaimed country in the world via the 1/1, 2/2, 3/3, etc logins. If the players are to register via email, provide them the deity email address and ask them to submit emails with subject 'empire game registration' (or similar), the following: player's RL (first, maybe last too) name, country name, password, skill level, email, favorite beer, etc. For the "what you will do with unbroken countries" section, this is where you need to pre-decide what is best for the game. Should you delay the first update to wait for those slackers to maybe come and break the next day? Set a cut-off time for players to break and set-up by, and if they don't by like 6-hours prior to the first scheduled update, you will give those players to someone on the replacements players list? Maybe the deity should "run" (not play) those countries for the first 2-4 updates while the deity actively looks for a replacement on RGE for those countries, then sinks them or neuters them into equivalent expansion islands if no replacement is found. For the "game webpage info", this can be a total time sink. Having a nice webpage with easy to access info, pics, graphs, midi music, etc can help enormously! But you can spend hours making these webpages. At least it's constructive. For the "some historical information" section, maybe if your game is based on a major world event, or has something of RL that is of interest, then this would help your cause for what makes your game extra special to have 25+ players. For the "other stuff even I don't know (ask wolfpack)" section, consult wolfpack, as this is beyond my scope of capibilities (at this time). (wholy crap this is a lot of info... 3 hours of brain dump so far... and I'm only up to the game anno.....) Run your game in blitz mode to allow a few players to stress test it! ** setting up the server: edit econfig run files empire POGO peter verify version change deity country and password qu empire Mapper password exec Msetup.txt map * repo * orig x,y (for deity 0) map * qu empire Bungholio password exec Bsetup.txt edit countries to set country names and passwords map * repo * cou * allow logins using turn command disable updates make anno send emails files change Bungholio add Mapper add visitor login as Mapper run islands script run players script seteff forts give guns/shells motd check things out announce it & email it Send emails to players enable updates making the motd (turn motd, etc) do backups capture data, power and report *, and maybe "cen * ?des#. >> census_for_mapping_file__update#.txt" for making maps later. NOTES ON HELPING PLAYERS: In an ideal world, all players should come to the game prepared to play and be knowledgable in how to play. There are two main types of Deity helping. The first is answering questions and giving guidance, and the second is actually modifying the game database by giving or modifying things. Providing answers to basic questions of players, especially new players, is generally acceptable (and somewhat encouraged to a certain extent). But don't let the newbies use you as their personal info-wiki. Point them to the info pages, and teach them the 'apropos' command. But under no circumstances ever provide game specific information, such as where the free land is, who is to my east, who is playing under country name 'alias', what tech level is somebody at, etc. If somebody asks these kinds of questions, tell them that asking for this kind of info is unacceptable, if they persist, take action. Giving players things or modifying things, on the other hand is generally frowned upon, as other players in the game may see it as deity cheating. Unless the game is a training game, an informal game, or the game is within the first 1-3 updates and a no-show player needs to be replaced with a substitute immediately, then you have to let that player's game run its course as is, and chalk it up as a lesson learned. And under no circumstances ever help out a country once another player has found it, as that country that has found it has probably already committed resources in that direction (this is why no-shows only get replaced during the first 4 updates or less, depending on world size). If you do decide that you must interfere with the world and modify anything, be very public about what you did and why, such as "At update #2, country #6 who was a no-show was replaced. I adjusted his civs for standard growth and gave him some commodities to get him in-line with the average of the world.". WHAT TO DO WHEN (not 'IF') THERE ARE PROBLEMS When there are game problems, things can go sour fast. Being prepared and having a course of action will help. Problems can range from the minor such as a minor bug, to something medium like an unplanned server outage, to the severe such as a total game database corruption requiring a roll-back. For minor bugs, sometimes it is just a matter of changing to a patched version of the game (either by fixing and recompiling yourself or by getting a binary from someone). I usually take a database snapshot of the current game over to a shadow server, and verify that things look correct and a forced update processes correctly with the new binary before going live with it. Sometimes players may feel they were the victim of a bug or from cheating. This is where things can get sensitive, as you will need to keep in mind the information that may need to be exchanged between yourself (all knowing) and one or more countries in the game. You can't just blurt out that someone's carrier was sunk by the fleet of 9 subs that were in sector 20,12, you got to be more discreet with the information (assuming you can even recreate the scenario to begin with, as many players with advanced clients auto-delete their telegrams upon being read, this is where taking lots of backup snapshots helps, you might catch some interim points in the battle setup). In the cases when the game is down, try to keep the players informed, so keep an off-site copy of all the players' email addresses so that you can email everyone (as BCC:) the status and/or post to RGE what's happening. It is really tough to send an email to all players when a car took down a utility pole down the street and you have no electricity (this happened to me!), luckily I had everyone's email addresses ready for such an event, and managed to send a quick 2-3 sentence email off in the 10 minutes before the UPS died. There are also times when the server in unaccessable due to human fault, one game several years ago suffered an afternoon outage because the deity's mom unplugged the router so that she could plug in the vacuum. Try to determine what was the cause of the crash. Who was online? What were they doing? Did the game crash or is there a problem with the ISP or host computer? Sometimes the server huccups and things continue on just fine. Sometimes there is some data corruption and things get progressively worse, usually requiring a roll-back or some quick advanced server coding to ignore the invalid data. There are times when it is better to shutdown the game for a few days while you investigate, versus possibly allowing players to obtain information they might not normally get if the game was working normally, either thru bugs that are suddenly giving out too much information to players using up their entire airforce / navy on suicide missions to gain information knowing that it will all be rolled-back (these players should then be penalized upon the restore if it appears it was intentional and excessive other than a few accidental overflights, navings, etc.) Empire is an intense game. Players put 100's of hours into a full length game. The better reliability/security you can put into their time investment the better. And when things go wrong with the game, it never fails that at least one country (if not several) get hosed by either a missed update, the game hangs in the middle of an invasion, a roll-back and thus a surprise invasion is no longer a suprise, etc. Send your appologies, and try to show that you've taken a course of corrective action to prevent this from occurring again will help. Run thru a couple of practice runs of the above scenario's, so that when you are in the hot seat, you have at least the experience of the exercise under your belt. making game status reports making game summary reports