Document player-info, player-enter, and player-update events

All of which were recently implemented in lmno-server.

Add a new game-info event

Which gives the game ID and the URL for connecting to the game.

This allows the client to display this information so that the player
can easily share it with friends, etc.

tictactoe: Change /move event to have data named "move", not "square"

We're intentionally being more generic here that the API could be
generalized, (allowing for an implementation in a base class handling
things in the general case).

tictactoe: Document a game-state event

This gives a snapshot of the current state as well as the history of
all moves up until now. This event will be served to a client when
joining a game in progress.

empires: Use "phase" instead of "state" for the different phases of the game

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.

Update Empires /register endpoint to return the generated ID

When augmenting the test suite, I noticed I needed this value and was
surprised it wasn't already being returned.

With this change we bump the version up to 0.8.

Add an initial protocol description for the tictactoe game

So far this just supports sending and receiving a move, (but what else
does Tic Tac Toe need, right?).

empires 0.7: Add endpoints to add, remove, and list spectators

The endpoints are:

  POST /spectator
  DELETE /spectator/<ID>
  GET /spectators

The addition of a separate notion of spectators from players gives us
two advantages:

  1. People can just watch if they want to

  2. A client can naturally separate the selection of the player's name
     (to create the spectator, join the game, see who else is in, etc.),
     from the selection of the player's character. This separation should
     avoid some confusion we saw in playtesting where players confused
     which name was which.

Rename api.txt to empires.txt

Since the API documented in this file is only for the lower-level
Empires-game specific API, (which sits below the LMNO API documented
in lmno.txt).

Document the new /profile API

This can be used to set a nickname, (and a set nickname can be used
instead of the "name" for the empires /register API).

Add a new protocol description for the new LMNO API

This exists above the level of any specific game implementation (such
as empires) and handles the allocation of unique IDs for games and
also allows for a namespace in which the API of games below are
mounted.

Clarify that at client connection server may give multiple game-state events

This mode is convenient for clients that aren't expecting to jump into
some mid-game state without having transitioned through each state
along the way.

With this change we increment the protocol version to 0.6.

Update the game-state event and increment protocol to version 0.5

Specifically, we change to lowercase names for the states, and we also
include both the old and new states on each transition. This also
means there is a new "none" state for the initial game-state event.

Add "/reveal","/start" endpoints and "game-state","character-reveal" events

Incrementing the protocol version to 0.4.

This is perhaps the minimum that is actually needed to play a game?

We'll see if this is sufficient as we get both client and server coded
to this and try it out.

Add a version indication to the protocol description

Starting with version 0.3 since there have been a couple of previosu
versions, (but also less than 1.0 since we haven't yet implemented a
functional game).

Document the new /events API endpoint

This is a server-sent events stream which should be very convenient
for implementing the desired semantics of the game. For example, this
stream will allow the server to push out each character name to all
clients dur the phase of the game where characters are revealed
(without requiring clients to poll for characters nor agree on the
timing for displaying them).

Indicate that sample game API is now at https://families.cworth.org/api/

We added an API suffix so that we could serve the client HTML from the
root.

Implement a few changes after an initial implementation

Specifically, we change the following:

  * Rename /escape/ to /liberate

  * Rename the "captured" json field to "captures"

  * Drop the /players/<id> API

Specify an initial REST API for playing a game of Empires

This is an initial draft which is hopefully adequate for playing a
game. At this point we haven't implemented this on either client or
server side so we anticipate revisiting this after we implement and
learn any deficiences.

Thanks to Kevin Worth for designing this with me today.

Initial commit with a README file

Giving a brief introduction to the game of Empires and why we are
motivated to design a client-server API for a party game that normally
requires almost no equipment. (Hint: It's about making this work when
not all players can be physically present in the same space.)