You can define XBATTLE symbol via FREEWARE_DEMO.COM procedure EXAMPLES Here are some example games to give an idea of the variability of the parameters. The first example is a simple symmetrical game between "me" in black on my own display, and a white opponent on the display "cnsxk:0.0". The troops will be rapidly exhausted in this small skirmish. xbattle -black me -white cnsxk:0.0 -armies 4 The next example adds bases, which will produce a much prolonged conflict involving long supply lines between the front and the bases, much like desert warfare. One conflict in this battle represents a skirmish like the entire game of the previous example. In this example black is playing on the display cnsxk:0.0, and white is on the system console. Note that the extension ":0.0" can be omitted. xbattle -black cnsxk -white unix -armies 4 -bases 2 The next example is a game with militia scattered around initially, that have to race to occupy the towns and link up with their compatriots before they can eliminate the enemy. This is a dynamic scenario requiring tactical and strategic skill and fast reflexes. In this example black is playing on cnsxk:0.0 while white is playing on the system console of the remote machine thalamus.bu.edu. xbattle -black cnsxk -white thalamus.bu.edu -towns 2 -militia 2 -hills 7 Here is a favorite around B.U. where the land is broken up by many bodies of water creating isolated islands, and view of the enemy is restricted to nearby squares, resulting in lots of surprises. Paratroops can be used for reconnaisance by launching them into unknown sectors, and they must be used in conjunction with heavy artillery barages for airborne assaults from one landmass to the next. In this example the color display will show cyan and red teams, while the monochrome monitor will show white and black teams respectively. The decay option prevents huge armies from building up at the end of the game, and the -store option is used to store this game to the file "battle.xba". xbattle -cyanwhite thalamus:0.0 -redblack cnsxk -rbases 5 -sea 8 -guns 4 -para 4 -horizon 2 -decay 3 -store xbattle.xba Now, the previous stored game is replayed to the original displays by repeating the original command line except that -store is changed to -replay. This is convenient if you have command line editing facilities. xbattle -cyanwhite thalamus:0.0 -redblack cnsxk -rbases 5 -sea 8 -guns 4 -para 4 -horizon -replay xbattle.xba With -replay, all arguments are actually ignored except the displays, so you could achieve exactly the same result with the simpler command xbattle -black thalamus:0.0 -black cnsxk -replay where the -black argument flags the subsequent argument as a displayname, but is otherwise ignored, i.e. any color name would suffice. The filename for -replay is omitted, so that the default file name "xbattle.xba" is used. The next example illustrates the use of the options file, tribal.xbo, to set up a game including, decay, seas, farms, militia, and many other options. xbattle -black me -white thalamus -options tribal.xbo Options files can also be read in individually for the two players, as in the following example... xbattle -options game.xbo -black me -white { -options weak.xbo } thalamus This results in a biased game where both black and white receive the options defined in game.xbo, and white receives some specific handicaps defined in weak.xbo. For example, weak.xbo could define 2 rbases instead of 5, horizon of 1 instead of 2, and lower movement and fighting values. Since these options overwrite existing options in game.xbo, the command line arguments may NOT be typed in arbitrary order, because later options overwrite the earlier options, so the global options must be defined before they are overwritten by the specific options to the white team. OPTIONS [ -options []] [ -bases 4 teams max.] [ -rbases ] [ -armies 4 teams max.] [ -militia ] [ -towns ] [ -repeat no argument- allows command repeat] [ -bound no argument- allows multiple commands] [ -march ] [ -erode