Dr. Scott M. Baker

SGW Design Document

SGW Design Document

Scott M Baker, 1995-1996

This Document

This main purpose of this document is to serve as my notes while
working on the SGW project. I’ve also added some general information for
those who might want more information. When SGW is released, I’ll probably

release this as a technical doc to those who are interested in adding LGPL

SGW Gameplay: Basics and Objectives

SGW is your typical space trading game – it shares aspects with Galactic

Warzone (obviously!), Trade Wars, and other space trading games. The objective
is traditionally to amass wealth and power, destroy everyone else, and basically

dominate the universe.

The universe is a collection of “sectors”, connected via semi-random “warps”.

The player may navigate the universe by manually moving from sector to sector
or by using an autopilot which will automatically calculate the shortest

Initially money is made by trading. Trading is the process of docking
at a port, taking the contents to another port, and selling it for a higher
value – the “buy low, sell high” principal. This is a fairly boring and time

consuming process, but people seem to get the hang of it. More money means
you can buy more cargo holds which means you can do more trading.

Once the player is built up sufficiently, a planet is usually construced.

Planets produce cargo automatically and therefore are an easy source of wealth.

The player must transport cargo to a planet to increase it’s production.

The player will then start to build several planets and transfer cargo
from one to another, thus increasing all of their production. With such a

collection of valuable planets, defense becomes very important and fighters,

mines, etc will be employed to defend the planets.

What makes SGW different

A game can’t be successful unless it has something that makes it
special. Obviously SGW will share many similarities with GW, but the following

enhancements will increase playability:

  • Port Ownership. Players can attack and take posession of ports and
    thus rake in 10% of the ports business per day.
  • Devices. SGW will have a rich set of specialty devices, including weapons,shields, navigational aids, and other specialty devices.
  • No too many devices. Too many devices make the game too complicated.
    Basic capabilities such as autopilot, macro computers, battlegroup computers,
    etc are going to be provided automatically.
  • Uniform format. Planets, ports, ships, and defense platforms will all
    have the same structure and thus devices may be swapped from one entity toanother. For example, a phaser bank could be added to any of the previously

    mentioned entities. This differs from most trading games which have a confusing

    assortment of specialty devices for planets, specialty devices for ships,

  • Generality. The uniform nature of the device format will allow easymodification of existing devices. You could for example add your own commodities

    to port trading just by creating a new type of buyer/seller device and adding
    it to the port.

  • No special code, no special structures. Since every device looks the
    same internally, I can get by writing a lot less code. This means fewer bugs,
    and a smaller executable. There’s no need to “special case” everything.Transferring a phaser from a ship to a port uses exactly the same procedure
    as transfering a phaser from a ship to a planet, which is the same as transfering

    a phaser from a ship to a ship, …

  • LGPL support. LGPL, my own programming language and compiler, will beprovided to allow endusers (sysops, not players) to create custom datasets
    with their own devices, modify existing devices, etc.
  • Dynamic Structure. Linked lists will be used rather than arrays. Games
    like GW relied heavilly on arrays and thus had all sorts of unnecessary fixedlimits. In SGW, a ship could have an infinite (well actually it limits off
    around 2 billion) number of devices in inventory. The same goes fort ports,

    planets, etc. Sectors can have multiple defense forces.

  • Large integer variables. Every game I’ve written seems to have suffered
    from players being able to overflow the variables. I’m going to use the BP
    Comp variable to handle all data that might get “large”. The comp is a 64
    bit signed integer. It’s maximum is somewhere around 9.22×10exp18, which
    is a big number.
  • Alternate weapons. Basic Fighters are boring – SGW will have multiple
    fighter classes as well as energy weapons which can be deployed on ships,
    ports, planets, etc.

Device Fundamentals

Devices are the backbone of SGW. With few exceptions, every object
in SGW is realized in the form of a device. This includes ships, ports, planets,

and any item which they may contain. A device has the following important

  • v1 … v4: These are generic numeric fields. What their values meandepends on the device application (devapp) code for the device. If the device
    in question is a co-device, then v1 has a special purpose — it is the quantity

    of the device which is present.

  • devapp: Each device has a SET of devapp codes. This set could be nil,
    just one devapp, or as many devapps as you wish. The devapp code specifies
    what the device does and what it’s data means. For example

    • dev_port: a port (i.e., something the user can dock and trade at)
    • dev_seller,dev_buyer: devices within a port which buy and sell commodities
    • dev_planet: a planet (i.e., something the player can land on)
    • dev_ship: a ship
  • name: Each device has a name. In terms of simple devices, such as
    a fighter or cargo hold, the name may just be “Fighter” or “Cargo Hold”.
    For special devices, such as planets, ports, or ships, the name will be what
    the player decided to call the item.
  • contents: Any device can contain other devices. This is how ships, planets,ports, etc work. A ship is just a device of type dev_ship which commonly
    contains the additional devices: engine, infrastructure, fuel, cargo hold,
    etc. A port is just a device of type dev_port which contains dev_sellers,

    dev_buyers, etc.

  • contained_by: Each device knows who contains it. This allows you to backtrackfrom a device to find the container.
  • playernum: This contains the player-number of the person who owns the
    device. This is very important in terms of ships, planets, ports, etc.
  • mass: every device has a certain mass. This mass is then summed by the
    ship and compared to the ship’s engine to see how much fuel is required to
    move a ship.

Device Types

Devices traditionally fall into the following categories:

  • “Special devices”. These are things like ships, planets, ports, etc.
    They typically contain an inventory of other devices.
  • Ordinary devices. Devices which occupy a numbered “slot” in the inventorylisting. Since they are assigned a slot, their number is constrained by the

    “infrastructure” of their owner. They are usually optional equipment – things

    which may be purchased or sold, transfered to other ships, etc.

  • Ship Systems. Ship systems do not occupy a numbered slot. They typicallycannot be removed or sold, but they may be upgraded. These are usually essential

    items such as an engine, treasury, docking thruster, etc which would cripple
    the owner if they were removed.

  • Unlisted devices: These are devices that are not specifically listed,
    or are represented in another manner. These include fuel, fighters, money,
    cargo, holds, etc. These items are bought, sold, and transfered using specialtycommands.

Player Ships

As previously mentioned, the player ship is a device which contains
the devapp code dev_ship. The ship also contains the following devices:

  • Infrastructure (dev_infra). This is the skeleton and hull off the
    ship. The infrastructure tells the number of ordinary devices that the ship
    may hold.
  • Engine (dev_engine). The engine is essential to move the ship. An engine
    is capable of moving a certain amount of mass by expending a certain amount
    of fuel. For example, a basic engine may require 1 fuel per 250 metric tons
    of mass moved.
  • Docking thruster (dev_dock). The docking thruster is necessary to dock
    the ship with a port. Similar to the engine, it requires a certain amount
    of fuel per mass.
  • Fuel (dev_fuel). Fuel, essential for moving, docking, landing, etc.
  • Holds (dev_hold). Cells which are used to store cargo.
  • Cargo (dev_cargo). The cargo itself – ore, organics, or equipment. The
    total cargo may not exceed the number of holds.
  • Fighters (dev_fighter). Fighters which accompany the ship. Fighters areself-propelled and thus do not add to the mass of the ship.


A port is a device of type dev_port. The following flags determine
a port’s behaviour:

  • Flag_port_devsell: The port sells devices and is assumed to containsellers with the devapp code dev_devsell.
  • Flag_port_menu: The port should call up a menu (in the ports v3 variable)
    and execute it.
  • In the absense of the above flags, the port is assumed to be a standard
    port, which sells products (ore, org, eqp) and contains sellers and buyers
    with the devapp codes dev_buyer, dev_seller.

Ports in SGW are owned, and the playernum variable should reflect
the owner of the port. 10% of the daily business is automatically deposited
in the port’s treasury. This includes all types of ports, including device

sellers. The following devices are important to ports:

  • Product Seller (dev_seller): Sells a certain product.
  • Product Buyer (dev_buyer): Buys a certain product
  • Device Seller (dev_selldev): Sells a device.
  • Port Infrastructure (dev_infra): Tells how many ordinary device slots
    a port may contain.

Ports can be attacked and therefore should be defended. I intend
to automatically place a “Port Phaser” and “Port Shield” in each port to
act as defenses. Important ports like Sol will likely have multiple port
phasers installed.

The player may place additional devices on a port to enhance it’s defensive

capabilities. For example, adding a Phaser-1000, Photon-Launcher, etc.


A planet is a device with the devapp code dev_planet. Planets may
be landed on via the L)and command. Planets in general are storehouses for
cargo and produce cargo. Cargo production is increased whenever 10% of the

inventory exceeds the production. For example, if a planet had 1,000 ore,
then production would be a minimum of 100 ore/night.

The following are important to planets:

  • Cargo (dev_cargo). Just like in a ship… These hold the cargo that
    is on the planet.
  • Producer (dev_producer). These tell how much cargo will be produced eachnight. Production is increased automatically when cargo is deposited on the


  • Factories (dev_factory). Factory production is determined based upon
    the cargo production of a planet.
  • Planet Infrastructure (dev_infra). Tells how many ordinary device slots
    are available.

Defense Platforms

Defense platforms are devices (with devapp dev_platform) which may
be deployed in a sector. They have no cargo production capabilities or trading

capabilities. A defense program may be programmed with a wide range of defensive
program options.

The simple mine/fighter defense group is a special case of the defense

platform which only holds mines or fighters. It is really not a defense platform

at all in the physical sense, but rather just a group of objects deployed
in the sector.

Defense Platforms (except mine/fighter defense groups) may be augmented
with whatever devices the player wishes. These could be weapon or shield
systems used for defending the sector. The intended purpose for a defense

platform will be to hold defensive devices such as phasers or photon torpedos.

The following devices are useful to the defense platform:

  • Platform Infrastructure (dev_infra): tells how many ordinary device
    slots are available.
  • Weapons (dev_phaser, dev_photon, etc)
  • Shields (dev_shield)
  • Fighters (dev_fighter)

Defense Program Options

Defense programs are comprised of a series of bits which define the
functioning of the program. Individual bits may be turned on or off, thus
toggling the individual program features. Program settinges include:

  • prog_port: docking to the port (if one exists) in the current sector
    will be refused.
  • prog_planet: landing on planet will be refused.
  • prog_sector: entry to the sector is refused.
  • prog_ambush: devices will detonate after the player
    has entered the sector and without warning.
  • prog_team: team members will be treated the same as non-team members.
  • prog_toll: paying a toll fee will allow the player to bypass defense

The program will always be stored in a device of devapp “dev_program”
as follows:

  • v1 = amount of toll fee, if applicable
  • v3 = program bits
  • v4 = “mask” of allowable program bits that the owner may set.


Weapons are essential to combat. Weapons have many parameters, including

the following:

  • Consumable vs Rechargable. Some weapons, like photon torpedos andfighters can be consumed in combat. Others, like phasers are rechargable
    and available at full strength every time.
  • Damage. Photon Torpedos, Mines, Phasers, etc have a damage rating thatdetermines how many fighters they will destroy.
  • Ammunition/Launcher. The Photon-Launcher requires Photon Torpedos for
    ammo. Either of the two alone is useless.

Specific weapons classes:

  • Phaser. The phaser is automatically recharged and will do full damage.
    It does not require ammunition.
  • Photon Torpedo/Photon Launcher. The Photon Launcher will fire a predeterminednumber of torpedos at the enemy fighters. Torpedos are consumed when fired.
  • Fighters. Basic Fighters are engaged in one-on-one combat with enemy
    fighters at a 50/50 success rate. Specialized fighters may include (ER=EnergyResistant, MR=Mine Resistant,etc)
  • Mines. Mines are passive by nature and will detonate only as a last line
    of defense.
  • Shields. Shields are defensive-only and have no offensive capabilitywhatsoever. Shields protect a ship from being captured in the sense that
    the attacker must have a number of fighters >= the amount of shields of
    the defender.


Combat is the single most difficult programming/design aspect of
SGW. I’ve been struggling with the concepts and have decided on one single
combat strategy. Attacks are always designated with an attacker and
a defender. In most cases, the attacker will be the player who is

currently online and the defender will be a ship, planet, platform, or port.

The attacker usually forms a battlegroup which will assault the defender.
In the first attack pass, this battlegroup is the only thing that the defender

will encounter. All of the defender’s items (fighters, devices, mines, …)
will only assault the battlegroup, not the attacker’s ship.

In the second optional pass (“counterattack”), the defender may target
the attackers entire ship.

In detail…

  1. The attacker forms a “battle group” which will contain fighters whichwill assualt the defender.
  2. The attackers devices (phasers, photon torpedos, etc) will fire
    on the defender.
  3. The defenders devices (phasers, photon torpedos, etc) will fire on thebattlegroup.
  4. Fighter-vs-Fighter combat will engage between the battlegroup and thedefender.
  5. The defender’s mines detonate against the battlegroup
  6. “Takeover Test” is performed.
  7. If no takeover, then the battlegroup will return to
    the attacker and merge, and the defender may launch a counter-attack against
    the attacker (i.e. his full forces, not just the battlegroup)

Takeover Test

The test is performed in one direction only. If the attacker has
1 more more fighter and the defender
has zero fighters, then takeover will be attempted. Takeover succeeds if
the defender has no EM-Warp and the attacker has sufficient ships to breach
the defender’s shields.

Sector Posession

When an entity (i.e. a ship or battlegroup) attempts to enter a sector,

an attack menu will be displayed. This menu will contain options such as
attack, retreat, etc. If attack is selected, then combat will be engaged
in two steps: first the active combat, then the sector will be “occupied”
by the attacker, then passive combat will be engaged.

Planet Posession

If a player attempts to land on a planet that he does not own, then
an attack menu will be displayed, with the usual options. If the attacker

continues, then active and passive combat will be engaged. The attacker is
NOT given posession of the planet until both active and passive combat have

successfully completed.

Port Posession

Exactly the same as for planets….

Outpost Posession

Exactly the same as for planets…

Devapp Codes
devapp code
mass per fuel
mass per fuel
  energy weapon resistance mine resistance  
nightly production
price percent
nightly production
price percent
fighters destroyed
    menu number    
number of units to damage      
  dev to sell
  # critical slots
factory value
prod reqd per unit
    item produced
      (if flag_platform_group) then devapp code of constituent devices  
concurrent launches
fighters destroyed
fighters required to penetrate
dev_inhibitor     devapp code to inhibit    
dev_launcher     devapp code to launch devapp code of acceptable targets  
dev_reactor number to maintain       device to produce
dev_fusion stored quantity   devapp code to store    
dev_deflector number of mines to deflect        
dev_program toll fee   program bits program mask bits  

Related Topics

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!

New Kickstarter Project!

Interested in Nixie Tube projects? Check out my new Nixie Tube Calculator project on Kickstarter.

Copyright Notice

All content on this website is copyright Scott M. Baker and may not be used or reprinted without explicit permission.

Violators will be eaten by a grue.