@DATABASE Axis&AlliesGM.guide

@REMARK $VER: Axis&AlliesGM.guide 1.1 (5.4.02)

@NODE MAIN "Axis&AlliesGM"

  @{b}Axis & Allies Game Master Release 1.1@{ub}

  @{"  1 " LINK Copyright} Copyright and Disclaimer

  @{"  2 " LINK Introduction} Introduction

  @{"  3 " LINK Requirements} Requirements

  @{"  4 " LINK GUI} GUI

  @{"  5 " LINK Shell} Shell

  @{"  6 " LINK ARexx} ARexx

  @{"  7 " LINK Defects} Known Defects

  @{"  8 " LINK Author} Author Information

  @{"  9 " LINK History} Release History

  @{" 10 " LINK Future} Future Features

  @{" 11 " LINK Implementation} Implementation

  @{" 12 " LINK FAQ} FAQ
@ENDNODE


@NODE Copyright "Copyright and Disclaimer"

Axis & Allies Game Master
Copyright © 2002 Steven Solie.  All Rights Reserved.

Based on the original "Axis & Allies" board game.
Copyright © 1987 Milton Bradley Co.


You are hereby granted the right to copy and distribute verbatim copies
of the program archive unaltered and in its entirely.  All other rights
are reserved.


There is no guarantee or warranty of any kind.  Use at your own risk.

@ENDNODE


@NODE Introduction "Introduction"

I became addicted to the "Axis & Allies" board game while taking classes
at the University of Regina, Saskatchewan, Canada.  My friends and I
played almost every weekend until the wee hours of the morning.  Since my
university days ended some time ago, I've been itching to play a game or
two but lacked the necessary players and time to do so.

I first started a computer version of this board game in 1993 written in
C on my unexpanded Amiga 3000 system.  After several failed attempts in
both C and C++ over the years I was pretty much ready to give up on the
project when I discovered the Personal Software Process (PSP) by Watts
Humphrey.  I credit the PSP with giving me the structure and discipline
to get as far as I did this time around.

@ENDNODE


@NODE Requirements "Requirements"

Minimum requirements:

 · AmigaOS 3.9 with Boing Bag 1

 · 640 x 400 with 16 colours

 · Copy of the Axis & Allies board game (for the rules)


Recommended:

 · 68060 accellerator

 · Graphics card

 · 800 x 600 with 256 colours

@ENDNODE


@NODE GUI "GUI"

Double click on the icon to start the game.  The stack size should be
16384 bytes or larger.

The following tool types are supported:
 LANGUAGE - Specifies the language catalog to use for the GUI.
            The default is to use the current locale settings.

Some not-so-obvious notes about the GUI:
· Hold down the right mouse button and move the mouse to scroll the map.
· Zoom the map by holding down a shift key while scrolling.
· Click the right mouse button on a unit marker or movement line to cancel
  a move.
· Double clicking on a game space will also end a move.
· The screen mode can only be changed when a game is not in progress.

The GUI was designed to be a powerful interface for the experienced game
player and true to the original board game.  This means the GUI may not
be as intuitive as it could be for the beginner.  Another consequence is
the fact that the game map does not wrap around.  This decision was based
on the fact that players are prone to make mistakes at the edges of the
game board and I wanted that opportunity to carry over into the computer
version.

@ENDNODE


@NODE Shell "Shell"

If you have AmigaOS 3.9 with Boing Bag 2 or higher, the game will
automatically set the stack to the correct size.  If not, manually
set the stack to 16384 bytes or larger.

The command template is as follows:
 LANGUAGE/K

where:
 LANGUAGE - language catalog for GUI (e.g. "français")

@ENDNODE


@NODE ARexx "ARexx"

The ARexx interface is meant to serve a dual purpose.  For me, it means
the capability to automate functional testing which should help reduce
the need for beta testers.  For you, it means you have the capability to
program the game yourself.  Imagine creating your own robot opponents and
making them as smart or dumb as you want!

All commands set the RC variable to 0 when successful.


The following commands are available:
 NEWGAME
  Starts a new game.  Implicitly ends the current game in progress.

 ENDACTION
  End the current action.

 QUITGAME
  Quit the game and exit.  Implicitly ends the current game in progress.

 SCROLLMAP DX/N/A,DY/N/A,DZ/N/A
  Scroll the game map by delta x and y values.
  The delta z dimension zooms the map.

 GETUNITCOST TYPE/A
  Get the cost of a specific type of unit.

 BUYUNIT TYPE/A
  Buy one specifc type of unit.

 SELLUNIT TYPE/A
  Sell one specific type of unit.


The TYPE argument can be any of the following:
 INF - Infantry
 ARM - Armor
 FTR - Fighter
 BMB - Bomber
 AA  - Antiaircraft Gun
 IC  - Industrial Complex

@ENDNODE


@NODE Defects "Known Defects"

The following defects are known to exist:

· Rendering the thick lines takes a lot of time.

· Redrawing the map graphics on large screens takes too long and causes
  the pointer movement to become "jerky".

· Game runs far too slow on ECS/AGA machines.

· Saving and loading games over a network file system is very slow due to
  lack of buffering.

@ENDNODE


@NODE Author "Author Information"

Please feel free to contact me if you have any comments or questions:

  Steven Solie
  1708 Woodside Blvd.
  Airdrie, Alberta
  Canada, T4B 2K1

  Phone: (403) 912-1402
    Fax: (403) 912-1403
  Email: ssolie@shaw.ca
    WWW: http://members.shaw.ca/ssolie/
@ENDNODE


@NODE History "Release History"

@{b}Release  Date        Comments@{ub}
-----------------------------
1.0      2002-02-07  First public release.
1.1      2002-04-05  Added fighters and bombers.

@ENDNODE


@NODE Future "Future Features"

Obviously, the game is only partially complete.  Naval forces are
conspicuously absent from the game as well as most of the special rules
such as bombing factories.  Configuration options and other nice to have
extras are also missing.

My top priority is to complete all the basic game rules and make the game
as playable as possible.  I'm also open to suggestions from anyone on
what to implement next and all input will be seriously considered.

Ultimately, the game is intended to be moved on to a new platform.  My
first target is AmigaOS 4.0 followed closely by Linux.  I have no desire
to compete with the PC CD-ROM version and besides, I despise Windoze so
don't bother asking.  You're more than welcome to run it a Wintel machine
with one of the many Amiga emulators out there.  The game is being
designed so that it will be possible to write lightweight clients for it
in any programming language and play it over the internet.  I also intend
to make the game compatible with PBEM systems.

The ARexx port opens up a myriad of possibilities including a command
line interface, user programmable robot opponents and remote control to
name just a few.  I hope to expand the ARexx port to enable just about
anything a clever A&A hacker could imagine.

Please don't hesitate to contact @{"me" LINK Author} with your ideas and comments.

@ENDNODE


@NODE Implementation "Implementation Details"

The implementation is based on a basic client server model.  Each player
is essentially a client that connects to a single game master server. The
game master takes care of the game state (e.g. where all the markers are
on the map) and enforces all the rules.  AmigaOS Exec message passing is
currently used to move data between the clients and the sole server.

The GUI is implemented on top of Reaction and GadTools.  I tried to use
as many AmigaOS resources as possible to speed up development.  I created
a thin layer I call a Graphical Tool Kit (GTK) to encapsulate all the
nasty details such as tag lists and workarounds for earlier OS versions.
A similar thin layer was built on top of graphics.library and the
datatypes system.  The design of the two layers borrowed from the Java
API because I found its design to be easy to use and understand.  I hope
to create a Java client some day so it should be even easier to port when
that time comes. The thin layers should also make it possible to port the
GUI to other systems (e.g. GNOME) without too much effort.  Right now,
the object-orientated design eliminates the need for resource tracking
and hides most of the complexity to enable GUI changes and enhancements
to be created quicker.

The ARexx port has the potential for powerful extensions and custom
programming.  The port was initially added to enable automated functional
testing.  For example, if I want to test that all the rules in regards to
capitals are correct I can write a suite of ARexx scripts that manipulate
the game and test that the rules are being followed.  As more commands
are added, more powerful extensions are possible.

All files are in the IFF format so I can use the iffparse.library to read
and write them quickly and easily.  Another thin layer was developed to
hide the IFF format as much as possible.  This should enable a move to
XML or some other multiplatform standard when that time comes.  Right
now, I can quickly add, modify and remove data in the file and still
remain backwards compatible without too much effort.  For example, during
development of release 1.0 I changed file formats 5 times and no changes
were required to any of the other code.

@ENDNODE


@NODE FAQ "FAQ"

Q: Why is the executable so big?

My choice of C++ on the AmigaOS can take most of the credit.  The
underlying link libraries added about 800 KB to the total size.  As the
project moves on to other systems, I expect those systems to better
support C++ and include shared libraries which will bring the executable
size down to a more reasonable level.


Q: Why create a computer version of the board game?

The primary motivation for this project was a desire to play against
other players via the internet.  A secondary motivation was to learn how
to develop a large application in C++ using various software development
techniques.


Q: Are you aware there is already a PC version of this game?

Yes.  I've seen various reviews of the game and the hard core gamers have
basically concluded that it is an unusable buggy mess. I also believe I'm
targetting a completely different kind of player.  I'm trying to create a
game for experienced and expert players.  I won't be adding any fancy war
footage clips and such.  I want to concentrate on correctness and
reliability so you can play this game for many, many hours if you want to.


Q: Will the game always be free?

Yes!  I have no desire to make any money with this game.  Why else would
I have developed it on AmigaOS?  If you like this game, I suggest you buy
a copy of the board game and play it as well.  Nothing beats a night of
wargaming with some buds.

@ENDNODE