1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
|
/* (c) Copyright 1987, 1988 Chuck Simmons */
/*
* Copyright (C) 1987, 1988 Chuck Simmons
*
* See the file COPYING, distributed with empire, for restriction
* and warranty information.
*/
C Empire Sources
Here's my change-log.
1.2: Fri Jul 28 01:10:00 EDT 2000
The victory-odds table in previous versions was seriously buggy.
I folded in corrections from Michael Self. I also took changes
from James T. Jordan <kermyt@earthling.net>, who wrote some
speedups, added ANSI prototypes, and cleaned
1.1:
I colorized and speed-tuned this and added a
save-interval option.
The rest of this history is Chuck Simmons's original notes.
-- Eric S. Raymond
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 I 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.
The basic game has been heavily modified. I've changed the
types of objects built, modified the parameters on others,
and added lots of new kinds of movement functions. 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
edjames@ic.berkeley.edu
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
esr@snark.thyrsus.com
(home page: //www.ccil.org/~esr/home.html)
|
