An initial is an object created by the level. Initials form the starting setup of the level, and are used by conditions to script additional events after gameplay starts.
An initial is a procyon value with the following fields:
| Field | Req? | Type |
|---|---|---|
| base | yes | remapped name of an object |
| owner | no | index of a player |
| at | yes | point |
| hide | no | boolean |
| flagship | no | boolean |
| target.initial | no | index of an initial |
| target.lock | no | boolean |
| override.name | no | string |
| override.sprite | no | name of a sprite |
| earning | no | money |
| build | no | array of remapped names of objects |
What kind of object this is. Before creating the object, Antares first attempts to map the name through its owner’s race.
This feature is used in net levels. If an initial specifies base: "hvd", and the player chooses to play Ishimans (ish), then it will be an Ishiman heavy destroyer (ish/hvd). If the player chooses Cantharans (can), then it will be a Cantharan heavy destroyer (can/hvd). The net level must not allow the player to choose Elejeetians, as no object named ele/hvd or hvd exists.
In solo levels, player races are fixed, so it’s recommended (but not required) to use base: "ish/hvd" or base: "can/hvd" for clarity.
The index of the player that initially owns the object. If null, the object is neutral.
The point at which to create the object. Most levels are randomly rotated, and the level’s rotation is applied to this location.
If true, then the object won’t be created at the beginning of the level. It can be explicitly created later by the reveal action.
If true, then this object is its owner’s flagship. Every human player must have exactly one flagship. Non-human players should not have a flagship.
The index of another initial for this object to target. A player can later reassign this object’s target, unless target.lock is true.
If true, then it is not possible for a player to order this object to a new target. This should typically be used with target.initial. Together, they lock the object into guard or escort duty.
The object’s target can still be changed by the target action or hold action.
A replacement name for the object. Most planets and stations have their names overridden, so that the player can easily tell them apart. Typical names from the factory scenario would be:
| Object | Name |
|---|---|
| Sun | Regulus |
| Planet | Regulus Alpha, Regulus Beta, Regulus Gamma |
| Moon | Regulus Alpha 1, Regulus Alpha 2 |
| Bunker Station | Bunker Station 1, Bunker Station 2 |
| Power Station | Power Station R-1, Power Station R-2 |
| Outpost | Outpost 1, Outpost 2, Outpost 3 |
Names should be at most 25 characters. Longer names won’t fit in the computer.
A replacement sprite for the object. Most planets and moons have their sprites overridden.
Warning
The override sprite must have the same number of frames as the original sprite.
There are a large number of override sprites available for planets and moons:
How much money a player earns for owning this object. This value is multiplied by a player’s earning_power. The initial pays out the resulting amount of money over the course of every ten seconds.
Typical values from the factory scenario are:
| Object | earning |
|---|---|
| Planet | ¤1.0 |
| Moon | ¤1.0 |
| Bunker Station | ¤1.0 |
| Minor Bunker | ¤0.75 |
| Power Station | ¤1.0 |
| Outpost | ¤0.5 |
| Minor Outpost | ¤0.25 |
An array of objects that can be built at this object. Up to six entries can be listed.
When determining what objects an initial can build, Antares first maps each entry base according to the initial’s owner’s race:
For example, imagine a level has Ishiman, (ish), Cantharan (can), and Human (uns) players, and Earth’s build array is:
build: * "cruiser" * "hvc" * "can/defdrone" * "gro/gateship"
In this case:
