INCOMPLETE! This file is under construction ========== GET BREVE ========== Before getting started, you should download breve from: http://www.spiderland.org/ The preferred version is "breve CLI 2.7.2 for Linux". The Windows and Mac versions should also work. What is important is that the CLI (Command Line Interface) version is used. Follow the included instructions for installing breve, and run some of the included breve simulations to assure that breve runs correctly. ========== TEST BREVE-MONSTERS ========== Assuming you have installed breve correctly, the following command will show you all of the command line parameters along with their default values: breve -ux /[path_to_code]/Simulation.tz help Where /[path_to_code]/ is the location you have installed this code. If you configure your path correctly (in accordance with the installation instructions included with breve), you can run breve from anywhere, and can therefore simply run this code from the directory it is stored in. breve -ux Simulation.tz help The "-ux" part of this command are commandline parameters for breve itself, not for the simulation. The "u" parameter makes it so the simulation is not paused when it starts, and the "x" parameter disables visual display, which allows for faster simulation and does not require a graphics terminal. The list of command line parameters shown by the "help" is long and confusing, but most of them can be ignored. Some are only meant to be used by the simulation for loading and saving information, and some are associated with features that were experimented with, but never incorporated into any publication. The important parameters will be discussed in this tutorial. Furthermore, there are special commandline parameters called Evolution Modes (detailed in EvolutionMode.tz) that allow you to set several commandline parameters with a single command in accordance with several pre-established approaches to evolving NPC monsters in these games. ========== TYPES OF COMMAND LINE PARAMETERS ========== Commandline parameters map to numbers, strings or bits. Most commandline parameters are a pair of the parameter name followed by the value. For example, the following command sets the "n" parameter equal to "Test" and the "e" parameter to "5": breve -u Simulation.tz n Test e 5 The bit parameters are set either "on" or "off" by using those keywords. This example turns the "io" parameter "off" and the "fs" parameter "on": breve -u Simulation.tz n Test e 5 io off fs on The order of parameters is irrelevant, as long as each value is paired with its parameter name. Some commandline parameters are lists, which have to be specified in a particular format. First comes the name of the parameter, which in the next example is "task-set". Then comes one of three data types describing the contents of the list: "string", "int" or "double". Then come the list contents separated by spaces. After the last list item, the "end" keyword is used. The following example sets "task-set" equal to the list "{0, 2}": breve -u Simulation.tz n Test e 5 task-set int 0 2 end In addition to the above general types of commandline parameters, there are a few special parameters that require more than one value following the parameter name. These parameters are dealt with as special cases below. ========== BASIC COMMAND LINE PARAMETERS ========== These are some of the most common commandline parameters: String parameters: n : A string that describes the experiment, and is part of all filenames produced by it. fp : Absolute path to an existing directory where all output files are written. auto-resume : If a filename is specified, then the contents of this file will be updated with information about saved files whenever the simulation writes population information. An auto-resume file makes it easy to resume a previously crashed or terminated experiment. If an auto-resume file is specified, then it will tell the simulation what all relevant parameters were at the time of the last save, and also where to load the networks from to create the evolving population. List parameters: task-set int end: Specifies which tasks will be used to evaluate the evolving monsters. The task numbers are 0=FIGHT, 1=PREY, 2=PREDATOR, 3=SINK_BALL. Task 0 by itself is the Battle Domain used in several publications. The combination of tasks 0 and 2 is the Fight or Flight domain used in previous work. The other tasks have yet to be used in published work. Bit parameters: io : Turns file IO on/off. When loading previously saved results for viewing, it makes sense to turn IO off. Otherwise you will generally want it on. fs : Stands for "Feature Selective". Networks evolved for the included domains tend to do better when Feature Selective networks are used. Turning this option on means that initial networks will have only sparse connectivity (one synapse per output) instead of full connectivity. tug : Turns the Targeting Unachieved Goals method of fitness-based shaping on/off. Details are described in the 2010 GECCO paper. Note that turning on TUG by itself does not turn on automatically increasing goal values, which is handled by the next parameter. igwaa : Stands for "Increase Goals When All Achieved". Turning this on makes goals automatically increase in the manner used in the 2010 GECCO paper. bd : Turns the use of a behavioral diversity objective on/off, as described in the 2010 GECCO paper. This option needs to be combined with another which defines what type of input syllabus to use for generating behavior vectors. rbs : Turns randomized behavior syllabus on for use with a behavior diversity objective as in the 2010 GECCO paper. obs : Turns observed behavior syllabus on for use with a behavior diversity objective. The observed behavior syllabus randomly samples from inputs experienced by monsters during evaluation. z : Use the z-scores fitness method instead of NSGA-II, as in the 2008 AIIDE paper. NOTE: this method only works properly with the Battle Domain (which happens to be the default task-set specification). mate : Turns crossover between networks on/off. Crossover is performed using history markers in a manner similar to NEAT. tp : ????????????????????????????????/ homo : Turns homogeneous team composition on/off, meaning that a single team consists of copies of one network. The alternative is heterogeneous teams of different networks from the population. hud : Turns a heads-up display on/off, which is a window in the corner that displays the controlling network for a member of the monster team being evaluated. Clicking on different monsters changes the network being displayed. oee : ???????????????????????????????????? Number parameters: sp : Specifies the number of networks in the population to be evaluated. we : Stands for "write every". The number of generations between each time the simulation writes the entire population and simulation details to file. More frequent writes assure availability of a good resume point if it is necessary, but will slow down things slightly due to IO, and also eat up lots of disk space. max : Maximum number of generations to simulate. When using Open-Ended evolution (see "oee" parameter), evolution stops at this generation. Otherwise, there is a chance that evolution will stop sooner, given that all goals are achieved when facing the most difficult version of a task. e : Number of times that each network is evaluated. Fitness scores for a network are averaged across all evaluations in an effort to account for noisiness/variability in evaluation. s : The opponent bot for the monsters has several scripted strategies available, some of which were used in the 2008 AIIDE paper. They are 1=SPIN, 4=COMBO, and 5=SMART. Others are defined in Constants.tz. Perhaps most interestingly, 0=HUMAN allows human control of the bot via the keyboard. Papers after the AIIDE paper used 5=SMART exclusively. ei