RiverMan Media

Uniting Behavior, Effect, and RobotFunction
First I had to figure out how I would be able to put Behaviors, Effects, and RobotFunctions all into the same script. It seems like these three objects all work totally differently, right? Actually, they are more similar than I thought, at least in a few key ways. They all have an update() method and they all have listeners (of some sort). This is all the script needs to know, since all the script does is call their update() method and sets their listener to be itself. So to tie all of them together, we can have them all incorporate a simple aspect, ActionEvent (if you aren't familiar with Slag, just think of an aspect as a Java interface for this example).

underlying aspect ActionEvent
  METHODS
  method update():
  method setListener(ActionListener listener):
endAspect


underlying aspect ActionListener
  METHODS
  method callback(ActionEvent caller):
endAspect


# This code represents the new type declarations,
# which would show up elsewhere
abstract class Behavior : ActionEvent
abstract class Effect : ActionEvent
abstract class RobotFunction : ActionEvent

Okay, so now we've established that Behaviors, Effects, and RobotFunctions can all operate the same way in a script because they all incorporate ActionEvent (implementing the update() and setListener() methods). The ActionListener aspect, which our script incorporates, allows our script to listen to the event callbacks from the ActionEvents.

On to the next problem: our script doesn't just need to support ActionEvents, it also needs to be able to handle commands that execute instantly. These commands can be any arbitrary code. The lazy way to accomplish this would be to make a fourth kind of ActionEvent that only runs for 1 update cycle, and immediately notifies its listener that it is done. But that seems a hack, since if the command runs for an entire update cycle, then 10 commands in a row will take 10 updates, which isn't quite what we want. This would completely throw off the timing of the script.

Commands Are Different
Instead, why not make a new class, called a Command. Specific Commands override one method, execute(). When the script encounters a Command, it just calls the Command's execute() method and moves on. If the script encounters multiple Commands in a row, it processes them all at once in a while loop until the script is empty or it encounters an ActionEvent. Simple enough. Special note: in Java, you can declare, create, and add Command objects to the script as anonymous classes, keeping the code very compact and readable.

But how does a script hold both Commands and ActionEvents? How does it know which one to run? Well, since a script is implemented as a queue, it doesn't hold the Commands or ActionEvents directly, it actually holds ListNode Objects, which in turn knows the type of its data. But of course, that just passes the problem on to the ListNode class.

Two Node Types
All we have to do is make the ListNode a little bit more complicated than usual. ListNode becomes AbstractListNode, which has two children: EventNode and CommandNode. You can probably see where this is going. EventNodes hold data of type ActionEvent, and CommandNodes hold data of type Command. How does the script tell between the two kinds of Nodes? A simple int value called nodeType in the AbstractListNode class. For EventNodes, the nodeType is set to 0 in the node's constructor, and for CommandNodes, the nodeType is set to 1.

All of the pieces are in place. The script is a queue of AbstractNodes, and it can figure out which kind of data the Node holds. Here's is a simple version of what the script's update() cycle looks like:

method update():
  while (firstNode().nodeType == COMMAND_NODE)
    # cast operation
    local CommandNode c = firstNode().(CommandNode)
    c.data.exectue()
    dequeue()
  endWhile

  if (firstNode().nodeType == EVENT_NODE)
    # cast operation
    local EventNode e = firstNode().(EventNode)
    e.data.update()
  endIf

  # if the script is over, inform the listener
  if (firstNode() is null)
    listener.callback(this)
  endIf

method callback(ActionEvent e):
  dequeue()
  if (isEmpty() == true) listener.callback(this)

There are a few 'null' checks missing here, but this shows the basics. The update() call executes all of the Commands at the head of the queue first, then moves on to the ActionEvents, calling update() just once on the first one. If there aren't any commands at the head of the queue, it won't execute any Commands, and will just update() the ActionEvent at the head of the list (if one exists).

ActionEvents and callback()
In this code, we can see how the CommandNodes are removed from the queue during the while loop, but what about the ActionEvents? These are handled slightly differently, since we don't know when the ActionEvent will be done. The script, as an ActionListener, implements a callback(ActionEvent) method. When the Behavior/Effect/RobotFunction is finished, it invokes the method "listener.callback(this)." "this" is the caller (e.g., the behavior), and "listener" is the script.