Information flow - wolispace/creativeobjectworld GitHub Wiki

Information is sent between the client and server in json strings.

The flow is:

  1. user enters a command
  2. sent it to the server
  3. added the command to dbCommands
  4. process next x commands from dbCommands (these may add new documents to dbMessages)
  5. find all new dbMessages the player has not seen
  6. send them back to the browser
  7. display as dictated by the type of message (add to log, update look or view/edit divs).

In detail with an example: A command is entered by the user by typing something like "push the small elephant"

This is sent to the server along with the actor's id (the player). Other useful info like the players location or the last object the touched or last message they saw is stored in dbObjects - so its acting as a session storage itself.

We now look for the next batch of commands to process form dbCommands in chronological order.

Hopefully the command the user just added is there.. but sometimes not - so the player has to wait a couple of seconds for a response to their command.

Processing dbCommands first retirves useful info like the actor and location from dbObjects for the actors'id. Then it wraps the command in a "call" so the cowmand is "call push the small elephant"

The cowmand "call" retrieves the cowScript from "the command called push"

The first cowmand in the cowScript requires a target to push, so the rest of the text "the small elephant" is parsed and an object matching that is located in the current location.

If we have a suitable target the cowScript continues and adds messages to dbMessage for the current location. Some messages cause the player to re-look, or to view an object in detail, but the push simply adds a message to dbMessages informing all in the location what has happened.

Each message added to dbMessages will contain a trigger word. When a message is added, we look for objects that react to it. Any found have the required command added to dbCommands for later processing - but with the found object's id instead of the current actors'id

Now we locate all of the messages since the time-stamp for the initial player and send them back to them in a json string. This will contain bare-bones info about each object. Its up to the browser UI to format these into links and put on the page as they are intended.

The browser maintains a time-stamp cache of objects and their nicely formatted links and names. So this is used where possible to save time/processing.