My LEGO Nexus Organization

Previous tutorials focused on the basics of behaviors: #1 on custom behaviors, #2 on communication and #3 on states. This tutorial puts that all together to create a simple game. I encourage you to go through the earlier tutorials, especially #2 and #3, since we will build on them for this one.

The game we'll create is a challenge to smash a number of items within an alotted time. The scenario: the player encounters a Maelstrom communications array that must be destroyed. Before starting the game, only the central controller object is active, and interacting with it starts the game. The player must smash all eight antennae before the time runs out. If he does, the central object smashes too and he wins, otherwise the antennae rebuild and he loses.

I've made a video showing two play-throughs of this game, the first one too slow and the second one within the time limit.
http://youtu.be/W9IbspZ0RNc
This game requires some problems be solved:

    * the antennae are only smashable during the game
    * we need to count how many antennae are smashed to determine that the player won
    * we need to run a timer to determine that the player lost


These problems are solved with three sets of objects:

    * the central controller that manages the game
    * a set of eight antenna models, all with the same behavior
    * a set of models making a counter of how many antennae have been smashed


(http://cokerfamily.com/john/lu/behaviors4/fig1.jpg)
The Controller

The central controller object is the only one interactable in the Home (initial) state. This means that none of the models can be interacted with or smashed until the game starts. All together, the controller uses four states:

    * Home: before the game starts, the only behavior is Interact to start the game
    * Circle: the game is running (the counter and timer are active)
    * Square: the player won and the game is over
    * Star: the player lost and the game is over


(http://cokerfamily.com/john/lu/behaviors4/fig3.jpg)

The Home state (top left above) has only the behavior chain that starts the game:

    * On Interact
    * Silent Chat "reset" (restores the state of all models)
    * Chat "so you want to challenge the maelstrom?"
    * Pause 3
    * Chat "then prepare to smash all the antennas"
    * Pause 3
    * Chat "go!"
    * Change State Circle


The Circle state (top right above) has two parallel behavior chains. The first one is the timer to determine if the player loses (runs out of time).

    * On Start (when we transition to this state)
    * Chat "go!"
    * Silent Chat "game on" (set up the antennae)
    * Pause 15
    * Change Start Star (player lost)


The second Circle chain simply listens for the counter to complete. (The counter message is "for carry out" for reasons that will be described later.)

    * On Chat "for carry out"
    * Change State Square (player won)


Thus we have two parallel behavior chains in the Circle state that are used to determine win/loss. If the counter chat is seen before the timer runs out, switch to the Square state (which ignores the timer). Otherwise, the timer will switch to the Star state (which ignores the counter).

The Square state (bottom left above), representing a win, has two behavior chains. The first is the win player feedback:

    * On Start (when we transition to this state)
    * Chat "ooh! you got me!"
    * Sound BrickSmash
    * Smash


The second Square state is simply our generic reset handler which restores the object and resets to the Home state.

The Star state (bottom right above), representing a loss, contains a single behavior chain:

    * On Start (when we transition to this state)
    * Chat "not fast enough!"
    * Sound Incorrect
    * Silent Chat "reset" (to rebuild any antennae that were smashed)
    * Change State Home (to allow player to retry)


It may help to draw out a flowchart for yourself to see how these behaviors, and the states they transition through, create the game logic.

The Counter

There is no built-in behavior to do something like "when all models are smashed", so we implement that by counting how many antennae are smashed. Each antenna does a silent chat when smashed (see below) and the counter adds them up and sends another message when it counts to eight.

How do we build a counter? We will use three (active) models to implement a 3-bit ripple carry adder! Using virtual LEGO bricks to implement a simple electronics circuit has an appeal of its own, but is also necessary since this sort of thing isn't built in the LU behaviors.
(http://cokerfamily.com/john/lu/behaviors4/fig2.jpg)
My counter is like a binary abacus with a frame and three bead strings. Since it's binary, there is only one bead per string, which can be at the bottom (Home, indicating 0) or the top (Diamond, indicating 1). The rightmost string indicates the "ones place" and moving left we have the "twos place" and "fours place" strings. (This may be easier if you think of base-10 numbers having ones, tens and hundreds places.)

The counter models actually move up and down as their state changes, which makes what is happening visible in the video if you watch the counter at the edge of the property space.
(http://cokerfamily.com/john/lu/behaviors4/fig4.jpg)

The behavior chains for the ones bit implement the initial counting of the antenna smashes and pass the count up to the twos bit. Remember that a binary digit (bit) can only contain 0 or 1, so when we count, we think: 0, 1, 0 with carry out, ...

    * Home: On Chat "smash" > Move Up 1 > Change State Diamond
    * Diamond: On Chat "smash" > Silent Chat "one carry out" > Move down 1 > Restart
    * Diamond: On Chat "reset" > Restart


(The second behavior chain is used when the controller sends the reset message.)

The behavior chains for the twos bit is very much the same, except that its input is the overflow of the ones bit:

    * Home: On Chat "one carry out" > Move Up 1 > Change State Diamond
    * Diamond: On Chat "one carry out" > Silent Chat "too carry out" > Move down 1 > Restart
    * Diamond: On Chat "reset" > Restart


And of course the fours bit is again the same, except that its input is the overflow of the twos bit:

    * Home: On Chat "too carry out" > Move Up 1 > Change State Diamond
    * Diamond: On Chat "too carry out" > Silent Chat "for carry out" > Move down 1 > Restart
    * Diamond: On Chat "reset" > Restart


And that's why the chat "for carry out" is used by the controller to determine when all models have been smashed. The fours bit counted two overflows of the twos bit, which counted two overflows of the ones bit, and 2 × 2 × 2 = 8. Voila!

The Antennae

After all that, the antenna models are nice and simple. Also, all eight are the same models with the same behavior chains. We use three states for these models:

    * Home for when the game is not started
    * Square for when the game is running
    * Star for when this antenna is smashed

(http://cokerfamily.com/john/lu/behaviors4/fig5.jpg)

The Home state has the behavior used when the game starts:

    * On Chat "game on" > Change State Square
    * On Chat "reset" > Restart (for safety, shouldn't do anything normally)


Using the home state this way means that the user cannot smash or interact with the antenna until the game starts (and the antenna switches to the Square state).

The Square state is activated when the game starts and enables the model to be smashed:

    * On Attack > Silent Chat "smash" > Sound BrickSmash > Smash > Change State Star
    * On Chat "reset" > Restart


The Star state is activated after the antenna is smashed and simply holds that state until the game is reset (using the by-now familar) "OnChat reset" chain.

Putting it all together

OK, that was a lot of stuff! Let's do a quick review of what happens.

The controller starts the game when the user interacts with it. Starting the game allows the antennae to be smashed. Each time an antenna is smashed, the counter adds one and when it counts up to eight, it sends a message that the controller is listening for. This triggers the "win" behavior.

In parallel, the controller is waiting for the timeout and if the user runs out of time, this triggers the "lose" behavior.

I suggest taking another look at the video showing these two scenarios in action and then drawing out a flow chart or whatever diagram makes sense to you to see how you might implement the game. Then read through this tutorial again to see how I did it. Happy building!

And I thought the on-chat opening stuff was advanced. This takes the cake. =O

One slight note; the youtube link in the top of the post is slightly broken. ;)