Teleporting and Unlimited Lives Tutorial

= Overview = In AgentSheets, as in real life, multiple “lives” (regeneration) and teleporting don’t [yet] exist. However, both can easily be simulated using the same technique involving an agent generator and the broadcast action to cause the creation of a new agent at a worksheet location remote from where the “trigger” for the regeneration occurred. For example, the triggering event could be the destruction of an agent or the appearance of entering a portal. In either case, a common implementation is for the disappearing agent to broadcast a message to another agent (the generator) to create a new instance of the disappearing agent (or possibly a different agent) in a position dislocated from the cell in which the initial agent disappeared. This technique can be used to allow for multiple “lives” in a game like Frogger, or for the appearance of entering a portal and re-emerging elsewhere in a game like Mario Brothers.

= Example Implementation = In the example game for regeneration and teleporting, there is a key-controlled agent (“roamer”) who must reach the “goal” to win, avoiding moving obstacles (“moving_mine”). If the “roamer” moves onto a “portal”, it is teleported to the “portal_end”. If the “roamer” gets next to a “moving_mine”, it is erased and regenerated at a “generator” agent, simulating multiple lives. Below is a worksheet with appearances of the various agents on a light blue background:



In the worksheet above, the green rectangle is the “portal” into which the “roamer” can enter to be teleported to the “portal_end”, which is the pink rectangle. The flag is the “goal”.

Before discussing the “roamer” behavior, we look at the other agent behavior. First, the “moving_mine” behavior is simply to move randomly on the background:



Next, the behavior of the “generator” and “portal_end” agents each consist of method to respond to a “makenew” message, resulting in creating a new “roamer” agent:





Note that there is no While Running behavior in either of these agents; they only respond when they receive a “makenew” message to create a new “roamer” agent. The “goal”, “background”, and “portal” agents have no behavior.

Next, we examine the “roamer” behavior. First, the While Running method is partly shown below. The key-controlled movement rules are typical for user-controlled agent movement. There are actually three rules associated with each arrow key, permitting the “roamer” to move on the “background”, the “portal”, and the “goal” agents. There is a rule which declares the “roamer” a winner upon reaching the “goal” agent. The two remaining rules require some additional discussion.

The rule causing agent regeneration (simulating multiple lives) is the third rule in the While Running method. The combination of “erase” and “broadcast” actions result in the generation of a new “roamer” agent. The “show message” action suspends simulation until the user clicks on an “OK” button in a pop-up window. This delay turns out to be important to preclude a problem resulting from a key queuing phenomenon that is part of the AgentSheets processor, which will be described later.



Note that there are three rules for each of the arrow keys, permitting the “roamer” to move onto “background”, “goal”, and “portal” from each of the four directions.

The rule detecting movement onto the “portal” agent uses a separate method (“decide”) to determine how to effect the appearance of teleporting to the “portal_end” agent. In an actual implementation, one would most likely choose a technique and simply include it in this rule, rather than create a separate method. However, for this tutorial, the “decide” method explores three different options and, if implemented, will allow one to see the different results. In all cases, “roamer” first erases itself, then calls upon “decide” to determine when to cause regeneration:



The “decide” method uses the “control” simulation property to determine which technique to use. There are two simulation properties, whose initial values are shown below:



First, note that teleporting and multiple lives are the same implementation: absorption (erasing) at one cell and regeneration (“new” action) at another cell. The actions in the “decide” method change only the timing of the actions, not the essential effects.

When “control” = 0, the broadcast message to the “portal_end” agent is immediate. When “control” = 1, a fixed delay, specified in the “delay” simulation property, occurs before the broadcast message. When “control” = 2, a user dialog pop-up occurs, resulting in an indefinite delay, prior to the broadcast message. It is worthwhile to implement this simulation to observe the differences, because it will help explain what appear to be anomalies in agent motion behavior, specifically in response to keystrokes.

A word about simulation control
Before examining the “decide” rules, let us review how AgentSheets simulation control works. On a continuous basis, AgentSheets examines the “While Running” method of each instance of each agent on the worksheet. (AgentSheets examines other methods only when a message to those methods is presented.) When a rule within the “While Running” method of an agent has its conditions satisfied, AgentSheets performs the actions in that rule, then moves on to examine the “While Running” rules of the next agent. Note that the order of agent examination is not specified, so one cannot rely on a particular agent or cell being examined before another.

Keystrokes serve as condition inputs for rules. There may be multiple agents that respond to a single keystroke. Imagine, for example, a “cheat” key implementation in a game, whereby pressing the “A” key causes all agents to erase themselves. The “A” keystroke input must remain available until AgentSheets has been able to examine every agent’s behavior to determine if it requires that input. Thus, the existence of the “A” keystroke as an input does not disappear when the first agent acts upon it.

In this tutorial example, suppose pressing the “↑” causes the “roamer” agent to move onto the “portal”. If the broadcast message to the “portal_end” is immediate, that agent immediately generates a new “roamer” agent in that cell, which becomes another agent for AgentSheets to present the “↑” input. The consequence is that the new “roamer” agent moves upward one cell immediately after it is generated. As a minimum, this will confuse the user; it could definitely produce undesirable simulation results. Further, if the user is very fast on the keyboard, there could be multiple “↑” keystrokes queued up, causing the newly created agent to appear to jump multiple cells upon being generated.

Some approaches
One approach is to create a delay between the time the initial “roamer” agent erases itself and the broadcast of the message to the “portal_end” agent to generate a new “roamer”. This is what the second rule in the “decide” method does, which is invoked of the “control” simulation property is set to “1”. The amount of delay is specified in the “delay” simulation property. Unfortunately, there is no exact formula to determine how long the delay should be. This will depend on many things, including the number of agents on the worksheet, processor speed, the number of rules in “While Running” methods of agents, how many keystrokes are queued (that is, who quick the keyboard entries are made), etc. The longer the delay, the more likely AgentSheets will have completed its polling of agents to empty the queue of keystrokes. However, the longer the delay, the more time the simulation will appear suspended, which is usually not satisfying for the user. In the tutorial example, a delay of 1 second was not sufficient to preclude the newly generated agent from moving immediately after generation; whereas, a delay of 1.25 seconds seems to prevent the problem.

Another approach is embedded in the third rule of the “decide” method, which is invoked when the “control” simulation property is set to “2”: specifically, a user dialog pop-up message is presented, requiring the user to respond by pressing the “enter” key or clicking on the “OK” button in the dialog before simulation resumes. Since this usually requires at least a couple seconds, the delay is more than sufficient to empty the queue of keystrokes before the new “roamer” agent is generated. (Note: with sufficient practice, and anticipating the implementation, it is possible to defeat this solution with some very fast keyboarding, but this would not be a typical situation.) The disadvantage of this approach is that simulation is delayed until the user responds.

Multiple Lives or Infinite Lives?
In the example implementation, both teleporting and multiple lives are unlimited. For many simulations it may be important to limit the number of instances of one or both operations. To do this, one would implement a counter that determines when the limit is reached. The tutorial titled “Counters and Timers” describes some approaches to accomplish this.

Final consideration regarding agent attributes and simulation properties
Agent attributes are stored within each agent instance on a worksheet. As a consequence, when an agent is erased from the worksheet, its attribute information is lost. This means that if the simulation requires that information be carried forward, for example, to a “teleported” agent, it cannot be done using agent attributes. Instead, this information must be preserved in simulation properties. Therefore, if it is important to keep track of the number of “lives” an agent uses before ending the simulation, this must be maintained as a simulation property, rather than an agent attribute.

In addition, as is explained in more detail in the tutorial discussing multiple worksheets (“Implementing Multiple Levels in Games and Other Projects”) care must be taken when switching among worksheets to retain simulation properties, since some versions of AgentSheets reset simulation properties when switching among worksheets.