Example script for testing screen preconditions
Add the first version of a technical overview document
Implement immediate opcodes

Each Scene object contains a list of opcodes that represent the
content in that scene.  By default we move forward through that list
based on user input, i.e. when the user presses Enter we process the
current opcode in the list, execute its associated instruction, and
increment the index in that opcode list.

However, there are situations where we want to deal with an opcode
immediately and without requiring user input.  An example is the
opcode ’set-character-name’.  We should not require the user to press
any key in order for that opcode to take effect.  Instead we should
process it immediately.

This patch introduces the concept of ’immediate opcodes’.  All such
opcodes are listed in a new table: ImmediateOpcodes.  And all Opcode
objects have an ‘immediate’ boolean property which is set based on
whether or not the opcode appears in the aforementioned table.

The default handler for scenes, i.e. Scene.DefaultHandler(), now
performs its logic in a loop, handling all opcodes and not returning
until it finds one that has a false ’immediate’ property.

Traq-Ticket: 27
README: Correct a Markdown formatting error
Merge commit 'b18e5bea4afae6f650618e7575d70e39902e732d'

* commit 'b18e5bea4afae6f650618e7575d70e39902e732d':
  Added the speedTable to the scene object.
  Change of the display speed for each character.
  Testing the display speed change too now.
  Modified the call to LNVL.Graphics.DrawText.
  Added a displaySpeed initialization in DrawText.
  Added a dialogSpeed element to each character.
  Reinitialized the displaySpeed in LNVL.Advance.
  Added a dialogSpeed to the example.
  Initialized variables to gradually draw text.
  Made love.keypressed() call LNVL.Advance().
Remove opcode processors from the public API

We always invoke the processor function for an opcode by calling the
process() method on an Opcode object.  That method uses the name of
the opcode to find the processor in a look-up table.  This patch makes
that table private because the process() method is all we need, not
access to the processor functions themselves.
Makefile: Update ‘make tags’ to find opcode processors

This change is necessary because we have changed the name of the table
that contained opcode processor functions.
Merge branch 'hide-opcode-processors'

* hide-opcode-processors:
  Makefile: Update ‘make tags’ to find opcode processors
  Remove opcode processors from the public API
Fix indentation for the comment for Scene.activeCharacters

This patch contains no changes to logic.  It only fixes the
indentation of the first line of a comment block so that everything is
properly aligned.
README: Add Yusuke Tanaka to the ’Special Thanks’

He deserves mention for making LNVL compatible with the latest version
of the LÖVE engine.
Add comments explaining why the LNVL table cannot be ’local’
Improve error output in LNVL.LoadScript()

This patch adds a message to the assert() that checks the metatable of
LNVL.CurrentScene to make sure it is an LNVL.Scene object, so that if
the assertion fails we can see the reason why.
Correct two bugs with the example for scene preconditions

1. The script does not define any scenes because it does not call the
Scene constructor, causing an assert() to fail in LNVL.LoadScript().

2. The precondition scene list for ’BATHROOM’ has an accidental and
incorrect space at the end of the scene name.
Characters: Accept color names for text and border colors

When creating a character in a dialog script the Character constructor
will treat strings for properties like ‘textColor’ as hex color
strings, e.g. ’#33cfaa’.  This fails to account for situations where
the string explicitly names a color, e.g

    Eric = Character { textColor = "Black", ... }

This patch fixes this bug by first testing if a given color string is
a valid key in the LNVL.Color table.  If so then we use the table of
RGBA values mapped to that name.  Failing that we revert to the
original behavior of treating the string as a hex color value.
Remove debugging for-loops from the ‘set-scene’ instruction
Correct the whitespace for the ‘set-scene’ instruction

This patch contains no logic changes.  It only corrects the
indentation for the instruction so that it is consistent.
Fix two typos in a comment for the ‘set-scene’ instruction
Do not quote the number of opcodes in Scene.__tostring()

This is a slight and trivial improvement to debugging output.
Add a debugging function to dump the script environment

This gives us a way to see all of the variables in the
LNVL.ScriptEnvironment table along with their types.  This does not
give us specific type output when the values are tables, e.g. we do
not see whether a table represents a Scene object versus a Character.
However, this basic amount of output lets us quickly see what
variables exist in the environment, which is useful for debugging.
main: Dump the script environment after loading scripts

This modifies love.load() so that we dump the script environment if we
are running in debugging mode.  The intent is to help us track down
current bugs in example scripts that change scenes, as they are
crashing with errors about not being able to find scenes in the script
environment.