unsigned slot);  virtual rf<State> getCurrentState();  virtual ConfidenceInterval getCapability(rf<State> s,                                           rf<Goal> g);public:  MyBehavior(std::string const &id,             std::string const &playerClass);};\end{verbatim}\end{program}You can do this by hand, but you can also use the utility script {\tt createbehavior.pl} to do this for you:\begin{program}\begin{verbatim}$ cd util/$ ./createbehavior.pl[Enter the behaviors name (e.g. MyBehavior)]\end{verbatim}\end{program}This creates a directory with your behavior's name in the Behavior directory and fills it with a header file with the necesary method declarations and code files with basic implementations for these methods.\subsubsection{Constructor (defining slots)}After making the base of your behavior you have to implement the constructor, where you define the structure of the behavior's sub behaviors by creating slots. The {\tt createbehavior.pl} script makes a start by creating a tree that defines a sequence of 1 step with 1 slot:\begin{program}\begin{verbatim}// Define the root, which is always a sequence:d_tree = new AST::Node(sequenceType);// Add one step to the sequence:d_tree->addChild(new AST::Node(andType));// Add one slot to the first step:d_tree->getChild(0)->addChild(new AST::Node(orType));\end{verbatim}\end{program}If you need more steps in the sequence, you can add new conjunction nodes ({\tt andType}) to the root, if you want to run sub behaviors in parallel in a step, you can add new disjunction nodes ({\tt orType}). The following gives an example of a behavior with 3 sequence steps and 2 parallel slots in the second step:\begin{program}\begin{verbatim}// Define the root, which is always a sequence:d_tree = new AST::Node(sequenceType);// Add first step to the sequence:d_tree->addChild(new AST::Node(andType));// Add one slot to the first step:d_tree->getChild(0)->addChild(new AST::Node(orType));// Add second step to the sequence:d_tree->addChild(new AST::Node(andType));// Add two slots to the second step:d_tree->getChild(1)->addChild(new AST::Node(orType));d_tree->getChild(1)->addChild(new AST::Node(orType));// Add third step to the sequence:d_tree->addChild(new AST::Node(andType));// Add one slot to the third step:d_tree->getChild(2)->addChild(new AST::Node(orType));\end{verbatim}\end{program}\subsubsection*{getCurrentState()}The first virtual method to implement is {\tt getCurrentState}. Different behaviors rely on different information of the world and/or agent state. In the BATS agent architecture a behavior defines this state itself in a standardized tree-based state description. This standardization is useful when using a learning algorithm to train different behaviors that use different state information. These state descriptions can also be used to define goals as states that should be reached, as we will see in the next sections.A basic state description is a conjunction of the state of several variables. To cater for incertability, the state of a variable is defined as a range of possible values:\begin{equation}\label{eqState}(0 \leq BallDist < 5) \wedge (10 \leq OpponentDist < 15)\end{equation}A behavior's state is defined in its {\tt getCurrentState} method. The {\tt createbehavior.pl} script sets up a conjunction for you to place variables into. The following code shows how to create the state in \ref{eqState}:\begin{program}\begin{verbatim}rf<State> state = new State();rf<OrNode> dis = state->addDisjunct();rf<AndNode> con = dis->addConjunct();con->addVar("BallDist", 0, 5);con->addVar("OpponentDist", 10, 15);\end{verbatim}\end{program}\subsubsection*{getCapability()}Behaviors that are placed in the same slot compete with eachother for execution. They receive the same goal and are selected based on their capability to achieve that goal. Also, before advancing to the next sequence step, a behavior checks if the sub behaviors in that step have enough capability to finish that step. A behavior's capability is requested by calling its {\tt getCapability} method, passing it a goal and the state it created in {\tt getCurrentState}. The behavior returns an estimate of its capability of achieving the goal, ranging from -1 to 1, with a confidence interval that depicts the accuracy of the estimate.\subsubsection*{Commitment}As explained earlier a behavior can commit to its goal when it is chosen. By doing so, it lets the super behavior know that it will take some time to reach the goal and that in intermediate steps it could not be good to switch between behaviors. Commitment is requested by setting the d\_committed member variable, which should be done in the behavior's overloaded {\tt update} method:\begin{program}\begin{verbatim}void MyBehavior::update(){  Behavior::update();    // Check if we are already committed  // due to committed subbehavior(s)  if (d_committed)    return;    // Commit if we can still reach our goal    if (goalStillReachable())    d_committed = true;  else    d_committed = false;\end{verbatim}\end{program}The {\tt update} method is called at the beginning of each time step if the behavior could be selected to run that timestep. First of all the {\tt Behavior::update} should be called. This updates the child behaviors, checks if they are committed and commits the behavior if it should commit if children are committed \footnote{Abbreviated to SCICC (Should Commit If Children Commit)}. If this is the case you can choose to override this, but usually you just return.Next you check whether the behavior should commit to its goal. Usually this is the case when the goal can still be reached. It is important to also reset the flag when a goal is no longer reachable, as shown in the example, to prevent a behavior to lock the agent in useless behavior. Note that the behavior's goal ({\tt d\_goal}) is the goal received in the previous timestep.\subsection{Configuration XML setup}\label{subsecConfiguration}The humanoidbats agent has to have an XML configuration file. This file is used to structure all the behaviors in the binary together. The XML file will define all the steps and slots and will define a root behavior which is at the top of the behavior hierarchy.The general XML layout contains:%%%  HIERONDER MNOETEN NOG LINKS KOMEN NAAR DE HOOFDSTUKKEN..........%%%\begin{itemize}\item The root conf element	\item The player id (unum) to class type coupling	\item The player class defenitions\begin{itemize}		\item The behaviors element\begin{itemize}			\item Behavior elements\begin{itemize}				\item Behavior parameters				\item Behavior slots\end{itemize}\end{itemize}\end{itemize}\item XIncludes\end{itemize}\subsubsection*{The root conf element}Every XML file has a root element, in the configuration XML files this is the conf element. If the file includes other XML files, make sure to include the XInclude namespace. The most common header will therefore contain:\begin{program}\begin{verbatim}<?xml version="1.0" encoding="ISO-8859-1"?><conf xmlns:xi="http://www.w3.org/2003/XInclude">\end{verbatim}\end{program}\subsubsection*{The player id (unum) to class type coupling}All the players on the field share the same XML configuration files as they are all instances of the same command. To allow for the different player types to share the same XML, the playerclass has been added. Every agent has a playerclass, and all player classes have their own behavior hierarchy. To define which player class is used for which unum, using the following code:\begin{program}\begin{verbatim}<player id="1" class="attacker" />\end{verbatim}\end{program}\subsubsection*{The player class definitions}The player class element holds the behaviors for the player class. Every player class has an id and contains the behaviors.\begin{program}\begin{verbatim}<player-class id="attacker">\end{verbatim}\end{program}\subsubsection*{The behaviors element}The behaviors element is a simple container element for all the behavior elements. It currently has no attributes, but must contain at least one behavior with the id 鈥渨in鈥