WIP: Transition Implementation

[alecpm]

This PR implements various aspects of stories #236, #241, and #237, and provides the basic functionality that's needed for the transition related aspects of #234.

It provides the following actions triggered by pressing the space bar:

• item_transition: executes a transition (if a transition exists between the player's item and map item)
• item_pick_up: picks up the item in the current square (if it is portable)
• item_consume: consumes the currently held item (if it has a caloric value)

There's also a new action executed with by pressing the d key:

• item_drop: drops the currently held item onto the current map square (if it the square is empty)

We provide a simple display of the currently held item and a mechanism for determining transition visibility. A transition can set its visible attribute to always, never, or seen. This does not attempt to provide information about available transitions or the item on the current square in the UI.

The client side can look up the currently available transition using transition = player.getTransition() and can determine if the transition has been seen by the current player by checking transitionsSeen.has(transition.id).

If the server side encounters an error when executing an action it will send an action_error notification with player_id, position, player_item, item properties which can be used to reset the state on the client side. Resetting state is not yet implemented (and may not need to be implemented, since it will be reset eventually by the game state sync).

Experiment changes:

• Items include a remaining_uses property which starts with the item n_uses value and is altered based on the transition modify_uses property (as well as by consuming items, see note below).
• Items can have a null position, which generally means they are being held by a player.
• Item is now semi-mutable because item position needs to be able to change along with the new remaining_uses property.
• Items include a limit_quantity property which determines if GridWorld.replenish_items() should remove items of the type or just add them based on the growth rate. Without this, items which had an initial quantity of 0 would be removed immediately when a player created one via a transition.
• Transitions indicated as last_use are stored under a key that looks like ('last', actor_id, target_id) ('last_$actorId_$targetId' in JS).

Notes:

• Right now picking up a portable item results in picking up all its uses, and consuming such an item results in consuming a single use (reducing remaining_uses). I think this may be backwards, picking it up should create a new Item of the same type with a single remaining use held by the player while reducing the remaining_uses of the map item. The current way was a little easier to implement, so it might be OK for now. Perhaps multi-use items will generally be like the Gooseberry Bush and not portable, so this doesn't really matter. Confirmed with @nataliavelez that the current approach is correct
• Right now we're not respecting the crossable property, and I'm not sure how it will be possible to have a non-crossable item that you can execute a transition on, since you currently need to be on the square of the object to perform a transition.
• Right now the server blindly accepts the position sent with these action requests as the player position and performs actions relative to that. At some point we might want to verify that is or very recently was the player position if we're concerned about cheating.
• The client side currently updates the grid to reflect the item_drop, item_pick_up, and item_consume outcomes before sending the message to the server (to avoid lag). If there's a problem with the action on the server it sends an action_error message, which could be used by the client to reset to the original/correct state, but it currently goes unused.
• No "predictive" action is taken on the client side for item_transition, so the updated game state from a transition won't be reflected in the client until the next game state update is sent from the server.
• Needs tests.

[alecpm]

@jessesnyder I hope this implementation hasn't violated the expectations you might have had when implementing transition display for #234, and isn't too difficult to integrate into your work.

@silviot It would probably be a good idea to write some tests for these new handlers.

[alecpm]

@jessesnyder would you prefer I merge this now to make your work easier to rebase/merge or should I wait for @silviot to add tests and/or review further?