[PHost Logo]© 

Alliances
The Portable Host
Version 3.2.3.3 
INDEX

Introduction

If two players want to co-operate in a game they need to share information and to co-ordinate their actions so that their ships and planets work with each other. In HOST games, locking alliance friendly codes implement a limited form of co-operation. PHOST implements an alliance mechanism that is more extensive, configurable, and also addresses the issue of information sharing between allies.

PHOST supports formal alliances between players by modifying its behavior as necessary in order to enable the allies to easily co-operate. Thus, allies can fly through each other's minefields (without matching friendly codes), allies can avoid fighting each other in combat (without matching friendly codes), allies can see each other's ships, and so on. Moreover, each of these alliance features can be tailored for each alliance so that different levels of trust and co-operation can be established. Team games especially benefit from PHOST's implementation of alliances.

Back to the index 

Alliance Mechanics

Alliances are formed and broken by using the allies command of the PHOST command processor. Briefly, to offer an alliance to another player, a player must send a command message (i.e., a message to himself) that reads:
allies add 5

where the '5' indicates that the player wishes to offer an alliance to Player #5. Any player number from 1 to 11 can be specified. To rescind the alliance offer (and break the alliance, if it has been formed) a command message must be sent that reads:

allies drop 5

where, once again, the '5' is just an example and would be replaced with the desired player number. The different levels of alliance are modified using the config subcommand:

allies config 5 +ship -mines +combat

The "Command Processor" page describes the above commands in more detail.

For each turn that a player is involved in alliances, PHOST will send a message summarizing the status of alliances (offered, requested, or accepted). This message contains information that takes into account all alliance management activity submitted by players for that turn (i.e., the status messages are sent after all processing of alliance commands for all players is complete). See the Examples section below for examples of alliance status report messages.

Changes in alliances may take effect either before or after host processing, depending upon the DelayAllianceCommands configuration option. If DelayAllianceCommands is disabled, then alliance management commands are processed as soon as they are received, before movement and before combat. This allows a player to "backstab" an ally by breaking the alliance and attacking in the same turn. If DelayAllianceCommands is enabled, alliance management commands are remembered but not implemented until after host processing. This gives players one turn in which to notice that an alliance has been broken and to prepare for any subsequent action by the former ally. In any case, the alliance status message generated by PHOST will always reflect the updated state of all alliances.

Back to the index 

Alliance States

An alliance may be in one of three states: An offer of alliance need only be submitted once, it is remembered for the duration of the game or until it is rescinded with a drop command. Once the target of the alliance also sends an add command with the first player as the target, the alliance is complete. If either player sends a drop command, the alliance is broken, but the other player's alliance proposal is still pending and may be used to re-form the alliance (a good tactic if the other player forgets to issue a drop after being backstabbed!)

==> It must be noted that none of the alliance features are in operation, for either player involved, unless both players offer alliances to each other, thus bringing the alliance to the accepted state. Thus, even if player A offers an alliance to player B, player B cannot take advantage of alliance features until he too offers an alliance to player A. The Examples section in this page shows an example of alliance negotiation.

Back to the index 

Alliance Levels

An alliance is characterized by the following five levels: More details on the above levels are presented in the next section.

Back to the index 

Trust

Each alliance level may be granted or denied to an ally, implying varying levels of trust. Each alliance level may be in one of three states: By default, when an alliance is created, all levels are disabled (no trust is assumed). The alliance levels may, however, be modified in the same turn that the alliance is offered.

Note that an alliance need not be symmetrical in these levels. For example, player 1 may allow player 2 vision but player 2 may disable vision to player 1. Note that the combat level of alliance makes little sense unless it is symmetrical.

==> Conditional alliance levels allow players to set up alliances in which there is no risk. By requiring that the ally also enable the same level of alliance to the player, both players either do get or both do not get the benefit of the alliance level.

The following table summarizes who benefits from alliance levels depending upon the alliance level state of each player. Each box indicates which player (player 1, player 2, both players, or neither player) benefits from the combination of enabled, disabled, and conditional states. 

Player 2 Offers 
+ 
- 
~ 
Player 1 
Offers 
+ 
  Both benefit  2 Benefits  Both benefit 
- 
 1 Benefits  None benefit  None benefit 
~ 
 Both benefit  None benefit  Both benefit 
Back to the index 

Detailed Alliance Level Operation

Each level of alliance modifies PHOST behavior in some specific ways. These modifications are described below. The descriptions follow the convention that they are written from the point of view of the player offering the level of alliance to his ally.

Ship Alliance Level

==> Notes for DOS Planets, VPA, and shareware WinPlan users:

Planet Alliance Level

==> Notes:

Minefield Alliance Level

Combat Alliance Level

Vision Alliance Level

==> Notes for DOS Planets, VPA, and shareware WinPlan users: Back to the index 

HOST Alliance Compatibility

Clearly, PHOST's alliance mechanism is different from the "locking alliance codes" recently implemented in HOST 3.2. Some add-ons, however, make use of HOST-type alliance information to modify their behavior, but do not take PHOST games, and PHOST alliances, into account. To enable these add-ons to work equally well with PHOST, a bridge between PHOST alliances and HOST alliances has been implemented in PHOST 3.

This bridge works as follows. When a player in a PHOST game enables all five alliance levels to another player (either conditionally or unconditionally), this becomes the equivalent of using the ffX friendly code in a HOST game (==> but note that PHOST does not recognize the ffX nor the eeX friendly codes).
Thus, an add-on program that only reads HOST-type alliance information will see that this player has offered an alliance. Note that a reciprocal alliance offer is not needed, it is simply the offer of an alliance (on all 5 alliance levels) that is of interest.

There are some implementation issues that are worthy of note. On every turn, PHOST checks the alliance status of all players and writes out the equivalent HOST-type alliance information to the GREY.HST file (this file is used by HOST for storing alliance information). If a player has offered all five alliance levels to another player, then the GREY.HST file is marked as if the player had used an ffX code. In all other cases, the GREY.HST file is marked as if the player had used an eeX code. Thus, it is the PHOST alliance information that is "locking", and the HOST information simply tracks the PHOST information. In normal operation, this behavior will be completely transparent to the player, but it is worth noting that you do not need to send out an alliance offer every turn in order to maintain a HOST-type alliance.

Additionally, note that this conversion of PHOST alliance information to HOST alliance information is one-way; that is, PHOST does not accept external changes to the GREY.HST file as modifications to alliance status. The GREY.HST file is only written by PHOST, it is not read. Note also that all other information in the GREY.HST file is preserved; only the alliance data is modified by PHOST.

Finally, remember that all of the above is only relevant when an external add-on is being used that makes use of HOST-type alliance information (but does not recognize PHOST-type alliance information). The above information may be safely ignored when this is not the case.

Back to the index 

Examples

This section provides some examples for how to work with alliances. The basic steps needed to form an alliance are presented along with the status messages that PHOST returns to the player. For the remainder of this appendix, everything is viewed from the point of view of the Federation player who wants to form an alliance with the Rebels.

As mentioned above, an alliance may be in one of three states: offered, requested, or accepted. Initially, the Federation wishes to form an alliance with the Rebels. The player then sends the following command message:

The first line of the message indicates that an alliance with player 10 (Rebels) is desired. The second line indicates that only the Combat and Minefield levels are to be allowed unconditionally. The Ship and Planet levels are only offered conditionally. That is, they do not take effect unless the Rebel player also enables the Ship and Planet levels to the Federation player. (But nothing takes effect until the alliance as a whole is offered back to the Federation from the Rebels.)

At this point, the alliance is in the offered state for the Federation player and in the requested state for the Rebel player. On the next turn, the Federation player will receive the following message from PHOST: 

                                   <<< Alliance Status Report >>>

                                Race Offered to Race Allowed by Race
                                ---- --------------- ---------------
                                 10  ~s ~p +m +c -v
This message shows that the Minefield and Combat levels of alliance have been unconditionally offered to player 10 (Rebels), and the Ship and Planet levels of alliance have been conditionally offered. The Federation player sees that no alliance has yet been offered by player 10 (nothing in the "Allowed by Race" column) hence the alliance has not yet been accepted.

On this same turn, the Rebel player will receive the following message: 

                                   <<< Alliance Status Report >>>

                                Race Offered to Race Allowed by Race
                                ---- --------------- ---------------
                                  1                  ~s ~p +m +c -v
This message indicates to the Rebel player that the Federation player (race 1) wishes to form an alliance, with the levels of alliance as described above.

As long as neither player takes any further action, PHOST will continue to generate the above two messages on every turn. ==> It is important to note that the alliance has not been formed at this stage; it is only formed if the Rebel player also offers an alliance to the Federation.

Some turns later, the Rebel player decides that he/she wishes to accept the alliance and issues a command message:

The first line of the message indicates an offer of alliance to player 1. Since player 1 already has an offer of alliance submitted for player 10, the alliance will now enter the accepted state for both players. The second line shows that the Rebel player is less trusting than the Federation player since only the Combat level of alliance is enabled.

After this command message is processed, the alliance between the Federation and the Rebels is now in effect. PHOST will now generate the following message to the Federation player: 

                                   <<< Alliance Status Report >>>

                                Race Offered to Race Allowed by Race
                                ---- --------------- ---------------
                                 10  ~s ~p +m +c -v  -s -p -m +c -v
Since both offered-to and allowed-by columns are filled in, the Federation player now sees that the alliance with player 10 is complete.

Similarly, the message generated for the Rebel player is as follows: 

                                   <<< Alliance Status Report >>>

                                Race Offered to Race Allowed by Race
                                ---- --------------- ---------------
                                  1  -s -p -m +c -v  ~s ~p +m +c -v
At this stage, the Federation and Rebel ships will never fight each other in combat. In addition, Rebel ships can fly through Federation minefields without hitting mines (along with other benefits). But since the Rebel player has not offered Ship and Planet levels of alliance (-s and -p), the conditional alliance levels offered by the Federation (~s and ~p) are not in effect. The Rebel player does not see Federation ships and planets (other than through normal, non-alliance means).

On a subsequent turn, the Rebel player decides that he will trade ship information with the Federation. He enables a conditional Ship Level of alliance by sending the command processor command:

Now, both the Rebel and Federation player have enabled conditional ship alliances levels to each other. On the next turn, this ship level will be enabled to both players and they will see each other's ships. The Planet Level of alliance is still disabled to both players.

Back to the index 

This document is maintained by The Portable Host Project (phost@gmx.net).

Last updated 13 July, 2001