Literals should be parsed into an object representation of themselves.
Built in types should be defined and turned into objects.

Code needs to execute in an environment. This environment should contain, at least:

• Variables
• A parent environment, which or none for the root environment
• A context, which is the object executing this code (an agent, the player, etc)

Sketch out and implement the skeleton of the framework for client-server interactions.
Security can come later.

For instance, the optimizer will generate output like

[
 [{timestamp:1, ...}],
 [],
 [],
...
 [{timestamp: 123, ...}]
]

Those empty time stamps should be omitted entirely; the information about the actual time stamp of an event is stored in the event.

A native function would be one that is implemented in an underlying language (in our case, Python).

Really, what we need is an internal representation of a function.

Functions

lambda
if

I'm sure I'm missing a bunch, and I'll add them as I go.

This will make them much more efficient.

Right now there's a function that get called whenever an event is created, but it doesn't do anything. It should handle events.

The executor needs to be able to walk the AST and determine what to execute.

The lisp stuff will be have the world passed into it, and will therefore be able to call whatever functions it needs to. However, Seabass needs to know what those functions are so that they can exist. There should also be a function that will be called by the engine that performs a single beta reduction timestep's worth of beta reductions on a player's lisp code.

The engine generates a large number of events that become outdated later in the timestep. In order to avoid complication of the engine with concerns about generating optimized messages, there should be an optimizer that the engine calls before serializing the events, which removes and redundant events in order to minimize heavy bandwidth usage.

Only load ~10 games at a time on the play/versus page.

Probably some kind of OAuth.

Walls need to exist on the engine's side.

For now, it can just be an error message, though it might be good to make it highlight the offending code later.

Relies on #29, #30.

The map needs to be sent from the server to the client. Suggestions for the exact format should probably go here.

Ideas, @Shriken?

Write the code to allow for the client to display what happened in a turn, given a list of events and the proper metadata.

Figure out all of the events necessary for the game.

Not entirely sure how to do this, but I'll look into it.

Walls need to be rendered on the client side.

Edit: Never mind.

Currently, the parser generates the AST with the first argument as a value.

Take the code
(define discriminant (lambda (a b c) (- (* b b) (* 4 a c))))

Currently, the AST generated would look like:

               define
              /      \
    discriminant     lambda
                      /  \
                     a    -_____
                    / \    \    \
                   b   c    *    *__
                           / \   /\ \
                          b   b  4 a c

It should actually look like:

        ._________________
       / \                \
  define  discriminant     .___________
                          / \          \
                     lambda  .          .____________
                           / | \       / \           \
                          a  b  c     -   .           .____
                                        / | \       / | \  \
                                       *  b  b     *  4  a  c

Basically, the first element of the list should not be set as a value in the ASTNode. Values should only be used for leaves.

((f)
should throw an error.

Maps will be made of walls, need to be interesting and symmetrical (or at least fair)

For instance, the code
((a b c)
should indicate that the unmatched paren is the first character.
Error: Unmatched Paren: ((a b c) ^

For instance, you could have information such as a line number, a stack trace, etc.