PSSAI

This page contains all the details about the AI system of the computer game "Pixel Starships". This is the part of the game that, for me, is its unique selling point: The ability of the player to "program" the rooms and crew of the starship so that they perform actions autonomously during battle.

A few notes on how to read this page:

In order to be able to talk about the AI system we need some definitions - read these first in the "Glossary" section.
The next section AI script processing rules, develops an unambiguous set of rules how the game engine processes the AI scripts of rooms and crew members.
The next section AI script processing pseudo code, attempts to show a command loop programmed in pseudo code that implements the rules from the previous section.
In the next section you can browse through two tables that list all AI conditions and all AI actions in the game. The tables show the version of Python research that is required to gain access to each condition/action.
The final section has a number of AI script snippets with explanations what they do.

Glossary

Some of the definitions in this sections were borrowed from the Pixel Perfect Guide website.

AI: Artificial Intelligence.
Script: All lines with which a room or crew member is programmed for AI.
Script owner: The room or crew member that is programmed with the script.
Command: One line in the AI script.
Condition: The first half of a command. A condition is evaluated.
Action: The second half of a command. An action is executed or performed.
True/False: The result of evaluating a condition.
Valid: An action is valid when it can be completed.
Frame: A graphics frame generated by the game engine.
Room instance: A specific room.
Room category: For the purpose of AI scripting, room instances are placed into categories. A condition or action never refers to a specific room instance, it always refers to a room category. The actual room instance used by a targeting action is determined only at runtime, according to rules listed below.
Seniority: How long you have hired a crew member. The longer you have hired the crew member, the higher her seniority.

AI script processing rules

Introductory notes

This section contains the rules that govern the processing of AI scripts. Each rule is labelled with an ID so that rules can be referred to in discussions.

Note that the game UI prevents AI commands that do not make sense (e.g. a weapon room is not allowed to target a friendly room, the "Target Condition Room" is not allowed if the condition does not refer to a room, etc.), so these things are not mentioned in the rules.

Action types

All actions have a type. It's important to know each action's type to successfully write AI scripts. Some action types are available to both Room and Crew AI scripts, while others are available to only one of them.

Action types
Action type	Room or Crew?	Priority	Comment
Special Power	Crew	1
Ammo Selection	Room	1	In reality, priorities could be different for these action types, but for all practical purposes they can be treated the same because there is no interdependency between ammo selection and power setting.
Power Setting	Room	1
Targeting	Room and Crew	2

Basic rules

This table lists the most basic rules how the game engine processes AI scripts.

Basic AI processing rules
Rule ID	Rule text	Comment
B1	The game engine processes a script in a loop.
B2	The game engine generates 40 frames per second.	I found this information on the PPG website, and later also deeply buried in the PSS wiki, on the Fire Damage page.
B3	Every frame the game engine performs 1 iteration of the loop.	This means that a script is processed 40 times per second. In fact, all scripts of all rooms and crew members that take part in the battle are processed 40 times per second.
B4	At the beginning of an iteration of the loop, the game engine first sorts the commands of the script according to the priority of their action, but within each priority group preserves the order in which the commands appear in the script.	The effect of this rule for crew member scripts is that commands with targeting actions are processed first, commands with Special Power actions second (e.g. at the beginning of the battle a new target room is selected before the Rush Command ability is activated). For room scripts it is similar: commands with ammo selection and power setting actions are processed first, commands with targeting actions second.
B5	During an iteration of the loop, the game engine processes the pre-sorted commands of the script from top to bottom.
B6	The game engine skips over a command if the game engine has already executed an action of the same type during the current iteration of the loop.
B7	The game engine skips over a command with a targeting action if the script owner is a weapon room and the weapon room is in the middle of a volley.	Weapon rooms that have a volley length only retarget at the end of the volley. A weapon room with a volley length may therefore keep firing at a target room instance even after it has been destroyed. This information is from the "AI Randomness" section on the PPG site.
B8	When the game engine processes a command (i.e. does not skip it), the game engine first evaluates the conditon of the command, then possibly executes the action of the command.
B9	If the condition evaluates to false, the game engine does not execute the action.	The game engine probably does not even test the action for validity.
B10	If the condition evaluates to true, the game engine tests the action for validity.	Validity heavily depends on the action type, and whether the script owner is a room or a crew member. Specifics follow in the tables further down.
B11	If the action is not valid, the game engine does not execute the action.
B12	If the action is valid, the game engine executes the action.
B13	At the end of an iteration of the loop (i.e. after all commands have been processed), if a targeting action was valid the game engine remembers the room instance that was targeted by the action.
B14	At the end of an iteration of the loop (i.e. after all commands have been processed), if no targeting action was valid the game engine sets the room instance that it remembered from a previous loop iteration (rule B13) as the target, even if that room instance currently is not a valid target.	This rule means that a room or crew member will stay on its previous target if it cannot select a new target.

Condition evaluation

This table lists the rules how the game engine evaluates conditions.

Rules for evaluating AI conditions
Rule ID	Rule text	Comment
C1	A condition that refers to a room category is false if no room instance within that room category fulfills the condition.
C2	A condition that refers to a room category is true if one or more room instances within that room category fulfill the condition.

Validity of Special Ability type actions

This table lists the rules how the game engine determines validity of Special Ability type actions.

Rules for determining validity of Special Ability type actions
Rule ID	Rule text	Comment
S1	A Special Ability action is not valid if the crew member has previously used her Special Ability during that battle.	This means that a crew member can use her Special Ability only once per battle.
S2	A Special Ability action is invalid if the crew member is not in the room she is targeting.	A crew member that is en route to her target room cannot use her Special Ability.
S3	A Special Ability action is invalid if the crew member's Special Ability targets rooms but the Special Ability is not applicable to the room that the crew member is in and that she is targeting.	Rush Command: TODO. Urgent Repair: TODO. System Hack: TODO. Ultra Dismantle: TODO.
S4	A Special Ability action is invalid if the crew member's Special Ability targets crew members but there are no eligible crew members in the room that the crew member is in and that she is targeting.	Healing Rain: TODO. First Aid: TODO. Poison Gas: TODO. Critical Attack: TODO.

Validity of Ammo Selection type actions

This table lists the rules how the game engine determines validity of Ammo Selection type actions.

Rules for determining validity of Ammo Selection type actions
Rule ID	Rule text	Comment
A1	Ammo Selection actions are always valid.	This might be wrong.

Validity of Power Setting type actions

This table lists the rules how the game engine determines validity of Power Setting type actions.

Rules for determining validity of Power Setting type actions
Rule ID	Rule text	Comment
P1	Power Setting actions are always valid.	This might be wrong.

Validity of Targeting type actions

This table lists the rules how the game engine determines validity of Targeting type actions.

Rules for determining validity of Targeting type actions
Rule ID	Rule text	Comment
T1	A targeting action is invalid if the game engine was unable to select a valid room instance.
T2	A targeting action is valid if the game engine was able to select a valid room instance.

Selection of a room instance

This table lists the rules how the game engine selects a specific room instance for a targeting action.

Rules about selecting room instances
Rule ID	Rule text	Comment
Rules independent of who the script owner is
R1	Only room instances that match the condition's or action's room category are valid targets.	This means that if there are zero room instances that match the room category the condition will be false, or the action will be invalid. The "any friendly/enemy room" category is matched by all friendly/enemy room instances.
R2	Only room instances that have non-zero health are valid targets.
R3	If the script owner has been targeting a room instance in the previous iteration of the loop, and that room instance is still valid in the current iteration of the loop, then the game engine selects that room instance.	This rule is important because it takes precedence over the random room selection rules R10-R11. The PPG site describes this under the heading "AI doesn't want to change". The effect of this typically is that once a weapon room has randomly selected a target enemy room (R10-R11), it continues firing at that same enemy room until it is destroyed. TODO: Is this rule also applicable to crew members?
Rules if the script owner is a room
R10	The game engine selects a room instance at random from all valid room instances.
R11	The game engine selects the same random room instance for all targeting actions that are executed in the same frame and that use the same room category.	This rule allows two rooms with the same targeting commands to target the same room instance despite the randomization rule R10. Weapon rooms with different volley lengths can become out-of-sync because weapon rooms only retarget at the end of a volley (cf. rule B7). TODO: If room 1 targets enemy reactors and there is a valid room instance for that, and room 2 targets "any room", will room 2 target the same enemy reactor room instance as room 1?
Rules if the script owner is a crew member
R20	Only room instances whose capacity has not been reached are valid targets.	When a crew member successfully targets a room instance, it uses up 1 capacity of that room instance - it occupies a slot, so to speak. When all slots are occupied, no more crew members can target the room.
R21	When crew members compete for capacity, the crew member with the highest Seniority wins.
R22	Only room instances for which there is a valid path - i.e. that can be reached by the crew member either by walking or by teleporting - are valid targets.	This basic rule is further detailed by rules R30-R34.
R23	The functionality of the friendly teleporter room does not affect path validity.	This means that room instances that are otherwise valid remain so even if the friendly teleporter room is System Hack'ed or EMP'ed or destroyed. TODO: Is this rule actually in effect? I have not seen this described anywhere, but I concluded it from the observation that after an enemy teleporter room is rushed and hacked/destroyed, any enemy boarding crew waiting to be teleported remain in that state, which means they continue to target a room that they cannot reach at the moment. There is some logic to that because the crew member might be able to reach the targeted room in the future when the teleporter room is repaired. On the other hand, the observation might lead to the false conclusion because it could be that the enemy boarding crew remains blocked only because they have no AI command that targets anything valid (e.g. a room on their ship), so their initial target remains locked forever (rule B14).
R30	If the room category that is targeted is on the same ship that the crew member is currently on, then only room instances that the crew member can reach by walking are valid targets (unless they are invalid due to some other rule). From among the valid targets, the game engine selects the room instance that is closest to the crew members current location.	In other words: Target is friendly room + crew member is on her own ship, or target is enemy room + crew member is on enemy ship.
R31	If an enemy room category is targeted and the crew member is on her own ship and the crew member can reach the friendly teleport room by walking, then all enemy room instances are valid targets (unless they are invalid due to some other rule). From among the valid targets, the game engine selects a random room instance - see rules R10 and R11 for details.	The reason is that all enemy rooms can be reached by teleport, and their distance to the friendly teleport is equal.
R32	If an enemy room category is targeted and the crew member is on her own ship and the crew member cannot reach the friendly teleport room by walking, then none of the enemy room instances are valid targets.
R33	If a friendly room category is targeted and the crew member is on the enemy ship, then only room instances that the crew member can reach by walking from the friendly teleport room are valid targets (unless they are invalid due to some other rule). From among the valid targets, the game engine selects the room instance that is closest to the friendly teleporter room.	The reason is that the crew member will first teleport back to her own ship, where she will arrive at the friendly teleport room. TODO: Is this rule actually in effect? I have not seen this described anywhere, but it would seem logical.

AI script processing pseudo code

Here is an attempt to write the AI command processing loop in pseudo code, based on the AI script processing rules that can be found further up on this page. I feel more comfortable when I can read code instead of the usually unstructured descriptions of how AI is supposed to work.

This section needs to be updated! I also need to rewrite everything to use functions.

script-owner = get-script-owner()
script-owner-type = get-script-owner-type(script-owner)

while (battle-is-running)
{
    action-type-was-performed[ammo-selection] = false
    action-type-was-performed[power-setting] = false
    action-type-was-performed[ability-use] = false
    action-type-was-performed[targeting] = false

    last-valid-target-room-instance = none

    // Loop through commands in the order defined by the user
    foreach (command in all-script-commands)
    {
        bool is-condition-true = get-is-condition-true(command.condition)
        if (is-condition-true)
            continue

        // Possible action types:
        // - ammo-selection (rooms only)
        // - power-setting  (rooms only)
        // - ability-use    (crew only)
        // - targeting      (both rooms and crew, only rooms can be the target)
        action-type = get-action-type(command.action)

        // An action cannot be performed if another action of the same type
        // has already been performed in the same command loop
        if (action-type-was-performed[action-type] == true)
            continue

        if (action-type == ammo-selection)
        {
            if (script-owner-type == crew-member)
                continue

            // For the purpose of this processing loop, it does not matter whether
            // or not the weapon room is actually capable of loading the specified
            // ammo. What DOES matter is that the ammo-selection action is valid,
            // that we perform it, and that from now on no other ammo-selection
            // action can be performed until all commands have been looped through.
            try-load-ammo(script-owner, command.action)
        }
        else if (action-type == power-setting)
        {
            if (script-owner-type == crew-member)
                continue

            // For the purpose of this processing loop, it does not matter whether
            // or not the weapon room is actually capable of setting the specified
            // power. What DOES matter is that the power-setting action is valid,
            // that we perform it, and that from now on no other power-setting
            // action can be performed until all commands have been looped through.
            try-set-power(script-owner, command.action)
        }
        else if (action-type == ability-use)
        {
            if (script-owner-type == weapon)
                continue

            // For the purpose of this processing loop, it does not matter whether
            // or not the crew member is actually capable of using her special
            // ability. What DOES matter is that the ability-use action is valid,
            // that we perform it, and that from now on no other ability-use
            // action can be performed until all commands have been looped through.
            try-use-special-ability(script-owner)
        }
        else if (action-type == targeting)
        {
            // Target room type is ...
            // - Either a room type determined by the condition, if the target action is
            //   "Target Condition Room"
            // - Or a room type explicitly named in the target action
            //   (e.g. "Target Enemy Engines")
            target-room-type = get-target-room-type(command)

            // This is theoretically possible if the action was "Target Condition Room", but the
            // condition ...
            // - Did not specify a room type (e.g. "None", "... has shield", "has active craft",
            //   "ship HP")
            // - Did specify a room type, but that room type is not valid as a target
            //   (e.g. "current HP" refers to a friendly room, but a weapon room cannot target
            //   friendly rooms)
            //
            // I have no idea if this is actually how it's implemented in the game, but it would
            // seem logical. In any case, the game UI does not allow to select the
            // "Target Condition Room" action for any of the conditions mentioned as examples,
            // so the question of implementation is at best of academic interest.
            if (target-room-type == invalid)
                continue

            // If several room instances exist for the type, the order in which room instances
            // appear in the list is this:
            // - Script owner is a room: The order is random. However, the order is the same
            //   for all script owners that choose in the same frame.
            // - Script owner is crew: The room instance that is closest to the crew member's
            //   current position appears first. If the crew member is on your ship and targets
            //   an enemy room type, the order is random because the teleport distance is
            /    equivalent for all enemy rooms.
            target-room-instances = get-room-instances(target-room-type)

            // If the script owner already has a target from a previous run of the command loop,
            // the AI stays on that target if it still satisfies the action's requirements.
            // We can achieve this by shuffling the target to the front of the list so that
            // it is examined first.
            if (last-valid-target-room-instance != none)
            {
                if (last-valid-target-room-instance is in target-room-instances)
                {
                    move-element-to-beginning-of-list(target-room-instances, last-valid-target-room-instance)
                }
            }

            valid-target-room-instance = none

            // Notes on what can happen here:
            // - If several room instances exist for the type, the loop tries one room instance
            //   after the other, in the order in which room instances appear in the list, until
            //   one of the room instances is valid. The list order is documented above.
            // - If only one room instance exists, the loop obviously has only 1 iteration.
            // - If no room instance exists, the loop is not entered at all, which results in no
            //   targeting action being performed.
            foreach (target-room-instance in target-room-instances)
            {
                target-room-side = get-side-of-room(target-room-instance)

                if (script-owner-type == weapon)
                {
                    // We already checked for this further up, but hey, let's be thorough.
                    // A weapon obviously cannot fire on a friendly room.
                    if (target-room-side == friendly-room)
                        continue

                    // For the purpose of this processing loop, it does not matter whether
                    // or not the weapon room is actually capable of firing. What DOES
                    // matter is that the targeting action is valid, that we perform it,
                    // and that from now on no other targeting action can be performed
                    // until all commands have been looped through.
                    try-fire-weapon(script-owner, target-room-instance)

                    valid-target-room-instance = target-room-instance
                    break
                }
                else if (script-owner-type == crew-member)
                {
                    current-room-instance = get-room-instance(script-owner)
                    current-room-side = get-side-of-room(current-room-instance)

                    // From the PSS wiki page on Teleport, section "Boarding Mechanics":
                    //   If the number of Crew targeting a room exceeds its capacity, the
                    //   extra will ignore the target command until there is available space.
                    // I assume that this mechanic is true not just for boarding, but for
                    // any targeting.
                    number-of-crew-targeting-room = get-number-of-crew-targeting-room(target-room-instance)
                    room-capacity = get-room-capacity(number-of-crew-targeting-room)
                    if (number-of-crew-targeting-room >= room-capacity)
                        continue

                    if (current-room-side == target-room-side)
                    {
                        can-walk-to-target-room = get-can-walk-to-room(current-room-instance, target-room-instance)
                        if (can-walk-to-target-room == false)
                            continue

                        walk-to-room(script-owner, current-room-instance, target-room-instance)
                    }
                    else if (current-room-side == friendly-room)
                    {
                        friendly-teleport-room-instance = get-friendly-teleport-room-instance()
                        if (friendly-teleport-room-instance == none)
                            continue
                    
                        can-walk-to-friendly-teleport-room = get-can-walk-to-room(current-room-instance, friendly-teleport-room-instance)
                        if (can-walk-to-friendly-teleport-room == false)
                            continue

                        // We must be in the teleport room to be able to teleport to the enemy ship
                        walk-to-room(script-owner, current-room-instance, friendly-teleport-room-instance)
                        teleport-to-room(script-owner, target-room-instance)
                    }
                    else if (current-room-side == enemy-room)
                    {
                        // Since the crew member is already on the enemy ship there must be a friendly
                        // teleport room, i.e. there is no need to check for its existence
                        friendly-teleport-room-instance = get-friendly-teleport-room-instance()

                        // Not sure if this check is actually implemented.
                        can-walk-to-target-room = get-can-walk-to-room(friendly-teleport-room-instance, target-room-instance)
                        if (can-walk-to-target-room == false)
                            continue

                        // No need to walk around on the enemy ship, we can teleport back to our ship from
                        // anywhere on the enemy ship
                        teleport-to-room(script-owner, friendly-teleport-room-instance)
                        walk-to-room(script-owner, friendly-teleport-room-instance, target-room-instance)
                    }

                    valid-target-room-instance = target-room-instance
                    break
                }
                else
                {
                    throw exception("unknown script owner type")
                }
            }  // foreach (target-room-instance in target-room-instances)

            if (valid-target-room-instance == none)
                continue

            // If in the future the command loop cannot find a valid target room instance,
            // the last valid target room instance will be reused
            last-valid-target-room-instance = valid-target-room-instance

        }  // else if (action-type == targeting)
        
        action-type-was-performed[action-type] = true
    }

    if (action-type-was-performed[targeting] == false)
    {
        // A weapon room will continue firing at the target room.
        // A crew member will continue repairing the target friendly room, or destroying
        // the target enemy room.
        continue-to-do-whatever-you-were-last-doing(script-owner, last-valid-target-room-instance)
    }
}

AI conditions and actions

AI conditions

Notes on the following table:

Unless otherwise noted, AI conditions can be used by rooms and crew alike.
The in-game condition names are somewhat inconsistent and may not match exactly to the condition name shown here. There may be slight differences in wording (e.g. "Enemy Ship no Active Shield" in the game is missing the verb, "Enemy Ship has Shield" is missing the word "active", or "Your Teleport HP" in the game is missing the word "room"), or in capitalization (e.g. "Enemy Ship has Shield" in the game has the verb in lowercase).
The game uses "Friendly ..." for room conditions, and "Your ..." for ship conditions. The following table uses the "Friendly ..." column header to also mean "Your ..." where appropriate.
The value "N/A" in the "Target Condition Room" column means "not available", i.e. for the condition in this row the "Target Condition Room" action cannot be selected. A (very) educated guess is that these conditions ...
- Either do not refer to a room, so "condition room" has no meaning (although it could be argued that referring to the shield or to craft could mean the Shield Room or Hangar Room).
- Or the conditions refer to a room, but it would not be a legal target (e.g. a "Current HP" condition would mean that a weapon room would have to fire on itself).
- Or there is an explicit targeting action for the same room, so "Target Condition Room" would only make things more complicated (e.g. "Origin Room HP" and "Current Room HP" conditions).
The value in the "Minimum Python" column refers to the minimum version of Python you must have researched in order to have access to the condition. I started this table when I already had Python 1.0, so at the moment I don't know which conditions were available without any Python research.
Similar tables can be found on the PSS wiki on the Command Center page (but not on the AI page).

List of AI conditions
Friendly ...	Enemy ...	Condition	Sub-condition	Effect on "Target Condition Room"	Minimum Python	Comment
-	-	None		N/A	None
x	x	Ship HP	Has Full HP	N/A	None	Because hull damage cannot be repaired, this condition is true only for a limited time at the beginning of a battle. This can be used to focus all weapons on a single room until it is destroyed and the first shot deals hull damage.
			< 100%		None
			< 75%		2.0
			< 50%		1.0
			< 25%		2.0
			> 25%		2.0
			> 50%		1.0
			> 75%		2.0
x	x	Shield	Has Active Shield	N/A	None
			Has No Active Shield
			Has Full Shield
x	x	Room HP	Has Full HP	Any Room	None
			< 100%		None
			< 75%		2.0
			< 50%		1.0
			< 25%		2.0
			> 0%		? (None or 1.0)
			> 25%		2.0
			> 50%		1.0
			> 75%		2.0
x	-	Origin Room HP	Has Full HP	N/A	? (2.0 or lower)	Only available for crew members.
			< 100%
			< 75%
			< 50%
			< 25%
			> 0%
			> 25%
			> 50%
			> 75%
x	-	Current Room HP	Has Full HP	N/A	? (2.0 or lower)	Only available for crew members.
			< 100%
			< 75%
			< 50%
			< 25%
			> 0%
			> 25%
			> 50%
			> 75%
x	-	Current HP	Is Full	N/A	? (None or 1.0)
			< 100%		None
			< 75%		2.0
			< 50%		1.0
			< 25%		2.0
			> 25%		2.0
			> 50%		1.0
			> 75%		2.0
x	x	Craft	Has Deployed Craft	N/A	1.0	The "Enemy" condition reads "Enemy Has Active Craft".
x	x	Craft	Has No Deployed Craft	N/A	1.0
x	x	Cloak	Has Cloak	N/A	2.0
x	-	Laser Room HP	< 100%	Laser room	None
x	-		< 50%
-	x		> 0%
x	-	Engine Room HP	< 100%	Engine room	None
x	-		< 50%
-	x		> 0%
x	-	Shield Room HP	< 100%	Shield Generator room	None
x	-		< 50%
-	x		> 0%
x	-	Missile Room HP	< 100%	Missile Launcher room	None
x	-		< 50%
-	x		> 0%
x	-	Reactor Room HP	< 100%	Reactor room	None
x	-		< 50%
-	x		> 0%
x	-	Teleport Room HP	< 100%	Teleport room	1.0
x	-		< 50%
-	x		> 0%
x	-	Hangar Room HP	< 100%	Hangar room	1.0
x	-		< 50%
-	x		> 0%
x	-	Anticraft Room HP	< 100%	Anti Craft Laser room	1.0
x	-		< 50%
-	x		> 0%
x	-	Security Room HP	< 100%	Security Gate room	1.0	There is no "< 50%" condition because the Security Gate room has only 1 HP.
-	x	Security Room HP	> 0%	Security Gate room	1.0
x	-	Android Room HP	< 100%	Android Studio room	1.0
x	-		< 50%
-	x		> 0%
x	-	Medical Room HP	< 100%	Med Bay room	2.0
x	-		< 50%
-	x		> 0%
x	-	Cannon Room HP	< 100%	EMP and Ion Cannon rooms	2.0
x	-		< 50%
-	x		> 0%
x	-	Cloak Room HP	< 100%	Cloak Generator room	2.0
x	-		< 50%
-	x		> 0%
x	-	Radar Room HP	< 100%	Radar room	2.0
x	-		< 50%
-	x		> 0%

Target Room Has No Friendly Crew

The AI condition "Target Room Has No Friendly Crew" is a vital ingredient of multi-rush AI. But how does it work exactly? "Has No Friendly Crew" is ambiguous and can mean several things:

It could mean that no friendly crew member is physically present in the target room.
It could also mean that no friendly crew member is targeting the target room.
And what about the crew member in whose AI script the condition appears? Is she considered friendly or not? Should it maybe read "No other friendly crew?

When we show the logical combinations in cross-tabular form, we start out with a lot of question marks where we would like to see "AI Condition is True" or "AI Condition is False".

Target Room Has No Friendly Crew

                            Friendly crew members  Friendly crew members do
                            target the room        not target the room
---------------------------------------------------------------------------
Friendly crew members are   ? (case A)             ? (case B)
physically present

Friendly crew members are   ? (case C)             ? (case D)
not physically present

Two of the four cases should be clear, though. Were it otherwise, the AI condition would be phenomenally useless and not working.

Case A: The AI condition must obviously be false if friendly crew members are both physically present in the targeted room, and targeting it.
Case D: The AI condition must obviously be true if friendly crew members are neither physically present in the targeted room, nor targeting it.

So here is what we actually have:

Target Room Has No Friendly Crew

                            Friendly crew members  Friendly crew members do
                            target the room        not target the room
---------------------------------------------------------------------------
Friendly crew members are   Condition is           ? (case B)
physically present          false (case A)

Friendly crew members are   ? (case C)             Condition is
not physically present                             true (case D)

The AI condition's in-game description reads "This condition is true when the currently targeted room has no friendly crews targeting it". So in theory the description is clear. In normal games I would trust the in-game description, but since this is Pixel Starships all bets are off. The "Multi-Rush AI" page on Pixel Perfect Guide has a Frame by Frame Analysis section. Since this analysis is based on observable fact, I trust it much more than the in-game description, and I'm going to base my conclusion of how the AI condition works on PPG.

Frame 1:

PPG says that for A, B and C the AI condition "Target room has no friendly" is false.
- A-D are physically present in the Hangar during the whole frame, so the condition could be false because there are other crew members physically present in the room (+ the script owner).
- A-D are targeting the Hangar at the beginning of the frame, A-C are switching target to room Y one by one, but when it is C's turn D is still targeting the Hangar. So the condition could also be false because there are other crew members targeting the room (+ the script owner).
- In the end we can't say anything about which of the two components is relevant. This is case A.
PPG says that for D the AI condition "Target room has no friendly" is true.
- D is physically present in the Hangar during the whole frame, and at the time the AI condition is evaluated D is also targeting the Hangar. This means that the script owner's physical presence and targeting is not evaluated, only other friendly crew members' physical presence and targeting are evaluated. This answers the third question with which we started at the beginning.
- A-C are physically still present, but they are not targeting the Hangar. The conclusion is that targeting is clearly necessary, while physical presence alone is not sufficient. This proves case B.

Frame 2

PPG says that for A the AI condition "Target room has no friendly" is true.
- Remember that A is currently targeting room Y because she has switched targets in frame 1.
- B and C are also targeting room Y after they switched targets in frame 1.
- No crew members are physically present in room Y.
- The conclusion is that the AI condition can become false despite other friendly crew targeting the same room. This proves case C.
- On a side note, this also shows that the in-game description of the AI condition (see above) is at least misleading, if not outright wrong.

So this is the end result:

Target Room Has No Friendly Crew

                            Friendly crew members  Friendly crew members do
                            target the room        not target the room
---------------------------------------------------------------------------
Friendly crew members are   Condition is           Condition is
physically present          false (case A)         true (case B)

Friendly crew members are   Condition is           Condition is
not physically present      true (case C)          true (case D)

To write down things in words:

The AI condition is true even if other friendly crew members are physically present in the targeted room, as long as the other friendly crew members are not also targeting the room.
The AI condition is true even if other friendly crew members are also targeting the targeted room, as long as the other friendly crew members are not also physically present.
The AI condition is false only if other friendly crew members are physically present in the targeted room AND they are also targeting the targeted room
The script owner's presence and targeting is not evaluated, only OTHER friendly crew are evaluated

AI actions

Notes on the following table:

Targeting actions refer to a room category, not to a specific room instance. If a ship happens to be equipped with only 1 room in a category, targeting that category will of course have the same effect as targeting the room instance.
The "Security Room" category generally refers to the Security Gate room.

List of AI actions
Room	Crew	Action	Sub-action	Action type	Minimum Python	Comment
-	x	Use Special Power		ability-use	None	Only available when crew member is level 10 or higher and has a Special Ability
x	-	Set Item	Cheapest Item	Ammo-selection	None	The following rooms can use these actions: Missile Room, Hangar Room The PSS wiki does not list "Highest System Damage" and "None", but it's reasonable to assume that these are available without any Python research, just like the other 8 ammo-selection actions.
			Dearest Item
			Highest System Damage
			Highest Hull Damage
			Highest EMP
			Highest Character Damage
			Highest Fire Items
			Highest AP Damage
			Highest Shield Damage
			None
x	-	Set Power	Set To Maximum	Power-setting	None	All rooms can use these actions
			Set To Zero
			Set To 1
			Set To 2
			Increase By 1
			Decrease By 1
x	x	Target Room	Condition Room	Targeting	None	All rooms except the following can use these actions: Anti Aircraft Room, Engine Room (although they can select "Target Condition Room", which makes no sense), Shield Room (ditto), Teleport Room (ditto) Crew members can use targeting actions that target both the Friendly and the Enemy room variant. Exceptions: "Condition Room" is neutral "Random Room" is only available in the Enemy variant. Rooms can use only targeting actions that target Enemy rooms. This makes sense - you don't want to shoot at your own ship. When my ship was at level 6 the "Target Your Android Room" action was not available for crew members. Although annoying, it made a certain sense because at ship level 6 you don't have the Android Studio unlocked (although you can have the Visiri Mechbay). After I upgraded to ship level 7 the action was still unavailable, and it remained so even after I had actually built and equipped the Android Studio. I then though to upgrade the Command Centre to level 7, but still no luck. I then started the research for Python 2.0 and the upgrade to Android Studio level 2. Later - while the research and upgrade were still going on - I noticed that the "Target Your Android Room" action had suddenly appeared. I have no idea what the trigger was.
x	x		Random Room		None
-	x		Origin Room		? (2.0 or lower)
-	x		Current Room		? (2.0 or lower)
x	x		Laser Rooms		None
			Shield Room
			Engine Rooms
			Reactor Rooms
			Missile Rooms
			Teleport Room		1.0
			Hangar Room
			Anticraft Room
			Security Room
			Android Room
			Medical Room		2.0
			Cannon Room
			Radar Room
			Cloaking Room

AI script snippets

Engine room AI

Engine room 1
Command#	Condition	Action
1	Your Reactor HP < 50%	Decrease Power by 1
2	Enemy Missilie Room HP > 0%	Increase Power by 1
3	None	Set Zero Power

Engines are power hungry (3 energy each). They can be useful if everyhing goes well, but if the ship reactors are damaged, they should be the first things to power down. With the above script, an Engine Room will start powering down when the reactor takes heavy damage, and only powers up if the enemy has active missile rooms. By default the room keeps a low energy profile.

Engine room 2
Command#	Condition	Action
1	Your Reactor HP < 50%	Decrease Power by 1
2	Your Engine HP < 50%	Increase Power by 1
3	None	Set Zero Power

This script is intended for the secondary Engine Room: It keeps that Engine Room powered down unless the primary Engine Room becomes heavily damaged. In that case it powers up, thus acting as a backup.

Note: In the examples on squid.boards.net both scripts have an additional AI command "0: Your Ship Has Full Shield, Set Minimum Power". I don't see the purpose of this.

Anti Craft Laser room AI

Anti Craft Laser room AI
Command#	Condition	Action
1	Your Reactor HP < 50%	Decrease Power by 1
2	Enemy Has Active Craft	Increase Power by 1
3	None	Set Zero Power

Notes:

This script works exactly the same as the script for the main Engine room (see above). The only difference is the condition.

Security Gate room AI

Security Gate room AI
Command#	Condition	Action	Comment
1	Enemy Teleport HP > 0%	Increase Power By 1	The idea is that the room does not power up if the enemy has no Teleport room. The condition we use here might backfire, though: If we manage to destroy the enemy Teleport room after an enemy boarder is already on our ship, she is now free to roam our ship. If you have sufficient energy, it is therefore safer to just say Condition = None, Action = Increase Power By 1.
2	None	Set Zero Power

Notes:

None

Power management for weapon and other rooms

Power Management for all weapon and other rooms consists of the following as the very first command:

Power Management for weapon rooms
Command#	Condition	Action	Comment
1	None	Increase Power by 1

2 weapons operating with reduced power are better than 1 weapon operating at full power. Having weapons fighting each other to gulp full power apparently can result in some problems, so we let them power up slowly ("sip not gulp").

Weapon rooms targeting

Targeting 1
Command#	Condition	Action	Comment
2	Enemy Reactor HP > 0%	Target Condition Room

This simple strategy tries to disable all enemy reactors. Without energy the enemy ship cannot attack you and becomes a sitting duck. When the last reactor is destroyed, the script continues to shoot at the last reactor it was targeting causing hull damage. This strategy works well with small ships, but becomes less efficient with increasing enemy ship size. The reasons for this are that bigger ships have more reactors (up to 4), they all have high levels and therefore high HP, they tend to be well armored and the enemy AI is practically guaranteed to repair them with a high priority.

Bottom line: Never target reactors with your weapon rooms! If you want to go after the reactors, use crew that boards the enemy ship.

Targeting 2
Command#	Condition	Action	Comment
2	Enemy Shield Room HP > 0%	Target Condition Room

Another simple strategy that focuses fire on a single room (a ship can have only 1 Shield Room). This disables a key defense of the enemy ship and then starts to deal hull damage relatively early on. The strength of this strategy is also its weakness: The shield room is guaranteed to be armored, so with every shot you lose a certain percentage of damage, lowering your overall DPS throughout the entire battle. In addition, the enemy AI is probably configured to keep the shield room repaired with top priority. Despite these problems, focusing fire on the shield room is probably one of the best overall strategies in the game.

Bottom line: Focus Fire on one or maybe two rooms is a key strategy for winning battles! The shield room is a sensible target, but if in doubt choose the room that makes you lose the most (e.g. if your attack strategy uses craft spawned from the Hangar, then target the Anticraft room).

Targeting 3
Command#	Condition	Action
2	Enemy Shield Room HP > 0%	Target Condition Room
3	Enemy Lasers HP > 0%	Target Condition Room
4	Enemy Missilie Room HP > 0%	Target Condition Room

This script follows a multi-target strategy. It very systematically destroys the key defensive and offensive facilities of the enemy ship. It is interesting to note that the reactors are not targeted: Targeting them in this situation is pointless. As you destroy systems you are technically giving the enemy ship extra power, why would you then waste time destroying reactors for no effect? The problem with this script is the slowness of the systematic approach: You still need to deal with the heavily guarded shield generator, and you also spend time targeting multiple other rooms. This can result in your ship shooting to no effect as multiple rooms are repaired and your AI trys to target them all. By the time you start to do real hull damage, the enemy may already have destroyed your ship, or time may run out.

Targeting 4
Command#	Condition	Action	Comment
2	Your Ship Has No Actve Shield	Target Enemy Lasers
3	Enemy Ship HP > 50%	Target Enemy Shields

This cleverly crafted script avoids some of the major problems with the previous method. First of all, it relies on the assumption that your shield remains operative for a long time, because the shield room is well armored and also because the defensive crew AI scripts keep the shield room fairly well repaired. Therefore, if this script (and possibly other offensive measures) manage to destroy a significant amount of the enemy weapons (say 2/3), your shield can handle the rest.

So if your shields are up, the enemy shields are targeted. The primary goal here is to get a few potshots into the enemy shield room to kill the crew manning it. It makes sense to also send anti crew missiles into the room. Your shields will eventually fail to enemy weapons fire so the AI will then switch over to target enemy lasers. As the shields go up and down the AI will switch fire between the two room types. The important thing is that when the enemy ship eventually falls below 50% HP and your shields come back up and can handle the remaining enemy weapons fire, the AI will not switch targets to another laser but continue to target the destroyed laser, thus inflicting more and more hull damage.

Programming crew to use the Teleport

Basic understanding how to teleport to the enemy ship via AI:

A crew member can use the Teleport Room to beam to any room on the enemy ship that can be selected as a target.
There is no actual action that tells a crew member to use the Teleport Room.
Specifically, you don't have to target your Teleport Room.
Instead you just use any AI command that targets a room on the enemy ship.
- IF the crew member is on your ship, AND ...
- IF the crew member has a path that she can use to walk to your Teleport Room, AND ...
- IF the target room on the enemy ship is a valid target (e.g. not destroyed, at least one targeting slot is still free) ...
- THEN the crew member will walk to your Teleport Room ...
- THEN IF the Teleport Room is working and is fully charged, the crew member will teleport directly to the target room as soon as she has reached the position in the middle of the room.

Basic understanding how to teleport back to your ship via AI:

A crew member can use the Teleport Room to beam back to your ship.
- The Teleport Room does not need to be powered for this to work - in fact teleporting back works even if the Teleport Room is destroyed!
- The crew member's current position does not matter. For instance, teleporting back works even if the crew member is currently in a lift.
There is no actual action that tells a crew member to use the Teleport Room.
Specifically, you don't have to target your Teleport Room.
Instead you just use any AI command that targets a room on your ship.
- IF the crew member is on the enemy ship, AND ...
- IF the crew member has a path that she can use to walk from your Teleport Room to the target room, AND ...
- IF the target room on your ship is a valid target (e.g. not destroyed, at least one targeting slot is still free) ...
- THEN the crew member will teleport directly to your Teleport Room regardless of its current position ...
- THEN the crew member will walk to the target room.

Teleport Room congestion:

Several crew members who want to teleport to the enemy ship at the same time will queue up, in the order in which they arrive at the Teleport Room.
Teleporting back requires no queueing because the process is instantaneous. The only restriction for the teleport back to work is that the target room is valid.

Hand-to-hand combat rules:

After boarding, a crew member has a 0.5 seconds delay before she is able to activate her Special Ability or attack the room/defending crew.
Unless prevented by an AI condition, an enemy crew member's Special Ability is activated when the boarder arrives in the room. Combined with the 0.5 seconds delay the defenders therefore have the chance to kill the boarder before she can activate her own Special Ability.
Once a boarder reaches her destination and survives the 0.5 seconds delay, she will start to attack the room, with a 1 second delay between each attack.
Enemy crew members intervening will cause the boarder to switch targets to them. Hand-to-hand combat ensues.
Unless prevented by an AI condition, the boarder's Special Ability is activated before the first round of hand-to-hand combat. This means that an ability such as Critical Attack can kill an enemy crew member before she gets a chance to deal regular damage.
Boarders fill a room from left to right. Enemy crew members target the leftmost boarder first.

Goals:

The primary goal is to kill repair teams, because they interfere with the secondary goal.
The secondary goal is to damage the enemy ship. Without repair teams this goal can be easily achieved.

General Teleport Room tactics:

Dedicate some crew members to be your primary boarding crew. These crew members do nothing else, they focus on the enemy and teleport immediately when the battle begins.
Optionally, assign some crew members to be your secondary boarding crew. These crew members have other duties first, but they can also teleport if certain conditions are met.
Crew stats: The most important stats for boarding crew are HP and Attack. The higher these stats the better!
Special Abilities: The most obviously useful abilities are Poison Gas and Critical Attack, but depending on the overall boarding strategy or the purpose of an individual boarding crew member other abilities can be at least as useful.
The highest HP primary boarding crew member - the "tank" - should teleport first, so that she can receive (and hopefully survive) the blows from any enemey crew members that are already present in the arrival room.
The highest Attack primary boarding crew member - the "damage dealer" - should teleport second. If everything works well, the tanking crew member who arrived first has already killed or at least damaged the enemy crew so that the damage dealer can mop up.
The only way how you can decide the order in which crew members are going to teleport is to place them in rooms with different distances to the Teleport Room, so that they take different times to arrive at the Teleport Room.

Teleport 1: Destroy all rooms of a given type
Command#	Condition	Action	Comment
1	Enemy <room type> HP > 0%	Target Condition Room	The crew member first teleports to one of the rooms of the specified type and destroys it, then she walks to the next room of the same type and destroys it, etc. If a room of the same type exists but cannot be walked to, the action fails and command #2 is executed.
2	Enemy <room type> HP > 0%	Target Your Teleport	The crew member teleports back to your ship. On the next AI script cycle, command #1 will be executed again because the target room can now be reached via teleport.

Notes:

The second command is very important because it counteracts segmented ships!

Teleport 2: Destroy all rooms of several types
Command#	Condition	Action
1	Enemy Engine Room HP > 0%	Target Condition Room
2	Enemy Engine Room HP > 0%	Target Your Teleport
3	Enemy Missile Room HP > 0%	Target Condition Room
4	Enemy Missile Room HP > 0%	Target Your Teleport
5	Enemy Reactor HP > 0%	Target Condition Room
6	Enemy Reactor HP > 0%	Target Your Teleport

Notes:

This is not a particularly good script. Its main purpose is to demonstrate that the commands in the Teleport 1 script can be repeated.
Room types that appear earlier are destroyed first, because the actions further down are never performed.

Teleport 3: Room Hold
Command#	Condition	Action	Comment
1	Enemy Teleport HP > 0%	Target Condition Room	If the enemy has a Teleport Room, the crew member will target it. Once the crew member arrives at her destination she will stay there and hold the room against any repair crew until killed or the battle is over. The reason why it does not leave once the Teleport Room's HP reaches 0% is because at this time in the battle the condition of command #2 is very unlikely to be true. Since the targeting action #2 is not performed, the original target will therefore remain in force.
2	Your Ship Has Full Shield	Target Enemy Reactors	This is the backup command in case the enemy has no Teleport Room. At the beginning of the battle the condition of this command is guaranteed to be true, and this command's targeting action will therefore be performed, because the targeting action of command #1 is not performed due to its failing condition. Once the crew member arrives at her destination, she will stay there and hold the room, the same as in command #1.

Notes:

This script does not include the command that counteracts anti-segmented ships because the intent is a room hold, i.e. the crew member should NOT wander around.

Teleport 4: Room Hold and Mid-Battle Scatter
Command#	Condition	Action	Comment
1	Enemy Ship HP < 50%	Target Enemy Reactors	Regardless of whether the enemy ship ...
2	Your Ship HP < 50%	Target Enemy Reactors	... or your ship falls below 50% HP first - the crew member drops its room hold (either command #3 or #4) and starts to attack any nearby reactors.
3	Enemy Teleport HP > 0%	Target Condition Room	See Teleport 3 script.
4	Your Ship Has Full Shield	Target Enemy Shield Room	See Teleport 3 script.

Notes:

None

Teleport 5: Room Hold, Mid-Battle Scatter and Anti-Segmented Ship
Command#	Condition	Action	Comment
1	Enemy Ship HP < 50%	Target Enemy Reactors	See Teleport 4 script
2	Enemy Ship HP < 50%	Target Your Teleport	Plus handle segmented ships
3	Your Ship HP < 50%	Target Enemy Reactors	See Teleport 4 script
4	Your Ship HP < 50%	Target Your Teleport	Plus handle segmented ships
5	Enemy Teleport HP > 0%	Target Condition Room	See Teleport 4 script.
6	Your Ship Has Full Shield	Target Enemy Shield Room	See Teleport 4 script.

Notes:

If you have two boarders it might be better to split the scatter commands between them: One scatters when the enemy ship falls below 50% HP (commands #1 and #2), the other scatters when your ship falls below 50% HP (commands #3 and #4).
Reason 1: If both scatter at the same time and there is an elevator on the way to the target room, one crew member will catch the elevator while the other has to wait.
Reason 2: If one stays at his post and holds the room, she might still catch straggling repair crew that took a long time to arrive.

Teleport 6: Room Hold, Evasive Scatter + Anti-Segmented Ship and Emergency Teleport
Command#	Condition	Action	Comment
1	Current HP < 25%	Target Your Laser Room	If the crew member is critically wounded she will try to save herself by teleporting back to your ship. To remain useful she will man a gun for the remainder of the fight.
2	Current HP < 50%	Target Enemy Engines	If the crew member is badly wounded and is no longer able to hold the room she is assigned to, she will perform evasive action and flee to a room that is likely to be unoccupied - in this case an enemy Engine Room. Here she can do at least something: By destroying the enemy engines your missiles will always hit.
3	Current HP < 50%	Target Your Teleport	This counteracts a segmented enemy ship. Or, if the enemy has no Engine Room, the crew member will guard your Teleport Room.
4	Enemy Teleport HP > 0%	Target Condition Room	See Teleport 4 script.
5	Your Ship Has Full Shield	Target Enemy Shield Room	See Teleport 4 script.

Notes:

This script is most useful for relatively weak crew members. It allows them to survive the battle so that they can receive XP.
If the crew member does not have a good Weapon skill, instead of targeting a laser in command #1 she might wish to target a different room that is more suitable to her best skill.

AI Recipes

TODO: Review whether this section is still needed.

Rushing the enemy Teleport Room

Purpose:

Prevent the enemy crew from boarding your ship.

Method:

Send a crew member to the enemy Teleport Room as fast as possible by using the Rush Command ability.
Once there your crew member sabotages the enemy Teleport Room. This prevents the enemy crew from using it.
The crew member then maintains a room hold on the enemy Teleport Room so that crew that tries to repair it will be killed.
One or even two additional boarders can be sent over to help the first maintain the room hold.

Special effect:

Enemy crew members who have been instructed to board your ship will stay in their destroyed Teleport Room without doing anything.
The reason is that they are targeting a room in your ship and not their Teleport Room.
They wait indefinitely for the room being repaired, but they don't repair it themselves, because crew members repair only those rooms that they target.
They also don't attack your boarders, because crew members attack only enemy crew members that target the same room as they do.
Following the same logic, your boarders also do not attack the stranded enemy crew members. The exception are Special Abilities - using a Special Ability is not normal hand-to-hand combat, so if your boarders use something like Poison Gas or Critical Attack they may still kill some or all of the stranded enemy crew.

PSSAI

Contents

Glossary

AI script processing rules

Introductory notes

Action types

Basic rules

Condition evaluation

Validity of Special Ability type actions

Validity of Ammo Selection type actions

Validity of Power Setting type actions

Validity of Targeting type actions

Selection of a room instance

AI script processing pseudo code

AI conditions and actions

AI conditions

Target Room Has No Friendly Crew

AI actions

AI script snippets

Engine room AI

Anti Craft Laser room AI

Security Gate room AI

Power management for weapon and other rooms

Weapon rooms targeting

Programming crew to use the Teleport

AI Recipes

Rushing the enemy Teleport Room

Navigation menu

PSSAI

Glossary

AI script processing rules

Introductory notes

Action types

Basic rules

Condition evaluation

Validity of Special Ability type actions

Validity of Ammo Selection type actions

Validity of Power Setting type actions

Validity of Targeting type actions

Selection of a room instance

AI script processing pseudo code

AI conditions and actions

AI conditions

Target Room Has No Friendly Crew

AI actions

AI script snippets

Engine room AI

Anti Craft Laser room AI

Security Gate room AI

Power management for weapon and other rooms

Weapon rooms targeting

Programming crew to use the Teleport

AI Recipes

Rushing the enemy Teleport Room

Navigation menu

Search