The data flow is a description of what information the players send to the GMs?, what information it interacts with there, and what goes back to the players. This will lead to solidifying the DataBase and system structure needed to have a program keep track of all the little bits of data that float around the game.
Currently this will be loosly based on the ideas in Tau Ceti (because thats what I played last :) but will change as the GameWorld and GameSpecifics get updated. I have also incorperated the idea of players not having mineral tokens, but just money. Mineral quantity is stored by the GMs? (and players are told about it each turn).
Note that the bits that say "GM <does something>" could actually mean that the program does it for the GM. Sometimes it also seems to get to stupidly trivial detail, thats just the way I'm working through it sorry :) Also Player ⇔ Team.
- Survey info
- Player specifies set of locations to be surveyed (cardinality s)
- GM determines the number of places n that the player can survey
- GM looks up table of survey results for the first n locations
- For each of these, the location and the team are recorded to allow map updates.
- GM writes down survey result information
- If n<s, GM adds a note about this.
- Survey form returned to player
- Map updates
- This is the map that all teams are permitted to see that is updated at some point, probably after all the turn data has been processed. The map details where players have surveyed, and where they have built.
- For each new survey or deployment:
- If appropriate, GM places token on map.
- Flags survey or deployment record as not new.
- Build info
- Player submits form that specifies: money included m, set of (building to build), set of (building to deploy, location, building token)
- For each building b in set (building to build), add cost of b for player to c.
- If c>m, no further buildings may be built this turn. (exit loop)
- If minerals required for b > minerals player has, this building can't be built. (next iteration)
- Build b, record that player has a new instance of b, ensure that they get building token.
- Remove appropriate minerals from players supply
- For each building b, location l, token t in set (building to deploy, location, building token)
- If t not supplied, building can't be built. (next iteration)
- If player doesn't have building b undeployed, then there is a GM error :)
- If location l doesn't have relevant building prerequisites for b, building can't be built. (next iteration)
- Deploy b on l, record this. Also record for map updates.
- Remove b from from undeployed buildings list.
- If applicable, add any new production capacity to the turn producion values. (e.g. for mineral extractors)
- Combat
- ?
- Matrix Actions
- These allow the player to perform any GM-sanctioned action. Dealing with these is difficult within a strict framework, and many actions may not require any changes to the information flow. To make it possible for actions that allow changing numbers used, e.g.making buildings cheaper, the following things must be provided:
- All the values must be stored specific to the player, initialised with defaults, but allowing a fine-grained change that only affects that player. This allows permenant changes.
- Either the facility for temporary changes (probably creates unnecessary complexity), or a notes section (preferred as it may have other uses also) so that the GM knows what to do.
- The ability for all actions to be overridden by the GM, even if it doesn't make sense. (For example, if the player is allowed an extra survey for some reason as a one off, then the GM should be able to specify the extra survey without trouble.) It is recommended that a warning be generated to reduce errors, but they must be ignorable.
- These allow the player to perform any GM-sanctioned action. Dealing with these is difficult within a strict framework, and many actions may not require any changes to the information flow. To make it possible for actions that allow changing numbers used, e.g.making buildings cheaper, the following things must be provided:
- Turn Transition
- At turn transition, all the results are returned to the players, however there my be some extra things that happen independant of the players actions for the turn.
- Mineral production is calculated, added to the mineral supply and the player is informed of how much they have.
- At turn transition, all the results are returned to the players, however there my be some extra things that happen independant of the players actions for the turn.