Game timing

Galactic Empire does not have one universal game tick. Movement, ship systems, automated-ship decisions, and planet production run on separate schedules. A command may take effect immediately, but the visible result of movement, a recharge, a projectile hit, or a countdown depends on which scheduled routine handles it. This page expands the recurring-callback branch of Game execution flow.

The main schedules

GEMAIN.C registers these callbacks with MajorBBS rtkick(). In the 16-bit builds, the 5.x callback names and the p-prefixed 6.x PHARLAP names are both forwarding wrappers for shared implementation routines (for example, plarti() and pplarti() call plartia()). The 32-bit plarti(), autorti(), and warrti() contain their implementations directly. The table names the 16-bit entry points and implementations. Each implementation schedules its next invocation rather than running continuously.

Scheduled callback	Interval	Implementation and principal calls
`warrti2()` / `pwarrti2()`	1 second	`warrti2a()` calls `rotateship()`, `accel()`, and `moveship()` for one third of the live ship slots. ge-next adds `tick_entrymsg()` for delayed entry notices; ge-arena also advances match timers through `arena_tick()`.
`autorti()` / `pautorti()`	1 second	`autortia()` visits automated ships. It calls each eligible class's configured `tick_func` when that ship's delay expires, and considers one vacant NPC slot for its configured `init_func` every 30 scheduler ticks.
`warrti()` / `pwarrti()`	6 seconds	`warrtia()` calls `checkmines()`, then visits every active ship for repair, shields, cloaking, recharge, ordnance, ion fire, and damage checks. Classic also calls `fluxstat()` here; ge-next adds `validate_lock()` and skips defensive-state and recharge work once ship damage reaches 100.
`warrti3()` / `pwarrti3()`	First call after 60 seconds; then every 120 seconds	`warrti3a()` sends the neutral-zone warning through `outsect()`.
`plarti()` / `pplarti()`	Classic starts after its startup-calculated `plantime`; ge-next first calls it after 10 seconds on 5.x or 30 seconds on 6.x. Subsequent intervals vary.	`plartia()` searches planet records, updates neutral-zone stock and eligible ordinary planets, calls `multiply()` and `check_spy()` as appropriate, and recalibrates `plantime` after a pass. Classic updates Zygor and Tahanian Station inline; ge-next calls `update_plan_1()` and `update_plan_2()` and adds `update_plan_3()` for the Enforcer Planet.

The diagram below follows three of these scheduled paths into their principal calls. An asterisk marks a ge-next-specific call path or guard; it does not always mean the routine itself is absent from classic GE.

These are scheduled intervals, not a guarantee that every message appears at an exact wall-clock instant. A busy BBS can delay a callback, and a condition may not be noticed until the next relevant pass. The two one-second callbacks are independent: NPC decisions and ship movement are not the same pass.

Movement and ship state

The movement callback runs once a second but processes only ship slots in one of three groups. A ship's internal slot number determines its group: slots 0, 3, 6, and so on are in group 0; slots 1, 4, 7, and so on are in group 1; and slots 2, 5, 8, and so on are in group 2. In other words, the group is the slot number modulo three, not a property of the ship class or its speed. The callback cycles through the groups in order, so a ship receives a movement update roughly every three seconds. On that update the game rotates it toward its ordered heading, changes its speed, and moves it. Ships in different groups need not move at the same instant; their positions and headings change in steps rather than continuously between updates.

As an illustration, twelve successive movement callbacks visit slot groups 0, 1, 2, 0, 1, 2, 0, 1, 2, 0, 1, 2. During roughly that span, the separate ship-state callback runs twice and checks all active ships on each pass. The two schedules are not synchronized to one another, so this is an illustration of frequency, not a promise about their exact ordering at second 6 or 12.

The separate six-second callback first advances mine timers, then makes one pass over all active ships, regardless of movement group. For each ship it checks maintenance state and target locks, updates shields and cloaking, recharges the energy pool, advances incoming torpedoes and missiles, ages decoys and weapon reload counters, processes ion fire, and checks damage and repairs. The pass can destroy a ship whose damage has crossed the destruction threshold. A ship can therefore move twice between two system passes. A player may also issue commands between callbacks: a command can change the ship's intended course immediately, while its actual position or heading changes on its next movement turn.

Weapons and other short timers

Incoming torpedoes and missiles are advanced and checked during the six-second ship-state pass, not on every one-second movement callback. Mine timers also decrement in that pass; mine proximity work occurs every fifth such tick, with detonation on the timer's zero pass. Decoys and several weapon reload counters are likewise handled there. For example, a reload counter of one normally means the next six-second system pass, not precisely one second after firing.

Combat restrictions use the same distinction. The cantexit counter is decremented during the six-second ordnance check, so its duration is measured in system passes. In GE, a full FIRETICKS value of 10 corresponds to roughly 60 seconds, but further hostile activity can refresh it and some events set a shorter delay. ge-arena uses a value of four, roughly 24 seconds. The time actually remaining depends on where the ship is in the current six-second cycle and whether another event changes the counter. See Exit command and Maintenance command for what the restriction affects.

Automated ships

The automated-ship scheduler runs every second and visits live NPC slots, but visiting a slot does not mean the ship makes a new decision every second. Each NPC has its own tick counter: the scheduler decrements a positive value and calls that ship class's behavior routine when it reaches zero. The behavior routine can choose a different delay for the next decision, and combat or pursuit can shorten that delay. The scheduler also considers one vacant non-user ship slot for NPC creation after every 30 of its one-second ticks; this is an opportunity to create a ship, not a promise that one appears every 30 seconds. Movement still follows the same three-group schedule used for player ships, while shields, damage, and ordnance still use the six-second ship-state pass. This is why an NPC's movement cadence and its decision cadence should not be treated as the same thing. A sysop Cybertron pause suppresses the active behavior pass, including countdowns, but the scheduler can still consider vacant slots for NPC creation. In ge-arena, the ordinary NPC scheduler does no work outside active regulation play; Base mode's initial staging spawns are handled by the separate arena clock.

Planetary updates

Planet production is not tied to the six-second ship callback. A separate routine steps through eligible planet records, using a variable interval. The administrator's PLANUPD setting specifies how many passes through the eligible planets the game aims to complete in a day; the default is four. GE recalibrates the interval as passes complete. ge-next also stores per-planet timestamps and accounts for missed updates after downtime. A larger database can require more frequent callbacks, and not every callback necessarily finds a planet to update. For the traversal, pass schedule, timestamps, and catch-up, see Planetary update cycle. The calculations within one production pass are at Planetary production.

Other callbacks and ordering

GE runs a separate neutral-zone beacon callback about every 120 seconds. Its timing is independent of the three-second per-ship movement cadence and the six-second ship-state pass. The midnight routine is different again: MajorBBS calls it during host cleanup, not through rtkick(), and it does not perform a planetary production pass.

Ordering between callbacks matters. Movement may happen before or after an ordnance update, and a ship can cross the destruction threshold before the pass that removes it. A later effective hit in that interval can change the last attacker. Maintenance, locks, shield state, and delayed messages are likewise observed when their own callback runs. Ports should preserve these schedules rather than collapse the mechanics into one timer. The 5.x and 6.x 16-bit builds use different MajorBBS callback signatures, but thin wrappers call the same gameplay routines.

ge-arena clocks

In ge-arena, the one-second callback also advances the arena state machine. The automatic lobby start timer and initial staging each last 60 seconds; combat then runs for 15 minutes. Respawn selection lasts 10 seconds. A tiebreaker, when needed, has a 10-second staging countdown and a two-minute combat limit. These are separate from ship movement and system recharge: the match clock can advance on a second when a particular ship has not yet moved. See ge-arena for match rules.

Centocks and displayed time

Older GE documentation uses centock as an approximate short interval, often described as about five seconds. It is not a single timer that drives every part of the game. When converting a delay into seconds, identify the counter and the callback that changes it; five NPC scheduler counts, one movement turn, and one ship-state tick are different things.

Countdowns and messages describe elapsed play in human terms, while effects are observed at callback boundaries. If a system is due to recharge on the next six-second pass, it may appear almost immediately or nearly six seconds later depending on when the preceding action occurred. This ordinary phase difference is distinct from a timer being configured incorrectly.