JACK——AgentManual3 Agents
3 Agents
3.1 Introduction
The Agent class embodies all the functionality associated with a JACK intelligent agent. To define agents, extend this class, adding members and methods that are applicable to the agents current application domain.
3.2 Agent Definition
Agent definitions take the form shown below:
agent AgentType extends Agent [implements Interface]
{
// JACK Agent Language statements specifying containment
// relationships.
// These are described in the following sub-sections.
}
Each component of this definition is explained in the following table:
| Syntax Term |
Description |
| agent |
A JACK Agent Language keyword used to introduce an Agent definition. |
| AgentType |
The name of your derived Agent class (which can not be further subclassed). |
| extends Agent |
This part of the statement plays the same role as in Java – it indicates that the agent being defined inherits from a JACK Agent Language base class called Agent. The Agent base class implements all the underlying methods that provide an agent's core functionality. |
| [implements Interface] |
This part of an agent definition is optional. |
Table 3-1: Components of an Agent definition
3.3 Agents and Interfaces
The optional implements Interface component in an agent definition is important when it comes to writing portable JACK Agent Language programs that allow for code re-use. Interfaces provide a common ground between agents that allows them to share plans.
When an agent executes a plan, this plan will often call ordinary Java methods. It is important to remember that when this occurs these methods must be included in the agent definition, not the plan definition. Therefore, any agent that uses this plan must include the defined methods or the plan will not be able to run properly.
This means that the JACK Agent Language places restrictions on which agents can use what plans. So that this restriction can be observed in a modular way, the JACK Agent Language allows these dependencies to be packaged up into a Java Interface. Any agent that wishes to include this plan must declare that it implements this interface. If an Agent class implements the interface, it provides all the methods necessary to run the plan.
3.4 Agent Declarations
An agent should fully describe the functionality it implements via JACK Agent Language definitions. In general, this definition needs to include the following conceptual statements:
- BeliefSets and Views which the agent can use and refer to.
- Events (both internal and external) that the agent is prepared to handle.
- Plans that the agent can execute.
- Events the agent can post internally (to be handled by other plans).
- Events the agent can send externally to other agents.
These definitions are handled by statements that occur at the field or member level of an agent definition. While there is no restriction on where they appear in Jack code, by convention these definitions appear before the definitions of any regular Java data members and methods that the agent may contain.
An example agent template showing some of the declarations that can appear in an agent appears below:
agent AgentType extends Agent [implements InterfaceName]
{
// Knowledge bases used by the agent are declared here.
#private data BeliefType belief_name(arg_list);
// Events handled, posted and sent by the agent are
// declared here.
#handles event EventType;
#posts event EventType reference;
#sends event EventType reference;
// Plans used by the agent are declared here.
// Order is important.
#uses plan PlanType;
// Capabilities that the agent has are declared here.
#has capability CapabilityType reference;
// other Data Member and Method definitions
}
Each JACK Agent Language agent declaration is described in more detail in the following sub-sections.
#handles event EventType
This statement identifies the events that the agent will attempt to respond to if they arise. By handling the event, the agent claims to have at least one plan available that it can execute when this event arises. These plans may not be relevant to all forms of the event or applicable in all circumstances, but the agent must know how to handle the event in at least some situations.
Because it is really claiming that the agent's plans can handle the event, the #handles event agent definition statement is analogous to a function prototype. It is an explicit statement with which the runtime can check for completeness rather than functional necessity. However, defining the events that an agent handles up front allows agents to be prototyped and helps ensure that sound design practices are followed.
Including the #handles event definition is also important to ensure that task processing takes place in the agent when the event occurs. If an agent receives an event that it does not handle, a runtime warning is generated and the event is not processed. By claiming to handle the event, the agent looks through its plans to find one that has a matching #handles event statement. A suitable plan might not be found, but at least the agent looks to make sure. Claiming to handle an event is like an employee claiming that a situation falls under their responsibility: they take notice when it occurs and try to do something about it. Whether they succeed or not is another matter.
When an agent definition includes a statement of the following form:
#handles event EventType;
The agent claims that when an event of EventType occurs, it has a plan to handle it. This plan should be declared with the #uses plan declaration. How this event is processed depends on whether it is a BDI event or a normal event. Behaviour Attribute settings can also influence how events are handled and particularly what happens on plan failure.
Refer to the Events chapter for more details on how different event types are handled and how this behaviour can be customised.
#posts event EventType [reference]
This statement describes an event that the agent can post. Posting an event means that an agent creates an instance of the event and posts it internally (i.e. sends the event to itself).
The #posts event declaration identifies those events that the agent posts explicitly, not those that arise from actions of other agents or indirectly from the agent's own actions or changes in internal state. Therefore, it is usually used to declare that the agent posts events of the types Event, BDIFactEvent and BDIGoalEvent. For more information on these event classes, refer to the Events chapter.
When an agent claims that it posts an event, this event will only arise if it is explicitly generated in one of the agent's methods.
An agent definition contains a statement of this form to indicate that the agent has reasoning methods or code that explicitly causes an event of this type to arise.
Each term in the previous definition is described in the following table:
| Term |
Meaning |
| #posts event |
Identifies that the agent can post events of the given type. The event is always posted internally, and hence needs to be handled by the agent's own plans. |
| EventType |
Identifies the type of event to be posted. |
| [reference] |
When present, JACK creates an agent member called reference which can be used to create events of EventType using its posting methods. |
Table 3-2: Terms in a #posts event declaration
When an agent posts an event, it does so by calling the method postEvent() as shown below:
postEvent (event)
The event being posted must be constructed using one of the event's posting methods. This is described in the section on posting / sending events in the Events chapter.
Events posted in this way are handled internally by the agent. No other agent is affected by the posting process. Hence, they are like 'thoughts' or 'ideas' that the agent has. The agent essentially tells itself that this event has occurred and needs to be dealt with.
Agents can also send external events to be handled by other agents. These events are called message events and are described in the Events chapter.
#sends event EventType [reference]
This declares that the agent is able to send a message event to another agent. Message events are events that extend either of the following event classes:
- MessageEvent
- BDIMessageEvent
For more information on these event classes, refer to the Events chapter.
This declaration identifies events that the agent sends externally. It is analogous to the #posts event statement in all respects other than the fact that the event arises in a different agent to the one that sends it.
When an agent includes a declaration of this type, it indicates that the agent has reasoning methods or code that can send an event of EventType to other agents. The following table describes each term in this definition:
| Term |
Meaning |
| #sends event |
This agent has methods or code that can send events to other agents. The event is always sent to a different agent and hence needs to be handled within that agent's own task execution structure. |
| EventType |
Identifies the type of event to be posted. |
| [reference] |
When present, JACK creates an agent member called reference which can be used to create events of EventType using its posting methods. |
Table 3-3: Terms in a #sends event declaration
When a method belonging to an agent definition needs to send a message event to another agent, it does so by executing the following statement:
send (agentName, event )
send() is a base method provided by the Agent class. It is almost identical to the postEvent() method except that it takes the name of the target agent as the first argument. This is the full name that the agent is known by on the JACK runtime network. The event being posted must be constructed using one of the event's posting methods. This is described in the section on posting/sending events in the Events chapter.
To obtain the name of an agent, use the Agent base method name(). This method returns the agent's name as a String. Note that the name returned is the full name of the agent which takes the form agent@portal . If a portal name is not supplied, the send() method appends an @ symbol, followed by the portal name of the sending agent. This can cause some ambiguity if there is more than one process in the current application, so it is advisable to always supply the full name of an agent.
#uses plan PlanName
This statement identifies the plans that an agent can execute to handle events. An agent can only execute instances of a plan if it declares that it uses this plan with a #uses plan declaration. If a plan is defined, but no agent uses it, that plan will never be executed.
When an agent definition includes a #uses plan declaration, all instances of this agent that are created have access to the given plan. This plan is said to form part of that agent's plan set.
Note: Ordering of #uses plan statements in the body of an agent (or included capabilities) is important. For normal event handling, plans are tested for relevance and applicability in the order in which they are declared. For BDI event handling, after a candidate plan set is assembled, the plan declared first in the agent will be chosen first in the absence of meta-level reasoning or plan rank being set.
If an agent claims to handle an event, the agent should use a plan that also handles that event. If this is not the case, a warning will be generated when you start up the application. The warning is issued because if an agent has no plan to handle a given event, it cannot strictly claim that it is capable of handling that event.
#has capability CapabilityType reference
The capability concept brings structure to the functional elements of agents. The user declares an agent to have selected capabilities by using the #has capability declaration statement. Each declaration then requires both a capability type name and a reference name that identifies the particular instance of the capability.
If, for instance, Painting is a Capability type, an agent might include the following declaration:
#has capability Painting painting;
The declaration makes the agent capable of whatever the Painting capability brings, that is, the agent is given access to all of the functional components enclosed by the capability. The reference name painting allows agent code to refer into the capability instance. An agent may have more than one instance of the one capability type.
3.4.1 Beliefsets
3.4.1.1 Conceptual Model
In JACK, beliefs are modelled as beliefset relations which take the following form:
relationName(key1,key2, ..., data1,data2, ...)
That is, each relation is identified by a name and contains any number of fields. Some of these fields are key fields, uniquely identifying the kind of object that this relation describes, and others are value fields, identifying the attributes of this object that need to be recorded.
Each object described by a beliefset relation is represented as a tuple. A tuple is an instance of the relation where the fields represent the key fields and value fields of a particular object. For example, one may choose to model a bank account with the following beliefset relation:
bankAccount(account number, name, balance, credit rating)
A particular bank account would then be described as a tuple, such as
bankAccount(10019875, "Fred Jones", 101.95,"A1");
3.4.1.2 Beliefset Declarations
JACK beliefset declarations within an agent take the following general form;
#{private|agent|global} data BeliefType belief_name (arg_list)
which declares that a beliefset of type BeliefType is to be contained within the agent. Each declaration is described below.
#private data BeliefType belief_name(arg_list)
When an agent definition includes a statement of this form, it declares a named data that is private to the agent. Agents of this class have private access to the beliefset relation belief_name (or to a user-defined data structure as described in the next section). Private access means that the agent has its own copy of the relation, which it can read and modify independent of all other agents, even those of the same agent class.
Each parameter in the previous definition is described in the following table:
| Term |
Meaning |
| #private data |
A JACK Agent Language field-level construct, which specifies that agents of this class have private access to the beliefset relation. |
| BeliefType |
The type of beliefset relation that the agent will use. The beliefset type is analogous to the Agent class, and extends one of the underlying JACK Agent Language types.
|
| belief_name |
Used to identify the instance of the relation that the agent is using. |
| arg_list |
An optional argument. When present, it specifies arguments to be passed to the constructor each time an instance of this beliefset relation is created. |
Table 3-4: Terms in a #private JACK beliefset declaration
When a beliefset relation is private, all the relation's tuples are unique to that agent. If the agent adds or removes tuple information, this is only reflected in its own belief state. Any other agent with access to a relation of the same name will not have its own set of tuples affected. Hence, any changes made to an agent's private relations have no effect on the belief state of other agents.
Private relations are the only beliefset relations where the agent can add, modify or remove tuples: agent and global relations are read-only. It should be noted that:
- An agent can query a private relation's tuples using the relation's query method.
- An agent can modify a private relation's tuples using the relation's add() and remove() base methods.
Refer to the Beliefset Relations chapter for further details.
#agent data BeliefType belief_name(arg_list)
When an agent definition includes a statement of this form, it declares a named data that is shared among all agents of this type in the same process. Agents of this class have agent access to the beliefset relation belief_name (or to a user-defined data structure as described in the next section). Although it is not enforced, agent access means that the agent should have shared read-only access to the relation with other agents of the same class.
Each term from the previous definition is described in the following table:
| Term |
Meaning |
| #agent data |
A JACK Agent Language field-level construct, which specifies that agents of this class have shared access to the beliefset relation, but only with other agents of this class. |
| BeliefType |
The type of beliefset relation that the agent will use. The beliefset type is analogous to the Agent class, and extends one of the underlying JACK Agent Language types.
|
| belief_name |
Used to identify the instance of the relation that the agent is using. |
| arg_list |
An optional argument. When present, it specifies arguments to be passed to the constructor each time an instance of this beliefset relation is created. |
Table 3-5: Terms in a #agent beliefset declaration
As access to agent beliefsets is intended to be read-only, the beliefset should be populated by reading data from a file as part of the beliefset constructor. Details on how this can be achieved appear in the BeliefSet Construction section.
The first instance of an agent class that uses an agent beliefset causes the beliefset to be constructed. Each subsequent instance of that agent class is simply allowed access to the beliefset.
An agent can query an agent beliefset using the relation's query method.
Refer to the Beliefset Relations chapter for further details.
#global data BeliefType belief_name(arg_list)
When an agent definition includes a statement of this form, it declares a named data that is shared among all the agents in the same process. This means that all the agents in the process have global access to the beliefset relation belief_name (or to a user defined data structure as described in the next section). Although it is not enforced, global access means that the agent should have shared read-only access to the relation with all other agents in the same process.
Note: A JACK application can consist of one or more processes. However, by default (and unless otherwise specified) an application consists of a single process.
Each term in the previous definition is explained in the following table:
| Term |
Meaning |
| #global data |
A JACK Agent Language field-level construct, which specifies that the agent shares this relation with all other agents in the process. |
| BeliefType |
The type of beliefset relation that the agent will use. The beliefset type is analogous to the Agent class, and extends one of the underlying JACK Agent Language types.
|
| belief_name |
Used to identify the instance of the relation that the agent is using. |
| arg_list |
An optional argument. When present, it specifies arguments to be passed to the constructor each time an instance of this beliefset relation is created. |
Table 3-6: Terms in a #global beliefset declaration
As access to a global beliefset is intended to be read-only, the beliefset should be populated by reading data from a file as part of the beliefset constructor.
The first instance of an agent class that uses a global beliefset causes the beliefset to be constructed. Each subsequent instance of an agent class that uses the same global beliefset is simply allowed access to the beliefset.
An agent can query a global beliefset using the relation's query methods.
Refer to the Beliefset Relations chapter for further details.
3.4.2 Data stored in User-defined Data Structures
Agent beliefs or normal Java objects can be stored in JACK beliefset relations or in user-defined data structures as agent data members. User-defined data structure members are declared in the agent in an analogous way to JACK beliefset relations by using the #private data, #agent data or #global data statements as described below. The agent's plans gain access to the user-defined data object using the #uses data declaration described in the chapter on plans, and like JACK beliefsets, user-defined data structures can be exported, imported or declared private to capabilities as discussed in the Capabilities chapter.
In addition, a plan can gain access to its enclosing agent as a Java object, (and thus to the agent's data members) by using the #uses interface or the #uses agent implementing statements described in the Plans chapter.
JACK declarations for user-defined data structures within an agent take the following general form:
#{private|agent|global} data DataType data_name(arg_list)
which declares that a Java object of type DataType is to be contained within the agent. Each declaration is described below:
#private data DataType data_name(arg_list)
When an agent definition includes a statement of this form, it declares a named data that is private to the agent. Agents of this class have private access to data_name.
Private access means that the agent has its own copy of the data object, which it can read and modify independently of all other agents, even those of the same agent class.
Each item in the previous definition is described in the following table:
| Term |
Meaning |
| #private data |
Specifies that agents of this class have private access to the data. |
| DataType |
The user-defined data structure. |
| data_name |
The name used to identify the instance of the user-defined data structure that the agent is using. |
| arg_list |
An optional argument. When present, it specifies arguments to be passed to the constructor each time an instance of this data structure is created. |
Table 3-7: Terms in a #private user-defined data structure declaration
#agent data DataType data_name(arg_list)
When an agent definition includes a statement of this form, it declares a named data that is shared among all agents of this type in the same process. Agents of this class have agent access to the Java object data_name of type DataType. Although it is not enforced, agent access means that the agent should have shared, read-only access to the data object (data_name) with other agents of the same class.
Each item in the previous definition is described in the following table:
| Term |
Meaning |
| #agent data |
Specifies that agents of this class have shared access to the data, but only with agents of the same class. |
| DataType |
The user-defined data structure. |
| data_name |
The name used to identify the instance of the user-defined data structure that the agent is using. |
| arg_list |
An optional argument. When present, it specifies arguments to be passed to the constructor each time an instance of this data structure is created. |
Table 3-8: Terms in a #agent user-defined data structure declaration
As access to the object is intended to be read-only, the data object should be initialised when it is constructed. The first instance of an agent class that uses the object will cause the object to be constructed. Each subsequent instance of that agent class is then allowed to access the object.
#global data DataType data_name(arg_list)
When an agent definition includes a statement of this form, it declares a named data that is shared among all agents in the process. Although it is not enforced, global access means that the agent has shared read-only access to the data object data_name with all other agents in the same process.
Each term in the previous definition is described in the following table:
| Term |
Meaning |
| #global data |
Specifies that agents of this class have shared access to the data, with all other agents in the process. |
| DataType |
The user-defined data structure. |
| data_name |
The name used to identify the instance of the user-defined data structure that the agent is using. |
| arg_list |
An optional argument. When present, it specifies arguments to be passed to the constructor each time an instance of this data structure is created. |
Table 3-9: Terms in a #global user-defined data structure declaration
As access to global data is intended to be read-only, the object should be initialised when it is constructed. The first instance of an agent class that uses the global data object causes the data object to be constructed. Each subsequent instance of an agent class that uses the same global object is allowed to access the data object.
3.4.3 Task Managers
Task managers govern how an agent handles concurrent execution when they have committed to more than one task execution.
By default, JACK uses the SimpleTaskManager. The SimpleTaskManager tells the agent to persist with its currently active task until one of the following situations occurs:
- it encounters a @wait_for statement (and the task blocks);
- it encounters a @sleep statement (and the task blocks); or
- it completes (either succeeding or failing).
Regardless of the number of tasks that are outstanding, the agent will continue with a single task until one of the above conditions occurs.
As soon as one of the above conditions occurs, the task is removed from the task queue and the agent moves on to the next applicable task. If the task is completed, it is removed completely from the task queue. If the task encountered a @wait_for or @sleep, the task is returned to the end of the task queue only when the statement is completed.
If a plan step of the active task takes a long time to complete, or an infinite-loop arises, the agent will not switch to another task.
In most applications, the SimpleTaskManager is sufficient. However, if the agent has tasks involving intensive processing that may need to be preempted by shorter, more urgent tasks, the task manager described below may be preferable.
#uses taskManager SimpleRRTaskManager(<steps>)
This statement declares that the "round robin" task manager is to be used in place of the SimpleTaskManager. This task manager offers a more "balanced" approach to managing the tasks that are currently active within an agent. Instead of persisting with the currently active task until it either pauses or is complete, the agent rotates its efforts between all tasks that are currently active.
Each active task is kept in a round robin queue and is allocated a number of plan steps that it can run. A plan step is meant to represent an atomic action within a plan. In some cases, this corresponds to a single statement (such as the @send statement). However, many JACK Agent Language statements actually involve more than one plan step (such as the @wait_for, where multiple plan steps are used to test each condition). When a plan statement covers more than one plan step, this statement can be suspended after any given plan step. When the round robin task manager lets the task run again, the statement is able to resume where it left off.
If a plan calls a normal Java method, that entire method executes as a single plan step. This is because the round robin task manager does not know at which point it can suspend the task while it is executing non-reasoning method code.
The number of plan steps allocated to each task is governed by the steps argument (an unsigned long) supplied to the #uses taskManager declaration. When specifying the number of plan steps, take care to choose a value that is appropriate to the application domain. Choosing a small value minimises the chances of a single task locking out all others, maximising the agent's responsiveness to new events. However, the smaller a value, the more of an agent's processing time is devoted to context switching, reducing the agent's overall efficiency. A good value for the number of plan steps is somewhere in the hundreds (100-200), depending on the response and throughput characteristics required.
If the task terminates or pauses (by reaching a @sleep or @wait_for statement) before its number of plan steps has been reached, the agent behaves as it would with the SimpleTaskManager. However, if it reaches its requisite number of plan steps before this happens, the active task is moved to the end of the task queue, and the task at the head of the queue is activated. Therefore, all active tasks are given an opportunity to run, and the danger of one CPU-intensive, long-running task hampering the agent's overall performance is reduced.
3.5 Agent Members and Methods
Once the required set of #-declarations has been added to an agent's definition, the event, plan and beliefset components that the agent requires will need to be identified. Each of these components contains its own data members and methods. The remaining step in completing the agent definition is to specify the agent's data members and methods.
An agent's data members and methods are defined using normal Java. After all, agents are fundamentally implemented as Java classes, so the full Java functionality is available. The user may want to define data structures for the agent to use that are different from the beliefset construct provided, and you may want to include methods to post events when certain situations arise. You will certainly want to define constructors and destructors so that individual agents can be created and destroyed. Note that at least one constructor for the agent must be defined.
When defining an agent's methods, the user may wish to use some of the base methods that the Agent class provides. Since all agents extend the Agent class, these methods are always available. Typically, they implement useful low level functionality such as:
- constructing an agent instance;
- terminating an agent;
- posting an event (only those identified using a #posts event or #sends event declaration);
- sending messages to other agents;
- replying to messages from other agents;
- specifying which timer the agent will use; and
- determining the agent's name on the JACK network.
Agents also have a data member that allows you to specify the Timer (clock) that the agent uses to measure the passage of time.
Furthermore, if any of the agent's plans require it to implement a particular interface, all the methods specified by this interface must be included among the agent's methods and be fully implemented.
Note: Personalised Agent sub-classes can be defined by extending from other Agent classes that have been defined. It is not necessary to extend directly from the base Agent class.
Agent Construction
To construct an agent, follow the convention for constructors used in Java. An example of agent construction is shown below:
agent ExampleAgent extends Agent
{
// #-statements
// data members
ExampleAgent (String name)
{
super(name);
...
}
}
Agent Termination
To terminate an agent, use the Agent base method finish(). When this method is executed, all event processing within the agent terminates immediately and the agent is removed from the JACK runtime network. Actual removal of the agent and the freeing of its allocated memory is left to the Java garbage collector.
void postEvent(Event e )
The postEvent() method is used by the agent to post a new event. It can be used to post all types of events.
The prototype for this method is shown below:
public void postEvent (Event event_name);
where event_name is the name of the event to be posted. Note that to use this method:
- the event being posted must have already been constructed; and
- this event must have been included among the events that this agent can handle (by means of a #handles event declaration)
An agent executes a separate task to handle posted events. Hence, the postEvent() method does not return a result, even if the agent cannot handle the event (e.g. if none of its plans are relevant or applicable).
The event is handled asynchronously by the agent. Note that this is also true if the event posted is a goal event. Normally goal events are handled synchronously in separate subtasks but when posted using this method, they are treated and handled asynchronously as normal events.
Message events should not be posted in this way. If they are, they will appear as internal events and the from member will be set to null.
boolean postEventAndWait(Event e)
This base method is similar to the postEvent() method, except that instead of posting the event asynchronously, it is posted synchronously. The agent still executes the event as a separate task, but the calling method must wait until this task has been completed before continuing. The prototype for this method is shown below:
public boolean postEventAndWait(Event event_name);
The method returns a boolean result depending on whether the task that the agent performs to handle the event succeeds (true) or fails (false).
Note: Unlike most other agent methods, this method must not be called from any of an agents tasks. It can only be used from methods used by normal Java programs that are integrated with the JACK application.
void send(String s, MessageEvent e)
This method is used to send messages (MessageEvents or BDIMessageEvents to other agents. The prototype for this method is given below:
public void send (String name, MessageEvent message)
It takes two arguments:
- the name of the destination agent, and
- a MessageEvent to send to this agent.
The agent name can either be in short (agent) or full (agent@portal ) form. The short name is simply the name that was specified in the constructor of the agent. If a short agent name is passed, the message event will only reach the agent if it is running within the same process as the agent that sends the message. If a fully-qualified name is passed, on the other hand, the message will reach the destination agent if it is running anywhere on the same DCI network.
void reply(MessageEvent q, MessageEvent r)
This method is used to send messages (MessageEvents or BDIMessageEvents) back to an agent from which a previous message originated.
If the agent has received a message and performed a task in response to this message, one of the steps in the plan that responds to this message may be to send another message back to the originating agent in the form of a reply. This may be to confirm that the task has been completed.
The prototype for this method is given below:
public void reply (MessageEvent query, MessageEvent response)
Unlike the send() method, the reply() method does not require specification of the destination agent as an explicit input argument. This is because the agent already knows which agent sent the original message. The sender's address is specified in the original message event's from member.
String name()
This method is used to retrieve the agent's full name, which includes its process portal name. It returns the name as a String.
The name returned consists of two components:
- the agent's name as it is known locally within the process; and
- the portal name assigned to the current process.
For example, suppose an agent called kermit is running in a process which has been assigned a portal name sesameStreet. The name returned by this method would be kermit@sesameStreet.
Timer timer
This data member specifies which timer (clock the agent will use to measure the passage of time. JACK includes a number of different Timer classes to give programmers more control over how agents respond to the passage of time in a program.
The definition of this member is given below:
Timer timer;
The Timer class is JACK specific. Timers can be categorised as: the real-time clock (measuring the passage of time as would a normal system clock); dilated clocks (enabling the agent to manipulate time with effect, such as fast forward, slow motion and pause); and simulation clocks (enabling manual ticking and even greater control than that offered by dilated clocks).