Data Model¶

The data in Stellar Magnate is divided into two categories: static data that defines base information and dynamic data that changes over the course of the game.

Static data is shipped in yaml files with the program. When a new Stellar Magnate game is started, the yaml files are loaded into a database to initialize the program.

The dynamic data is generated by the game as it moves along. It is persisted into separate tables in the database as the game progresses.

Static data and dynamic data reside in different tables in the database but the dynamic data can reference the static tables.

Static Data¶

Shipped format¶

Game Dependent¶

These are various records that only the game ships because there needs to be new game logic whenever something is added to them.

order_status_type:
location_type:	enumeration of known location types. :surface: On the surface of a celestial body :orbital: Orbiting a celestial body in the system :dome: Exists under a dome because the ecosystem is otherwise non-habitable
planetoid_type:	enumeration of planetoid types - oceanic - gas giant - rocky - oxygen - methane
moon_type:	enumeration of planetoid types
commodity_type:	enumeration of known commodities. - food - metal - fuel - low bulk chemical - low bulk machine - high bulk chemical - high bulk machine
finance_type:	enumeration of known bank types. - mafia - system - capital - planetary
	The status of a transaction - presale - submitter - rejected - finalized
ship_type:	Passenger Cruiser Etc
equipment:
ship:	Cargo hauler
property:	Warehouse
ship parts:	Cargo module Laser

Extendable by Server Owners¶

system:

list of stellar systems

name:

name of the stellar system

possessive:

If a location’s name is not unique, then the possessive is applied to the name for display purposes

planetoid:

A list of bodies orbiting the system’s sun

name:

name of the planetoid

type:

type of the planetoid

moon:

A list of bodies orbiting the planetoid

name:	name of the moon
type:	type of the moon

location:

A list of inhabited locations in the Stellar System

name:	A location’s human name
place:
type:	Type of the location

Someday locations will have other characteristics like:

Orbit velocity
Initial position
Orbit radius
type jump will have locations that can be jumped to
population. Population affects the amount of commodities that a location needs or produces
population_origin: list of stellar systems that the population originates in. Affects

commodities for sale
commodity consumption and production information
- Production should be of a specific commodity
- Consumption can be of a commodity or commodity_type
- These numbers should be weightings. Production weighting affects how likely (or how much) a place is to sell an item
- Consumption affects how much of an item a place is likely to take

financial_institution:
commodity:	list of commodities that can be bought and sold :name: name of the commodity :type: Type of the commodity :mean_price: average price of the commodity :standard_deviation: How much money is there in one std deviation :depreciation_rate: How quickly the value of a product degrades :space: Volume the commodity consumes
	list of financial institutions in these stellar systems :name: name of the institution :type: type of institution

Someday commodity should grow a weight attribute. Weight will affect a fee for transporting the commodity to the ship. (Perhaps. Perhaps there needs to be a way for this to be offset. Rockets are inefficient weight. Space elevators are volume constrained. Counter grav can land a whole ship but only high tech worlds and weightless environments (orbital facilities) have it?) To implement this, locations would need to grow a surface_to_orbit type

event:

list of events that can change the price of goods :msg: Description of the event. Like headline and subheading of a news article :affects: list of commodities affected by the event

commodity_name: The specific commodity that this event effects. One of name or type is filled

commodity_type: A type of commodity that this event affects. One of name or type is filled

adjustment: A numeric value to adjust the price by

adjustment_type:

How to treat the adjustment. Can be offset to add the adjustment value to the price or percent to change the price to adjustment percent of the current price.

ship:

A user’s ship :type: Type of ship :mean_price: Average price of the ship :standard_deviation: How much the ship’s price fluctuates :depreciation_rate: How quickly the resale value of the ship drops :holdspace: How much space the ship has for cargo :weaponmount: How many weapons the ship can have ready to fire

Database Schema¶

This closely mirrors the Shipped format. The static data should live in separate db tables from dynamic data and be associated via foreign keys. This allows for easier changes to the static data if an update occurs.

Tables for static data should all have _data as a suffix

Linter¶

There should be a static_data linter that does the following:

Verifies the schema
Checks everything for spelling
Assembles a list of commodity types (in commodity and in event) and asks for confirmation if any of the commodity_types are unknown
All location names must be unique within a stellar_system
All stellar_system names must be unique within the game
All commodity names must be unique within their system
All types (for locations, commodities, etc) must be known to the game

Dynamic Data¶

These pieces of data are per game instance. They change as the game progresses

Database Schema¶

All records have a system created id

players:

Table of players :username: Player’s handle :display_name: If set, an alternate name the player can go by :password: hashed password that the player can use to verify themselves :cash: Amount of cash on hand

epoch:

Number of “ticks” since the game was created. Eventually a number of calculations will include the epoch

bank_accounts:

Table of bank accounts that players have :bank_id: foreign key to bank :loan amount: amount on loan :loan_rate: interest rate

commodity:

commodity_data_id:
price:	The present price this sells for

location_id:	location that this is selling at

order:

warehouse_quantity:
location:	location at which the sale takes place
commodity_id:	commodity being bought or sold
price:	Amount at which the user is agreeing to buy or sell
hold_quantity:	Amount of the commodity to place in the ship’s hold
	Amount to place in or draw from the player’s warehouse
buy:	True if this is a buy order. False if it’s a purchase order
status:	status of the order
originated:	timestamp for when the order was placed

manifest:

commodity_data_id:
	Commodity which this is
quantity:	Amount of the commodity
price_paid:	Average price paid for this entry. Can be used to show profit and loss reports
average_age:	Average age this was bought ago. Used for depreciation calculations
ship_id:	What ship this cargo is a part of

ship:

ship_data_id:	Which type of ship this is
location_id:	Where the ship is at

ship_parts:

ship_part_data_id:
	Link to the ship part that this implements
ship_id:	Link to the ship that this is mounted on