Somebody Elses Problem:

Using existing game systems & your own

AVATAP is a really lovely system for authoring even though it makes artists used to friendly GUIs to make their games in JSON

http://slides.com/cheapjack/inf

"""
    Avatap provides a model for text adventures in which players travel between distributed stations
    with lo-res screens, tapping in at each station with an RFID card containing their 'game state'. 
    
    On the card is 
    * a storyUid - identifying which Story they are following
    * a nodeUid - identifying their position or Node in the Story
    * a sack - containing accumulated game state in the form of key:value pairs
    
    Nodes only represent story structure and temporary data used for screen-rendering logic. The only 
    persistent state remains in the player's RFID card. Game input takes place purely through the act 
    of tapping a station. 
    
    The basic load and render cycle (visible within engines.Engine) is as follows...
    *   The card is read, and the box, card, story, and sack are made available as attributes of the 
        engine. 
    *   The current node is set as engine.node
    *   The node's activate() routine is called, passing the engine reference. If activate() returns 
        a new current nodeUid, the activated node gets a deactivate() call, and the previous step is repeated.
    *   The final node in the chain (which did not redirect to a different node) will get a render() call
        causing a template to be generated and sent to the screen
    *   At this point, the RFID card is rewritten with the new game state, the node gets a deactivate() call
        and all state related to this player and tap is lost
    
    Processing all story logic through transient state within the lifetime of a single tap imposes 
    substantial limitations on the interaction model available compared to, for example, the Twine framework.
    
    The design of this API has focused on guiding authors who are not expert programmers to create their
    own stories using the primitives of Boxes and various specialised Story 'Nodes' and 'NodeOperators'
    which respect the fundamental limitations of this unusual medium.
    
    In particular, the syntax for authoring is comprehensible, consistent and exposes no python language 
    structures other than keyword arguments and dicts (lookup tables). 
    
    This approach is enriched by certain values being interpreted as python expressions accessing API objects. 
    A consistent set of entities is made available using python identifiers within Story templates, routing 
    and trigger conditions, (recorded in milecastles.signature), currently "engine, story, box, node, card, sack"
    
    The core components you need to master to create a story are the following three Node types and one NodeOperator...
    
    ConditionFork   - Immediately redirects to one of two Nodes in the story, according to whether its 'condition' evaluates to true or not
                      [Typically this condition will check for the state of things in the sack]
    NodeFork        - Guides the player to choose Nodes hosted at different Boxes. When you choose a Box, redirects to the corresponding Node
                      [Story validation failes if your choice nodes don't have different goalBoxes]
    ThroughPage     - Guides the player to a specific Box. On arrival at the Box, renders a page, then redirects to a specific Node in the Story 
                      [the ThroughSequence procedure creates a ThroughPage chain in which Box guidance is not normally triggered; they are at the same box]
                    
    SackChange      - If the trigger condition is True (or omitted) the player's sack is changed according to named sets of name:value pairs
                      ['assign' - sets the values, 'plus' adds them, 'minus' subtracts them, 'reset' must be used on its own and replaces the sack completely]
"""