Documentation for Almonaster Build 621.3

Max Attar Feingold

Table of contents:

• 1.0 Introduction
  • 1.1 The basic objective
  • 1.2 The basic rules
  • 1.3 The basic strategies
• 2.0 The System Interface
  • 2.1 The Login screen
  • 2.2 The New Empire screen
  • 2.3 The Active Game List
  • 2.4 The Open Game List
  • 2.5 The System Game List
    • 2.5.1 Game class options
    • 2.5.2 How game class options affect game play
    • 2.5.3 How resources are assigned to planets
  • 2.6 The Profile Viewer
  • 2.7 The Profile Editor
    • 2.7.1 Empire Associations
  • 2.8 The Top Lists
    • 2.8.1 Classic Score
    • 2.8.2 Almonaster Score
    • 2.8.3 Bridier Score
  • 2.9 The Chatroom
  • 2.10 Exit
  • 2.11 Spectator Games
  • 2.12 Tournaments
  • 2.13 Latest Games
  • 2.14 Latest Nukes
  • 2.15 Personal GameClasses
  • 2.16 Personal Tournaments
  • 2.17 Server News
  • 2.18 Server Information
  • 2.19 Documentation
  • 2.20 Contributions
  • 2.21 Credits
  • 2.22 TOS
  • 2.23 Privileges
  • 2.24 Empire autologon
  • 2.25 Advanced Options
• 3.0 Game Play
  • 3.1 The Info screen
    • 3.1.1 Next Ratios
    • 3.1.2 Technological levels
    • 3.1.3 Ship types
    • 3.1.4 Ship costs
  • 3.2 The Options screen
  • 3.3 The Map screen
  • 3.4 The Planets screen
  • 3.5 The Diplomacy screen
    • 3.5.1 Diplomatic levels
  • 3.6 The Ships screen
    • 3.6.1 Fleets
    • 3.6.2 Color coding
  • 3.7 The Build screen
  • 3.8 The Tech screen
  • 3.9 The Quit button
  • 3.10 The Exit button
  • 3.11 Ruins
  • 3.12 Surrenders
  • 3.13 Randomization
  • 3.14 Independence
  • 3.15 Etiquette
  • 3.16 Web Browser Compatibility
• 4.0 Advanced Topics
  • 4.1 Ship combat
  • 4.1.1 Ship combat details
  • 4.2 Overbuilding
  • 4.3 The Pop Trick
  • 4.4 Custom GETs
  • 4.5 Security
    • 4.5.1 HTML Filtering
    • 4.5.2 Session Ids
    • 4.5.3 Password hashing
    • 4.5.4 Game entry filtering
    • 4.5.6 In-game message filtering
  • 4.6 Tournaments
• 5.0 Administration
  • 5.1 The Server Administrator screen
  • 5.2 The Empire Administrator screen
  • 5.3 The Game Administrator screen
  • 5.4 The Theme Administrator screen
  • 5.5 The Tournament Administrator screen
  • 5.6 Setting up the server
  • 5.7 The Almonaster database
  • 5.8 Maintaining the server
  • 5.9 The admin page source
  • 5.10 Compilation
    • 5.10.1 Compilation options
    • 5.10.2 The Win32 version
  • 5.11 Client requirements
  • 5.12 Server requirements
  • 5.13 System architecture overview
  • 5.14 Graphics
    • 5.14.1 Buttons

1.0 Introduction

Almonaster is a turn-based multi-player war game that runs on the World Wide Web using form submissions as user input. No downloads, JScript, Java or ActiveX controls are required. If you are reading this page and your browser can post forms, then you can play.

Almonaster was inspired by a long line of strategy games, particularly T&E Software's Daiva series, which were programmed for the MSX2 computer. If you have an MSX2 emulator, you can run the 1986 game Daiva story V, which was way ahead of its time.

The design of Almonaster was also heavily influenced by the popular online game Stellar Crisis, and the look and feel of Almonaster has been designed to be familiar and usable by those who are familiar with Stellar Crisis 2.8x. Stellar Crisis resources that may be useful for a better understanding of Almonaster culture and gameplay include:

• Yahoo's Stellar Crisis Club
• Al Camp's Stellar Crisis Room
• The original Stellar Crisis FAQ, maintained by Al Camp
• Erick Beck's Faces of Stellar Crisis and Guide to Stellar Crisis Etiquette

No source code from Stellar Crisis or from any other program was used create Almonaster. The graphical elements common to both games are either in the public domain or permission was obtained from the authors to make use of them. Many of the fundamental elements of Almonaster can be found in classic war games such as Risk or Stellar Conquest. Others, such as the ship types and attributes, are attributable to Sylvan Clebsch's Stellar Crisis. It is not the intention of the authors of Almonaster to portray these ideas as their own.

Almonaster is free software, released under the GNU Public License. In addition to the privileges and restrictions imposed by the GPL, there are two additional clauses that apply to the use of Almonaster and any derivative works:

• The game must always be free for users to play. No fees may be charged for any form of gameplay.
• The game may not suffer from the addition of commercials of any type during gameplay.

If a server is found to be violating these principles, please notify the current maintainer of the matter.

The following are responsible for the existence of Almonaster:

• Max Attar Feingold: design, programming and user interface
• Jens Klavsen: graphics, icons, user interface, bug reports
• Tim Rowles: testing, hosting and bug reports
• Bryan Bush: hosting and testing of the early versions
• Peter Bortas: script code contribution
• Ken Eppstein, Ron Kinion, Chris John, Michel Lemieux, Simon Gillbee, Ella Elman, Haavard Fledsberg: icons
• Jerome Zago, Aleksandr Sidorenko, Clinton Carr, many others: ideas

1.1 The basic objective

Almonaster is a game of strategy played on a galactic scale, in which multiple empires vie for the control of a set of planetary systems.

The objective of an Almonaster game is to develop a small planetary civilization into a galactic empire, overcoming enemy aliens and creating powerful coalitions with friendly races. There is no artificial intelligence built into Almonaster (yet): every empire that one might encounter belongs to another player logged in somewhere on the Internet. An Almonaster game ends when there are no more enemies left in the galaxy: either one empire remains, or those who remain are all in a state of alliance. Empires are eliminated by destroying their home world with a ship or fleet of ships.

However, Almonaster is more than a simple war game. It allows the establishment of diplomatic relationships with other empires, ranging from all-out war to resource-sharing alliances. Different players have different means of achieving the goal of supreme domination of the universe: some prefer to establish multiple liaisons and use teamwork to defeat their opponents, while others opt for more individualistic approaches. There are game types that allow and encourage alliances and others that force empires to survive on their own. The primary virtue of Almonaster gameplay is that there is a great diversity of roles, strategies and options to explore, so no two games are ever alike.

1.2 The basic rules

An Almonaster game is assigned a predetermined amount of time that serves as an interval between turns or "updates." When an update is executed by the server, the orders entered by a player on behalf of his empire are processed. These orders include such actions as building or moving ships, executing special actions such as colonizing a planet, nuking a planet, terraforming a planet or changing diplomatic status with another empire.

Almonaster games take place on a map of planets, which can be thought of in computer science terms as a connected graph. Each planet is a node in the graph and each link between planets a connection between one node and another. Links between planets indicate paths along which ships can travel. A ship can stand by, move from one planet to another or perform one special action per update. There are several different types of ships, each of which can perform a different type of special action. For example, science ships can explore along previously uncovered links; colony ships can colonize unclaimed planets; minefields are immobile ships that explode, taking all ships with them; etc. All mobile ships can nuke, which is the action that returns colonized planets to unclaimed status, as well as reducing their resource levels. All Almonaster ship types are discussed in section 3.1.3.

Each empire begins with the ownership of one planet, which is called a "homeworld". The links off the home world will usually be unexplored at the beginning of the game, so the first action of an empire in any game will be to construct science ships and begin exploring the galaxy. When ships from different empires meet for the first time, combat will occur and the empires will be inserted into each other's "diplomacy" screens, allowing them to establish different diplomatic levels: war, truce, trade or alliance.

Ship combat resolution in Almonaster is rather complex. A simple formulation is as follows: ships fight until the greater force has eliminated the lesser force. (Note that there are some advanced scenarios where this might not be the case, but the vast majority of combat situations are resolved with only a single side surviving.) Ships belonging to empires at truce or better with one another will fight as a unit against a common foe. There is no random element in ship combat resolution, with the exception of the order in which ships are considered for destruction. A more detailed discussion of ship combat can be found in section 4.1 and section 4.1.1.

The economic aspect of Almonaster is also important. Each planet possesses three different resource parameters: agriculture, fuel and minerals. The first allows population to increase on a planet and exploit the other two, which allow empires to build and repair ships. Agriculture is pooled among all planets colonized by an empire, so planets with great agricultural resources but small amounts of minerals or fuel are still very valuable. Ships can only be built on planets that have reached a high population level, so it is important to colonize planets with agriculture early in a game in allow to grow the populations of planets located near the front where battles will occur and ships will be needed.

A further aspect of the game is technological development. An empire develops a certain technological level based upon the amount of resources (fuel and minerals) that it has and the amount that it does not consume each update in the building and maintenance of ships. At certain fixed intervals (when the technology level reaches certain values) an empire gains the capacity to build stronger ships, which can give it decisive advantages in combat with other empires.

An Almonaster game ends when one empire or coalition of allied empires obliterates every other empire. An empire is obliterated when its home world is nuked by an opponent, in which case all of its colonized planets become unclaimed.

1.3 The basic strategies

Successful Almonaster play requires players to balance the following considerations:

• Exploration - The greater the percentage of the full map available to a player, the better his chances of success. Exploration is needed to find resource-laden planets to colonize, as well as to view the activities of enemy empires.
  
• Colonization - Once explored, planets must be colonized and defended against enemy ships that may be in the vicinity. The more planets colonized, the better an empire's economy and the higher its chances of success.
• Terraforming - Not all planets offer the appropriate conditions to support life. Terraformer ships exist that can in some cases increase the agricultural capabilities of a planet.
  
• Defense - Other empires will compete for planets in deep space and will attempt to weaken each other by nuking their already-colonized planets. Defensive measures will be required to defeat invaders.
  
• Attack - The best defense is a good attack; the best way to keep an empire busy is to attack it and force it to defend itself.
  
• Technological development - If an empire spends too many resources building ships, then its technological development will suffer and more frugal empires will in the long run be able to develop stronger fleets and win the decisive battles.
  
• Diplomacy - Sometimes the best way to "beat" a strong enemy is to join him. Successful choices of alliance partners can lead to victories that would otherwise be impossible.

The experienced Almonaster player will learn to balance these aspects and develop a healthy economy through exploration and colonization while maintaining a high technological level, preventing enemy probes from exploring his territory and establishing relationships of alliance with other empires of similar potency.

2.0 The System Interface

The first thing that has to be done in order to play on an Almonaster server is to create a new empire with a password. Once this is done a player can begin to use the resources on the server: he can edit his profile, search for other empires, chat with fellow players, join games currently in progress or start new games.

2.1 The Login screen

This is the first screen that players see when they connect to an Almonaster server. This screen allows players who have already created empires to access the server by simply typing in a valid empire's name and password. New empires can be created by typing in an otherwise unused empire name and a password to be used with it, and selecting the Create Empire button. If the empire name is not already in use on the server, then the player will be directed to the New Empire screen.

Empire names are case insensitive and all initial and trailing spaces will be stripped by the server when it canonicalizes the name. Therefore, the names "PlanetCrusher" and "  pLaNeTcRuShEr   " correspond to the same empire. In addition, names and passwords containing characters from outside the range between ASCII character 35 (#) and ASCII character 126 (~) will be rejected. Unicode characters are not supported.

After an empire has successfully logged in, the Active Game List will appear.

2.2 The New Empire screen

This screen is reached when a new empire is created. It requires the player who is creating the new empire to verify (retype) the password that he or she entered in the Login screen. No other information is requested at this screen.

An option available to experienced players who wish to start off a new empire with the same privileges as their old empire is the ability to cause newly created empires to inherit a previous empire's Almonaster score and privileges. This can be accomplished by typing in the name and password of the "parent" empire into the forms at the bottom of the screen. The parent empire will be deleted during this process. Therefore, it must not be in any games at the time, or else the new empire will not be able to inherit from it.

After an empire has been successfully created, the server's Terms of Service will appears. Once they have been read and accepted, the Active Game List will appear. Rejecting the Terms of Service will result in the destruction of the new empire.

2.3 The Active Game List

The Active Game List provides a list of the games that the logged-in empire is currently playing. Clicking on the "Login" button for a game will lead to the information screen for the selected game.

2.4 The Open Game List

The Open Game List provides a list of games that are currently being played on the server and that the logged-in empire has permission to view. Clicking on the "Enter" button for a game will allow the empire to join the selected game.

2.5 The System Game List

The System Game List provides a list of the game classes that are currently available on the server and that the logged-in empire has permission to view. Clicking on the "Start Game" button for a gameclass will allow the player to start a new game. The advanced checkbox exists to provide the player with detailed options concerning the nature of the game to be created, and should be left unchecked by the novice player.

The System Game List also allows empires with privilege levels equal or superior to a certain privilege (usually 'Apprentice') to create their own custom games. More information about custom games and privileges is available in section 2.23.

2.5.1 Game class options

To the Almonaster beginner, the fields that describe game class characteristics may be somewhat confusing:

These fields are explained in the following table:

The "Options" field contains the following values. Scratched values are inactive and non-scratched values are active.

If the game has a limit on the number of possible concurrent active games, that information will be displayed on the System Game List or the Personal Game Classes list.

Fields displayed only in the Open Game List that refer to a particular game are explained in the following table:

2.5.2 How game class options affect game play

Almonaster allows administrators to create game classes (game types) designed with custom parameters. Among these parameters are some that greatly affect game play:

• Update time - Blitzes (games that update once every several minutes) demand different strategies than longterms (games that update every day).
  The former require succinct communications between allies and rapid decision-making skills, because players may not have the time to examine the map and the game situation exhaustively before they are forced to make a decision. The latter require a more reasoned approach to the game and more developed diplomatic skills, which might allow players to obtain temporary cease-fires or trade agreements with otherwise non-friendly empires.
  Other requirements of long-term games include superior strategic planning abilities, because every player in the game will have greater opportunities to analyze the situation of his empire or coalition and plan accordingly.
  
• Number of empires - Game classes can have different maximum and minimum numbers of empires. The minimum number needed for a game is two, and the maximum number can be as high as the administrator's whim. In general, however, more than fifteen or twenty empires per game would be terribly confusing in anything but a longterm.
  Games with only two players (grudge matches) are different from other types of games because diplomatic considerations are unimportant.
  
• Number of planets - The number of planets per empire in a game can range from three to about twenty. The opening strategies for small numbers of planets are different from those for large number of planets because large galaxies lead to situations where some empires, through luck of the map layout or diplomatic inability, are allowed to expand freely while others run into competing neighbors immediately.
  This leads to inequalities in resource distribution that are not as present in games with smaller maps. These inequalities lead to the existence of exceptional diplomatic situations, such as temporary alliances and coalitions, back-stabbing and information leaking.
  
• Technology delta - Different game classes can have different default technology increases per update. Games with larger increases will lead to greater technological differences between different empires, but these differences will rarely be decisive because technology can be acquired easily. On the other hand, games with smaller increases will usually allow technological parity to be maintained between empires. However, should a difference occur, it would be almost decisive in determining which empire or coalition would win.
  
• Diplomatic settings - There are games that do not allow the full set of diplomatic settings (war, truce, trade, alliance) to be used. Some games fix diplomatic settings at "war," thus impeding all diplomatic arrangements outside of tacit non-aggression agreements. Other games only allow "war" and "truce" or "trade," which leads to situations where coalitions may be formed, but they can never be permanent and every action must be performed with the idea that one will eventually be forced to attempt to destroy one's partners and vice-versa. This type of game makes for interesting relationships of trust.
  
• Shared maps - Some game classes allow maps to be shared between empires at a given diplomatic level. What this means is that if an empire explores a planet, all empires at that diplomacy level or higher with the exploring empire will see the new planet added to their maps. This allows more effective sharing of information between empires. It also increases the uncertainty concerning which empires have explored which planets.
  
• Invisible builds - It is possible for Almonaster administrators to create game classes that by default do not display ships built during the current update on the map screen. This further reduces the amount of information available to players concerning each other's activities, and it allows empires to experiment with building fleets without leaking this information to the outside.
  
• Available ship types - Some game classes do not allow empires to develop and build all of the different ship types available in Almonaster in general. The effects of this restriction depend on the ship types that are eliminated. For example, if stargates or jumpgates (which are ships that teleport other ships from one planet to another) cannot be built, then the acquisition of build-capable planets near the battle front becomes essential.
  
• Private messages - In some game classes, empires are not allowed to send private messages to other empires. In these games, they are forced to communicate sensitive information through the use of insecure channels such as open broadcasts, planet and ship renaming, or through the development of special codes.

2.5.3 How resources are assigned to planets

When a game begins and the game's map is generated, resources (amounts of minerals, fuel and agriculture units) are assigned to each planet. These numbers are obtained in the following manner:

1. If the average resource totals for each planet are variable, a random number is chosen between the minimum and maximum limits for each resource. Otherwise, the fixed average resources totals are used.
2. The average resource total for each planet is multiplied by the number of planets to be created per empire: this returns the total number of resources to be assigned to the group of planets, for each resource type.
3. Random numbers between 0 and the average resource total for a planet (multiplied by a server-wide variable known as the Resource Allocation Randomization Factor) are chosen for each planet and for each resource type. The random values are added together, normalized to the desired total calculated in step 2 and adjusted for floating point errors.

2.6 The Profile Viewer

The Profile Viewer is designed to allow players to search for other empires and view their profile information. Novice empires can only search for other empires by name, but those with privilege levels greater than novice can choose a more advanced search form that allows searching for empires by many characteristics

If multiple empires are found in a search, a choice is offered as to which profile to display. Profiles look like this, with most of the fields being rather self-explanatory:

[Icon] We

• The Empire Key is a unique numerical identifier for the empire on the server.
• The Privilege Level is explained in section section 2.23.
• Broadcasting is the ability to broadcast messages in games and to send system messages to other empires. This privilege is granted by default, but can be revoked by an administrator. Empires inheriting from another empire will inherit their broadcast settings.
• The Login Count field is the number of times the empire has successfully logged on to the server
• The Browser field is simply the string that web browsers use to identify themselves to the server. It can obviously be spoofed.
• IP addresses are hashed (scrambled) in order to preserve privacy, but this field is useful because two identical addresses will be hashed in the same way and will thus be converted to the same values.
• The Max Econ and Max Mil fields represent the greatest Econ and Mil values that the empire has reached in all the games it has played. These values are cached until empires leave a game, in order to prevent information about empires' current totals from leaking out during the game. (Econ and Mil values are explained in section 3.5.)
• Wins, Nukes, Nuked, Draws and scoring are explained in section 2.8.
• The Unread Messages field indicates the number of system messages the empire has in its queue. It does not count unread game messages.
• The Games and Tournaments fields represent the number of games and tournaments the empire is currently participating in.

Private system messages can be sent from the Profile Viewer to any empire whose profile is being displayed. System messages (as distinguished from game messages) are those displayed outside of games in the system interface.

An empire's personal game classes can be accessed from the Profile Viewer. Personal game classes are discussed in section 2.23.  Nuke histories can also be accessed from this screen.

2.7 The Profile Editor

The Profile Editor allows players to customize their empires' profiles. Actions that can be performed from this screen include the following:

Empire Information:

• The empire's name can be recased. E.g., "BigB" can become "bIGb" and vice-versa.
• The empire's password and can be changed.
• The empire's personal details can be changed:
  • Real name
  • Age
  • Gender
  • Location
  • E-mail address
  • Private e-mail address
  • Instant Messenger
  • Webpage
• The empire's tournament membership details can be changed.
• Empire autologon can be turned on or off.
• Empires can be added and removed from the empire's associations.

System User Interface:

• The empire's alien icon can either be chosen from the server's set or uploaded by the player. An alien icon is used to identify the empire within a game: it appears on the in-game map in the place of the planets that the empire has colonized. In order to be accepted, the size of an uploaded alien icon must be less than a server defined size, and it must be a correctly formatted 40x40 transparent gif in GIF89a format. An empire can only have one uploaded icon at a time: previously uploaded icons will be over-written. Uploaded icons are also deleted when an empire is deleted.
• The empire's graphical theme can be changed. Graphical themes are described in section 5.14.  Graphical themes can be chosen from the following options:
  • Individual graphical elements: the player can pick and choose elements from among all the themes available on the server
  • Graphics from an alternative path: the player can use a URL of a file path on his local computer as the theme directory, and all game graphics will be read from there. All server themes can be downloaded and used this effect. This provides some performance improvements, as well as a fully customizable environment, but care must be taken not to provide an erroneous directory or to access the server from a machine lacking the correct directory, or graphics will not be displayed properly. This option should only be used by advanced computer users.
  • The Null Theme: this is a low bandwidth theme designed for modem users, slow servers and minimalists. It is available on all Almonaster systems.
  • Various full themes provided by the default Almonaster installation or added by an administrator
    
• Command buttons can be displayed at the top and bottom of the screen, or just at the top, on game or system screens.
• The current server time can be displayed on game or system screens.
• The empire's saved system messages can be viewed.
• The number of system messages that the system will save can be changed.
• The background can be made fixed (Internet Explorer only).
• Uploaded icons can be blocked from display, and replaced by the server's default icon. This option also applies to the empire's own icon.
• If the empire is not a novice, the player can choose between simple and advanced search interfaces in the Profile Viewer.
• Confirmation prompts when performing actions such as deleting an empire, entering, quitting or resigning a game can be enabled or disabled.

Game User Interface:

• Refresh on update countdown refresh. This option requires JavaScript, and will cause the current page being displayed to be automatically refreshed when the update countdown ends.
• Visual update countdown. This option requires JavaScript, and provides a visual countdown in a text box for the remaining update time.
• Refresh unstarted game screens every two minutes. This option requires JavaScript, and will cause the current page being displayed to be automatically refreshed every two minutes before a game starts. This option can prevent players from being taken by surprise while waiting for others to join a game.
• Displace End Turn button to corner. This option will make it more difficult to press the End Turn button unintentionally.
• Map coloring by diplomatic status. If enabled, planet text on the empire's maps will be colored according to the diplomatic status of the empires who own the planets being displayed.
• Ship coloring by diplomatic status. If enabled, ship count text will be colored according to the diplomatic status of the empires who own the ships located at the planets being displayed.
• Ship highlighting on the map screen. If enabled, ship count text will be larger and bolder than other text on the screen.
• Sensitive maps (Internet Explorer only). If enabled, each planet will contain an ALT tag displaying a detailed list of the ships located at the planet.
• Partial maps. This option will cause only small portions of maps to be displayed at a time.
• Local maps in up-close map views.
• Ship menus in up-close map views or on the Planets screen.
• Build menus in up-close map views or on the Planets screen.
• Ship type descriptions in tech screens. This option can be useful for new players who are still unfamiliar with all the different ship types.
• Ratio lines in game screens.
• Game screen password hashing. See Section 4.5.2 for more details on this option.

Gameplay:

• Default game message target. This option selects the default recipient of messages selected in the Diplomacy screen.
• Default builder planet. This option defines the default builder planet selected in the Build screen.
• The maximum number of ships that can be built at once from the Build screen.
• Independent ship gifts. In games where Independence is enabled, if an empire is nuked with ships located on other empire's planets, those ships can revert to the ownership of those empires, or they can be dismantled. This option allows players to reject or accept such gifts.
• Disband empty fleets on update.
• Collapse or expand fleets by default.
• Send message with score information on nuke. Players can choose to view messages with changes to scoring when a nuke occurs.
• Send update messages on obliteration. Players can choose to view the game update message from the update in which their empires are obliterated. This allows them to see what actually happened during the update in which they were nuked.

• The empire's quote and victory sneer can be changed.

Default ship names:

• The empire's default ship names can be changed. Default ship names are used in the Build screen.

The empire's statistics can be blanked. This includes Wins, Nukes, Nuked, Draws, Max Econ, Max Mil, the various scores, and Privilege Level.

2.7.1 Empire Associations

An empire association is a two way relationship that is established between two empires. These associations provide a mechanism for quickly switching between different empires belonging to the same player. New empire associations can be established through the Profile Editor by entering the name and password of another empire. When this is done, each of the two empires involved in the association will be able to log in as the other empire without entering a password, even if the empires' passwords change. Associations may be deleted by either empire involved in the association. There is no limit on the number of empires that may be associated with one another.

Associations are used by navigating to the current empire's profile and selecting the desired empire from the dropdown list. This list will only appear when the empire forms an association with another.

2.8 Top Lists

The Top Lists screen allows players to view lists of empires ranked using various scoring systems.

For novices to understand the contents of this screen, it should be explained that an empire can only defeat another empire by obliterating the latter's homeworld. This is accomplished by using one or more uncontested ships to nuke the homeworld in question. An empire obtains a nuke when it obliterates another empire. The obliterated empire in turn obtains a nuked. If an empire ends a game as a member of the winning coalition it obtains a win. A draw is obtained when all remaining empires agree to cease all hostilities and end the game without a winner. If an empire is idle for enough updates, it will fall into ruin and be removed from the game if the gameclass allows ruins to occur.

2.8.1 Classic Score

Classic Score is defined as the following simple formula:

Wins + 0.25 * Draws + 0.5 * (Nukes - Nuked) - Ruins

This scoring system is a relic of Stellar Crisis gameplay and is primarily a measure of games played. It is more significant to old-timers than to beginning players.

2.8.2 Almonaster Score

Almonaster Score is far more complicated than Classic Score, and is used to restrict game access. It is intended to be a more accurate measure of player quality than the Classic Score, which measures mostly quantity.

The core notion of Almonaster Score is the concept of a Base Unit (BU). The BU is the amount of points that is given to an empire that nukes another empire of equal quality and with an equal number of allies and trade partners. It is also the amount that is subtracted from an empire nuked by another of equal quality and with an equal number of allies and trade partners.

The quality of an empire, of course, is measured in Almonaster points, so the Almonaster Score can be thought of as a recursively defined ladder system. If the interacting empires are not equivalent in quality, then the quotient of their scores is used to multiple the BU. E.g., if empire A with 10 points nukes empire B with 20, A will gain BU * (20 / 10) points and B will lose BU * (20 / 10) points.

However, a good quality empire can easily be nuked by a low quality opponent, if that opponent has allies to support it and outnumber the better empire. The Almonaster Score takes this problem into account with the notion of an alliance ratio (AR), which is the number of allies and trade partners the nuked empire has divided by the number of allies and trade partners the nuking empire has. The alliance ratio is capped by the system's minimum alliance ratio and maximum alliance ratio.

Furthermore, a good quality empire with many games on a server and a high score can be nuked by an empire with no record (and thus, a low score) whose owner is actually quite good. To solve this problem, the Almonaster score uses two separate significance ratios: the Nuker's Significance Ratio (RSR) and the Nuked Significance Ratio (DSR), which are separately capped by system defined minimum and maximum values.

Other important constants that are used:

• The Minimum Score (mS), usually defined as 10. No empire's score can drop below the mS.
• The Maximum Decrease Factor (MDF): with an equal number of allies and equal score significance, an empire can lose a maximum MDF * BU points from a single nuke.
• The Maximum Increase Factor (MIF): with an equal number of allies and equal score significance, an empire can gain a maximum of MIF * BU points from a single nuke.

The latter two are introduced to reduce the results of score disparities to reasonable levels.

To summarize, one one would express the Almonaster Score in C in the following manner:

void GetAlmonasterScoreChanges (
    float fNukerScore,         // Empire's current score
    float fNukedScore,
    int iNukerSignificance,    // Nukes + nuked
    int iNukedSignificance,
    int iNumNukerAllies,       // Number of allies and trade partners empire has
    int iNumNukedAllies,
    float* pfNukerIncrease,    // Final increase in nuker's score
    float* pfNukedDecrease     // Final decrease in nuked empire's score
    ) {

float fIncreaseFactor, fDecreaseFactor, fAllianceRatio, fNukerSignificanceRatio, fNukedSignificanceRatio;

// Prevent division by zero
iNumNukedAllies += 2;
iNumNukerAllies += 2;

iNukerSignificance += 2;
iNukedSignificance += 2;

// Calculate initial increase / decrease factors
fIncreaseFactor = fNukedScore / fNukerScore;
fDecreaseFactor = fIncreaseFactor;

// Normalize increase factor
if (fIncreaseFactor > ALMONASTER_MAX_INCREASE_FACTOR) {
    fIncreaseFactor = ALMONASTER_MAX_INCREASE_FACTOR;
}

// Normalize decrease factor
if (fDecreaseFactor > ALMONASTER_MAX_DECREASE_FACTOR) {
    fDecreaseFactor = ALMONASTER_MAX_DECREASE_FACTOR;
}

// Calculate alliance ratio
fAllianceRatio = (float) iNumNukedAllies / iNumNukerAllies;
if (fAllianceRatio > ALMONASTER_MAX_ALLIANCE_RATIO) {
    fAllianceRatio = ALMONASTER_MAX_ALLIANCE_RATIO;
}
else if (fAllianceRatio < ALMONASTER_MIN_ALLIANCE_RATIO) {
    fAllianceRatio = ALMONASTER_MIN_ALLIANCE_RATIO;
}

// Calculate significance ratios 
fNukerSignificanceRatio = (float) iNukerSignificance / iNukedSignificance;
fNukedSignificanceRatio = fNukerSignificanceRatio;

if (fNukerSignificanceRatio > ALMONASTER_MAX_NUKER_SIGNIFICANCE_RATIO) {
    fNukerSignificanceRatio = ALMONASTER_MAX_NUKER_SIGNIFICANCE_RATIO;
}
else if (fNukerSignificanceRatio < ALMONASTER_MIN_NUKER_SIGNIFICANCE_RATIO) {
    fNukerSignificanceRatio = ALMONASTER_MIN_NUKER_SIGNIFICANCE_RATIO;
}

if (fNukedSignificanceRatio > ALMONASTER_MAX_NUKED_SIGNIFICANCE_RATIO) {
    fNukedSignificanceRatio = ALMONASTER_MAX_NUKED_SIGNIFICANCE_RATIO;
}
else if (fNukedSignificanceRatio < ALMONASTER_MIN_NUKED_SIGNIFICANCE_RATIO) {
    fNukedSignificanceRatio = ALMONASTER_MIN_NUKED_SIGNIFICANCE_RATIO;
}

// Calculate nuker empire's increase
*pfNukerIncrease = ALMONASTER_BASE_UNIT * fIncreaseFactor * fAllianceRatio * fNukerSignificanceRatio;

// Calculate nuked empire's decrease
*pfNukedDecrease = ALMONASTER_BASE_UNIT * fDecreaseFactor * fAllianceRatio * fNukedSignificanceRatio;

// Make sure decrease doesn't drop nuked empire below min score
if (fNukedScore - *pfNukedDecrease < ALMONASTER_MIN_SCORE) {
    *pfNukedDecrease = fNukedScore - ALMONASTER_MIN_SCORE;
}

}

A ruin affects an empire's Almonaster score as if the ruined empire had been nuked by the empire in the game whose nuke would have cost the ruined empire the most, had the latter nuked the former with no alliance considerations.

2.8.3 Bridier Score

The Bridier scoring system was designed for chess and adapted for Stellar Crisis 3.x by Jerome Zago. It attempts to perform the same type of evaluation of an empire's quality that the Almonaster Score does, but only for selected one-on-one (grudge) games. More information about the Bridier scoring system can be found on Jerome's website.

If a server is down for longer than a week, the timestamps that record their last Bridier activity, which are used to calculate Bridier Index decay, will be updated accordingly.

2.9 The Chatroom

The chatroom is a simple implementation of an IRC-like message board designed for those who wish to find a quick opponent for a game or are unable to access real IRC channels. The chatroom keeps a certain number of messages stored in memory and has an upper limit on the number of empires who can share the room simultaneously. Empires who enter the chat room and do not post a message for a certain period of time will time out.

Needless to say, the basic rules of civility that govern all Internet communications also apply to the Almonaster chatroom.

2.10 Exit

The exit button will take players who press it back to the Login screen and allow them to use different empires or create new ones.

2.11 Spectator Games

The Spectator Games screen lists all active games that have been created with settings that enable them to be viewed by spectators. From this page, players can view the full maps of these games, as well as some information about the empires playing the games. In order for a game to be displayed on this page, it must:

• Have an exposed map
• Have exposed diplomacy
• Have been made available to spectators from the Advanced Options page, or have been started on a server with spectator availability enabled as the default.

2.12 Tournaments

2.13 Latest Games

2.14 Latest Nukes

2.15 Personal GameClasses

2.16 Personal Tournaments

The Personal Tournaments screen appears to empires who have attained the level of Adept. This screen allows empires to create and administer their own tournaments. Tournaments are explained in detail in section 4.6.

2.17 Server News

The Server News screen displays a news page edited by the server's administrators. The content will vary depending on the server. Users of a particular server are advised to check the Server News page once in a while to inform themselves of important occurrences concerning the server and the game. When the server news page is updated, empires that log in or autologin afterwards will receive notifications that the server news has been updated.

2.18 Server Information

The Server Information screen provides information about system and game variables that are specific to the server or the version of Almonaster. It also provides data concerning the state of the server process and the traffic the web server has serviced since it last started up. This information is required reading for players new to Almonaster or to a particular server.

2.19 Documentation

The Documentation screen displays this very document, which should be synchronized with the version of Almonaster running on the server.

2.20 Contributions

The Contributions screen explains how the player can contribute resources to the server's administrators. Generally, gifts of money, hardware or time are much appreciated buy those who provide a free service such as Almonaster at their own expense.

2.21 Credits

The Credits screen attempts to give credit where credit is due, by mentioning the people responsible for the important work that led to the existence of Almonaster and Stellar Crisis. This page is of course a work in progress, just like the games themselves.

2.22 TOS

The TOS (Terms of Service) screen provides a description of the contract between the server administrators and the users. It attempts to regulate player behavior by establishing for them a set of rights and responsibilities. All players must accept the TOS in order to play on a server. The TOS text distributed with Almonaster is generic, but can me modified and adapted to suit the needs of a given server and its administrators. A player who is new to a server should read its TOS to verify that its terms are reasonable and acceptable.

2.23 Privileges

There are five levels of privilege that an empire can be assigned in Almonaster:

• Novice: this is the default privilege level assigned to all newly created empires. Novices can play any game that their score allows them to play, and can customize their profiles to their hearts' desires.
• Apprentice: this level is attained when an empire has won a few games and can be considered to be somewhat knowledgeable about the game. Apprentices can create their own personal games from the System Game List. Personal games are individual games that do not belong to a specific gameclass, but which can have the settings that the player wishes within administrator-configured restrictions. Regardless of security or scoring restrictions, the creators of personal games can always enter their own games. Apprentices also have access to the parameterized advanced search interface in the Profile Viewer.
• Adept: this level is attained when an empire reaches an accomplished degree of expertise with the game, as measured by its Almonaster Score. Adepts have all the privileges of Apprentices plus the ability to create personal gameclasses. Personal gameclasses are similar to system gameclasses, but they are configured by the player and can be started from the empire's profile screen. There is an upper limit on the number of personal gameclasses an empire can create, and their characteristics are limited by the same restrictions that custom games are. Regardless of any security or scoring restrictions, the creators of personal gameclasses can always enter their own games.
• Administrator: there is one default administrator created when a server is set up, but there can be any number of empires on a server with administrative privileges. An administrator has the following abilities beyond the privileges of Adepthood:
  • Server administration: administrators can rename the server, introduce new alien icons, change server parameters, backup and restore the database, change the default ship names, change the default themes, etc.
  • Game administration: administrators can create and delete superclasses (which are groupings of gameclasses) and individual gameclasses, as well as view information about active games, kill active games, etc.
  • Empire administration: administrators can broadcast messages to all empires, change empire settings and delete empires.
  • Theme administration: administrators can add, rename, delete and configure the system themes.

  Administrators can also join any game, regardless of score limitations and have the right to delete other empires' personal game classes.

• Guest: this is a privilege level that is used for the default guest empire and as a punishment for empires whose right to enter games is to be removed without actually deleting the empires. Guest empires cannot enter or create games, even games they are already in. However, guest empires can view all open games, regardless of score restrictions. There is one default guest created when the server is set up, but there can be any number of empires on a server with guest privileges.

The empire named 'root' is the default administrative empire created during new server setup. This empire is considered special by the server: it cannot be deleted, downgraded from administrative status, prevented from broadcasting, have its password changed, have its scores changed or blanked, or have its personal game classes deleted, even by another administrator.

The empire named 'guest' is the default guest empire created during new server setup. It exists to allow applications such as the game availability page which poll SC and Almonaster servers for active games. This empire is considered special by the server: it cannot be deleted, upgraded from Guest status, allowed to broadcast, change its own password, have its scores changed or blanked, create or enter games, create personal game classes.

It is recommended that players understand the meaning of the different game class options available to them before creating their own custom games or game classes.

2.24 Empire autologon

The option exists on Almonaster servers to configure an empire for autologon. This option can be both activated and deactivated in the Profile Editor. Only one empire per user per web browser can be set to autologon at a time.

When autologon is enabled, the player's web browser will provide the server with the identity of the desired empire and its hashed password in the form of a cookie. The player will be directly presented with the Active Game List, directly bypassing the login screen. A failure in the autologon process will cause autologon to be turned off, and the player be presented with the standard login screen.

2.25 Advanced Options

When a game is created from the System Game List with the Advanced checkbox selected, a menu will appear with options that the player can use to configure the new game:

3.0 Gameplay

3.1 The Info screen

The Info screen looks something like this:

Game Information

Empire Totals

The next update time is calculated in the following manner:

• If the game has not started, take the full update period and add the game's first update delay.
• If the game has started, it is the following:
  • Take the last update time and add the full update period.
  • If still the first update, add the game's first update delay.
  • If the game does not update on weekends, and the time falls on a weekend, add the remaining weekend time plus the server's after weekend delay.
• Calculate the timespan between the calculated time and the current time.

If an empire is "ready for an update", then the empire has finished making its moves for the current update and has clicked on the End Turn button, signaling its readiness to move on to the next turn or update. When all empires have Ended Turn, an update will occur, regardless of the time remaining in the current update period. This ensures that games move along quickly and time is not wasted waiting for the game's update timer to run down. If an empire is ready for an update but wishes to make changes, it has the option of clicking on the Unend Turn button, which sets the empire back to an unready state.

• Minerals are used to build and maintain ships. The total listed here is the sum of the exploited mineral units of each planet owned by the empire. A planet can exploit mineral units in a number equivalent to its population size. For example, a planet with 60 mineral units and 42 population units will provide 42 mineral units to the empire's total. One with 42 minerals and 60 population will provide 42 mineral units.
• Fuel is used to provide power to existing ships. The total listed here is the sum of the exploited fuel units of each planet owned by the empire. Fuel units are exploited by a planet's population exactly like mineral units. Both minerals and fuel are consumed automatically by the ships the empire has built. Excess minerals and fuel are used to develop technology.
• Agriculture is used to feed planetary populations. One unit of agriculture feeds one unit of population. Excess agriculture leads to population growth, which in turn allows planetary resources to be exploited at the fullest, which makes the empire stronger. Agriculture does not require exploiting, so the total agricultural units an empire possesses is simply the sum of the agriculture units of all planets owned by the empire.
• Population is the sum of the individual planetary populations of all planets are owned by an empire.
• Target population is the sum of the individual maximum populations of all the planets that are owned by the empire. The maximum population of a planet is a value specified by the player in the Map or Planets screen that limits the population growth on a given planet. This maximum population of a planet defaults to the agriculture level of the planet. The reason an empire would want to limit the population of its planets is because there is a limited amount of agriculture to go around, and if a planet's population is already exploiting the mineral and fuel units of the planet to their fullest, there is rarely a reason to have more population units on that planet.
• The tech level, tech increase and battle rank are explained in section 3.11.
• The next tech level is defined as the tech level that the empire will have after the next update occurs.
• The next battle rank is defined as the battle rank that the empire will have after the next update occurs.
• Planets and ships refer respectively to the number of planets and ships that the empire owns.
• The maintenance ratio is the number of mineral units divided by the number of mineral units in use. The use of this ratio is described in section 3.6.
• The fuel use ratio is the number of fuel units divided by the number of fuel units in use. The use of this ratio is described in section 4.11.
• The agriculture ratio is the number of agriculture units divided by the total number of population units. This ratio multiplies the population of every planet at each update and increases the population of the planet by that amount (capped at the planet's max pop). If the ratio is less than 1, then a Malthusian situation has occurred and populations will decline.
• The total build cost is the number of mineral units used in building ships during the current update.
• The total maintenance cost is the number of mineral units used in repairing and maintaining ships' battle readiness.
• The total fuel use is the number of fuel units used to provider power to all currently existing ships. Ships do not consume fuel until they are launched, which is during the next update after they are built.

3.1.1 Next Ratios

The next maintenance, next fuel use and next agriculture ratios are defined as the system's best guess at the values of these ratios after the next update. These values take into account deterministic factors such as max population settings, colony construction, visible upcoming trade settings, colonies set to colonize or minefields set to detonate. They do not consider non-deterministic events such as ship combat, most special actions such as terraforming, invasion or planet colonization.

The reason special actions are not considered is because it is not possible to predict if the ship in question will successfully act. There are two reasons why it might fail:

• Special actions occur in random order. Another ship might act first.
• The ship might be destroyed.

The first can easily be discarded if there are no other ships on the planet. The second, however, depends on ship combat outcomes, which use random input (namely, the order in which ships are destroyed). One would think that the system could notice those cases where ship combat is simply not possible, and adjust the next ratio accordingly, but that would provide the colonizing empire with an information leak: the knowledge that there are no cloakers on the planet he's about to colonize, and no enemy ships located at adjacent but unexplored planets. Consequently, special actions are ignored when computing next ratios.

The next ratios are primarily useful as references when overbuilding or pop tricking.

3.1.2 Technological levels

The technological level of an empires is a floating point number that begins each game set at an initial level (usually at least 1.0). As the updates progress, each empire's level increases depending on the amount of resources (minerals and fuel) that it is using and the maximum tech increase allowed by the gameclass. This formula can be expressed as follows:

This allows empires that use few resources in building or maintaining existing ships to develop high technological levels. On the other hand, over-ambitious empires that build too many ships are penalized as time passes, because their technological levels will be inferior to those of their opponents and this disadvantage may not be outweighed by the economic benefits the additional ships might have brought.

Technological development is useful for two different reasons:

1. Ships built by empires with higher technological levels are more effective in battle.
2. As empires reach higher levels, they can develop new types of ships not available at the beginning of the game.

The important notion to grasp is that effective technology levels increase by cut-off points. The floor of the square root of an empire's technological level (the battle rank, or BR) is the relevant number in determining both ship capacity and the availability of new ship types. When this number increases (as it does when the technological level reaches 4.0, 9.0, 16.0, 25.0, 36.0, etc.), the BR of the empires will increase (to 2, 3, 4, 5 and 6, respectively). As a consequence of the BR increase, an additional ship type can be developed and more powerful ships can be built.

If an empire builds enough ships, it will over-spend on ship maintenance and will actually see a negative technological development. This can cause the empire to slip back to a lower BR. If this occurs, the empire will not lose the new ship type that it can develop, but its ships will be built with the lower BR and will be less effective in combat situations.

The rationale for using a geometric system rather than a linear one is simple: the intention was to make it increasingly difficult to reach the next BR level. There are two ways to explain why this is desirable:

1. The "realistic" explanation is that once a certain level of ship building expertise is achieved, it becomes increasingly harder to build better ships. Once every ship has a warp drive, a photon cannon and nuclear bombing capabilities, what else can one add? In other words, it takes more R&D efforts to improve more advanced ship designs than it does to improve more primitive ship designs.
   
2. The "game-play" explanation is that a linear system would lead to constant imbalance between empires at different technological levels. The increasing "space" between BR levels helps to balance out inequalities between empires with different resource levels and building needs.

The effectiveness of a ship in combat is actually the square of its current-BR. So a BR6 ship will fight with 36 combat "points." The most important consequence of this is that ships with higher BR's are much more effective in combat that ships with lower BR's, and this difference in effectiveness increases as the respective BR's are higher. The "realistic" rationale here is that once the massive R&D efforts described in explanation (1) are made, the result is actually quite worth the expenditure.

One might think that this squaring of the current-BR simply eliminates the square-root formula for calculating BR, and therefore contradicts explanation (2) above. This is not the case: ships built by an empire with technological level 48.0 are no more powerful than those built by an empire with technological level 36.0. Therefore, technological inequalities between different empires are not so much balanced out as dampened through the use of the geometric BR scale.

3.1.3 Ship types

There are sixteen different ship types in Almonaster. All ship types have the same offensive and defensive capabilities at the same BR, but many have special abilities that differentiate them from the others:

3.1.4 Ship costs

The following table displays the costs of building and keeping ships alive. The build and maintenance costs count against the empire's minerals, while the fuel cost counts (logically) against the empire's fuel. All costs will detract from technology development. If a ship loses MaxBR through special actions or other mechanisms, it will cost its owner the same amount of resources as the same ship type built at the new MaxBR level.

(Note: the costs listed here are generally the same as for classic Stellar Crisis. However, doomsdays in Almonaster are cheaper than their SC counterparts.)

3.2 The Options screen

The options screen allows players to choose various options for the current game:

3.3 The Map screen

The map screen allows players to view the planets that their science ships have explored in a two-dimensional graphical form: The representation of a planet should be interpreted in the following manner:

• The number 91 represents the planet's mineral units.
• The number 16 represents the planet's fuel units.
• The number 42 represents the planet's agriculture units.
• The number 65 represents the planet's population units.
• The number (3) represents the number of ships belonging to the empire that are located at the planet.
• The number (1) represents the number of ships belonging to other empires that are currently located at the planet.
• The name Mining Co. is the name of the planet.
• The links protruding from the planet represent jumps to other planets. If the planet is not displayed on the map, then is has not yet been explored and a science ship will be required. Otherwise, any ship that can move will be able to jump from one planet to its linked neighbour during an update.

Each planet also has a pair of X-Y coordinates that uniquely identify it in the galaxy. The X coordinates increase towards the East, while the Y coordinates increase towards the North, just like standard Cartesian coordinates.

If mini-maps have been enabled in the Options screen, they will display a smaller version of the map without planetary statistics, links or ship information. When maps are very large, setting the default map display to mini-maps can improve load times and visibility.

Clicking on a planet will lead to an up-close screen where the planet's characteristics are displayed in more detail. For example, this is a planet owned by the empire viewing it:

This is a planet owned by another empire: