Join GitHub today
Ada Roff Shell Tcl
Fetching latest commit…
Cannot retrieve the latest commit at this time.
This is a port to Ada of cempire (see https://github.com/jimwise/cempire ). This is very much a work in progress -- it works, but is missing some functionality of the C version, and is still not completely stable. This code is Copyright (C) 2006-2012 Jim Wise As a derivative work (a straight port) of a program under a GPL-like license, this software is offered under the same license as that program -- this corresponds with the author's clear intent, although it may not be a legal necessity. --- Below is the README from the C version ---- /* * Copyright (C) 1987, 1988 Chuck Simmons * * See the file COPYING, distributed with empire, for restriction * and warranty information. * * $Id: READ.ME,v 1.1 2006/02/21 17:33:41 jwise Exp $ */ C Empire Sources History Apparently, this game was originally written outside of Digital, probably at a university. The game was ported to DEC's VAX/VMS from the TOPS-10/20 FORTRAN sources available around fall 1979. Ed James got hold of the sources at Berkeley and converted portions of the code to C, mostly to use curses for the screen handling. He published his modified sources on the net in December 1986. Because this game ran on VMS machines for so long, a previous version is known as VMS Empire. In early 1987 Chuck Simmons reverse engineered the program and wrote a version completely written in C. In doing this, I used lots of structures and defined constants, and I attempted to make the code flexible and easy to modify. The algorithms used in this C version are completely new, the names of the commands have been changed to be more mnemonic, and new commands have been implemented. Only the format of the display is the same. I suspect that many of my changes are slower and less intelligently implemented than the originals. Also, I have not implemented some of the original functionality. However, my hope is that the commented C sources I have written will prove far easier to modify and enhance than the original FORTRAN sources. If you make changes for the better, by all means send Ed James and I a copy. Sometime thereafter, Eric S. Raymond took over work on C-Empire, adding color support and some modernizations. In 1998, the torch passwd to Jim Wise, who has brought the code up to modern C standards, ported it to not assume the presence of the GNU ncurses library, and otherwise maintained the code against bit-rot. The basic game has been heavily modified since 1979 -- the types of objects built have changed, as have the parameters on others, and lots of new kinds of movement functions have been added. Read the man page for a complete description. The file 'bugs' contains lots of ideas for enhancements, and describes the bugs I haven't been able to find. Organization I have attempted to organize the sources into relatively few coherent pieces. The pieces are: empire.h -- definitions of data structures extern.h -- definitions of global variables data.c -- constant data main.c -- option parsing empire.c -- main program loop and outermost command handler usermove.c -- move the user's pieces compmove.c -- move the computer's pieces edit.c -- handle the user's edit mode commands game.c -- saving, restoring, and initializing the game board display.c -- update the screen term.c -- deal with information area of screen math.c -- mathematical routines object.c -- routines for manipulating objects attack.c -- handle attacks between pieces map.c -- find paths for moving pieces util.c -- miscellaneous routines, especially I/O. Debugging notes From command mode, there are two special commands that can be used to turn debugging mode on or off. "++" turns debugging mode on. "+-" turns debugging mode off. When debugging mode is turned on, the following commands are available: "#" -- display a sector of the computer's map. "%" -- enter "movie" mode. The computer continuously makes moves, and the computer's map is shown on the screen. This is useful for debugging the algorithm used by the computer when it makes a move. Don't confuse this with saving a movie and replaying it. "@" -- enable/disable "trace pathmap" mode. If this command is followed by a "+", trace pathmap mode is enabled. If this command is followed by a "-", trace pathmap mode is disabled. In this mode, every time a "pathmap" is created, it is displayed. This is useful for debugging the subroutines that search for an optimal path along which to move a piece. "$" -- enable/disable "print_debug". This command is also followed by either a "+" or "-". In this mode, various messages will be printed out at times which may indicate that something is being done non-optimally. "&" -- enable/disable "print_vmap". This command is followed by a char that specifies the type of vmap to be displayed. Values are "a" -- army load maps "l" -- transport load maps "u" -- transport unload maps "s" -- ship maps "i" -- pruned explore map Any other character disables the printing of vmaps. The program will not provide any prompts for the debugging commands. If you make a mistake, the computer just beeps. You can also replay a saved movie with the normal "W" command when debugging mode is turned on. Also, the -DDEBUG flag can be turned on to cause consistency checking to be performed frequently on the internal database. This consistency checking is fairly exhaustive and checks for all sorts of screwed up pointers. My measurements suggest that consistency checking causes the program to run half as fast. Final Notes Unfortunately, I have a rather powerful mainframe at my disposal which is somewhere between 10 and 40 times as fast as a 68020 based computer. This means I can afford to use extremely inefficient algorithms. I suspect that running this program on a smaller machine, such as a Sun workstation or Vax will not be overly rewarding. In particular, the computer will take a very long time to move its pieces, and it may not be desirable to save the game after every move. (You mean your system doesn't write out 1/2 megabyte files in a few milliseconds?) This second problem is easily fixed, but I don't yet have any good ideas for fixing the first problem. The size of a saved file can be easily tuned by reducing the LIST_SIZE constant in empire.h. The only current simple tweak for making the computer move faster is to reduce the size of a map. Chuck Simmons amdahl!chuck Ed James firstname.lastname@example.org ucbvax!edjames My changes enable color on machines with terminfo color support, for a dramatic improvement in appearance and readability of the display. Color support, if present, will be auto-detected at compilation time. They also implement and document a `save-interval' option, addressing one of the misfeatures noted in the bugs file. I've also tweaked the sources so they compile clean under GCC -- they assumed the older K&R model of forward reference, causing many warning references. Finally, I've sped up expand_perimeter by cutting down on the number of array references it has to compute. This eliminates several multiplies from the inner loop, and is a technique that should be applied much more widely in the code. Eric S. Raymond email@example.com (home page: //www.ccil.org/~esr/home.html) Jim Wise firstname.lastname@example.org http://www.draga.com/~jwise/cempire/