Adventure system

This is the documentation of the design of the adventure (ADV) system. Because of the hack/slash format, there is no state distinction between combat and adventure, so some of the concepts may overlap.

The ADV system includes the concepts of:

  • Player attributes
    • Affecting combat
    • Affecting adventure interactions
  • Alert levels
  • Time of day
  • Movement
  • Trading system
  • Interaction with environment
    • Containers
    • NPCs
    • Robots
  • Sprite animation
  • GUI features

Player attributes

The player have attributes mostly related to combat (COM), but it falls under ADV when it comes to upgrading skills based on the experience points (xp).

When a player reaches a particular xp bracket, it is entitled to put more skills in the attributes. Xps are gained by accomplishing missions, and by disabling/destroying robots.

These are the player attributes and how they relate to improvement.

Agility (agile): relates to stealth and defense chance-to-hit.

Toughness (tough): relates to defense damage modifier.

Accuracy (acc): relates to combat offense chance-to-hit

Experience (xp): though this is accumulation from missions accomps, this attribute adjusts the combat effectiveness by modifying damage.

Speed (speed): the actual movement speed of the character. The use is not only to be able to cover more ground and thus make use of the time, but also in combat, the player is able to take cover faster.


Movement in ADV is tied to combat (COM). Very much like hack/slash where there is no distinction when a player goes into COM or ADV,

Crouching. Increases  stealth (ste) and defense (def) ratings. Slower movement.

Speed. Physically faster.

Animation poses

(up=Standing, dn=Crouching)

  • 8-direction
    • idleup/dn, walkup/dn, runup
      • wepnone/small/medium/large
    • die, useup/dn



This is a trading system used to buy and sell goods for money.


First, in order to simplify costing, a cost type is assigned to the item in a variable called cost_type. Cost type is rated alphabetically — the lowest is A upwards —  and it used to give a sequential degree of costliness for each item as it relates to another. Some examples.

  • Pen: A.
  • Adhesive tape: B
  • Spray paint: B
  • Portable data drive: C.
  • Powerjax: D
  • Doorjax: D
  • Jaxbox: F
  • Geomap: F
  • Shokgun: F
  • Berator: F
  • Python: G
  • Pony: H
  • SG-X: H
  • SG-Y: I
  • SG-Z: I
  • Betamax: J
  • Plasmax: J
  • Stunbomber: K
  • Blackminder: L


This is covered (no pun intended) in the Combat system page.

Alert levels

The concept of robots being on alert due to some factors. These factors are:

  • Initiation of combat: the init of combat is the first attempted hit of the player against the robot or SCAM or some other robot property. This may include a simple discharge of a weapon.
  • Trespass: location-based. When a player goes onto a location area of which is monitored, or of which player is observed to have entered by SCAM or patrolling robot, alert is raised.
  • Hacking (eg powerlet or terminal): hacking action on particular world object). Since terminals and powerlets are sensed by the robot framework, this is automatically detected, and alert levels go up.
  • Very late registration. This aspect takes some time to raise, and only when warnings have been issued to the player.  Time-based.

Alert levels have the following characteristics.

  • Alert condition: like DEFCON, the condition reflects the severity. It goes from ALERT0 (no alert) to ALERT4 (high alert).
  • Alert cooldown. An alert can go down or up in levels depending on the kind of instigation that happens. Each level has its own cooldown period. A cooldown period is the amount of time needed for the player to remain out of LOS before it goes down one level.
  • Alert escalation. An alert can escalate or reset the cooldown by the player being spotted again before the cooldown period. If the player does something that can escalate the situation, then the alert level gets promoted up depending on the action.

Alert level conditions are raised depending on detected player actions. Here’s a suggested design:

  • ALERT0: nominal.
  • ALERT1: cooldown is 5s.
    • Raised when a robot is quickly disabled/destroyed in one shot (no time to report back).
    • Raised when player discharges a medium or large weapon out of detection range of robot or SCAM (weapon report).
  • ALERT2: cooldown is 10s.
    • Raised when powerlet is jacked.
    • Raised when a player trespasses a restricted area.
    • Raised when robot engages player.
    • Raised when a player discharges a weapon in the detection range of a robot or SCAM.
    • Raised when SCAM sees weapon drawn.
  • ALERT3: cooldown is 20s.
    • raised when player discharges and hits one SCAM.
  • ALERT4: cooldown is 30s.
    • Raised when player hits a robot with a weapon, unless robot is completely disabled or destroyed in that single hit (in which case an ALERT 1 is raised).
    • Raised when player hits at least 2x SCAMs.

The purpose of the alert level is to make robots evaluate whether to attack the player if seen. The alert level, thus, is a timer based on the actions of the player.

When the alert condition is higher than ALERT0, and the player is seen, robots will engage the player. For example:

  • Start at ALERT0
  • Player destroys robot in one shot. Raise to ALERT1 (robot mainframe detects something went wrong, but doesn’t know what)
  • Robots converge to location of attack. Suppose robot sees player before ALERT1 cooldown expires, robot engages player, raising to ALERT2.
  • If player continues to evade and not fire back, and successfully keeps out of LOS, then alert level is downgraded to ALERT1, then eventually ALERT0.
  • However, if player attacks robot, then ALERT4 is immediately raised.

Another example:

  • Start at ALERT0
  • Player disables a SCAM. Raise ALERT3.
  • Robots converge to SCAM location. Can’t find player.
  • In the meantime, before ALERT3 cooldown expires, player hacks powerlet, which should raise ALERT2. But it’s already ALERT3, so nothing happens.
  • Say ALERT3 expires and downgraded to ALERT2, and so on.

Another example, using player discharge:

  • Start at ALERT0
  • Player discharges weapon into the air. Raise ALERT1 because no robot is in sight.
  • Any robot or SCAM will be on alert. Robot will attempt to move into the location of the discharge until cooldown. If robot sees player, then ALERT2.
  • If SCAM sees player entering field of view with weapon drawn, then ALERT2.

Alert conditions will also affect the number of robots sent to the area.

  • ALERT1: 1x nearest robot attempts to go to the area.
  • ALERT2: 2x nearest robot.
  • ALERT3: 3x nearest robot.
  • ALERT4: all robots within a certain distance.

Ready Item List (RIL)

The ‘Ready Item List’ is 4 slots on the ADV gui. Advitems placed in this list can be used in the game world, for example on an NPC, an env prop, etc.

To get advitems in the RIL, that INV gui must be brought up. Then advitem are dragged (or double-clicked) onto the slots.


Useitem, which is the using of advitems on world objects, is done by selecting an item in the ‘Ready Item List’, which is a gui element that gives the player 4 slots to put advitems into. These advitems can be then be selected in the ADV mode which makes them ‘active’, whereby the player can click on a prop/env item in order to execute a Useitem directive on it.

Interact with object

The player can interact with objects in the scene and uses the ITS to achieve this. ‘Interact’ refers to any action done by player onto something without the use of items to do so.

Examples of interaction:

  • Examine object (yields adventure text)
  • Talk to NPC (utilises the Talk system)
  • Talk to intercom (Talk system)
  • open door/force open
  • use vhone
  • use terminal (to input)
  • enter registers
  • climb stairs
  • attack object (special command since the default attack is for robots and SCAMs only)
  • press button/flick switch/turn dial
  • connect wires


%d bloggers like this: