My LEGO Nexus Organization

Previous tutorials focused on the basics of behaviors; with #1 on custom behaviors and #2 on communication between models. This tutorial builds on those to explain behavior "States."

First of all, what are States?

    * Each state contains separate behavior action chains
    * The action chains are only active for the model's current state
    * Each model's state is independent of that for other models


The good news is that you already have been using states, but only the default "Home" state. Other states open up as you create behaviors that transition to them.

OK now, why would you want to use States? behaviors which run a set of actions that return a model to its original configuration don't need them. Models that always trigger the same behavior chain(s) given a trigger don't need them. When do you need them?

Example 1: Models that only respond to appropriate input

Let's start with a model that should be fairly common. We want to build a castle entrance gate that opens and closes as a result of separate chats (spoken by the user or sent from another model via Silent Chat). Here is a mockup using two separate models, one for the wall and opening and another for the gate itself.

(http://cokerfamily.com/john/lu/behaviors3/fig01.jpg)

And here is our first cut at the behavior for the gate. There are two action chains

    * On Chat "open" > Move Up 7
    * On Chat "close" > Move Down 7


(http://cokerfamily.com/john/lu/behaviors3/fig02.jpg)

The problem comes if the open is chatted when the gate is already open (or close if closed). The model will move each time, regardless of whether that is appropriate or not. Here we chatted open when the gate was already open and it moved up beyond the wall. This looks ugly, plus it means that it would take two chats of close to close it completely.
(http://cokerfamily.com/john/lu/behaviors3/fig03.jpg)

How do we fix this? We use States!

Let's take a step back and think about how we want the gate to work. One might start by thinking about it this way:

    * if gate is closed and On Chat "open", Move Up 7
    * if gate is open and On Chat "close", Move Down 7


Well, there is no "If" block so we do this with states. Since we have two exclusive rules, we will put each one in a different state. Since all models start in the Home state, we will actually take advantage of three states for this model. (It can be done with only two, but this method allows us to handle additional starting code if we want.) We'll use the Square for the gate being closed and Circle for the gate being open.

    * Home: On Start > Change State Square
    * Square: On Chat "open" > Move Up 7 > Change State Circle
    * Circle: On Chat "close" > Move Down 7 > Change State Square


Let's go through things one step at a time. One tricky thing is that you can't put actions in a state until there is another action that transitions to that state. This is why, initially, no states are available (other than Home) and there are no state icons on the right side of the behaviors dialog.
(http://cokerfamily.com/john/lu/behaviors3/fig04.jpg)

We just added a state transition from Home to Square. Remember that all models start in the Home state so if we didn't have this, there would be no way to get to other states. Note that because we've added a transition to the Square state, there are now two icons on the right edge of the dialog: Home, black because it's selected, and Square, gray but clickable.
(http://cokerfamily.com/john/lu/behaviors3/fig05.jpg)

Now we've clicked on the Square and added the behavior for opening the gate. Note that this is just the same as our first cut at the gate behaviors except that in this state, we only know how to open the gate. Also, since we have used a transition to the Circle state, that icon now shows up on the right as well (gray, but clickable).

(http://cokerfamily.com/john/lu/behaviors3/fig06.jpg)

Finally, we switch over to the Circle state and add the closing behavior. Note that this ends up taking us back to the Square state.
(http://cokerfamily.com/john/lu/behaviors3/fig07.jpg)

Now let's get out of building mode and test it. Because the behaviors are only active when the model is in a state appropriate to that behavior, we've fixed the problem with mismatched chats. This gate now functions correctly no matter what the user chats or whether there are bugs in other behaviors using Silent Chat.


Example 2: Models that behave differently for the same input

Let's extend this example by adding a guard at the castle gate. When people approach, we want him to say a different message depending on whether the gate is open or closed.

First of all, let's expand our gate behaviors a bit to make them trigger behaviors on other models. For each of the opening and closing behaviors, we add a Silent Chat at the beginning and end of the movement so that other models can trigger off them.

    * Square: On Chat "open" > Silent Chat "opening" > Pause 1 > Move Up 7 > Silent Chat "opened" > Change State Circle
    * Circle: On Chat "close" > Silent Chat "closing" > Pause 1 > Move Down 7 > Silent Chat "closed" > Change State Square


(http://cokerfamily.com/john/lu/behaviors3/fig08.jpg)
(http://cokerfamily.com/john/lu/behaviors3/fig09.jpg)

OK, now we have messages that the guard can react to: "opening", "opened", "closing", "closed". We don't need all these, but if you define your gate this way we've allowed other models to react in various ways. This makes the gate both reliable (it will ignore commands that don't make sense), and nicely encapsulated (it sends messages about its changes, but doesn't need to know about how those messages will be used).

Now let's go over to the guard model. Here we will use only two states: Home (when the gate is closed) and Circle (when the gate is open). Note that for consistency, we should probably have used the same three states that the gate uses, but I wanted to show that there is nothing special about the Home state and that the states for each model are completely separate.
(http://cokerfamily.com/john/lu/behaviors3/fig10.jpg)

Above and below you can see how the Home and Circle state each have two action chains. These create different behavior triggered by a player coming near and a state transition based on the chats from the gate.

    * Home: On Near > Chat "You shall not pass"
    * Home: On Chat "opened" > Change State Circle
    * Circle: On Near > Chat "Welcome friend, enter"
    * Circle: On Chat "closing" > Change State Home


(http://cokerfamily.com/john/lu/behaviors3/fig11.jpg)
So now our guard says a different message when approached by a player when the gate is open than when the gate is closed. Let's leave editing mode and see how this works.
(http://cokerfamily.com/john/lu/behaviors3/fig12.jpg)

You can see how these simple examples can be expanded to create complex interactions of behavior between models. The behaviors feature provides quite a bit of power, although you have to change your thinking a bit to recast your logic in terms of states and transitions.

This just made me want to play LU more. =O I had no idea Behaviours spread this far. This is extremely advanced, in my opinion.