Advanced Strategic Command
documentation
The Source
I started writing the program and designed the basic game system in 1994 using Borland Pascal as the programming language. In 1995 I started using object orientated programming and in 1996 I converted the whole project to Watcom C/C++. We started the port to GCC and Linux in 1999. If you look at the source you will "see" this history. If I started such a project now from scratch I would design it completely different (for example a client / server design and everything much more object oriented). But we have the project as it is and are trying to improve it in that direction without rewriting it from scratch.
The source code is not very well structured and documented. I always preferred writing cool new features instead of cleaning up the code :-)
We are going to improve this gradually. Don't hesitate to contact us if you have any questions regarding the source code or anything else about the game.
Another "historical" thing about the source code is the language (not the programming language) that was used for it. Since we did not intend to release the source code we used a mixture of German and English for variable- and function names and avoided writing comments and those that we have are mostly in German. We have now run several translation passes through the code to translate it to English. The global interfaces should be completely in English now, but several local variables may still be in German. Since we run the translation through the code by a source code wide "search and replace" there are now some comments and perhaps a few code elements that were negatively affected by it and sound quite funny.
Required Tools
for building the Windows version
We are building ASC/win with Borland C++ Builder 5. It should be possible to build ASC with any other Windows compiler too, if it has some sufficient understanding of the C++ language. Microsoft Visual C++ version 6 and older have not, it is absolutely impossible to compile ASC with these primitive compilers. But Visual Studio .NET is much improved and can compile ASC without any problems. The project files for Visual Studio .NET are included in the asc/source/win32/msvc directory, although they are not completed yet. But finishing them should be straight forward.
It is also possible to compile ASC with the free Borland command line compiler. Makefiles for it are included
Borland C++ Builder / free command line compiler
- Get the JPEG-lib source code by the Independant Jpeg Group.
- Uncompress the JPEG-lib source code into asc/source/libs/jpeg-6b/ (this directory already exists).
- Get SDL 1.2 or newer. It can be downloaded from www.libsdl.org. You need the source code and the DLL file (the later is called: "binary runtime / win32").
- Get SDL_mixer 1.2 or newer. It can be downloaded from www.libsdl.org/projects/SDL_mixer/. You need the source code and the DLL file (the later is called: "binary / win32", get the one without devel in the name).
- The project files assume there is a SDL and a SDL_mixer directory located in the same directory where asc is placed. You need this directory structure:
asc\ (from ASC source package or CVS)
asc\source\
asc\doc\
SDL\ (from SDL source package)
SDL\include\
SDL\src\
SDL_mixer\ (from SDL_mixes source package)
After uncompressing the SDL and SDL_mixer source packages, move them so that this directory structure forms. You probably have to rename the directories from SDL-1.2 to SDL, for example.
The asc directory may be called differently if you downloaded the asc source package from the homepage, That is no problem, it may for example be named asc-1.5.0
- Create a subdirectory called BIN in SDL\ and put the SDL.DLL into it.
- Go to this directory and run: IMPLIB -a -c SDL.LIB SDL.DLL
- Create a subdirectory called BIN in SDL_MIXER\ and put the SDL_MIXER.DLL into it.
- Go to this directory and run: IMPLIB -a -c SDL_mixer.LIB SDL_mixer.DLL
Borland C++ Builder
- Open asc/Asc.bpg and run "make all projects"
- If you want to run ASC from within Borland C++ Builder, place a file ASC.INI in asc\soure\win32\borland\ that contains the following line:
SearchPath0=c:\somewhere\
replace c:\somewhere by the directory where you want ASC to place its files (savegames, etc.).
- Get the datafile (main.con) from the website and put it in this directory.
Free Borland C++ command line compiler
- Execute asc/makebcc.bat
All major files will be placed in the asc\game\ directory that is going to be created.
for building the Linux version
Well, nothing special about that. We build ASC with the standard GNU development tools. Refer to INSTALL for (generic) build instructions.
Watcom C++
The discontinued DOS version and early Windows versions of ASC were built with Watcom C/C++ 11.0b. Since the compiler is dead and does not support all ANSI-C++ features, ASC can no longer be build with it.
Just in case that the OpenWatcom-Project will bring the compiler up to date, we preserved the build instructions.
Porting ASC
Porting ASC to any platform supported by SDL should be farely easy (as long as it is 32 bit and has Intel byte order).
The source documentation
The source documentation system used for ASC is doxygen. The doxygen configuration file is asc/source/doxygen.config.
A short walk through the ASC source
THE central class of ASC is tmap
in gamemap.h. It is the anchor where nearly all elements of ASC are chained to. The global variable actmap
is a pointer to the active map. There can be a maximum of 8 players on a map, plus neutral units (which are handled like a 9th player). Hence the array of 9 Player
classes inside tmap
.
Each player has units and buildings, which are stored in the lists vehicleList
and buildingList
. The terms units and vehicles are used synonymously in ASC. Since unit was a reserved word in Borland Pascal, we decided to use the term vehicle instead. But now, with ASC written in C++, 'unit' is also used.
Every building and unit is of a certain 'type'. The vehicletypes
and buildingtypes
are stored in the *.veh and *.bld files, are loaded on startup and globally available. They are not modified during runtime in any way and are referenced by the vehicles and buildings. The vehicletype
has information that are shared by all vehicles of this 'type', like speed, weapon systems, accessable terrain etc, while the vehicle
stores things like remaining movement for this turn, ammo, fuel and cargo.
The Vehicle
, Vehicletype
and Buildingtype
classes are defined in files having the same name as the class, while the Building
class is defined in buildings.h, since building.* was already used for something different.
The primary content of a map are its fields. Each field has again a pointer to a certain weather of a terraintype
. Each terraintype (can currently be found in typen.h, but will be moved to its own file sooner of later) has up to 5 different weathers ("dry (standard)","light rain", "heavy rain", "few snow", "lot of snow"). If there is a unit or a building standing on a field, it has a pointer to it.
On the field can be several Objects
. Objects are another central class of ASC. Roads, pipleines, trenches and woods are examples of objects.
Source code formatting
Since there are many different source code formatting styles out there, it would be quite a mess if everybody used his own style and spends half his time undoing the formatting that others did. I don't want to force everybody to use exactly the same formatting, but if some source is reformatted, then to a well defined layout.
Artistic Style is a capable program for formatting source code.
The settings --style=linux -s3 -C -S are recommended to be used for ASC. If you write these settings to a file ~/.astylerc, you don't need to type them each time you call Astyle. The central setting there is the -s3, which tells Astyle to indent with 3 spaces.
Some nested and nasty #ifdefs can confuse Astyle. After using Astyle, check the last line of the source file and verify they are correctly indented. If they are not, either fix the #ifdef or restore to the backup file that was created by Astyle!
I personally don't like cutting breaking each line after 80 characters. The times when that was the upper limit of what a monitor could display at once are long passed. And since the first 120 characters (or whatever the size of your screen is) of a command are usually sufficient to get an idea what it is doing, I prefer to not have the next line cluttered with some coordinate calculations that nobody is really interested in.
But, as always, there are exceptions where it helps to break a command into several lines...