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
code.

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
path.

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,
  etc.

• 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.22x10exp18, 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
fields:

• 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.

Ports

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.

Planets

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

  planet.

• 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
  forces.

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

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

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	v1	v2	v3	v4	Contents
dev_ship
dev_fuel	-co-
dev_engine	mass per fuel
dev_dock	mass per fuel
dev_hold	-co-
dev_fighter	-co-		energy weapon resistance	mine resistance
dev_seller	quantity	nightly production	product	price percent
dev_buyer	quantity	nightly production	product	price percent
dev_mine	-co-	fighters destroyed
dev_planet
dev_port			menu number
dev_cargo	-co-		product
dev_money	-co-
dev_plasma	-co-
dev_pulsar	-co-	number of units to damage
dev_genesis	-co-
dev_selldev	quantity	price	tag		dev to sell
dev_infra		# critical slots
dev_producer	quantity		product	factory value
dev_factory	production	prod reqd per unit			item produced
dev_cloak	-co-
dev_anticloak	-co-
dev_platform				(if flag_platform_group) then devapp code of constituent devices
dev_battlegroup
dev_torpedo	-co-
dev_photonlaunch	concurrent launches
dev_phaser	fighters destroyed
dev_shield	fighters required to penetrate
dev_emwarp
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