Documentation for Almonaster Build 700

Author: Max Attar Feingold

Table of contents:

1.0 Introduction

Almonaster is a turn-based multi-player war game that runs on a web server and can be played from a web browser. No scripts, downloads, plugins, Flash or ActiveX controls are required. If you are reading this page, then you can probably play Almonaster games.

Almonaster was inspired by a long line of space-themed strategy games.

In the eighties, there was Daiva Story V for the MSX2 computer. You controlled a galactic empire, built fleets of ships, engaged in tactical ship battles with the enemy, and taxed your subjects to the point of rebellion. It's still a fun game, and you can use an emulator like openMSX to play it on a PC.

In the nineties, there was Stellar Crisis, the first interactive war game to appear on the web. Connectivity had opened up new social possibilities, and the new gaming experience was frighteningly addictive.

The look and feel of Almonaster has been designed to pay homage to these games, and will be familiar to those who played the classic 2.x versions of Stellar Crisis. No source code from Stellar Crisis or from any other program was used to create Almonaster. Graphical elements common to both games are used thanks to permission generously granted by the original authors.

Stellar Crisis resources that may be useful for a better understanding of Almonaster culture and gameplay include:

Almonaster is free software, released under the GNU Public License.

1.1 Credits

The following people 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: many hours of testing, hosting and bug reports
  • Bryan Bush: hosting and testing of the early versions
  • Austin Che: Linux port
  • Ken Eppstein, Ron Kinion, Chris John, Michel Lemieux, Simon Gillbee, Ella Elman, Haavard Fledsberg: icons
  • Peter Bortas: some script code
  • Jerome Zago, Aleksandr Sidorenko, Clinton Carr, many others: ideas

1.2 Basic objectives

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.3 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.4 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:

Name Update period Empires Planets Tech Dip Resources Initial techs Possible techs Options
Beginner Blitz 3 min, 30 sec 2 to 10 empires 4 to 6 planets per empire 1.000 initial
3.500 delta
1 tech dev
Alliance (2)
Surrender (2 empires)
33-66 Ag
33-66 Min
33-66 Fuel
100 HWAg
100 HWMin
100 HWFuel
Attack, Science, Colony All VisibleBuilds
50 BuildPop
1000.000 MaxAgRatio
2 IdleUpdates
(10 updates)

These fields are explained in the following table:

Name The name of the gameclass. Usually gives some hint about the nature of the game. For example, "Daily Galaxy" implies a game with many planets and long intervals between turns. "Blitz Battle," on the other hand, is probably a fast paced game with a small map.
Update period The length of time each update lasts. Most games are either short terms or blitzes (with updates lasting about 3 minutes) or long terms or dailies (with updates lasting 24 hours or more). If the game has a first update delay, then that time will be displayed in this field.
Empires The number of empires allowed to participate in the game. This parameter has a maximum and minimum value: when the minimum is reached, the game begins and a section of the map is created for each empire. When the maximum is reached, no more empires can join and the game closes. Gameclasses created by experienced empires can be set to allow an unlimited number of empires.
Planets The number of planets per empire that the map contains. Common values range anywhere between 1 and 40. Unless the "Fully Colonized" option is selected, empires do not begin each game owning this number of planets. This number merely tells the map generator how many planets to create, as well as approximately how spaced out the home worlds should be from each other. If this number is variable, then a random value will be chosen from the displayed range for each individual game when the map is generated. This value will be the same for each empire.

The map can be generated either when the minimum number of empires is reached (the default setting) or when the first update occurs. The difference between the two possibilities is that the latter allows a period betwen the start of the game and the creation of the map where empires can join an already-started game without their planet allocation being performed upon an existing map.

Tech This field contains three values: (1) the initial technology level that each empire begins with; (2) the maximum technology increase that an empire can experience in one update; (3) the number of available technologies each empire begins with.

The technology level is explained in section 3.1.2.

Dip The diplomacy levels that are available in this game. A diplomacy level can be followed by a value in parenthesis that indicates a limit on the number of empires with which that level can be established. This can be a a static fixed maximum or a dynamic "fair" limit, enforced as (N - 2) / 2 empires, where N is the greatest number of empires that were ever simultaneously in the game. Diplomacy levels are explained in section 3.5.1.

If alliances are allowed by the game class and they are marked as unbreakable, then empires at alliance cannot drop down to any other diplomatic level.

If alliance limits are set to count for the entire game, then any alliance that ceases to exist (due to an annihilation, or an empire dropping down to a lower level) will count for the entire game and will limit the ability of the affected empires to establish new alliances. Empires who were previously allied can ally with each other again with no additional counts added.

If surrenders are available, they may either be available always, only when two players remain, or as classic SC-style surrenders (explained in section 3.12).

Resources How many resources does the average planet receive? Resources (minerals, fuel and agriculture) are explained in section 3.1. If this number is variable, then a random value will be chosen from the displayed range for each individual game.
Initial techs The ship types that are available to all empires at the beginning of the game. The different ship types are explained in section 3.1.3.
Possible techs The ship types that can be developed by all empires during the course of the game. Note that all initial techs must be developable.

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

VisibleBuilds If this option is active, ships being built by one empire can be seen by other empires that have explored the planet on which the ships are located. Otherwise, the ships will only be visible after an update has occurred.
 VisibleDip If this option is active, diplomatic offers are only visible after an update has transpired. Otherwise, they are visible immediately.
BuildPop The population a planet requires to be able to build ships.
MaxShips The maximum number of ships an empire can own simultaneously. If this option is not active, there is no limit.
MaxAgRatio The maximum possible agriculture ratio an empire can have. Ratios are explained in section 3.1. This value is important because of the pop trick.
FriendlyGates If this option is active, stargates and jumpgates can transport allied ships and fleets. Otherwise, they can only transport the owner's ships and fleets.
FriendlyScis If this option is active, science ships cannot nuke planets. Otherwise, they can nuke just like any other mobile ship.
SuicidalDooms If this option is active, doomsdays can annihilate planets belonging to their owner (except a homeworld). Otherwise, they cannot.
FriendlyDooms If this option is active, doomsdays can annihilate planets belonging to allied empires (except a homeworld). Otherwise, they cannot.
PermanentDooms If this option is active, the quarantine period during which a planet can not be colonized after being annihilated by a doomsday lasts until the end of the game (as in classic Stellar Crisis). Otherwise, it will last a gameclass-specific number of updates.
Weekend If this option is active, the game will continue to update on weekends. Otherwise, it will not update on weekends: if an update is scheduled for a weekend time, it will be postponed until the following Monday.
PrivateMsg If this option is active, private messages can be sent between empires. Otherwise, only broadcast messages can be sent. (Private messages are only seen by the specific recipients, while broadcasts are delivered to every empire.)
DipExposed If this option is active, all empires in the game will have met each other when the game begins; i.e., each empire will be automatically listed in every other empire's Diplomacy screen. Otherwise, empires only appear on this screen when their ships have met each other or reached each other's planets.
MapExposed If this option is active, all planets on the map are visible to all empires when the game begins. If this option is active, the map will be fully available to all empires at the beginning of play. Otherwise, each empire will begin with only its initially colonized planets visible on its map.
MapShared If this option is active, empires with a given diplomatic level can share their maps: when an empire explores a previously unexplored planet, the empire's partners will see it appear automatically on their maps as well. Otherwise, each empire will need to explore each planet for itself.
FullCol If this option is active, empires begin the game with their allocated planets already colonized. Otherwise, only their homeworld will be initially colonized. If the MapShared option is not enabled but FullCol is, then each empire will begin the game having explored its own planets but no others.
Disconnected If this option is active, each empire's allocated planets will begin the game disconnected from the rest of the map. This option requires engineer technology to be developable.
Independence If this option is active, when an empire is nuked, its territories remain alive and populated as independent planets that cannot simply be re-colonized by other empires. Similarly, the empire's ships either remain independent (hostile to all other empires) or revert to belonging to the owner of the planet at which they were located.
Subjective If this option is active, then the economy and military totals displayed in the diplomacy screen for each empire represent the portion of the empire's resources that can be seen by the each player in his or her map. Otherwise, they will represent the empire's true totals.
IdleUpdates The number of updates an empire can be absent from the game before it becomes idle.  Idle empires are automatically ready for each update.  They also automatically request draw and pause.  Idle empires cease to be idle not when they log in again, but when the next update occurs.

When all empires are idle in a game, and then one or more empires return, that empire will not be able to pause, draw or prematurely end the update via end turn until the next update occurs. This is because these empires are internally considered to be idle until the next update. This prevents games in which all empires are idle from prematurely pausing or drawing when they should ordinarily have ended in a ruin.

Ruins Games with simple ruins enabled will behave just like classic Stellar Crisis: if an empire has been idle for a gameclass-specific number of updates, then it will fall into ruin and be removed from the game. The maximum number of updates this value can be set to is 25.

Games with complex ruins enabled function as follows: if all empires or all empires except one are idle for a gameclass-specific number of updates, then the idle empires will fall into ruin, but only if more than two empires were in the game at some point during its lifetime.

Empires in games with no ruins enabled will never ruin unless all empires in the game are idle, in which case all empires will ruin.

In all cases where all empires are idle, the usual update times will be respected even though all empires are ready for an update. Such a game will not end until the empires actually fall into ruin.

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:

Missed updates The number of updates already transpired inside the game.
Next update The amount of time remaining until the next update.
Bridier Indicates if the game counts for the Bridier scoring system, what the restrictions are and what the potential rank reward would be for winning of losing the game.
Score The set of restrictions imposed by the game's creator on the scores of empires allowed to enter the game.
Security The behavior of the game with respect to empires with the same IP addresses or Session Ids as other empires already in the game. Warn will allow entry, but will broadcast a message to all empires should such an event occur. Block will prevent the duplicate empire from entering the game.

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.5.4 How maps are generated Mirrored and Twisted maps

The following map options are available to players when creating a new game with an exact, even number of empires:

  • Standard
  • Mirrored
  • Twisted

A standard map will simply create a planet graph in a random fashion.

The mirrored map generation algorithm works by creating planet chains for half the empires in the game, picking the edge with the greatest connectivity, then mirroring the map along that edge, adding a layer of buffer planets.

 The twisted generation algorithm works by creating planet chains for half the empires in the game, creating a copy of the half-map map, rotating it 180 degrees, and finding the location for the second half-map that maximizes connectivity without joining a planet with its mirror. No buffer planets are created. Fair maps

The following map fairness options are available to players when creating a new game:

  • Random
  • Somewhat fair
  • Very fair
  • Somewhat unfair
  • Very unfair

A random map will simply create the planet graph in a random fashion.

Other types of maps will be generated using an algorithm that retries random map generation until the map is deemed to meet specific fairness characteristics.

Fairness is computed by first evaluating the number of resources that can be claimed by each empire, given a specific map and using Dijkstra's algorithm to compute the shortest path from the empire's homeworld to each planet. Planet resources are pooled (with Agriculture considered to be 25% more important than Minerals or Fuel) and claimed on an inverse basis to distance to homeworld (the closer the planet, the better the claim) as well as comparative distance of the planet to other empires' homeworlds.

Claims with no realistic chance of realization are discarded. For example, a planet next to one empire's homeworld and ten hops away from another, or a planet where the shortest path is through another empire's homeworld.

The fairness of the map is determined by the ratio between the standard deviation and the arithmetic mean of all empires' resource claims. Fair maps will have small deviations, while unfair maps will have fairly large ones. 

Fair maps can be combined with mirrored or twisted maps. As described above, mirrored or twisted maps are generated until a map is created that meets the specified fairness characteristics.

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] Empire

Empire Key: 267 Wins: 16
Privilege Level: Adept Nukes: 21
Broadcast: Yes Nuked: 1
Creation Time: 23:39:50 Sat, 04 Dec 1999 Draws: 2
Real Name: John Smith Ruins: 0
Age: 26 Almonaster Score: 86.500
Gender: Male Significance: 26
Location: New York Classic Score: 36.000
Email Address:   Bridier Rank: 590
Instant Messenger: MSN:   Bridier Index: 330 (60 days left)
Webpage: Max Econ: 291
Last Login: 15:32:47 Sun, 01 Sep 2002 Max Mil: 143
Login Count: 1961 Unread Messages: 1
Browser: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt) Games: 3
Hashed IP Address:   Tournaments: 2
  • 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.


  • 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.

The empire can be deleted. Empires can only delete themselves if they are no longer in any games. Otherwise, they will be marked for deletion: their personal information will be deleted and they will not be able to join new games. When they leave their last game they will be automatically deleted by the system. Such empires can be undeleted from the Profile Editor and restored to their normal state.

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

// Normalize decrease factor

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

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

else if (fNukerSignificanceRatio < ALMONASTER_MIN_NUKER_SIGNIFICANCE_RATIO) {

else if (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

The Tournaments screen lists the system tournaments that are currently active on the server. System tournaments are created by empires with administrative privileges. Empires can join and quit tournaments from this page, as well as view empire and team participation statistics for the various tournaments. Tournaments are explained in detail in section 4.6.

2.13 Latest Games

The Latest Games screen provides a list of the latest games that have taken place on the server. The information displayed includes the number of updates and the results of the game, including the complete list of winners and losers for each game. Up to an administrator-defined number of games will be displayed

2.14 Latest Nukes

The Latest Nukes screen displays a summary of the latest nukes that have occurred on the server. It lists empire names, game names and numbers, and the time that the nukes occurred.

2.15 Personal GameClasses

The Personal GameClasses screen appears to empires who have attained the level of Adept. This screen allows empires to create and administer 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:

Updates before game closes The number of updates that will occur before the game closes. If the game fills up before this numbe of updates, the game will close. While a game is still open, other empires can still join and the game cannot end.
First update delay An additional period of time that is added to the first update of the game. This option is usually used to allow additional time for empires to join a game before it closes.
Message sent to empires entering the game A message from the game's creator that is sent to each empire that joins the game.
Empire names exposed The names of the empires in the game can either be hidden or exposed in the game list. This option also determines if empire names will be broadcasted to the other participants when they enter the game.
Game available to spectators Only available for games with exposed maps and diplomacy, this option determines if a game will be visible from the Spectator Games screen.
Password protection Entrance into the game can be restricted to players who know the password selected by the creator.
Empire filtering by scores Entrance into the game can be restricted to those empires whose scores fall within the ranges selected by the creator. Restrictions defined here do not apply to administrators, to the owner of the game class, or to the creator of the game.
Empire filtering by IP address and Session Id Entrance into the game can be restricted to empires whose IP addresses and Session Ids are not duplicates of other empires already in the game. The creator of a game can choose to allow all empires access to the game, to deny access to the game to empires with duplicate IP addresses or Session Ids, or simply to warn the other empires in the game that an empire with a duplicate IP address or Session Id has entered the game.

Needless to say, because of the disconnected nature of the HTTP protocol, it is not possible to prevent multiple empires belonging to the same player from joining a game, but these options can make it somewhat more difficult for players to cheat in this manner without being detected. The Options screen also allows players to search their current games for empires with duplicate IP addresses or Session Ids. Restrictions defined here do not apply to administrators, to the owner of the game class, or to the creator of the game.

Block idle empires Entrance into the game can be restricted to empires that are not idle in another game on the server. When this option is selected, empires that are currently idle in at least one game will not be able to see the game in their Open Game List and will be prevented from joining. An empire is idle in a game if it has not logged into that game for a gameclass-specific number of updates.

Empires with the same IP address and Session Id as the blocked empire can also be blocked from entering the game. The server will compare both the current values for these fields to all entering empires, as well as the values at which these fields were set when the game was created. This option is very powerful and should be used with some caution.

Any restrictions defined here do not apply to administrators, to the owner of the game class, or to the creator of the game.

Block specific empires This option allows the creator of a game to identify specific empires who will not be allowed to enter the game. Empires with the same IP address or Session Id can also be blocked. Restrictions defined here do not apply to administrators, to the owner of the game class, or to the creator of the game.

3.0 Gameplay

3.1 The Info screen

The Info screen looks something like this:

Game Information

Updates: 13 Last update: 11 sec ago Next update: 32 hrs, 13 min
You are not ready for an update The game is closed 1 of 2 empires is ready for an update

Empire Totals

Minerals: 96 12% in use Tech Level: 13.765 (BR 3) Economic Level: 2
Fuel: 96 25% in use Tech Increase: 1.016 of 1.250 Military Level: 0
Agriculture: 95 101% in use  
Population: 96 100% of target Next Tech Level: 14.780 (BR 3) Planets: 1
Target Population: 96 101% of agriculture Next Tech Increase: 1.013 of 1.250 Ships: 2

Ratios and Usage

Maintenance Ratio: 8.000 Fuel Ratio: 4.000 Agriculture ratio: 0.990
Next Maintenance Ratio: 7.917 Next Fuel Ratio: 3.958 Next Agriculture Ratio: 1.000
Total Maintenance Cost: 12 Total Fuel Use: 24 Total Build Cost: 0

Game Settings

Maximum Agriculture Ratio: 1000.000 Ship Limit: None Population Needed to Build Ships: 50

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:

Tech Increase = (1 - Resources used / Total Resources) * Maximum Tech Increase for the gameclass

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:

Attack Has no special abilities, but is cheap to produce and is therefore useful for creating large mobile fleets.
Science Can traverse unexplored links and increase the visible map area available to the empire.
Colony Can colonize unclaimed planets and settle already colonized planets. Building a colony induces a server-defined population cost at the planet where a colony is built. This cost is deferred until the next update and is subtracted from the planets population after the agriculture ratio has been applied.

As in classic Stellar Crisis, in Almonaster a colony will always be destroyed when depositing population on a planet. Regardless of the maximum population at a planet, the maximum capacity of the colony will always be deposited.

Stargate Can teleport ships and fleets to other planets colonized by its owner in a single update. Stargates are immobile, in that they cannot be moved from the planet upon which they were built. Stargates lose a server-defined amount of BR every time they are used. They can also suffer from range limitations. If a planet's ownership changed during the update in which it was being gated to, the gate action will still succeed.
Cloaker Can become invisible and move around without being detected by friends or enemies. Cloakers cannot nuke a planet or participate in ship combat unless they are uncloaked.
Satellite Does not consume fuel and is cheap to build.  Satellites are used mainly for creating large defensive fleets (satellite walls). Like stargates, satellites are immobile.
Terraformer Can increase the agriculture level of a planet to the greater of the planet's fuel and mineral units. The amount that is increased is equivalent to the terraformer's BR multiplied by a server defined amount. Unlike classic Stellar Crisis, in Almonaster multiple terraformers can act upon the same planet during the same update. Terraforming a planet will typically destroy a terraformer, although terraformers can survive with reduced BR if the planet's resource increase is below the capacity of the terraformer.
Troopship Can invade planets owned by other empires and independent planets. Invasions are successful if the troopship's BR multiplied by a server-defined number is greater than the total population of the planet. A failed invasion destroys the ship and removes a server-defined number of population units on the planet (usually a multiple of the troopship's BR). Troopships can survive a successful invasion with reduced BR if the planet's population is below the capacity of the troopship.
Doomsday Can annihilate a planet, reducing its agriculture level to zero and placing it in a quarantined state for a number of updates equivalent to the doomsday's BR multiplied by a server-defined value. A doomsday can act upon un-colonized planets, independent planets, the empire's own planets (with the exception of its homeworld) or planets belonging to warring empires. Some restrictions on doomsday use may apply from server-defined or gameclass-defined settings.
Minefield When destroyed, it detonates and destroys every other ship on the planet, unless a minesweeper belonging to any empire is present at the planet after the ship battle ends. Minefields can also be detonated intentionally by their owners. If a minefield is detonated and a minesweeper is present, the minefield will be destroyed with no ill effects to other ships. Minefields are immobile ships.
Minesweeper Nullifies the effects of exploding minefields. Minesweepers are present in any serious offensive fleet. Minesweepers act passively and do not require special orders to operate.
Engineer Can open and close links between planets, at a server-defined cost to its BR.
Carrier Behaves like an advanced attack ship that can absorb large amounts of damage inflicted by opponents during fleet battles. Carriers are expensive to build.
Builder Can create new planets from empty space. The resource levels of the new planets depend on the BR of the builder. Creating a planet will destroy a builder.
Morpher Can change its configuration from one ship type to another, choosing from among all the technologies developed by the empire. Each metamorphosis induces a server-defined cost to the BR of the morpher. Morphers change shape early in the update, before ship combat occurs.
Jumpgate Behaves similarly to a stargate, but can teleport ships and fleets to any planet, not just to those colonized by the owner. Jumpgates cannot send ships and fleets to planets under quarantine after being annihilated by a doomsday. Jumpgates lose a server-defined amount of BR every time they are used. They can also suffer from range limitations.

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.

Ship Build Cost Maintenance Cost Fuel Cost
Attack (BR + 4 ) ^ 2 BR * 2 BR * 4
Science ((BR + 4 ) ^ 2) + 25 BR * 2 + 4 BR * 4 + 8
Colony ((BR + 4 ) ^ 2) + 25 BR * 2 + 4 BR * 4 + 8
Stargate ((BR + 4 ) ^ 2) + 100 BR * 2 + 16 BR * 4 + 32
Cloaker ((BR + 4 ) ^ 2) + 25 BR * 2 + 4 BR * 4 + 8
Satellite ((BR + 4 ) ^ 2) - 10 BR * 2 - 2  (*) 0
Terraformer ((BR + 4 ) ^ 2) + 25 BR * 2 + 4 BR * 4 + 8
Troopship ((BR + 4 ) ^ 2) + 25 BR * 2 + 4 BR * 4 + 8
Doomsday ((BR + 4 ) ^ 2) + 10 BR * 2 + 2 BR * 4 + 4
Minefield ((BR + 4 ) ^ 2) + 10 BR * 2 + 2 0
Minesweeper ((BR + 4 ) ^ 2) + 25 BR * 2 + 4 BR * 4 + 8
Engineer ((BR + 4 ) ^ 2) + 100 BR * 2 + 16 BR * 4 + 32
Carrier ((BR + 4 ) ^ 2) + 75 BR * 2 + 12 BR * 4 + 24
Builder ((BR + 4 ) ^ 2) + 50 BR * 2 + 8 BR * 4 + 16
Morpher ((BR + 4 ) ^ 2) + 35 BR * 2 + 6 BR * 4 + 12
Jumpgate ((BR + 4 ) ^ 2) + 150 BR * 2 + 24 BR * 4 + 48
(*) If this value falls below 2, it becomes 2

(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:

Placement of command buttons The command buttons can be repeated at the bottom of the screen if the player wishes it. This is useful for large screens in which a lot of scrolling is needed to go from the bottom back to the top to issue the next command.
Server time display The server's current time can be displayed on each screen  under the command buttons.
End Turn button displacement The End Turn button can be placed with the other command buttons or off to the right under the Exit button.
Refresh upon update countdown The screen can automatically refresh itself when the update timer counts down to zero. This option requires a JavaScript-enabled browser.
Visual update countdown A form field can be displayed on each screen, with a graphical countdown timer indicating exactly how much time remains in the current update. This option requires a JavaScript-enabled browser.
Map coloring by diplomatic status The Map screen can be rendered with colored text in planet representations, corresponding to the diplomatic status of the empire with owner of the planet: good color for allies, bad color for foes, standard text color for truces, trades, independent and un-colonized planets.
Ship coloring by diplomatic status Per-planet ship counts on the Map screen can be colored according to the lowest respective diplomacy level with the viewing empire of all empires who have ships at the planet. If that level is war, then the color will be bad.  If the level is alliance then it will be good. Otherwise, it will be the standard text color chosen by the empire.
Ship highlighting on map screen Per-planet ship totals on the Map screen can be displayed with a larger font and in boldface, if the total is greater than zero.
Sensitive maps The Map screen can display alt-tag based tool-tips displaying the ships present at a given planet. This can save time switching from the map screen to up-close views of individual planets. Currently, this option only works well with Internet Explorer and Lynx.
Partial maps The Map screen can display a menu at the top allowing the player to choose the center of the map that should be displayed, as well as its X and Y radius. This allows players in games with very large maps to reduce the size of the map screen. This can be useful for users with slow connections, older computers, low resolution displays, buggy browsers or WebTV.
Mini-maps The map screen can be viewed as a reduced-size map with small planets and no links or statistical text. This is another way to deal with rendering large maps.
Display ship menus in planet views Ship menus can be displayed in the Planets or up-close Map screens.
Display build menus in planet views Build menus can be displayed in the Planets or up-close Map screens.
Display local maps in up-close map views Up-close views on the Map screen can contain a small local (3x3) map centered around the specific selected planet. This map is interactive and can be clicked on to obtain up-close views of the surrounding planets. This option provides a means of easily viewing the up-close properties of adjacent planets.
Display ratios line A line at the top of the screen describing the empire's current ratios can be displayed on every screen, on selected screens, or not at all.
Default builder planet Different planets can be selected as the default builder planet on the Build screen. Options include the empire's homeworld, the last planet used to build ships or a specific planet owned by the empire.
Default message target A default target selection can be chosen for messages sent via the Diplomacy screen. The options include none, broadcast, all at war, all at truce, all at trade, all at alliance and last target used. Some of these options may not be available if they do not apply to the gameclass.
Game messages saved Stored game messages can be viewed.
Maximum saved game messages The number of game messages to save can be selected. Messages are saved in FIFO order (first-in, first-out).
Ignore broadcasts All messages sent as broadcasts can be ignored. Important information can be lost when this option is selected, but it can help preserve sanity when a particularly annoying empire is broadcasting distracting messages.
Search for empires with duplicate IP addresses Empires with duplicate IP addresses can be detected. See section 2.5.4 for more details.
Search for empires with duplicate Session Ids Empires with duplicate Session Ids can be detected. See section 2.5.4 for more details.
Request pause Empires can request that the game be paused for a period of time. If all empires agree to pause the game, then its update countdown will stop until at least one of the empires in the game is no longer requesting pause. A paused game can also be updated if all empires choose to end turn.

A game can only be paused after it has started. When a game is paused, the number of seconds elapsed from the last update is recorded, and the update timer will display the time that would remain until the next update if the game were to be unpaused. This value will increase over the weekend if the game has no weekends updates. When the game is unpaused, the last update time is set to the current time minus the elapsed update time. The timer is restarted and the next update will occur at the displayed time.

When an empire becomes idle, it will automatically request a pause. This allows games with idle empires to be paused. However, if all empires in the game are idle, the game will not pause itself even if all empires are requesting pause. This prevents games with all empires idle from remaining alive on the server forever in a paused state.

Request draw Empires can request that the game be resolved as a draw. If all empires agree to this, then the game will end. Only those games for which draw is enabled will have this option.

When an empire becomes idle, it will automatically request a draw if there is still at least one empire in the game who is not idle. This allows games with idle empires to be drawn, while preventing games with all empires idle from drawing out when a ruin is appropriate.

Keep game notes here A scratch pad can be used to keep game notes of importance: diplomatic situations or coordinates of interest.
Resign from the game Empires can resign from a game, which causes them to unilaterally leave the game. A message of resignation will be broadcasted to the other empires in the game. The resigned empire's ships will be immediately dismantled, but its planets will remain as they are until the empire falls into ruin or is nuked. The resigned empire will also automatically request a pause and be automatically ready for updates. Only an administrator can revoke an empire resignation, so this option should be used with caution. Players can activate the confirmations option in the Profile Editor if they want to be prompted before the resignation takes effect.

Resigned empires are displayed in the Diplomacy and empire information screens as crossed out.

Surrender from the game Empires can surrender from a game, which causes them to be unilaterally nuked from the game. This option will appear in games that have enabled classic SC-style surrenders, or in games where only two empires remain.

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:

91 [Icon] 16
42 65
(3) (1)
Mining Co.
  • 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:

<form method="post"> <input type="hidden" value="1" name="KeyPlanet0">
  Name Location Owner Min Fuel Ag Pop Max Pop Next Pop Jumps
[Icon] <input maxLength="36" size="15" value="Tanderu" name="NewPlanetName0"><input type="hidden" value="We" name="OldPlanetName0"><input type="hidden" value="96" name="OldMaxPop0">79,76 We 96 96 95 96 <input maxLength="4" size="4" value="96" name="NewMaxPop0"> 95 North: Preyavarta (79,77)
East: Unknown (80,76)
West: Unknown (78,76)
  Empire Science
[Icon] We 2
</form> </center>

This is a planet owned by another empire:

<form method="post"> <input type="hidden" value="1" name="KeyPlanet0">
  Name Location Owner Min Fuel Ag Pop Max Pop Next Pop Jumps
[Icon] Preyavarta79,77 Maskull 96 96 95 96 - - West: Unknown (79,76)
South: Tanderu (79, 76)
  Empire Attack Minesweeper
[Icon] Maskull 3 2

If an empire owns the planet, it can change both the name and the max pop of the planet:

The Next Pop field represents the system's prediction of how much population will be at a planet the next update. This does not take into account factors that cannot be easily predicted, such as ship combat results. As a security measure, neither the Max Pop or the Next Pop fields of another empire's planets can be viewed.

The Max Pop field represents a maximum on the population the planet can have. There is usually no reason to waste resources on maintaining more population on a planet than its mineral and fuel units, unless the planet is meant to be a builder of ships and is below the building limit. If the Max Pop field is set to zero, then the planet can be colonized by other empires, friends or foes alike.

The population a planet will have after an update is calculated as follows:

  • If the planet is uncolonized, its population will remain at zero.
  • If the planet is independent, its population will increase or decrease according to the agriculture ratio calculated with the planet's own resources.
  • If the planet is colonized, the following steps will take place:
    • Begin with the planet's current population.
    • Subtract the population lost to building colonies.
    • Apply the agriculture ratio to this value.
    • Cap the value with the Max Pop.

If a planet is marked as quarantined, the up-close view will display the number of updates during which the planet will remain in that state. A planet can become quarantined if a doomsday annihilates it or a planet is nuked a server-defined number of times.

If there are ships located on the planet, their owner, type and number will be displayed below the planet's information. When morphers are present on the screen, their type will be displayed as their current type followed by "(Morpher)"

If the options to display ships and build in these views are enabled, ship and build menus will appear.

3.4 The Planets screen

The Planets screen displays up-close views of every planet that has been explored by the empire.

3.5 The Diplomacy screen

The diplomacy screen displays all empires that the player's empire has met. If the gameclass has the DipExposed option activated, then all empires will be listed on this screen from the beginning of the game. The list will be sorted by diplomatic status.

The diplomacy screen allows the player to view each visible empire's statistics and state:

Alien Econ Mil They Offer You Offer Status Messages Last Access
Destroyer of Worlds [Icon] 9 5 War <select name="DipOffer0" size="1"> <option selected value="0">War</option> <option value="1">Truce</option> <option value="2">Trade</option> <option value="3">Alliance</option> </select> War <select size="1" name="D1"> <option selected value="1">Hear</option> <option value="0">Ignore</option> </select> 22 min, 16 sec ago
(2 updates idle)

Wins Nukes Nuked Draws Ruins Created Max Econ Max Mil Hashed IP Address Ready for Update
12 19 4 1 2 Oct 11 2000 13 7 Yes

They offer is the diplomatic level currently being offered by the empire in question to the player's empire. You offer is the diplomatic level currently being offered to the other empire. The status is the current diplomatic level between the two, which is the level at which agreement has been reached. That level is always the lower of the two offered, and is changed only when an update occurs.

Diplomatic levels are discussed in section 3.5.1.

The Hashed IP Address is a mangled version of the player's real IP address. It can be used to determine if two empires are being controlled by same player (or at least from the same network address). The "last access" field displays the amount of time that has passed since the player last requested a screen in the current game. If several updates have occurred since that time, the number of updates the empire has been idle will also be displayed.

The Econ level is an expression of the empire's economic strength. It is obtained from the following formula:

Econ = floor ((Fuel + Min + Ag) / 100)

The Mil level is an expression of the empire's current military strength. It is obtained from the following formula:

Mil = floor (sum (all ship's BR's squared) / 50)

Both the econ and mil levels are only changed during updates, so the effects on these totals of ship builds or dismantles will only be seen after the subsequent update.

The Hear/Ignore option allows players to decide if they want to view private messages and broadcasts coming from the selected empire.

The Diplomacy screen displays information at the top of the screen about the visibility of diplomatic settings, diplomacy restrictions, and the number of empires requesting a pause in the game.

Messages to other empires can be also sent from the Diplomacy screen. Messages can either be broadcast to all, or sent as private messages. The option also exists to send messages to all empires who are at a given diplomatic status with the empire.

3.5.1 Diplomatic levels

There are four separate diplomatic levels:

War When empires are at war, their ships will fight and destroy each other whenever they encounter one another. Their ships can also nuke, annihilate and invade each other's planets.
Truce When empires are at truce, their ships will not attack one another and they cannot nuke each other's planets. There are no other benefits from this setting.
Trade When empires are at trade, they receive the benefits of truce as well as additional economic benefits: a server-specific percentage of their resource totals for the first trade partner (typically 10%), and a certain percentage of that for each additional partner (typically 90%). Trade bonuses do not stack on top of one another.
Alliance When empires are at alliance, they receive the benefits of trade.  They can also win games when no other empires remain.

There are two other settings that can be offered to another empire:

  • Surrender: if an empire offers surrender to another empire and is accepted, then the result is equivalent to the latter nuking the former.
  • Accept Surrender: this option accepts an offered surrender.

These settings are processed during an update just like the real diplomatic settings.  However, these settings are not real diplomatic levels and will not change the status between the empires. It is important to note that surrender and accept surrender are not diplomatic status settings. For example, if two empires are at war, but are offering to accept each other's surrender, they will still remain at war for all effective purposes. Empires can only offer to surrender to another empire if they are currently at war with one another and have never been allied.

In order for a coalition of allied empires win a game, they all need to be allied with one another. In other words, n! alliances are needed, where n is the number of empires. In games where there are limits imposed on the number of empires an empire can keep at a given diplomatic level, higher levels count as lower levels (for example, a trade counts as both a trade and a truce). When an empire is at one level and drops down to another, the superior level's count is only decremented at the end of the update.

Diplomatic levels are only known to the empires involved in them, although their effects are visible by all: increased economic levels in some cases, ships not engaging in combat in others. It is considered good ethical practice to disclose details of alliances to other empires, as this leads to games that are more fair and balanced, but there is no physical obligation to do so. The non-disclosure of an alliance might in certain circumstances lead to advantageous positions for the empires engaging such secret agreements, so private double-crossings can never be ruled out.

An interesting observation is that (except in games where alliances are forcibly unbreakable) an empire can break an alliance at any time. One can never rest easily on one's laurels because at any moment one's allies may move over to the other side. Trust is always a matter of game circumstances and of convenience, never a permanent asset. Monogamy may make for a healthy society, but polygamy is more rewarding from the perspective of the selfish individual.

One might think that with rules like these, anarchy would soon reign in every game (as it does in other online games or communities with lax rules, such as Ultima Online). However, it should be remembered that double-crossing players will be remembered by their victims and their actions will perhaps even be disclosed and discussed publicly. Subsequent games will be harder for the double-crosser, because his empire name will be viewed with suspicion and only the naive will ally with him. Empires who wish to be respected by the community will probably find themselves behaving honorably in most cases.

Because every game begins with the galaxy's resources distributed more or less equally among all empires, there is no real incentive to constantly sack and pillage one's allies (as there might be in Ultima Online, where rewards are more or less permanent). Consequently, the short-term gain that can be obtained from double-crossing is balanced out by the long-term damage to an empire's reputation. Because games of this type encourage role-playing, it seems likely that both well-known honorable empires and shady, double-crossing empires will co-exist, perhaps even under the aegis of the same human player.

All things considered, it appears that this situation is of benefit to the game, and not a drawback.

3.6 The Ships screen

The ships screen allows empires to give their ships orders for the next update:

You have 2 ships in service:

Ship Name BR Next BR After BR Max BR Location Type Orders
<input maxlength="20" name="ShipName0" size="15" value="Explorer"> 1.000 0.875 1.000 1.000 Planet 66,74 (66,74) Science <select name="ShipOrder0" size="1"> <option selected value="-1">Standby at Planet 66,74 (66,74)</option> <option value="-2">Move North to Planet 66,75 (66,75)</option> <option value="-16">Explore West to Planet 65,74</option> <option value="-7">Dismantle</option> </select>
<input maxlength="20" name="ShipName1" size="15" value="Probe"> 1.000 0.875 1.000 1.000 Mining Co. (65,75) Science <select name="ShipOrder1" size="1"> <option selected value="-1">Standby at Mining Co. (65,75)</option> <option value="-3">Move East to Planet 66,75 (66,75)</option> <option value="-5">Move West to Planet 64,75 (64,75)</option> <option value="-6">Nuke Mining Co. (65,75)</option> <option value="-7">Dismantle</option> </select>

The BR field is described in section 3.1.2.

The Next BR field is the BR at which the ships will be the following update. This total is reached by multiplying the BR by the maintenance ratio and reducing the total to the Max BR if it is greater than this value. If the maintenance ratio is less than 1.0, ships will operate at a weaker combat level than their potential maximum. This circumstance can be understood as the ship being in a state of disrepair. Furthermore, the options available to a ship in a given update are those that the ship will be able to perform during the next update, as judged by the current Next BR.

The After BR field is the BR at which the ships will be the update following the next.

The Max BR field is the maximum BR that the ships can reach. It corresponds to the BR at which they were built.

When morphers are present on the ships screen, their type will be displayed as their current type followed by "(Morpher)"

3.6.1 Fleets

Ships can be inserted into fleets, which can be created from the Build screen. Fleets can be moved like regular ships and all the ships in the fleet will perform exactly the same action. Fleets are useful for managing empires with large numbers of ships performing similar actions, such as moving to another planet or nuking a planet.

Fleets can be collapsed or expanded. An expanded fleet looks like this:

<input type="hidden" value="-2" name="FleetSelectedOrder0">
  Fleet Strength Next After Max Location Orders
<input type="submit" value="-" name="FltClpse-1"> <input maxLength="23" size="15" value="23026" name="FleetName0"><input type="hidden" value="23026" name="OldFleetName0"><input type="hidden" value="1" name="FleetKey0"> 5% 100% 100% 64.000Staging Area (309,160) <select name="FleetOrder0"> <option value="-1.0">Standby at Staging Area (309,160)</option> <option value="-2.0" selected>Move North to Planet 309,161 (309,161) </option> <option value="-4.0">Move South to We Front (309,159)</option> <option value="-20.0">Disband fleet</option> <option value="-21.0">Disband fleet and dismantle ships</option> </select>
  4 ships BR Next BR After BR Max BR Type Orders
  <input maxLength="23" size="15" value="Broom" name="ShipName0"><input type="hidden" value="Broom" name="OldShipName0"> 0.936 4.000 4.000 4.000 Minesweeper <select name="ShipOrder0"> <option value="-1.0">Standby at Staging Area (309,160)</option> <option value="-2.0">Move North to Planet 309,161 (309,161)</option> <option value="-4.0">Move South to We Front (309,159)</option> <option value="-10.0" selected>Remain in fleet 23026</option> <option value="-11.0">Leave fleet 23026</option> <option value="-7.0">Dismantle</option> </select>
  <input maxLength="23" size="15" value="Broom" name="ShipName1"><input type="hidden" value="Broom" name="OldShipName1"> 0.936 4.000 4.000 4.000 Minesweeper <select name="ShipOrder1"> <option value="-1.0">Standby at Staging Area (309,160)</option> <option value="-2.0">Move North to Planet 309,161 (309,161)</option> <option value="-4.0">Move South to We Front (309,159)</option> <option value="-10.0" selected>Remain in fleet 23026</option> <option value="-11.0">Leave fleet 23026</option> <option value="-7.0">Dismantle</option> </select>
  <input maxLength="23" size="15" value="Doomsday" name="ShipName2"><input type="hidden" value="Doomsday" name="OldShipName2"> 0.936 4.000 4.000 4.000 Attack <select name="ShipOrder2"> <option value="-1.0">Standby at Staging Area (309,160)</option> <option value="-2.0">Move North to Planet 309,161 (309,161)</option> <option value="-4.0">Move South to We Front (309,159)</option> <option value="-10.0" selected>Remain in fleet 23026</option> <option value="-11.0">Leave fleet 23026</option> <option value="-7.0">Dismantle</option> </select>
  <input maxLength="23" size="15" value="Doomsday" name="ShipName3"><input type="hidden" value="Doomsday" name="OldShipName3"> 0.936 4.000 4.000 4.000 Attack <select name="ShipOrder3"> <option value="-1.0">Standby at Staging Area (309,160)</option> <option value="-2.0">Move North to Planet 309,161 (309,161)</option> <option value="-4.0">Move South to We Front (309,159)</option> <option value="-10.0" selected>Remain in fleet 23026</option> <option value="-11.0">Leave fleet 23026</option> <option value="-7.0">Dismantle</option> </select>

The same fleet collapsed looks like this:

<input type="hidden" value="-2" name="FleetSelectedOrder0">
Fleet Strength Next After Max Location Orders
<input type="submit" value="+" name="FltClpse+1"> <input maxLength="23" size="15" value="23026" name="FleetName0"><input type="hidden" value="23026" name="OldFleetName0"><input type="hidden" value="1" name="FleetKey0"> 5% 100% 100% 64.000Staging Area (309,160) <select name="FleetOrder0"> <option value="-1.0">Standby at Staging Area (309,160)</option> <option value="-2.0" selected>Move North to Planet 309,161 (309,161) </option> <option value="-4.0">Move South to We Front (309,159)</option> <option value="-20.0">Disband fleet</option> <option value="-21.0">Disband fleet and dismantle ships</option> </select>
  4 ships: 2 attacks, 2 minesweepers

If all ships in a fleet are colonies, terraformers, troopships or doomsdays, the fleet will offer these ships' special actions as fleet options. Fleets can be merged and can pick up all unaffiliated ships located on the same planet. Fleets containing only ships that are being built can be moved from one builder planet to another.

Disbanding will destroy the fleet and will leave all ships in the fleet standing by at the planet. Disbanding and dismantling will destroy the fleet and set all ships to dismantle, except for ships being build, which will be cancelled.

3.6.2 Color coding

In the various Almonaster game screens, the observant player will notice that some values are coded with different colors, depending on their values. There is a reason for this:

  • Good colors represent values that are positive for an empire. For example, ships that are at full strength (that is, their current BR is equal to their Max BR) will have their BR marked in the good color. Similarly, in the Planets screen, significantly high resource totals will use good text.
  • Normal colors represent values that are factual or average, neither good nor bad.
  • Bad colors represent values that are negative for an empire. In this case of the Ships screen, the Next BR values displayed above are below the Max BR and therefore represent a non-optimal situation where ships will not be at full strength next update.

This scheme extends itself to such aspects as diplomatic settings. For example, allied empires will be represented in good colors, while warring empires will be in bad colors. Map coloring will also use these schemes to represent planets belonging to empires at various diplomatic levels.

The actual colors used to represent good and bad colors are selected by the empire's graphical theme.

3.7 The Build screen

The build screen looks something like this:

Build new ships:

<align="center" border="0" width="70%"> Type Number Name BR Location: Attack <select name="NumShips0" size="1"> <option selected>0</option> <option>1</option> <option>2</option> <option>3</option> <option>4</option> <option>5</option> <option>6</option> <option>7</option> <option>8</option> <option>9</option> <option>10</option> </select> <input maxlength="20" name="ShipName0" value="Needle" size="20"> <select name="ShipBR0" size="1"> <option>1</option> <option>2</option> <option>3</option> <option>4</option> <option>5</option> <option>6</option> <option>7</option> <option selected>8</option> </select> <select name="ShipLocation0" size="1"> <option selected value="0">Mining Co.(63,76)</option> <option value="1">Mining Co. (63,76) in new fleet</option> </select> Science <select name="NumShips1" size="1"> <option selected>0</option> <option>1</option> <option>2</option> <option>3</option> <option>4</option> <option>5</option> <option>6</option> <option>7</option> <option>8</option> <option>9</option> <option>10</option> </select> <input maxlength="20" name="ShipName1" value="Probe" size="20"> <select name="ShipBR1" size="1"> <option>1</option> <option>2</option> <option>3</option> <option>4</option> <option>5</option> <option>6</option> <option>7</option> <option selected>8</option> </select> <select name="ShipLocation1" size="1"> <option selected value="0">Mining Co.(63,76)</option> <option value="1">Mining Co. (63,76) in new fleet</option> </select> Colony <select name="NumShips2" size="1"> <option selected>0</option> <option>1</option> <option>2</option> <option>3</option> <option>4</option> <option>5</option> <option>6</option> <option>7</option> <option>8</option> <option>9</option> <option>10</option> </select> <input maxlength="20" name="ShipName2" value="Seed" size="20"> <select name="ShipBR2" size="1"> <option>1</option> <option>2</option> <option>3</option> <option>4</option> <option>5</option> <option>6</option> <option>7</option> <option selected>8</option> </select> <select name="ShipLocation2" size="1"> <option selected value="0">Mining Co.(63,76)</option> <option value="1">Mining Co. (63,76) in new fleet</option> </select> Engineer <select name="NumShips3" size="1"> <option selected>0</option> <option>1</option> <option>2</option> <option>3</option> <option>4</option> <option>5</option> <option>6</option> <option>7</option> <option>8</option> <option>9</option> <option>10</option> </select> <input maxlength="20" name="ShipName3" value="Warp" size="20"> <select name="ShipBR3" size="1"> <option>1</option> <option>2</option> <option>3</option> <option>4</option> <option>5</option> <option>6</option> <option>7</option> <option selected>8</option> </select> <select name="ShipLocation3" size="1"> <option selected value="0">Mining Co.(63,76)</option> <option value="1">Mining Co. (63,76) in new fleet</option> </select>

Create a new fleet:

Name: Location:
<input maxlength="20" name="NewFleetName" size="20"> <select name="NewFleetLocation" size="1"> <option selected value="7">Mining Co.(63,76)</option> <option value="1">Planet 66,74(66,74)</option> </select>
  • The number is the number of ships of a given type that will be built.
  • The name is the name that all the ships of a given type will receive. This name defaults to the default values specified by the empire in its Profile Editor.
  • The BR is the Max BR at which ships of a given type will be built. More powerful ships are more costly, and sometimes it makes sense to build less powerful ships for certain situations.
  • The location is the planet upon which the ships will be built. Planets must have a certain population level in order to build ships; this level is defined by the game class.

When a fleet is created, it starts out with no ships assigned to it. Ships can either join the fleet via the Ships screen or be built into the fleet via the location drop-down menu, which will include this option if a fleet is located on a builder planet. When ships are built into a new fleet, a new fleet with a random number as its name will be created to contain the ships. If different ship types are build into a new fleet in the same submission, all ships will end up in the same fleet.

The Build screen displays information at the top of the screen about whether builds are visible or invisible in the game.

3.8 The Tech screen

The Tech screen allows empires to choose new ship types that can then be built. New technologies can be developed when new BR levels are reached.

Developed technologies: Undeveloped technologies:
Science Explores unmapped planets
Colony Colonizes and settles uninhabited planets
Minesweeper Nullifies the effects of minefield explosions
<input type="submit" value="Attack" name="Tech0"> Workhorse for defense and attack
<input type="submit" value="Stargate" name="Tech3"> Teleports ships to planets belonging to the same empire
<input type="submit" value="Cloaker" name="Tech4"> Makes itself invisible to other empires
<input type="submit" value="Satellite" name="Tech5"> Cheap immobile defensive force
<input type="submit" value="Terraformer" name="Tech6"> Increases planetary agricultural resources
<input type="submit" value="Troopship" name="Tech7"> Invades enemy planets
<input type="submit" value="Doomsday" name="Tech8"> Makes planets uninhabitable
<input type="submit" value="Minefield" name="Tech9"> Detonates, destroying enemy fleets
<input type="submit" value="Engineer" name="Tech11"> Opens and closes links between planets

3.9 The Quit button

The quit button is only available to an empire when the game it is in has not yet started. It allows empires to cleanly leave a game without being given a loss or a nuke.

3.10 The Exit button

The exit button allows a player to take a break from the game that he or she is in and join another game or edit his or her empire's profile, without actually quitting the empire from the first game.

3.11 Ruins

When an empire becomes idle in a game, sometimes it will be removed from the game as if it had been nuked. This is generally referred to as "falling into ruin". The circumstances under which an empire will fall into ruin are highly gameclass-specific.

If a game has "simple" ruins enabled, it will behave just like classic Stellar Crisis: any empire that has been idle for a gameclass-specific number of updates will fall into ruin and be removed from the game.

If a game has "complex" ruins enabled, then ruins can only occur if all empires except one are idle for a gameclass-specific number of updates. In this case, the idle empires will only fall into ruin if more than two empires were in the game at some point during its lifetime.

When an empire falls into ruin, it is removed from the game as if it had been obliterated, and its Almonaster score is modified as if an empire with identical statistics had nuked it. The Classic Score cost of a ruin is by default -1.0. Empires who win games in which other empires fall into ruin will not gain any nuking or scoring credit for their elimination.

If all empires in a game are idle, then they will all fall into ruin and the game will end.

3.12 Surrenders

In Almonaster games in which the Surrender option is enabled, an empire can surrender to another empire at any moment after the game has started. In order to surrender, 

  • The recipient empire must be at war with the surrendering empire.
  • The recipient empire must never have been allied with the surrendering empire.
  • The recipient empire must accept the surrender.

If surrender is enabled and only two empires remain, these restrictions are relaxed. The remaining empires can surrender via the Options page and no acceptance is required. In this case, the game will end immediately.

The surrendering empire is considered to be nuked by the recipient empire in terms of all relevant statistics and scores. When an empire surrenders, its homeworld resources are reduced by one half, as if the planet had been nuked (note that if an empire's homeworld is annihilated with a doomsday, invaded with a troopship or colonized, its resources are not halved).

In games where classic SC-style surrenders are enabled, any empire can surrender at any time by using the button located in the Options screen. Surrendering empires receive a nuked and are removed from the game. Their homeworlds are labeled "Ruins of <empire name>", and when colonized they give their colonizers a nuke (which counts for all scoring systems). If a surrendered homeworld is not colonized before the game ends, then there are three possible scenarios:

  • When the game ends, no empires remain:  in this case, no empire is credited with the nuke.
  • When the game ends, only one empire remains: in this case the survivor is considered to have nuked the owner of the surrendered empire.
  • When the game ends, more than one empire remains: in this case no one gets a nuke, but the winners receive a partial increase to their Almonaster scores proportional  to the amount they would have obtained had they nuked the surrendered empire themselves. Similarly, the surrendered empire loses an amount of Almonaster score points equivalent to the average of the amount it would have lost had it been nuked individually by each of the survivors.

Empires can only surrender in games that have already closed.

3.13 Randomization

The following actions in Almonaster game play are fully randomized:

  • The order of empire addition to the map during map generation
  • The order of empire action processing during an update
  • The order of ship movement processing during an update
  • The order of ship special action and nuke processing during an update
  • The order of stargates and jumpgates processed during an update
  • The order of diplomacy resolutions during an update

3.14 Independence

If the independence option is enabled for a particular game, then when an empire is nuked its surviving planets remain alive and populated as so-called independent planets, and they cannot simply be re-colonized by other empires. Since they have a life of their own, they must be nuked or invaded in order to be used by other empires. The population of an independent planet will grow or shrink according to the amount of agricultural units the planet possesses. Planets with zero agriculture units will not become independent.

In a game with independence enabled, a dead empire's ships may either disappear, remain independent, or revert to the ownership of the empire who owns of the planet at which the ships were located. The logic is as follows:

  • If the ship is a cloaker, it uncloaks.
  • If the planet a ship is on is unpopulated, the ship will disappear, unless it's a colony, in which case it will attempt to colonize it.
  • If the planet a ship is on is independent, the ship remains alive as an independent ship, and its BR never changes.
  • If the planet a ship is on belongs to a different empire, the ship reverts to the ownership of that empire, regardless of the latter's tech developments. Empires do have the right to reject such independent ship gifts - this can be configured via the Profile Editor and Options screens - in which case the ship will disappear.

The realistic idea behind independence is that when an empire's homeworld is destroyed, the rest of the planets become local fiefdoms with no affiliation with their fellow planets. Ships' crews will go "mercenary" and will either affiliate themselves with their local planets or surrender.

3.15 Etiquette

Almonaster game playing etiquette does not differ greatly from basic Stellar Crisis etiquette. Erick Beck's Guide to Stellar Crisis Etiquette provides an excellent summary of the latter. There are several things I would add, however:

  • Communication is a fundamental part of the game, especially in the case of alliances. Many players will ally with someone and not inform them of their ship movements or overall strategy. This is a mistake.
  • HTML abuse is not a problem in Almonaster because the game does not allow it. Any HTML usage that can affect fellow players is a bug that should be reported and fixed.
  • The ignore option in the Diplomacy screen can be used to filter out messages from unpleasant empires.
  • The game is intended to be fun. Winning, acquiring nukes and incrementing one's scores is only a small part of the game. The larger part is enjoyment, both one's own and that of others. This should be one's guiding factor when deciding how to behave and which persona to adopt while playing. So one should feel free to send lots of messages, joke around, use funny empire names, upload humorous icons and have an all-around good time.  But one shouldn't be upset by losses or nukes. It is, after all, just a game.
  • Players shouldn't just leave a game, even if they're losing badly. Many players will just stop playing when they know they've lost, which costs the other players a few updates' worth of time before the game ends. The best shortcut for the losing player to resolve this situation is to go to the Options screen and resign.

3.16 Web Browser Compatibility

Alájar and Almonaster have been tested mostly with Internet Explorer. Some superficial testing has been performed with Mozilla and Opera, and any incompatibility issues with these browsers are considered bugs in the server.

Known problems with browsers include:

  • Some older versions of Opera, including 3.61, would hang waiting for images to download. This has apparently been fixed in Opera 4.0.
  • Some versions of classic Netscape have the bad habit of fetching the results of a form submission from the browser cache, which obviously won't work well with Almonaster. A workaround is to go to Edit / Preferences / Advanced / Cache and set "Document in cache is compared to document on network" to "Every time". This issue probably causes the icon upload "problems" some people have been seeing with this browser.

4.0 Advanced Topics

This section discusses several topics that users will need to understand in order to become quality Almonaster players. However, novice players may not understanding them fully before acquiring some hands-on experience with the game.

4.1 Ship combat

The formula that decides ship combat is rather complex. A high level overview of the combat sequence can be expressed as follows:

  1. For each set of ships involved in combat (where each empire owns a set), two numbers are calculated:
    a) The sum of the set's combat points, where the combat points for each ship is the square of its current BR.
    b) The sum of all the opposing ship sets' combat points. Only empires at war are counted in this total.
  2. The damage done to an empire's ships by another empire's ships is a percentage of the latter's combat points. This percentage is calculated by dividing the former's combat points by the total number of enemy combat points attacking the latter. In other words, empire A will attack empire B in direct proportion to the significance of empire B in the set of empires that are attacking empire A.
  3. Ships are destroyed until the opposing empire's combat points no longer suffice to destroy any of the remaining ships. At this point, the remaining damage is distributed equally among the remaining ships. With the exception of combat involving carriers, no opposing factions can remain at the end of combat. The only randomization in the algorithm is in the part that decides which ships are destroyed. Therefore, the strongest faction always wins.
  4. If at any point a ship's BR falls below 0.001, it will be automatically dismantled. This will occur early in the update, before ship combat. Ships dismantled in this way will not perform special actions or influence the update in any way.

4.1.1 Ship combat details

Almonaster ship combat follows the Stellar Crisis combat resolution algorithm in all but two details:

From the Stellar Crisis FAQ:

"Combat takes place between warring ships in the same system. Combat is resolved in the following manner:

Preliminary calculations:

Each empire determines their Battle Points.
BP = (sum of the squares of the current BR's of you ships) * (fuel use ratio (if less then one))
A list of all of the empires you are at war with is then made, call it enemy_list.
All of the BP's from those empires on the enemy_list are totaled together, call it enemy_BP_tot.
For each empire in the enemy_list, determine the percentage of enemy_BP_tot that their BP represents, and assign a similar percentage of your BP (call this %_DMG) to their ships' total damage sustained (TOT_DMG).
After this is done for every empire, everyone will have a TOT_DMG.
Combat resolution:

The TOT_DMG is then cut in half. One half of which, is the destruction value for that empire (DEST). The other half of TOT_DMG is the secondary damage value (2DV).

The DEST is then checked against the square of a ship's current BR. If DEST is higher then this then the ship is destroyed. (subtracting the BP of that ship from DEST) This is continued until either the DEST is two small to destroy any more ships, or there are no more ships.
The remaining DEST is then added back onto the 2DV. This is then used to check every ship once again to see if it is destroyed from secondary fire. This can result in destruction of all your remaining ships, of course.
the current_BP for your ship is then determined.
Then your opponent's 2DV is divided by your current_BP to determine the amount of damage sustained by your ships.
Damage Ratio= Opponents 2DV/ Your current_BP
Empires with Damage Ratios above one, have their entire fleet destroyed.
The current BR for the surviving ships is determined by:
Current BR = (1-damage ratio) * Initial BR"

The first difference is that in Almonaster, the percentage of TOT_DMG that is converted to DEST can be configured by the administrator, while in classic Stellar Crisis it is always set to 50%.

The second difference is that if an empire's fuel ratio is below 1.0, Almonaster also multiplies each ship's individual BP by its owner's fuel ratio when calculating the damage done to the ship, while classic Stellar Crisis only applies the fuel ratio to each empire's total BP. In other words, a BR 2.0 ship with a 0.75 fuel ratio can be destroyed with 2.0 * 2.0 * 0.75  = 3.0 DEST points. The advantage of the Almonaster approach is that if two full strength ships of equal BR and sub-1.0 fuel ratios collide, at least one will be destroyed, while in Stellar Crisis both may remain alive. In recent versions of classic Stellar Crisis (3.2.11 onwards) this behavior has been changed to be identical to the Almonaster version.

It should be noted that fuel ratio is only used during ship combat. It does not affect other ship operations such as military level or special actions. When an empire's fuel ratio is below 1.0, it will affect ship combat on the next update. After ship combat is resolved, a new fuel ratio is calculated, which will be used during the following update.

4.2 Overbuilding

Beginning players who have mastered the basics of ship deployment will usually be careful to keep their maintenance ratios above 1.0, in order to keep their ships prepared for engaging in combat at full strength. However, players using this strategy will soon find their ships overwhelmed by larger fleets belonging to more experienced players, created in the blink of an eye to the surprise of the beginners. This happens because experienced players know about overbuilding and are capable of taking advantage of the mathematics of the game.

The reasoning behind overbuilding is simple:  if an empire builds a fleet with enough ships to send its maintenance ratio below 1.0, during the next update all ships belonging to that empire will be very weak and will be easily defeated in combat by inferior forces. However, given an update or two to recover, that fleet will recover its full strength and will be large enough to be capable of defeating fleets that were built with more conservative maintenance ratios.

Some players will overbuild fleets that take two or even three updates to recover, but usually only in desperate situations since the technological cost of building such large fleets is usually very high.

The Next Maintenance Ratio displayed in the ratios bar and on the Info screen can be used to calculate what the strength of a fleet will be in two updates, and is therefore a most valuable tool for the eager overbuilder.

4.3 The Pop Trick

Another observation that newer players will make, when confronted with grizzled veterans, is the facility of the latter to take advantage of a momentary lull in hostilities to manipulate the population on their planets. While the beginner's planets will slowly grow from their original population of colonists to full builder status, the experienced player will be able to build at his or her frontier planets in a mere couple of updates, and will therefore have a large advantage in the subsequent war.

The reason this is possible is again due to the mathematics of the game. Given the way the Ag Ratio is calculated (essentially Total Agriculture divided by Total Population), the savvy player can manipulate his or her planets' populations so that in a subsequent update the Agriculture Ratio will be very large and by the next update the planets' populations will be greatly increased. This procedure is known as the pop trick.

For example, an empire has three planets with the following characteristics:

  1. 100 agriculture, 100 population
  2. 60 agriculture, 5 population
  3. 20 agriculture, 16 population

A successful pop trick at this stage will look like this:

  1. Set the planets' maximum populations to 4, 2, 1 respectively.
  2. End turn: after the update the planets' populations will be 4, 2, 1, respectively. The agriculture ratio will be 180 / 7 = 25.814
  3. Set the planets' maximum populations to 100, 50, 20, respectively.
  4. End turn: after the update, the planets' populations will be 100, 50 and 20, respectively

The risk here is that during the update in which the planets' populations are low, the empire cannot have a significant number ships alive, or its maintenance and fueling demands will far outstrip its available resources, which will lead to a large technology decrease. Consequently, the empire will be vulnerable to a stray science ship or a well-placed cloaker.

Experienced players usually know how to find the best time to perform a pop trick, but even they can sometimes be burned. A pop trick can be risky, but it does bring great advantages when used successfully.

4.4 Custom GETs

It is possible for players to reach screens inside an Almonaster server without passing through the login screen. This can be done by submitting a GET request with a URI formed in the following manner:


where X is the empire's name, Y is its password and Z is the desired page id.

In a regular web browser, an sample URL would look like this:

Here, the empire name is "Destroyer" and the password is "ofplanets99". The page id requested is that of the Open Game List.

To request a page from an active game, the gameclass id and game number must be known.  The URL would look like this:

The page ids that can be requested are the following:

Active Game List 1   Planets 22
Login 2 Options 23
New Empire 3 Build 24
Open Game List 4 Ships 25
System Game List 5 Game Server Information 26
Profile Editor 6 Game Documentation 27
Top Lists 7 Game Server News 28
Profile Viewer 8 Game Profile Viewer 29
Server Administrator 9 Game Contributions 30
Empire Administrator 10 Game Credits 31
Game Administrator 11 Game TOS 32
Theme Administrator 12 Game Quit 33
Personal GameClasses 13 Latest Nukes 34
Chatroom 14 Spectator Games 35
System Server Information 15 System Contributions 36
System Documentation 16 System Credits 37
System Server News 17   Latest Games 38
Info 18   Tournament Administrator 39
Tech 19   Personal Tournaments 40
Diplomacy 20   Tournaments 41
Map 21   System TOS 42

4.5 Security

There are several aspects to security in Almonaster:

4.5.1 HTML filtering

When a screen is rendered for a player, strings provided by other players such as empire names or messages may be used to provide content. All such strings are filtered for HTML or script tags before being displayed. If a player is capable of injecting HTML or script into another player's screens, then it is a bug in the server.

4.5.2 Session Ids

Each empire on an Almonaster server is assigned a 64-bit integer called a Session Id, which is stored in the server's database in association with the empire's information. Session Ids are used for game screen password hashing and for security measures involving the detection of multiple empires in the same game. A Session Id is also stored on a player's hard drive as a cookie, so it is common for multiple empires owned by one player to use the same Session Id. When the Session Id in the cookie conflicts with the Session Id stored in the database, the version stored in the cookie wins and overwrites the version stored in the database.

If a player 'loans' an empire to another player by giving the latter its password, it is possible that the server might conclude that the empire in question really does belong to the second player. This can lead to situations where the second player's empires is denied access to games in which the shared empire is participating. In these cases, manual editing of cookies or administrative intervention are usually the only means of resolving the problem.

4.5.3 Passwords

Players often find themselves wanting to save game screens, especially maps, in order to document a game or show off their nuking prowess. In most versions of Stellar Crisis, it is necessary to remove the password field from the HTML text before making it public, because the value could be used by other players to hack into the empire used to generate the screen.

Almonaster solves this problem by using the player's IP address and Session Id to provide uniqueness to the password hash stored in each game page. This additional security can be configured by selecting the respective options in the Profile Editor. If an attacker wanted to use the password value stored in such a page, he would have to guess the empire's Session Id and the IP address from which the empire generated the posted screen. A further means of defense is accomplished by including a 'salt' value in the password hash that represents the time at which the hash was generated. Hashes with salt older than 24 hours are rejected by the server as timed out submissions, so the attacker would either have to be operating within a day of the page generation, or find a time in the last day for which the hash computation is identical. The former is impossible if the page is older than a day, and the latter is either impossible or computationally impractical.

4.5.4 Game entry filtering

As described in section 2.25, the creators of a game can choose to exclude specific empires from entering that game. They can also block empires with duplicate Session Ids and IP addresses and filter empires by score.

4.5.6 In-game message filtering

Players can choose to block the messages from specific empires. They can also choose to block all broadcasts.

4.6 Tournaments

The objective of tournaments is to allow administrators and privileged players the opportunity to organize games with pre-defined sets of empires and alliances. Tournaments were conceived as a means of providing server-side support for the Stellar Kings Team Challenge, but they have many other uses.

Tournaments consist of the following elements:

  • A name, an icon, a description, a webpage link and recent news items
  • A set of gameclasses belonging to the tournament.
  • A set of empires who have joined the tournament.
  • A set of teams to which empires can be assigned.
  • A set of active games.
  • For each empire and each team, a record of wins, nukes, nuked, draws and ruins incurred while playing tournament games.

The creator of a tournament is its owner, with the exception of system tournaments which are owned by all empires with administrative privileges. Only the owner of a tournament can administer it. Tournament administration consists of setting the tournament parameters, creating or deleting gameclasses, inviting or deleting empires, creating teams, assigning empires to teams, starting games and administering games.

Gameclasses created for a personal tournament do not count against the empire's overall limit of personal gameclasses. There is a limit to the number of personal tournaments an empire can create, and there is a limit to the number of gameclasses that can be created per personal tournament.

In order for an empire to join a tournament, both the empire and the tournament owner must agree. A tournament owner can issue an invitation to the empire, which the latter must accept, or the empire can request to join the tournament, after which the owner can accept or decline. Empires can mark themselves as being unavailable for tournament games, which means that tournament owners cannot use their empires to create a new tournament game. Empires can remove themselves from tournaments they have joined through the Profile Editor.

It is up to the discretion of the tournament owner to place joined empires within the teams created for the tournament. Empires can be added and removed from teams, or moved between teams. When an empires leaves a team, it carries its score along with it, but the team's score will remain the same. Therefore, a team's score will not always be the sum of its component empires' scores.

Tournament games have the following unique properties:

  • Tournament games must have a fixed number of empires; i.e., the minimum and maximum number of empires must be equal.
  • Tournament games always begin and close at the same time (when all players are joined).
  • Tournament games never have any latecomers.
  • There is no password protection, empire filtering or blocking in tournamnet games.
  • Empire names are always exposed.

When the tournament creator starts a game, he or she can choose from among the empires and teams belonging to the tournament to populate the game with empires. If there is a team with more than one empire, the creator has the option to select from the following options:

  • Empires begin the game already allied with their teammates.
  • Empires begin the game having already met their teammates. This option is only available if the gameclass does not have exposed diplomacy.
  • No special team options.

Aside from this, games created within tournaments are played in identical fashion to any other game on the server. The tournament creator, however, can administer games created through his tournament as if he were an administrator. This includes:

  • Viewing the full game map.
  • Forcing an update in the game.
  • Pausing the game.
  • Viewing full empire information inside the game.
  • Deleting empires from the game.
  • Sending messages to all empires in the game.
  • Killing the game.

5.0 Administration

This section describes Almonaster's administrative interface (i.e., the set of additional screens available to empires with administrative privileges)

5.1 The Server Administrator screen

This screen allows an administrator to perform the following tasks:

  • Change the server's name.
  • Change the administrative email address displayed on every screen.
  • Change the default alien icon.
  • Choose the system's default UI elements.
  • Create a new empire.
  • Change the way privileges work on the server (either administratively assigned, or score-based).
  • Change the Almonaster score needed to reach the status of apprentice or adept.
  • Change the icon used for system messages.
  • Change the maximum allowed number of saved game and system messages.
  • Change the default maximum allowed number of saved game and system messages.
  • Change the maximum allowed size of uploaded alien icons.
  • Change the number of nukes listed in an empire's nuke history.
  • Change the number of nukes listed on the Latest Nukes screen.
  • Change the number of games listed on the Latest Games screen.
  • Change the number of updates the server must be down before a game is deleted (except if the game is a longterm).
  • Change the update duration for a game to be considered a longterm.
  • Change the frequency with which the server scans for Bridier Index decay.
  • Rebuild the system Top Lists, on the unlikely event that they become corrupted.
  • Enable / disable non admin empire logins, new empire creation, new game creation and access to the server for non administrative empires.
  • Shutdown the server, restart the server and restart the Almonaster page source.
  • Flush the database's dirty pages to disk.
  • Purge the database of empires that match certain characteristics. Purges can be tested before being put into effect.
  • Backup the database, view all backups and restore or delete a database backup
  • Create a new alien icon by providing the new key, the author's name and an uploaded file (which must be a transparent gif within the size parameters accepted by the server).
  • Delete an alien icon by providing its key
  • Change the default ship names provided to new empires
  • Edit the text above and below the name/password form on the Login screen.
  • Edit the news displayed in the Server News page.

5.2 The Empire Administrator screen

This screen allows an administrator perform advanced searches for empires, based upon various criteria. The chosen fields are AND'ed together, which means that a search with multiple fields selected is understood as a query of the type "list all empires whose names contain the letter 'w' and whose email addresses contain the string '' and who have between 3 and 6 wins".

The administrator can perform the following actions upon an empire:

  • Change their privilege levels, privilege types (score-based or fixed), passwords and scores
  • Toggle their broadcast privilege

  • Reset their session ids

  • Look up the DNS names for their IP addresses

  • Obliterate them (obliterated empires are removed from any games they are participating in and deleted from the server).

The Empire Administrator screen also allows administrators to broadcast a message to all empires on the server.

5.3 The Game Administrator screen

This screen allows an administrator to perform the following tasks:

  • Pause and un-pause all games.
  • Reset the update periods on all games
  • Create, rename and delete superclasses.
  • Create, halt, un-halt and delete gameclasses.
  • Change the default limits on system and personal gameclass characteristics.
  • View and modify any active games:
    • Pause a game.
    • Delete a game.
    • Reset the update period on a game.
    • Broadcast messages to all empires in a game.
    • Force a game to update.
    • Removed empires from a game.
    • Restore resigned empires to a game.
    • Search for empires with matching IP addresses or Session Ids in a game.
    • View the full map of the game.
    • View a table with the full statistics of all empires in a game.
  • Change server-wide settings for games and gameclasses.

The server-wide settings that can be changed listed below.

Gameclass parameters:

  • The maximum number of empires in a system gameclass.
  • The maximum number of planets in a system gameclass.
  • The maximum average number of resources per attribute per planet in a system gameclass.
  • The maximum initial tech level in a system gameclass.
  • The maximum tech development in a system gameclass.
  • The minimum update time in a system gameclass.
  • The maximum update time in a system gameclass.
  • The maximum number of personal gameclasses per empire.
  • The maximum number of personal tournaments per empire.
  • The maximum number of gameclasses per personal tournament.
  • The maximum number of empires in a personal gameclass
  • The maximum number of planets in a personal gameclass.
  • The maximum average number of resources per attribute per planet in a personal gameclass.
  • The maximum initial tech level in a personal gameclass.
  • The maximum tech development in a personal gameclass.
  • The minimum update time in a personal gameclass.
  • The maximum update time in a personal gameclass.
  • The privilege level required to create personal games and gameclasses with unlimited empires.
  • The initial state of games (paused or not paused).

Game parameters:

  • The Percent of damage used to destroy (DEST). This is the percentage of TOT_DMG is converted to DEST during ship combat (see section 4.11 for more details on this). As this value increases, more ships are destroyed during combat, and the BR of the surviving ships becomes higher. On classic Stellar Crisis servers, this value is typically 50%.  On Almonaster servers, it is usually 60%.
  • The Percent econ increase on first trade. This is the percentage by which an empire's resources increase when its first trade agreement is established.
  • Percent of previous econ increase on next trade. This is the percentage of the previous increase in an empire's resources when its last trade agreement was established that should be used to calculate the increase for the next trade agreement. For example, if the first increase was 10% and this value is set to 90%, then the second trade agreement will give an 9% increase, the third 8.1%, etc. All percentages apply to the original totals, not the stacked totals.
  • Percent of full tech increase for late entrances. This is the percentage of the maximum possible tech increase given to latecomers in a game. The maximum possible tech increase is the maximum tech development for an update, as defined by the gameclass, multiplied by the number of updates the newly arrived empire has missed. This value is then multiplied by the percentage to given the final tech increase for the latecomer.
  • Number of nukes before planet is quarantined. This is the number of nukes it takes for a planet to become temporarily annihilated. After this number is reached, the planet is considered to have been ecologically damaged. Any subsequent nuke will result in an immediate period of quarantine.
  • Number of updates in quarantine after planet is nuked. This is the number of updates a planet will be in quarantine after it is nuked the number of times selected in the previous option.
  • Update delay after a weekend for non-weekend-update games. This is the time added to the weekend update period of all non-weekend-update games. The additional time is added to avoid updates that would occur before players with no weekend access were able to access the server. Most servers will have players logging in from all possible time zones, some with completely different schedules to the local time the server is set to. This value can be set to at most 12 hours.
  • Maximum number of updates before games close. This is the value used to make sure that games close after a reasonable period of time. Because open games cannot end, games with unreasonably large values for this setting can consume server resources unnecessarily. This value provides a cap on such resource usage.
  • Default number of updates before games close.
  • Default Bridier configuration for grudge games (count for Bridier or not)
  • Default configuration for exposing empire names in game lists.
  • Default configuration for exposing appropriate games to spectators
  • Default entry blocking of empires based on duplicate IP addresses and Session Ids.
  • Default entry blocking of empires that are idle in other games.

Ship parameters:

  • Colony settings. They determine the population cost of a colony ship, as well as the population a colony will deposit. Build costs can be either simple (a fixed value) or multiplied (a fixed value times the ship's BR), while population deposit can be either multiplied (a fixed value times the ship's BR) or exponential (the ship's BR to a fixed power).
  • Engineer BR cost of opening of closing links.
  • Stargate settings. They determine if range limitations are enabled, the range factor and the BR cost of gating ships. The range factor is multiplied by the distance to a planet to give the BR the gate needs to reach the planet. The distance between two planets is the greater of the differences between their X coordinates and their Y coordinates. E.g., the distance between Planet 3,4 and Planet 7,16 is 16 - 4, which is 12. With a range factor of 0.5, a 12 * 0.5 is 6, so a BR6 gate is required to send ships from one planet to the other.
  • Jumpgate settings. They are determined by the same parameters used for stargates.
  • Terraformer agriculture multiplier. This is the factor that multiplies a terraformer's BR to determine the agriculture increase that it will provide when terraforming a planet. This value is capped by the maximum of the fuel and mineral totals available to the planet.
  • Troopship invasion multiplier. This is the factor that multiplies a troopship's BR to determine the planetary population it can successfully invade.
  • Troopship failure factor. This is the factor that multiplies a troopship's BR to determine the planetary population it will kill when an invasion fails.
  • Troopship success factor is the factor that multiplies a planetary population to determine how many units are killed when an invasion is successful.
  • Doomsday annihilation multiplier. This is the factor that multiplies a doomsday's BR to determine the number of updates a planet it annihilates will remain in quarantine. Quarantine is defined in section 2.5.1.
  • Carrier battle cost. This is the BR a carrier will lose after engaging in a battle in which its special DEST absorption abilities are used. Carriers absorb the square of their BR in DEST when targeted for DEST damage, but are otherwise unaffected, aside from their battle cost. See section 4.11 for more details on ship combat and how DEST operates.
  • Builder minimum BR. This is the minimum BR needed for a builder to be able to create a planet. Planets created by builders with BR above this minimum will be allocated resource totals according to the following formula:  BuilderResourceMultiplier * (average planet for game) * ((BR - BuilderBRDampeningFactor + 1) / BR) ^ 2.
  • Builder Resource Multiplier. This is the factor mentioned in the formula above.
  • Builder BR Dampening Factor. This is the factor mentioned in the formula above.
  • Cloaker behavior. This determines if cloakers are built cloaked or uncloaked by default.
  • Morpher behavior. This determines if morphers are cloaked or uncloaked by default when they morph into cloakers.
  • Morpher morphing cost. This is the BR cost of changing a morpher from one ship type to another.
  • Compatibility flags. These are options that enable server administrators to disable new ship behavior present in Almonaster but not in classic Stellar Crisis. These flags include:
    • Disable terraforming non-owned planets
    • Disable multiple terraformers acting on one planet during an update
    • Disable terraformer survival after terraforming
    • Disable troopship survival after invading
    • Disable minefield detonation

Map parameters:

  • Percent chance a planet will be a linked to an adjacent planet. This represents the chance that a new link will form after a new planet is created next to an old planet that it was not initially linked to. This defines the degree of 'connectedness' of maps.
  • Resource allocation deviation multiplier. This is the factor that multiplies the average resource totals for a planet and determines the maximum number of resources available to a planet. For example, if average agriculture value is 30, and the deviation multiplier is 6, then a planet can have up to 30 * 6 = 180 units of agriculture, minerals or fuel. In a nutshell: the greater this value, the greater the disparity between resources allocated to different planets on the same map.
  • Maximum map deviation. This is the number that places a cap on the random deviation of the first planet placed on the map from the central X,Y coordinate. This is important because if this value is small sometimes empires can use the coordinates of their homeworld to determine their location and the probable direction of their foes even before exploring their map.
  • Percent chance a new planet will be linked to the last created planet (large map). This represents the chance that, when generating a map, a new planet will be linked to the last created planet, instead of a random planet in the new chain. This value applies to large maps.
  • Percent chance a new planet will be linked to the last created planet (small map) is the same value applied to small maps. These two values determine how spread out the map will be, how many planetary chains will form and how much empty space will appear between clusters of planets. In general, the larger these percentages, the smaller the chance of large planetary clusters forming.
  • Large map threshold. This is the number of planets per empire required for a map to be considered "large".

5.4 The Theme Administrator screen

This screen allows an administrator to perform the following tasks:

  • Add a new theme
  • Delete an existing theme
  • Configure the system's themes and change any of their parameters:
    • Name
    • Version
    • Filename
    • Author's name
    • Author's email
    • Description
    • Checkboxes for the following elements
      • Background
      • Live planet
      • Dead planet
      • Separator
      • Buttons
      • Horizontal link
      • Vertical link
    • Text color and table color

5.5 The Tournament Administrator screen

This screen allows an administrator to create and administer system tournaments. Tournaments are explained in detail in section 4.6.

6.0 Installation and Maintenance

This section describes aspects of Almonaster useful to system administrators.

6.1 System Requirements

Minimal system requirements for an Almonaster server are as follows:

  • A supported Windows OS:
    • Windows XP SP3 / 2003 Server SP2
    • Windows Vista / Server 2008
    • Windows 7 / Server 2008 R2
  • 100 MB of dedicated RAM
  • 250MB of disk space
  • A reasonably fast computer
  • A fast network connection

6.2 Setting up an Almonaster server

Installing Alájar and Almonaster is a straightforward procedure:

  1. Ensure TCP/IP is working.
  2. Install a flavor of SQL Server.
  3. Unzip the binary distribution into an unused directory. Ensure all file names and directory structures are preserved.
  4. Edit the configuration files in bin\alajar.conf and site\config\*.conf. Each parameter is commented in its respective file. The following parameters need special attention:
    1. Edit site\config\admin.conf to change the default remote administrator's password.
    2. Edit site\config\default.conf to set the connection string for database access.
  5. Run alajar.exe from a command prompt, or install the alajarsvc.exe service.
  6. The first run of the program will create the default database using the connection string information in site\config\default.conf. Needless to say, the process will need access to the database. One technique that works well is to run first as a database admin to create the default database and tables, then grant access to a standard user and run Alájar as that user.
  7. Log into Almonaster and change the default root empire's password. The default credentials are:

    Login: root
    Password: neil:young

  8. To shut the server down, log into http://localhost/admin/ with the username and password from admin.conf and select the server showdown option, or type ctrl-c in the alajar.exe console window, or stop the alajarsvc.exe service.
  9. Using SSL with a signed certificate is highly recommended.

Uninstalling Alájar and Almonaster is even more straightforward:

  • Delete the directory in which the server was installed.
  • Delete the database used by the server.

To run Alájar as a system service, open a command prompt with administrative permissions and run “alajarsvc.exe -install” to install the service. Then use the Services MMC to set the service to autostart, restart on failure, and depend on the relevant SQL Server service.

After this, connecting to http://localhost/ or in any web
browser should display the Almonaster login screen. The server’s port number can be changed in the site\config\Alajar.conf file.

More detailed information on configuring Alájar can be found on CodePlex.

The Almonaster page source contains the following specific parameters inside its page source configuration file:

  • DatabaseLibrary is the name of the binary that implements ISqlDatabase. This should always be SqlDatabaseBridge.dll
  • DatabaseClsid is the Uuid of the class that implements ISqlDatabase. This should always be F0E65B48-F797-4E57-8459-C0EE4FC7BE9C.
  • DatabaseConnectionString is the connection string to the SQL Server database used to store game data. This must be set by the local system administrator.
  • ResourceDirectory is the directory where system resources are kept. This directory must be placed below the BasePath.
  • ChatroomMaxNumSpeakers is the maximum number of simultaneous speakers allowed in the chatroom.
  • ChatroomNumMessages is the number of messages kept in the chatroom's message buffer.
  • ChatroomMaxMessageLength is the length that long chatroom messages will be truncated to.
  • ChatroomTimeOut is the number of seconds a speaker may remain in the database without refreshing the screen or posting a message.
  • ChatroomPostSystemMessages is 1 if the system should post messages concerning enter, leave and timeout events, 0 if not.
If errors occur during startup or during execution, extended error information will be available in the various site\report files.

In addition to root, another default empire is guest. This empire provides read only access to the Open Game list, and its password does not need to be changed. The default credentials are:

Login: guest
Password: crazy:horse

The text displayed on the server's login screen can be customized by editing the resource\text\intro.html file, which contains the text printed on the left-hand side of the screen. Other files of interest can be updated through the Server Administrator page when the server is active.

6.3 The Almonaster database

In builds 700 and above, Almonaster uses SQL Server as its database store. All requests are executed transactionally against the database. In general, the contents of the database should not be modified manually while the game is actively running.

6.4 Maintaining the server

Once the server is up and running, some tasks need to be performed in order to maintain it adequately:

  • The administrator should establish the correct number of server threads to use with the server. If users report delays in the servicing of requests, but the reported average scripting times are normal, then the threadpool should be assigned more threads in bin\alajar.conf.
  • If the server is thrashing the disk, in all likelihood it is because there is not enough physical memory on the computer for <emAlmonaster to run properly and for SQL Server to cache the Almonaster database.
  • The administrator should ensure that there is enough disk space available for the database to expand as needed.
  • The administrator should log onto the server every once in a while to check for messages from other empires.
  • The Almonaster code generally does a good job of imposing limits and quotas on empire activity. However, Almonaster, like any other online games, can be vulnerable to spamming and un-sportsmanlike behavior on the part of players. If a player are is to be over-using server resources in some fashion, or making games unpleasant for other players, the administrator is encouraged to delete their empires from the server database and report the players to their ISP's. If certain IP addresses are determined to be responsible for any kind of unacceptable behavior, the administrator can block these users via the Alájar IP address blocking feature.
  • The administrator should configure SQL Server to back up the database automatically and frequently. While the game's transactional code should be sufficient to avoid data corruption, hard drives do fail.
  • Bugs, crashes and memory leaks that can be pinned down to specific actions and reproduced should be brought to the attention of the developer or current maintainer of the Almonaster source code.

6.5 The administrative page source

The Alájar web server provides a password protected administrative page source that allows remote administration of the server. Almonaster administrators may find this useful to:

  • View server statistics.
  • Restart or shut down page sources.
  • View page source logs and report files.
  • Restart or shutdown the server.
  • Release files from the file cache.
  • Change page source config file parameters.

The administrative page source can be accessed in a web browser via http://servername/admin/.

7.0 Development

This section describes aspects of Almonaster useful to developers.

7.1 System Architecture

Almonaster is a page source plug-in for the Alájar web server. The Almonaster game code registers itself as the recipient of HTTP requests directed at specific URLs, and responds by supplying HTML code to return to the client.

Almonaster itself is essentially a three-tier system. Its modular design incorporates the following components:

  1. The page source module implements Alájar's event-driven interface.
  2. Various webpage modules implement the functionality of the different game pages.
  3. The GameEngine module controls the rules of the game and serves information to the web pages.
  4. The Database module stores data for each empire and each game, and provides data caching to ensure responsive performance..

This is a simple ASCII art flow-chart of the modules:

HTTP clients ----------------> Alájar HTTP endpoints<----------------- HTTP clients


Almonaster page source

/ | \

Webpage modules





From a high-level point of view, the system operates as follows:

  1. A form submission is received by Alájar, which determines the appropriate page source recipient by decoding the URL from the HTTP headers.
  2. If the recipient is Almonaster, information about the request is sent to the Almonaster page source, which determines which page the client is interacting with by examining the form values contained in the request.
  3. Once this is determined, the web page module code processes the incoming request and generates a response. The game engine is queried for specific information needed to construct the page. The database is called in order to read or write game or empire-specific information.
  4. When the page generation process has completed, a response is sent back to Alájar in HTML form for transmission to the client.

7.2 Source Code

Alájar and Almonaster are free software. Their source code can be downloaded and inspected, and custom modifications can be made.

The vast majority of the game code is platform independent, and platform specifics are well abstracted in various libraries. To encapsulate advanced functionality such as threading and synchronization, the codebase uses of a set of classes called OSAL (Operating System Abstraction Library). The database library used by Almonaster is written in managed C++ and depends directly on SQL Server.

Because of this, ports to other operating systems should be relatively simple, since they only require a port of the Osal libraries and the SqlDatabase. While the source distribution also contains a partial Linux port contributed by Austin Che, it has not been maintained recently. If you are interested in improving the existing ports or working on new ones, please contact the current maintainer.

7.3 Compilation

To build Almonaster for Windows, obtain the source code from CodePlex, open the Almonaster.sln solution and compile it.

At the time of writing, Almonaster is compiled and tested with Visual C++ 2010.

7.4 Graphics

It is possible to dynamically add new themes to an Almonaster installation. Almonaster graphics consist of a set of themes, enumerated in the resource directory. A theme contains some of the following elements:

  • A live planet icon, 40x40: planet.gif
  • A dead planet icon, 40x40: planet2.gif
  • A separator bar, approximately 500x16: separator.gif
  • A background, of a reasonable file size: background.jpg.
  • A set of buttons.
  • A horizontal link bar, 7x1: horz.gif
  • A vertical link bar, 1x7: vert.gif
  • Various colors, expressed in HTML RGB format (e.g., FF40A2):
    • A text color, used for most text on the screen
    • A good color, used to indicate positive statistics and facts (see Section 3.6.2 for more details)
    • A bad color, used to indicate negative statistics and facts
    • A private color, used for the text of private messages (with the exception of messages sent inside a game by the system)
    • A broadcast color, used for the text of broadcast messages
    • A table color, used for tables with background colors

All gif's used for both icons and themes should be in GIF'89 transparent format.

The Null Theme is stored in the resource directory, as is the Almonaster logo (almonaster.gif) and the independent planet icon (independent.gif). The dot.gif file is used to enable login using the return button. The paypal.gif is used in the contributions page.

7.4.1 Buttons

The following buttons are used in an Almonaster theme:

<big>File name</big>



Active Game List

Add.gif Add
AdministerGame.gif Administer Game


Advanced Search




Almonaster Score






Blank Empire Statistics

Block.gif Block
BridierScore.gif Bridier Score








Cancel All Builds

Carrier.gif Carrier


Change Empire's Password

ChangePassword.gif Change Password
Chatroom.gif Chatroom




Classic Score






Create Alien Icon


Create Empire


Create New GameClass

CreateNewSuperClass.gif Create New SuperClass


Create New Theme
DeleteAlienIcon.gif Delete Alien Icon
DeleteBackp.gif Delete Backup


Delete Empire


Delete GameClass


Delete SuperClass


Delete Theme








Empire Administrator


End Turn




EstablishedBridierScore.gif Established Bridier Score


Flush.gif Flush
ForceUpdate.gif Force an Update


Game Administrator
HaltGameClass.gif Halt GameClass


Join.gif Join
Jumpgate.gif Jumpgate


Kill Game
LatestNukes.gif Latest Nukes


Leave the Chatroom








Minus.gif -


ObliterateEmpire.gif Obliterate Empire


Open Game List




Personal GameClasses
PauseAllGames.gif Pause All Games
PauseGame.gif Pause Game


Plus.gif +


Profile Editor


Profile Viewer






Refresh Messages
Remove.gif Remove
RenameSuperClass.gif Rename SuperClass
Reset.gif Reset
Resign.gif Resign
RestartAlmonaster.gif Restart Almonaster
RestartServer.gif Restart Server
RestoreBackup.gif Restore Backup
RestoreEmpire.gif Restore Empire










Send Message


Server Administrator
ServerNews.gif Server News
ServerRules.gif Server Rules




Shutdown Server
Speak.gif Speak








System Game List






Theme Administrator


Top Lists
Tournaments.gif Tournaments




Undelete Empire


Undelete GameClass


Unend Turn
UnhaltGameClass.gif Unhalt GameClass
UnpauseAllGames.gif Unpause All Games
UnpauseGame.gif Unpause Game


View Empire's GameClasses


View Empire's Nuke History
ViewEmpiresTournaments.gif View Empire's Tournaments
ViewGameInformation.gif View Game Information
ViewMap.gif View Map
ViewMessages.gif View Messages


View Profile

Last edited Oct 11, 2011 at 7:40 AM by mfeingol, version 9


No comments yet.