You might remember this if you saw a previous post about how nice I thought Crafty was. No more Crafty, this is Celice powering this guy with the use of Canvas. Entities, Components, Systems and Game States! The tile object code was straight copy pasted from the code I used with Crafty. That's what I call portable independent code! Little change to the entity portion of the tile creation was needed (mostly just adding the new components). Let's talk input.
Input, Intent and Action
What Celice has powering the input system is an Input Listener, Intent System, and an Action System. The intent system is probably the coolest part of this, but first let's go in order. The Input listener repackages the output and pushes it to external handlers. It uses Celice.listenTo("keyup").from(gameContainer).execute(handler).commit(), which I think is the most likable way to add events to the DOM from Celice.
The Intent System translates input keys/buttons into Intents. Intents are, in a nutshell, strings. These strings represent a state such as "JUMP" or "MOVE_RIGHT." What you choose to name them is up to you. The idea here is to bind these Intents to keys which are then split up into "MOVE_RIGHT_START" and "MOVE_RIGHT_STOP." These intents are put into an intent queue, which is read every frame and pushed out to all entities that have an Intent component, which is usually one. (This is flawed! Intents should be directed.) Now you are probably asking, how do you respond to these intents? That's where the Action System comes in.
The action system translates intents from entities with the Intent component into an action that you want. The basic idea is to bind an Intent to a callback. Currently, you get the action system from your game state and bind intents to callbacks, the callback is executed in the entity's context, so you can use "this" to refer to the entity. It is here in the callback that you do whatever you want in terms of logic and modify the entity as you see fit, so you a free to respond to an intent.
That's it!
Next Idea
The next idea may be an events/interaction system to handle/resolve things between two entities. Two entities may be in a collision state and have to be resolved, it may be that a fireball collided with one entity and that entity needs to be destroyed or the action system put the entity in a "looking for discussion" state in response to an intent, so the interaction system would pick this up and look to resolve that state before returning the entity to a normal state. The general idea for the Interaction System is for templating interactions, so that less code is written for individual entities and more code is managed by a system.