_bats_xmlconf.tex

The Little Green BATS is the first and so far only Dutch team in the 3D simulation league. We are a

\subsection{Configuration XML setup}

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 “win”.

\subsubsection*{Behavior elements}
The behavior elements contain all the information for the behavior structure. Every behavior has a type, that names the name of the behavior in the binary, and an unique id, which is used to reference it from other parts of the XML. The id only has to be unique within the behaviors parent element, not the whole configuration XML.

\begin{program}
\begin{verbatim}
<behavior type="MyBehavior" id="mybehavior">
\end{verbatim}
\end{program}

\subsubsection*{Behavior parameters}
Behavior parameters are behavior specific and are used in by the binary behavior to make it more general in use.
All parameters for a behavior are kept inside the \emph{param} element. This element can contain any type of element which is totally up to the binary behavior.
An example of is:
\begin{program}
\begin{verbatim}
  <param>
        <deg>10</deg>
        <joint slot="0">&rleg5;</joint>
        <joint slot="1">&lleg5;</joint>
  </param>
\end{verbatim}
\end{program}

\subsubsection*{Behavior slots}
Every behavior can have other behaviors below it. These other behaviors can be run in parallel, in sequence, or in competition.
The slots are created with a \emph{slot} element which is a direct descendant of the behavior element. Each slot has an index attribute
which describes where it is placed below the behavior. Each slot, in turn, contains any number of references to behaviors defined in the
configuration.

To reference to a behavior, a \emph{behavior} element should be used with a \emph{refid} attribute containing the XML configuration id of the behavior.

A typical example:

\begin{program}
\begin{verbatim}
<slot index="0-0">
  <behavior refid="mybehavior" />
</slot>
\end{verbatim}
\end{program}