Code structure

From Post-Apocalyptic RPG wiki

Jump to: navigation, search

Submitted code proposal.png This article features an submitted code proposal.

Submitted code proposals are currently under consideration for implementation.

This article is a proposal for the basic design of the game code for PARPG.

Model structure

Basic assumptions

Things in the world

  • Living
    • Mobile
      • A hero(ine).
      • Other humans.
      • Animals.
    • Immobile
      • Trees.
      • Plants.
      • Biological contaminants.
  • Non-living
    • Mobile
      • Vehicles.
    • Immobile
      • Buildings.
      • Tools.
      • Weapons.
      • Communication devices.
      • Clothing.
      • Food.
      • Radioactive and chemical contaminants.

Basic properties of the world

  • Time models
    • Turn-based.
    • Real-time.
    • Fast time (e.g. journeys).
  • Progression
    • Diurnal.
    • Seasonal.
    • Geological.
  • Terrain
    • Local terrain (tiles)
    • Regional terrain (maps).
    • Global terrain (world map).
  • Climatic (affected by terrain and progression)
    • Local climate (e.g. sheltered hollow).
    • Regional climate (e.g. cold front).
    • World climate (e.g. ice age).

Basic properties of all things

  • Affected by the climate.
  • Affected by the terrain.
  • Affected by the progression of time.
  • Have a degree of repair or health.
  • Have weight.
  • Have bulk.
  • Some things may burn.

Basic properties of living things

  • Can heal.
  • Require food.

Basic properties of mobile living things

  • Have some controlling intelligence.
  • Have an inventory.
  • Affected by the time model.
  • Can move (obviously).

Basic properties of non-living things

  • May have a capacity.
  • May alter the climate inside them or around them.

Extra properties for specific classes

  • Clothing has a size.
  • Weapons may require ammunition.
  • Use of tools involves a skill (weapons could be considered a class of tools).
  • Vehicles require fuel, and fuel has types.
  • Liquids can only be stored in liquid containers.
  • Food has some nutritional value.
  • Living things potentially become food when killed.

Entities (things)


  • weight
  • bulk
  • flammable
  • is burning
  • age()

To update the entity with the general effects of wear and tear.

  • internal temperature

E.g. submap buildings are warmer than outside, depending on the external climate. Need to keep something small warm? swallow it.

  • surface temperature
  • visibility [to handle stealth]
  • fastened to (Entity)

To allow dragging without picking up. Handles things like sleds pulled by dogs, people dragging carcasses, boats tied to trees etc


  • hunger
  • fatigue
  • speed
  • health
  • has an Inventory
  • has a Container (you could stuff things other than food in there, to keep them warm maybe)

When there's food in your stomach you aren't getting hungrier. It's consumed at some rate. If you consume poison/tainted food, you can ameliorate the effects by puking, emptying whats left in your stomach

  • has a liquid container (blood)

This is to keep track of what you're high on, as well as blood loss.

  • has clothing


  • associated Skill information (map from Skills to skill data - skill specific)

Skills can be applied to any item, but some items are beyond "generic" and have roles, and/or particular appropriateness for some skills. The skill data stores this kind of information. (e.g. pointy, usable to light fires, usable to repair an engine)

  • potential associated Container
  • potential associated LiquidContainer
  • potential associated Food


  • bulk capacity
  • weight capacity
  • set of Items


  • volume capacity
  • weight capacity
  • fluid quantities


  • weight per volume


  • maximum bulk
  • maximum weight
  • one item only


  • slots: map of names to InventorySlots


  • is your turn ()


  • attempt([entities]) [ e.g. given this mismash of entities, try to work your magic ]


  • has liquid containers (fuel tanks, coolant etc)
  • has containers (cabin, seats, trunk etc)
  • top speed
  • is operational


  • map from named "nutrition elements" to nutrition by weight [handles e.g. cars want "flammable" food, people want "fatty" food]


  • has a warmth
  • has a protection value
  • has a size
  • has a suitable slot


  • has a size
  • has a fudge factor (you could put this on but you're not doing yourself any favours)


  • set of named ClothingSlots



  • has a Map [largely static]
  • has a RegionalClimate [dynamic]
  • has a latitude and longitude


  • temperature at (location)
  • visibility at (location)
  • degree of precipitation at (location)
  • wind speed at (location)
  • precipitation type
  • has a Daytime


  • sunset
  • sunrise
  • maximum sun intensity (e.g. ozone effects)


  • terrain at (location) [LocalTerrain]


  • blocks wind [e.g. walls]
  • blocks precipitation [e.g. doors, trees]
  • ground cover depth [e.g. 10ft]
  • ground cover type [e.g. ice, snow, water]
  • elevation at (location) [mostly for shooting skills]
  • visibility cover [height, degree]
  • TerrainType


  • has a GlobalClimate
  • has a Time
  • has a WorldMap


  • RegionalClimate at (latitude, longitude, time)


  • Map at (latitude, longitude, time)
  • GlobalTerrain at latitude, longitude


  • ground cover depth [e.g. 10ft]
  • ground cover type [e.g. ice, snow, water]
  • elevation at (location) [mostly for shooting skills]
  • TerrainType [ just an enumeration of types, no further meaning, except how they're drawn and so forth, and how things react to them ]

Game structure


These taken from Basic Game GUI.


We need some kind of basic window management, since there are more windows that we can simultaneously display. A simple approach is two paned. There are two slots, right and left, that any window can go into. Windows can be in three states: open and visible, open and covered, or closed. Whenever a visible window is closed, a covered window is moved in to take its place. Open windows freeze time.

Character generation

Function of a Critter CharacterWindow(Critter); takes one pane.


Function of a Player Automap(Player) (since we aren't going to track what all critters have seen, only what the PC has seen). Requires some kind of recording scheme for marking cells as seen.

Dialog interface

Easiest if this is a single pane too, with portraits and dialog. Allows things like talking during barter if necessary. Dialog(Critter (controlled), Critters...(also involved))

Barter interface

An inventory window extension. Probably best if there's some kind of callback that deducts cash whenever something is dropped into the player inventory, and adds it when dropped into the barter inventory. Nothing is finalised until the window is closed. Barter(Critter).

Character interface

Same as character generation, with most parts locked. This is probably just handled by the underlying critter no longer having points/whatever available to change, or being marked as "locked". CharacterInterface(Critter).

Quest interface

Some kind of journal. Surfaces an underlying log of quest events. Perhaps multiple kinds of page, so a table of lists, one entry per kind of page, list of entries per page type. Quest(Game)


Same as barter interface, without cash callbacks. Inventory(Critter). Could be displayed for vehicles, also dead critters.


Permanently visible. Surfaces some kind of game state holder; current time, party members. Needs to know who the PC is by some means. HUD(Game)

Class Summary

WindowManager(dimensions, HUD)
Inventory(Critter, WindowManager)
BarterInventory(Critter, WindowManager)
Quest(Game, WindowManager)
Dialog(Critter, Critter[], WindowManager)
Automap(Game, WindowManager)
Character(Game, WindowManager)

Communication with other systems

FIFE Instances

One per Entity. Draw selection done based on idea instances can take two paths

  • return themselves
  • ask their children

World (special container) - asks all children for instances

Normal instance - returns self

Instance with other instances drawn inside (maybe open top vehicles?) - returns self + requests children

All returned instances drawn.

FIFE Actions

Entities have "physical" methods (mark these somehow) which describe things that entity can do in the world. Each of these can have a mapping to an action. e.g. Wall.crumble() Man.move_to(). Maybe this is done better with an Activity class e.g. Entity.apply(Activity).

Story engine

Queried per frame. Push all entity information into story engine database for fast caching (eliminates virtually all property lookups). One of the responsibilities of an entity is keeping the story engine up to date (is there introspection magic we can use to guarantee this?). SE responses are acted on immediately. TBD decide whether to act on all or one response (nb you have to query again after you execute any response).

Class Summary

  • Entity(StoryEngine)
    • apply(Activity)
    • get_drawables
  • StoryEngine
    • query
    • execute(Response)
  • Activity
    • action_name
  • World
    • get_drawables
Personal tools