Add event sequences (dialogue, map changes, cutscenes, etc.)

[food-please]

Feature implementation: v 0.2.0 - Event Sequences

I'm hoping to next implement event sequences. The implementation should provide a simple, extend-able means to allow events to occur on the gameplay field. Examples of field events are:

• doors opening and closing.
• moving the player to a new map or playing a series of events on a different map (imagine the stereotypcial bird's eye view of the bad-guy planning session).
• moving a character that's blocking a path.
• dialogue (witty and gripping, of course).

Note: Event sequences may be usually known as "cutscenes". I think that the implementation should be more generic, however, than requiring a stoppage of gameplay. For example, the player walking on a given cell may cause a change on another part of the map (such as opening a door) without requiring the screen to fade or the player to stop moving.

Implementation
This milestone should include NPC conversation. As per Nathan's suggestion, I propose implementing dialogue via Dialogic 2. It is simple to pickup, robust, and quick to incorporate into the existing project.

Please note that I'm proposing that events are essentially commands from the command pattern.

Coupling is tricky here. I see the event sequences as a high-level object that should be able to manipulate most objects in the game. Instead, events could modify game state via the FieldEvents singleton, but that has several undesired consequences (i.e. should the cursor REALLY be able to change the playing music via singleton? Also, an event would still need access to various objects to await different commands, such as moving a gamepiece along a path). I think we probably want to inject dependencies into the event and allow events to be the high-level cross-system state-changing objects in the project architecture (which, incidentally, should help everything else remain decoupled).

Therefore I anticipate field events as being a subclass sandbox interface implemented as a node (added to an event pool). This has a few advantages:

• event sequences can take full advantage of Godot. Want the screen to fade out or a sound to play? Compose the event from Godot's built-in nodes.
• events are basically just scripts affecting whatever is slapped onto the scene. I toyed with using Dialogic's timelines for event sequences, but I think that would make the code very rigid and limited in exchange for a nice UI.
• events may be found up by uid, allowing modification of anything running. Should make pausing easy.
• events can be added to anything and can easily be chained together. Some will be executed by code, some will be interacted with from other gamepieces, some will be walked over on the field map, etc.

The milestone is broken down into tasks for my own benefit here. The scope and details will probably change as the main feature is being implemented.

Discussion and Feedback
I would love to hear any feedback on the propsed model before I begin the implementation.

[NathanLovato]

The description you are making of the system is a little too abstract. My recommendation for these kinds of things is to always start by implementing the concrete event sequence and generalize based on that experience. Abstraction and thinking abstractly tends to increase coupling and code complexity.

Using a subclass sandbox, commands, or just some dictionary describing an event sequence, any of these approaches can generally get the job done.

Concretely you just want to have a limited list of functions to restrict what developers can do. And if so, it does not matter if these functions are accessed through a Singleton, as long as they prevent users from messing up the game.