Because the default cursor will usually be the correct event trigger, you will check for it first. In your table and in your code, you will identify it as “default.” There aren’t any examples in the test setup, but you would also list any cursors that would trigger a customized reply. An example would be if you tried to pick the locked chest lid with a Rock Icon. The lid would do nothing, but you might get a snappy reply, like “Chest bashing will get you nowhere.”
The third column will be the state that the object is moved into as a result of the interaction. In some cases, there will be no state change, but there will be a transition back into the original.
Following the first two columns, the remainder will be evaluated in pairs. They will allow you to trigger any other objects that may need animating, instantiating, a state change, or any other special cases. The auxiliary object/new state pairs are optional, but you may add as many as necessary.
You will have to fill out a table for each action object’s possible states, once you have determined and defined those states. See the State Management PDF, available from the Download area of the Apress web site (www.apress.com), for the full Lookup table information.
This Lookup table is what you will use to find out what each object should do when triggered by any other object. This, along with the metadata arrays you will create, will allow you to specify everything that needs to be done when a specific condition is met or identified. For more ambitious projects, you may wish to manage the lookup tables in the database of your choice.