]> git.cworth.org Git - lmno-api/commitdiff
empires: Use "phase" instead of "state" for the different phases of the game
authorCarl Worth <cworth@cworth.org>
Mon, 1 Jun 2020 05:40:00 +0000 (22:40 -0700)
committerCarl Worth <cworth@cworth.org>
Mon, 1 Jun 2020 05:40:00 +0000 (22:40 -0700)
We're planning to start using "state" in a generic sense for
everything needed to capture a game's, well, state. So the current
"phase" is not the state, but simply one aspect of it.

empires.txt

index 28cc7313e8a2a3c82f12a850428e69400d4fc776..fef6a08fbfaaa25da34ec4355b2b0a31a294ee0d 100644 (file)
@@ -1,6 +1,6 @@
 Empires Game Protocol
 =====================
-Version: 0.8
+Version: 0.9
 
 For a specific game the following API endpoints are defined.
 (Note: Only the trailing portion of the API URI is provided here.
@@ -49,35 +49,35 @@ For a specific game the following API endpoints are defined.
                event: player-leave
                data: {"id":3}
 
-       TYPE: game-state
+       TYPE: game-phase
 
-       WHEN: When client first connects and whenever game state changes
+       WHEN: When client first connects and whenever game phase changes
 
-       VALUES: Event gives both the old and new state.
+       VALUES: Event gives both the old and new phase.
                Each will be one of the following:
 
-               none: Pseudo-state used as old_state when game is started
+               none: Pseudo-phase used as old_phase when game is started
                join: Players are choosing characters and joining the game
                 reveal: Character names are being revealed to players
                 capture: Players are guessing characters in capture attempts
 
        NOTE: When a client first connects, it may see multiple
-             game-state transitions, to transition step-by-step from
-             the initial state to the state of the current game. See
+             game-phase transitions, to transition step-by-step from
+             the initial phase to the phase of the current game. See
              the example below which would be presented to a client
-             joining a game that is already in the "reveal state.
+             joining a game that is already in the "reveal phase.
 
        EXAMPLES:
 
-               event: game-state
-                data: {"old_state":"none","new_state":"join"}
+               event: game-phase
+                data: {"old_phase":"none","new_phase":"join"}
 
-               event: game-state
-                data: {"old_state":"join","new_state":"reveal"}
+               event: game-phase
+                data: {"old_phase":"join","new_phase":"reveal"}
 
        TYPE: character-reveal
 
-       WHEN: Periodically during the "reveal" state of the game
+       WHEN: Periodically during the "reveal" phase of the game
 
        EXAMPLE:
 
@@ -142,17 +142,17 @@ For a specific game the following API endpoints are defined.
 
     Method: POST
 
-    When: Only valid when in game state of JOIN
+    When: Only valid when in game phase of JOIN
 
-    Behavior: Change state to REVEAL; reveal character names to all clienta
+    Behavior: Change phase to REVEAL; reveal character names to all clienta
 
 /start
 
     Method: POST
 
-    When: Only valid when in game state of REVEAL
+    When: Only valid when in game phase of REVEAL
 
-    Behavior: Change game state to CAPTURE
+    Behavior: Change game phase to CAPTURE
 
 /reset