User Tools

Site Tools


gcsetgamesequel

GCSET 2

Overview

A more complicated version of GCSET.

Text based tactical space combat. Ships have hit points for various regions (bridge, engine, guns, power) and shoot each other up. After the combat engine is completed, the final version will have interstellar trade and possibly politics and BaronsOfGidea-style economics.

New features should include:

  • Ship configuration
  • Trading a la TradeWars

Development Roadmap

Progress halted as of summer 2003.

Version 0.01

  • Basic container model (75% done)
  • Basic thrust model
  • Basic damage model (50% done)
  • Basic weapons model

Version 0.10

  • Basic targeting model
  • Playable clone of original GCSET with more abstracted engine

Version 0.20

Version 0.30

  • Read ship specs from data files
  • Save ship specs to data files
  • Modular weapons system
  • Modular ammunition system

Version 0.50

Version 1.0

  • Interstellar trade
  • Crew
  • Lots else

Features

Technical Features

The game should be playable from a text console.

The game should use an internal communications language to allow alternate user interfaces to be developed.

The game should be developed in a forward-thinking manner so that multiplayer capabilities could be slapped onto it in GCSETVersionThree.

Dependencies

Gameplay Features

Weapons

Need design for a modular weapons system, as well as a modular ammunition system. May require “keys” on each item, a base weapon/ammo type (projectile, direct energy, launched missile, launched energy), an ammunition key for determining whether weapon can use the ammo, another key for whether the weapon may be mounted on a weapon platform,

Weapons must be installed on a weapons platform. A weapon built into the ship itself will be considered to have a custom weapons platform which can only take that one kind of weapon. Weapon platforms will have ammunition loading and storage chambers. Ammunition stored elsewhere on the ship takes time to retrieve and deliver to the loading chamber. Consider “pipes” which direct material from one container to another.

Containers

Ammunition, weapons, ships' rooms, cargo all will be “containers”. Each container has:

  • Thickness - How thick the container's shell is.
  • Material - What the container wall is made of.
  • Volume - How much space the container takes up, including its shell.
  • Mass - How much the container weighs.
  • Hit points - capacity for damage.

The idea is to construct containers out of materials which have set ratios of mass to volume, durability, and explodability, and then build an object of X volume and Y storage capacity (which is additional Volume that is not made of the same material). This is being implemented by using set values of volume and container thickness, and calculating storage capacity and mass on the fly.

Trade would then be conducted in volumes of tradeable objects such as “grain” which would have little to no durability and capacity for holding other objects. In container terms, their thickness takes up their entire volume.

These material-container based objects can also allow for the idea of “livingspaces” which would be required on board a ship to keep morale up, and which would just be areas of empty volume inside a ship. The detrimental effects of not having enough living space on a ship would increase the longer the ship goes without the crew having a planetary leave; Fighters have no living space but don't need it since they quickly return to a ship that does.

Damage model

Imagine a shot striking Container 1 which contains Containers 2 and 3.

  1. Damage strikes Container 1. Whatever damage is not absorbed or deflected pierces Container 1 and continues inward.
  2. Damage can strike one of Container 1's children or can pass through any empty space inside Container 1. In this case, let us say that damage strikes Container 2. Container 2 has no children, so the damage is directed out of Container 2.
  3. Damage strikes Container 2 again upon exiting the container. This represents the damage hitting the container's far wall
  4. Damage may again strike a child of Container 1 which it has not already struck. In this case, it hits Container 3.
  5. Container 3 has no children, so damage passing into Container 3 is redirected outward, hitting Container 3's far wall.
  6. Damage again strikes a child of Container 1. In this case, the damage passes through a region of empty space and is directed out of Container 1, hitting Container 1 again on the way out.
  7. Damage has left Container 1 and dissipates into space.

Damage has a “width” value representing the size of the shot. Wide shots will be more likely to hit subcontainers than to pass through space, and may hit multiple small siblings at the same time.

Crew

Ships' crew can go crazy if they're in cramped areas for too long. You will need to design ships with some empty space left over. Incidentally, this will prevent fightercraft from staying spaceborne for more than a few hours of gametime.

Transferring Goods

Goods are transferred at a flow rate that includes both bandwidth and latency. Latency is affected by the size of the parent container.

Occasionally, goods will need to be transferred from one system to another. This includes:

  • Moving goods on/offship to sell
  • Moving ammunition from stores to gun emplacements
  • Moving fuel from stores to engines
  • Moving equipment from stores to damaged regions of the ship

Methods of transferring goods:

Liquid goods can be transferred through a “pipe”, a type of construction which has can move a good from one container to another. To implement pipes, consider adding “to” and “from” container* to container object. May also need flow_rate variable.

Solid goods must be moved by the crew.

  • If a good is larger than the available empty space in the parent container, it cannot be moved.
  • Size of parent container effects time to deliver

When liquid goods must be moved by the crew, they can only be moved in barrels (which must be acquired separately) or through a pipe fitted from the cargo bay to a port on the ship's hull

Gaseous goods == liquid goods for now.

Problems with pipes

A pipe that traverses containers will be a child of all of them. This means that the free() routines must be rewritten to recognize pipes and to only free them once.

Pipes look like a recipe for losing containers and gaining memory leaks

How will a container know that it has a pipe attached to it so the computer would send needed goods down the pipe instead of sending crewmen to carry them over?

Thrust

Engines must be on the outside of a craft if they are intended to be fired; otherwise, they would be considered cargo. Being on the outside, engines are exposed to immediate damage. Components inside the hull are not exposed to damage until the hull has been shot through.

This brings up the question of how to have an armoured sheath around the majority of an engine. Possible solution for now: Place engines as immediate children of the hull, and have a chance that they can be hit without damaging the hull.

Missile example

A missile can be constructed as a small ship with the AI to fire its single weapon and self-destruct when it reaches its target.

There are two fuel tanks: one in the engine, and one in the missile's main body. The engine can only use the fuel in its own smaller fuel tank. Since this can quickly run out, the missile has a larger fuel tank which feeds into the engine's fuel.

This is done through a type of connection which is automatic and requires no crewman's time. The connection has a flow rate which, in this case, would be high enough for the engine to continue firing at full capacity until the larger fuel tank runs out.

None of these components requires crewmen to operate. Hits to the engine would either:

  • have no effect on the engine's running
  • reduce thrust
  • disable the engine completely
  • Any of the above, /plus/ go through to the engine's internal fuel hold
  • Any of the above, /plus/ hit the connection to the main fuel tank

Hits to the engine's fuel hold would:

  • cause minor damage (glance off the container)
  • start a leak of the non-solid fuel
  • cause the volatile fuel to explode, hitting the engine and connection
  • Any of the above, /plus/ hit the connection to the main fuel tank

The connection/pipe to the main fuel tank is available to hit from both the engine and engine's internal fuel tank. It can also be hit from the hull or the main fuel tank. This is because, to reach the engine's fuel hold, the pipe must start at the main tank, go “up” the tree to the hull, go “down” into the engine, and “down' into the fuel hold.

This also brings up the hull/engine issue that isn't figured out yet.

A hit to the fuel pipe would have the same effects as hitting the fuel hold. Since the pipe is small and has no armour, a hit would almost certainly put a hole in it. If the pipe is destroyed without causing a fuel explosion, the flow rate of the pipe becomes the flow rate of leaks from the pool and the main tank. Since there is no crew to patch the leaks, the leaking will continue until both tanks are empty.

Hits to the fuel tank are like hits to the smaller fuel hold. A difference is that there is more fuel there, so an explosion would cause more damage than one in the engine's fuel hold (not that it matters, since the smaller explosion would wipe out the missile too).

The hull, like all Containers, has a thickness. Hits which are not strong enough to break through the hull's thickness will only damage the hull, while stronger hits can do some damage to the hull and continue to damage internal components. If the hull or any container has taken enough damage, there becomes a chance that enemy shots will completely bypass it.

The chance of hitting an internal component is that of the component's size versus the non-hull volume of the parent container. If empty space is hit, the damage hits the parent container again and passes “upward” until it passes out the other side of the craft.

Damage effects have a piercing value which effects the chance of passing through a container's wall. Low piercing damage will wipe out large sections of a container, while high piercing damage will punch smaller holes in the container and bounce around the internals.

The internal components of this missile are (the engine,] the fuel tank, the cpu, the warhead, the pipe, and the targeting system. The fuel tank is larger than the others [except the engine?] and has the greatest chance of being hit. The pipe, cpu, and targeting systems are smaller and have less of a chance of being hit.

Damage to the CPU will disable the missile.

Damage to the targeting system will cause the missile to lose track of its target. Effectively, it is lost.

Damage to the warhead would make it explode, causing significant damage to the other components such as the fuel tank (which would explode causing significant damage to the other components).

Interface

Possibly use “command language” protocol for base interactivity which UIs will translate into English for the player.

Metadata

{“TOPICINFO”:{“author”:“DeltaTango”,”date”:“1333593390”,”format”:“1.1”,”version”:“1.1”},”TOPICPARENT”:{“name”:“WebHome”},”GameAboutFormTemplate”:{“GameGenre”:“Unspecified”,”Inspirations”:false,”GamePerspective”:“Unspecified”,”ProjectLegality”:“Unspecified”,”ProjectDifficulty”:“Doable”,”TargetPlatform”:“Unspecified”,”TargetERSB”:“E”,”YearOfIdea”:“1998”,”DesignVersion”:false,”DesignCompletion”:“Needs Work”,”CodeVersion”:false,”CodeCompletion”:“No code”}}

gcsetgamesequel.txt · Last modified: 2013/11/30 03:03 by deltatango