Games/Productive

Productive sources in projects/productive Tickets all - active - new Mike Fletcher Andrew Clunis Myles Braithwaite mime x-productive-world .xo Bundle – Productive.xo

Productive

Productive is a simplified real-time strategy game. The initial implementation was completed during the OLPC Toronto Game Sprint (Nov 16-18, 2007). Work continues on the project to make it a fun, playable "first class" game for the OLPC. Development work on Productive is also being used to drive development of the OLPCGames Pygame wrapper.

Simplifications from "normal" real-time strategy games:

• Just two unit-types
• Single-tech tech-tree (military units of varying grades)
• Just two commands (territory-create-unit, unit-move)
• No battle system (no battles per-se, just shifts of allegiance to controlling powers)
• Single resource type
• Constrained map structures

Those changes put Productive somewhere between chess or checkers and traditional computerized RTS games. All of the complexity of game-play is emergent from the simple rules, but the style-of-play is real-time.

• 
• 

Game-play

These rules should create a fairly broad range of possible strategies, defending, farming, raiding, road-building and city-building. The parameters and rules will likely need tweaking to keep the game-play fast and fun.

Board Setup

• Grid playing "field" of a given size
  • To start with, a simple grid
  • Might allow for adding "dead areas" to the grid eventually
  • To start with, regular territories within the grid
• Each player gets X starting units and places them on the board one after another until the units are all placed
  • All players must join before start-of-play
  • On player quit, other players can elect to continue with the quiting player's pieces removed from the board (game should create a save-state just before removing the player's pieces, i.e. you can continue, or you can come back to the game at exactly the point you left it)

Resource Production

• Resource production is proportional to the number of productive units with adjacent empty land (regardless of whether the land is within the territory the unit is in) and how many units are "farming" the empty land.
• Productive units begin producing when they are adjacent to empty land
  • They retain their production counter internally until it is used
  • Usage of resources by the society (e.g. for feeding units and creating new ones) is done evenly across all units in all controlled territories
  • Future idea: productive units of multiple grades like the military units.
• If a unit converts allegiance or moves to a new territory then they take their collected resources with them
• A player's current wealth is the sum of the wealth of their productive units in those territories that they control. They may dispense this wealth as they see fit (given constraints on unit maintenance)

Unit Production/Maintenance

• Unit survival requires resources
  • Each existing unit requires a certain amount of resources to survive
    • this value is comparatively low for productive units (say 1/10 of a unit's production)
    • this value is comparatively high for military units (say 2/10 of a productive unit's production)
• All units must be fed (starvation)
  • When a unit cannot be fed it begins to starve, each unit has a starvation resistance value, when this value is exceeded the unit dies. Feeding the unit lowers the starvation level.
  • If no territories are controlled, individual units which have resources will live off those resources until they expire (military units will expire immediately)
  • No unit production possible under starvation conditions (insufficient food for all units) occurs (note: not yet implemented)
    • In process unit production is canceled, 50% of resources are lost, 50% recovered to feed units, oldest production is stopped first, until all units are fed or all in-process production is canceled
  • If no units in-production, non-productive units are lost
    • Military units (those without empty squares in their area first (random), then any (random)) (currently just random)
    • Productive units with the least amount of internal resources (normally in the middle of cities)
    • (Note: I'd rather have the units switch allegiance that are in the other-player-controlled territories, but that's probably too involved for now)
• Controlled territories can produce new units
  • If there is no controlled territory, no new units are possible
  • New unit production requires significant resources
    • Setting for each unit-type, along with other requirements (e.g. city status, control of territory)
    • Maybe 500% of unit's production for a productive unit
  • Wealth remains with the productive unit until a controlled territory begins producing a unit
    • If you do not create units (use your resources) your productive units become targets for takeover
  • If a territory is taken over (control shifts to another player) while it is producing a unit, the unit becomes the unit of the controlling player on creation (the unit is assigned to the controlling player at the moment the unit is created, but the cost is borne at the moment the unit is ordered)

Cities/Technology

• Very dense population centres, (i.e. those which occupy every point in a territory), will produce more mobile units which do not produce resources when occupying, but which contribute to controlling/occupying territories (military versus productive units)
• Larger cities will produce ever more mobile units (i.e. two adjacent city territories)
  • e.g. one-territory city, 2-unit military, two-territory city, 3-unit military
• Military units require exponentially more resources to produce for each level (e.g. a unit that can move 2 squares at once would cost 4 times as many resources as a farmer, those moving 3 squares, 9 times).

Territoriality

• Territories are controlled by having the largest population in a territory (equal population results in no-one controlling the territory)
  • Military units have a multiple of the weight of productive units when determining control, i.e. a level-2 military unit counts as productive unit, a level-3 as 3 productive units.
• Territories provide access to the controlling player to the resources of that player's units in the territory
  • Players use resources of all of their controlled territories to start production of units and to feed their population
• Territories are YxY grid fragments, marked visually, so that users can see the territory "boundaries" (it would be nice to allow overlapping, shifting boundaries, but not likely to be feasible)

Conversion

• Each territory has a balance of power represented by a simple count of the total number of units within it, with the maximum count being the power in control (equal counts == no controlling balance)
  • Each unit retains an internal counter of "allegiances" (one for each player)
  • Time within a territory controlled by another player increases the unit's allegiance to that power (without upper bounds, so a very old farmer is going to be far harder to sway than a young one)
    • Military units are less affected, but still affected
  • Units start with reasonably high allegiance to the player that created them, enough to withstand 2 minutes or so in a foreign-controlled territory (enough time to "mount a defense", but not enough time to build new units to mount it)
  • Units belong to (respond to the commands of, provide resources for) the player to whom they have the greatest allegiance
  • Unit conversions will be reported to the user, individual unit's allegiances can be viewed one-by-one by hovering over the unit
• Player with balance of power for a territory can use the resources of their units in that territory to produce new units in any of their controlled territories

Motion

• Movement is instantaneous, that is, it occurs at a discrete time
  • All units can move across un-occupied spaces in response to commands by user
  • Productive units can only move slowly through un-occupied space (e.g. 1 square at a time, every 15 or 20 seconds)
  • "Military" units can move farther/faster through un-occupied space (e.g. 2 squares at a time, on the same period)
• Controlled square motion
  • Units can travel instantly through a chain of their own units
  • Productive units cannot move through opposing units' occupied squares
  • Military units can move across opposing unit's squares if there is an empty square within their movement range (i.e. a 3-square military unit can jump two opposing player's squares, but a 2-square unit can only jump one)
  • Military units can combine a move through a chain of their own units and a jump over an adjacent opponent.
• Player can move as many units as they want as often as the units are allowed to move (real time operation)
• New units appear at the closest un-occupied square to the center of their creating territory

Goals

• Report "success" at any point in time along various measures:
  • Territoriality (Conquest, number of territories occupied/controlled)
  • Resource Base (Money, total income over time)
  • Technology (Maximum "tech" level (military distance), number of cities)
  • Population (Simple count)
  • Loyalty (Average allegiance of population)
    • Conversions (Ratio of conversions to/from player)

Open Questions

We'd like to minimise "safe" configurations in the game to prevent static situations. Defensive rings of a given width can be used to protect an internal productive area (similar to Go). The defensive rings do not currently have a method which would breach them other than producing a higher technological level, which can be quite expensive. In a corner, 8 pieces can produce a defensive ring that produces ~ 30 pieces worth of food, on an edge 14 produce a defensive ring that produces ~50 pieces worth of resources, in open space, 25 pieces can produce a ring which produces ~90 pieces worth of food.

We could address this, for instance, by having production from a piece of land drop as more people farm it, so that the cluster's productivity would drop below sustaining itself. Something as simple as 1/x production would work reasonably well, with each adjacent square granting 1/x to each of its neighbouring producers. With that only the corner configuration would be worthwhile, all others would require more food than they produce to defend against a military-level-2 unit. It would also make invasions easier (by opening out the farm-land), and thus reversals much more frequent.

Implementation

Productive's core was implemented during the Toronto OLPC Game Sprint/Jam Nov 16-18th, 2007. Work has continued since then on completing the game and getting it ready for deployment. As of 2008-01-22 (version 2), the game is loosely playable, but is missing many of the niceties that would make it a finished activity (such as hooks to save/restore state, and to deal with users leaving the activity).

Development is being completed in the OLPC GIT Repository and new developers are welcome. The lead developer (User:Mcfletch is rather over-committed these days, and would be happy to have people willing to take the project and run with it).

UI/Design

• Screen Layout
  • Orthogonal grid playing field (easy to program quickly in PyGame)
    • Wide bars on edge for scrolling window (currently requires an explicit click on a widget)
  • Statistics side-bar/bottom-bar (portrait layout below, landscape beside), (currently only landscape mode is supported)
    • Overall map (clickable to move to another area)
    • Hover information display (not yet implemented)
  • Notifications (click to zoom to the unit/territory) (not yet implemented)
    • Territories being invaded (entry of foreign unit into player-controlled territory)
    • Territories lost (conversion of territory to another player's control)
    • Units being converted (units who are allied to the player which are becoming more allied with another player)
    • Units converted (units whose allegiance has switched to another player)
    • Units created (local-player creation only)
  • Statistics/readouts (not yet implemented)
  • Resource Meter (three part, background production, two overlays of usage, highlight on danger and more so on crises)
    • Current resource production (rate)
    • Current maintenance resource usage (rate)
    • Current unit-production resource usage (rate)

• Interactivity
  • Unit-selection (single-only)
    • Hover to see unit details (including timers) in HUD (not yet implemented)
      • Unit should display it's planned route (to the player who controls them) as a path on the screen
    • Click and click empty square to issue movement command
    • Click on unit, or another unit (of any player), to cancel movement command (or escape key on keyboard), on the first click planned motion is stopped, so clicking on a moving unit then clicking on them again stops their motion
    • Movement blockage will be reported back as flashes or the like highlighting a blocked move (not yet implemented)
  • Territory Icon (single-selection-only) (not yet implemented)
    • Hover to see territory details including unit production progress
    • Click to create new unit, if the territory hasn't begun production yet, click again to abort production and retain all resources
  • Tablet Operation
    • Gamepad/arrows to move cursor, accelerate on long hold-down, auto-scroll to follow selection
    • Navigation rocker-down to "click"
    • Navigation rocker-up to switch to side-bar and back
    • "Hover" by not moving
    • Other rocker directions for e.g. bringing up save or option overlays
• Miscellaneous UI Features
  • Store/restore UI (later)
  • Initial setup screens (later)
  • History viewer? (later)
  • Observer view? (later)

File/Network Format

We use a simple set of utility classes along with a simple JSON lineariser to store and restore data to/from zip files to provide our long-term storage format. We use Telepathy data-formats with the same utility classes to provide network wire protocol formats.

Note: Productive is extremely hard on a Telepathy Gabble/Jabber server. The Telepathy folks are implementing out-of-band Gabble connections in part to allow us to avoid server round trips when sending data between client machines.

Code/Organisation

• Simulation code as a separate engine (i.e. not directly connected to the display code, so that we can replace the display should we need to)
  • Provide the simulation engine as a DBUS service using RPC-style calls for UI actions and events for updates
  • Speed control (new users wanting to play slow, to learn, experienced to play fast, very experience to play slowly and chess-like)
• Host will run the simulation (for now we won't worry about "cheats")
  • Use whole-board-updates from the server to the clients (reduce synchronization problems)
  • Allow anyone to save off the board at any time (and potentially resume it later with different players, share it with others, etceteras)
  • Updates should be first-come-first served, but keep in mind that many updates will be constrained by the unit/territories counters regarding e.g. frequency of movement and/or production
  • We may want to introduce an arbitrary delay into the host child's updates (to prevent them having an edge)
• Keep the various simulation parameters as controllable parameters so that we can tweak game-play through development, a few of these might be exposed to the player
  • Board size (e.g. start with 30x30 for 2-player)
  • Territory size (e.g. start with 3x3 for 2-player)
  • All periods/rates
    • Resource-collection rate per productive unit
    • Production rate per unit/distance
    • Period before auto-placement
    • Cost per unit
    • etc.
  • Using AStar algorithm for path-finding

Game flow

• Main screen turn on
  • Choose unit type / icon
  • Wait for players to join
    • Client: Ready for game button
    • Host: Start game button
    • (Host: Choose map in the future)
• Start game engine
  • Init map
  • Init players
  • Init units
• Start game loop
  • Check win conditions
  • Update map
    • Update each Tile
      • If unoccupied and not at maximum resources, produce resources
    • Update cities
      • Produce units
  • Update units
    • • Update resources
      • Update movement
  • Update game state
  • Process events
  • Draw
• End game
  • Display finish screen (message, stats?)

There's a few complications we need to deal with. For instance, the simulation code is going to be running on the server and communicating back/forth with the individual clients over the network. In essence, it is decoupled from the individual user's events, though they will arrive via DBUS events in the simulation engine. That makes the GUI (Pygame) mainloop look something like this:

• load map description (produce User and Tile Proxies)
  • build network proxy connections
• process events (network and user)
  • network events update Tile/Territory/Unit proxies depending on event type (or, if a full-state update, updates everything at once)
  • user events send messages across the network (possibly with local predictive behaviour)

and the simulation mainloop would be event driven, looking something like this:

• Init players
• Init core timer (game-time)
• Init map
  • Init Tiles/Territories (or load from saved state)
    • Resource growth timer (probably a single timer)
    • Individual Territory timers (normally null, but saved state may have them in-process)
  • Init Initial Units (or load from saved state)
    • Init internal timers (food, movement, resource collection, again, may be in-process)
• Return to the GObject mainloop (DBUS)

where timers firing would cause callbacks to fire that perform the actual logic to occur on each event.

Art Required

We'll need quite a few art pieces to polish the game. Likely need at least one graphic and one auditory artist to participate.

Graphics

• Territory Icons
  • Uncontrolled Territory
  • Controlled Territory
  • Territory Lost
  • Territory Threatened (other player moves into your territory)
• Unit Icons (note that we need different icons for different players, so each of these is probably 8 icons)
  • Productive
  • Military (multiple levels, likely composed from a base icon)
  • "Moving" versions of each (or a tag to the effect)
  • "Moving Blocked" versions of each
• Movement Icon
  • Conflict Icon (Move Blocked)
• Resource Icon
• Allegiance Icon
• Unit-Allegiance
  • Each player gets their XO colours assigned to their icons
  • Need to look into colour-reliance issues, may need to provide different icon sets so that black-and-white mode is playable, alternately, use player "badges" added to the base icon-set
• Resource Meter

Sounds

• Action sounds
• Event/notification sounds

Lesson Plan Ideas

• Geography/Social Studies/Environment
  • Resource exhaustion/depletion
  • Conflict over scarce resources
  • Resource and technological connections