Implement multiplayer

[darkf]

As a rather interesting novelty, we can implement multiplayer sessions based around a host which powers the game and guest clients which join the host's game and can move around and interact with the world in a limited fashion.

This builds off the map (de)serialization of saving and loading.

It also adds a centralized event manager which routes game events to interested observers. The engine will need to be modified to support a wide variety of events relevant to displaying/updating the world state, such as events for dialogue, critter movement, combat, etc.

Combat is a low priority right now, but it will work in the same round-robin turn-based fashion as usual, except players can wait on the remote player to finish their turn.

Only one guest player will be supported; in the future this can be expanded to more than one quite easily.

It currently uses WebSockets and a dedicated server (written in Python with eventlet) to host the game.

This work is being done in the net branch.

Task list:

• [x] Host player can connect
• [x] Guest player can connect
• [x] Host player sends map
• [x] Guest player receives map
• [x] Host and guest players can walk around
• [x] Host player can change elevation
• [x] Host player can change map
• [x] Maps are transferred compressed
• [x] Objects move on guest
• [ ] Remote players use walking animations
• [ ] Remote objects use walking animations
• [ ] Guest players cannot use exit grids or stairs
• [x] Host can use doors and it appears on guests
• [ ] Scripts work
• [ ] Timed events work
• [ ] Dialogue works (Open questions: Can guests participate? Are options voted on, or is it whoever clicks first?)
• [ ] Host player can initiate combat
• [ ] Guest players can participate in combat
• [ ] All players can initiate combat
• [ ] Guest players have inventory
• [ ] Guest players can interact with game objects

[darkf]

Merging to master, some commits were getting intertwined. Also implemented compressed map transferring.

[darkf]

It should also be documented (things like how to use it) in the README or wiki.

[darkf]

FYI, the overarching design goal is to have the hosting player make the majority of the decisions, and have sole authority -- for example, when the host player changes map, so do guests.

The multiplayer part will also have to be regularly tested to combat regressions, because it involves a lot of moving parts that change (semi-)frequently and can easily break in subtle ways.

We should be sending "walk to" or "walk along this path" messages instead of simple move messages, too, for animated movement.

Finally, combat is pretty asynchronous as it is, so we can stall waiting for the remote player to make a move before invoking nextTurn. The guest players should send their selected actions and the host player should enact them, and send back the results (in the form of actions taken by the AI.)

The guest players will then need to be on the same AI team (they're friendlies), and disallow friendly fire (or do we want that?)

The combat logic will need to be reworked a bit to support multiple players. We have isPlayer but it only signifies one local player currently.

[darkf]

Also, in the future we'll probably want to use a binary message protocol, something like BSON/msgpack or a small custom TLV protocol.