Initial revision
[vms-empire.git] / BUGS
1 /* %W% %G% %U% - (c) Copyright 1987, 1988 Chuck Simmons */
2
3 /*
4  *    Copyright (C) 1987, 1988 Chuck Simmons
5  * 
6  * See the file COPYING, distributed with empire, for restriction
7  * and warranty information.
8  */
9
10 Bugs
11 ----
12
13 1)  The computer is allowed to leave armies in cities.  Fixing this
14 feature might be difficult.  This feature also gives the computer
15 a small advantage which slightly helps overcome the natural superiority
16 of humans.
17
18 2)  Once upon a time, if a fighter landed on a carrier, the user
19 was never asked if she wanted to move it again.  I don't know if
20 this bug still exists.
21
22 3)  Satellites are not completely implemented.  When the user
23 moves to a satellite, it should be allowed.  The user should
24 not be asked if she "really wants to attack her own piece".
25 Enemy satelites should not cause the user's pieces to be
26 awoken, since there is nothing the user can do.
27
28 4)  If the computer has a damaged ship and is returning it to
29 port, the user can block the ship with another piece.  The computer
30 will not attempt to move the damaged ship.  The user can then
31 sail up a transport to the city the damaged ship is heading toward,
32 unblock the damaged ship, and as soon as the damaged ship enters
33 port, take the city.  Since ships in port are capturable, the user
34 should now own one slightly damaged ship.
35
36 5)  An assertion failed in 'attack_obj'.  Somehow this routine
37 was passed a location where there was no defending object.  This
38 implies that a view map was messed up.  I've no idea why.
39
40 6)  Currently, a fighter's range is not decremented if it is not
41 moved during a turn.  This could be called a feature, but I think
42 I would really prefer that a fighter's range was decremented by at
43 least one each turn.  The computer does not take advantage of this
44 bug.
45
46 7)  While playing a game, one of my cities was producing armies.
47 At one point in the game, the city sudddenly decided that never
48 again would it increment the build count.  Actually, at one point
49 the build count seemed to be negative.  The count eventually reached
50 zero and stayed there.  My hypothesis is that somewhere I'm trashing
51 my data structures, and somehow the "owner" of the city got set to
52 some incorrect value.
53
54 (Note that bugs (5) and (7) occured while there was an inconsitency
55 in the 'kill_city' routine.  Hardware had its ownership modified,
56 but it remained in the object list of the wrong user.  This
57 could have caused some problems.  So potentially bugs 5 and 7 no
58 longer exist.)
59
60 8)  Movement of armies in "attack" mode seems a little strange.
61
62 9)  Maybe in "sentry" mode, an army should wake up and go into "attack"
63 mode if an invader appears on the continent.  In any event, there
64 should be some mechanism to allow a user to specify that an army
65 should sit on the shore and wait for either a transport to pass by,
66 or for an invader to appear on the continent.
67
68 10)  When setting a city function, the computer should prompt
69 for the various pieces of input.  Even I have a hard time setting
70 functions for cities.
71
72
73 Code Cleanup (Enhancements to improve performance or generality)
74 ----------------------------------------------------------------
75
76 1)  How can we use minicurses?  minicurses is smaller and possibly
77 faster than full blown curses.  The curses routines that I use
78 which are not part of minicurses are 'clrtoeol', 'getstr', and 'getch'.
79 These seem pretty fundamental, but I know very little about curses.
80
81 2)  'vmap_cont' and 'vmap_mark_up_cont' would almost certainly be
82 faster if we didn't recurse, but instead used something like the
83 perimeter lists used in all the other map scanning algorithms.
84 Since 'vmap_mark_up_cont' takes about 10% of the processing time,
85 the performance improvements could be significant.
86
87 3)  The real speed killer is 'expand_perimeter'.  This routine
88 is very generalized, and not all the generality is always needed.
89 It might be better to write multiple non-general routines.  I believe
90 this routine accounts for roughly 20% to 30% of the processing time.
91 If we take subroutines like 'strchr' and 'terrain_type' into account
92 as well, this routine accounts for more like 50% of the processing.
93 However, on a mainframe, the game plays sufficiently fast.
94
95 4)  Allow multiple computer players and/or multiple human players.
96 Allow the players to come in over a network of workstations.
97
98 5)  The width and height of the map should be parameters to the
99 program.
100
101 6)  Interrupts should be caught.  When an interrupt is received,
102 the user should be asked if she really wants to quit, and she
103 should be warned if the game will not be saved.  This is particularly
104 useful when playing over a noisy phone line that generates spurious
105 interrupts.  (When will digitial telephone transmissions arrive?)
106
107 7)  Storage for the various data structures should be allocated
108 dynamically instead of being stored in static tables.
109
110
111 Debugging Aids
112 --------------
113
114 1)  My current debugging algorithm is to put the program into
115 debug mode with the "++" command, and then put the program into
116 movie mode with the "%" command.  When I see something wrong, I
117 hit the interrupt key and restart the program, so that I can
118 use other debugging commands.  It would be nice if this interface
119 was better.  (See comments above about catching interrupts.)
120
121 2)  It would be nice if there were debugging commands which allowed
122 me to examine the computer map and request information such as
123 "What is this city producing?  What objects are in this city? etc."
124 This would be very much like the edit mode "?" command.
125
126
127 Computer Algorithm Enhancements
128 -------------------------------
129
130 1)  What improvements can be made to speed up the acquiring of
131 territory by the computer?
132
133 Note:  As a person, I can acquire about 1/2 the board (and control
134 3/4 of the board) in about 150 turns.
135 The current algorithm seems to be a little bit slower, but within
136 the same order of magnitude.
137
138 Observations:
139
140 I've implemented an algorithm which keeps the computer from exploring
141 every little square of the world it comes across.  Building satellites
142 seems to slow down the computer.  The computer has an algorithm
143 for unloading armies on interesting continents.
144
145 A careful balance seems to be needed between the number of army
146 producing cities and the number of tt producing cities.  Currently,
147 I build a tt as soon as poosible.  On large
148 continents, this is a drawback, as the tt is built before armies
149 are ready to leave.  To counter this effect, I attempted to build
150 more armies in other cities.  This causes an overproduction in
151 armies after the first tt's fill up and head off to find something
152 to dump on.
153
154 Suggestions:
155
156 Various minor improvements might be made in causing tt's to load
157 one or two turns faster, and to unload one or two turns faster.
158 Other improvements would prevent two tt's from heading to the
159 same destination.
160
161 This fix would probably go in 'transport_move' in 'compmove.c'.
162 In this routine, for a loading transport, we would count the
163 number of adjacent loading armies for the current cell, for each reachable
164 cell that is one away, and for each reachable cell that is two away.
165 If there were reachable loading armies, we would move the transport
166 to that square.  Otherwise we would use the current algorithm to
167 find a destination for the transport and move the transport to that
168 destination.
169
170 For unloading transports, things are perhaps slightly more difficult.
171 I think what needs to be done here is, if the transport cannot move
172 along a shortest path towards the destination, then the transport
173 should attempt to move to an adjacent square which minimizes either
174 the row distance between the tt and the objective, or the column
175 distance between the tt and the objective.  For tie-breakers, the
176 tt would move to the cell which touched the most land.
177
178 Possibly I should describe the problems that the above to tweaks
179 would fix.  For loading armies, loading transports prefer moving to
180 staying in place.  Thus, they will sometimes move from a square
181 that touches lots of loading armies, to a square that touches very
182 few loading armies.  This probably increases the load time by one
183 or two turns.
184
185 For unloading tt's, a tt will often be on a diagonal from a city
186 that is an objective.  Unloading armies will hop off one at a time
187 because there is only one land square on a shortest path between the
188 tt and the city.  This particular case wastes about 4 moves.
189
190 2)  The computer's algorithm is optimized for 70% water and
191 a smoothness of 5.  (More accurately, I developed the algorithm
192 using these parameters for all of my testing and debugging.)
193 Potentially the computer algorithm will be extremely poor for
194 other parameter values.  For example, the computer currently
195 builds transports at the first possible opportunity.  Transports
196 would not be very useful on a world with only 10% water.  (Still,
197 there are checks to prevent ships from being built in inappropriate
198 cities, so this may not be too much of a problem.)
199
200 Potentially, the computer should use a more dynamic alogorithm
201 where it "notices" that certain kinds of pieces are going to be
202 need in the near future and then builds these things.  I've no ideas
203 in this area for concrete algorithms, however.
204
205 A plausible alternative would be for the computer to examine the
206 parameters supplied by the user.  If the user knows the parameters,
207 why shouldn't the computer?
208
209 3)  The computer should be willing to land a fighter on a
210 carrier if the carrier can be reached in one turn.
211
212 4)  The computer should "track" user ships.  That is, whenever the
213 computer sees a user ship, it should keep a list of possible locations
214 where that ship could be.  It should then make some attempt to find
215 and destroy the ship.  (See "Search and Destroy" under the user
216 interface comments.)
217
218 This code may be more trouble then its worth.  Currently, it appears
219 that the computer does a very good job of destroying user shipping.
220 The reason for this is that there are good reasons for the user's
221 ships to reappear where ships were previously seen.  Also, the
222 computer tends to amass great amounts of fire power when a ship
223 has been seen, so the computer tends to bump into any other user
224 ship that happens to be in the area.  Also, the user is looking for
225 the computer's ships, and is moving lots of ships into the sealanes
226 that the computer tends to use.
227
228
229 User Interface Enhancements
230 ---------------------------
231
232 1)  In edit mode, it would be nice if it was easier to move around
233 the screen.  (Mouse based approaches where the user points and clicks
234 to say "move this piece to here" would be real nice.)  One idea
235 would be to allow the user to type in four digits that specify the
236 square to move to; or to type in two digits where the first digit
237 is the 10's row, and the second digit is the 10's column.  (Thus,
238 if the user typed "43", the cursor would be moved to location "4030".)
239
240 2)  Small screens should not be redrawn so often.  When moving
241 pieces, we should move everything that is on the current screen
242 (except for stuff that is real close to the edge of the screen,
243 but not the edge of the board).  If necessary, we might redraw
244 the screen as the user moved off the screen.  Or we could allow
245 the user to explicitly tell us to redraw a new sector.  If the
246 screen was redrawn, we would then work on moving pieces that were
247 displayed on the new screen.  In general, we only want to redraw
248 the screen if we absolutely have to.  (This approach would also
249 be real, real useful on terminals that are just a little bit smaller
250 than the complete map.  Using a terminal with something like 105
251 columns will be extremely disconcerting.  The screen will be
252 redrawn for what seems like no reason at all.)
253
254 3)  It is extremely difficult to tell when a satellite has gone
255 by, and when an enemy piece displayed on the screen is current,
256 and when the piece is a ghost.
257
258 One possibility would be to highlight enemy pieces that have just
259 been seen.  Another possibility would be for the user to type
260 a "?" when the cursor is on top of any enemy piece, and the displayed
261 information would be how long ago that piece was seen.  (Also, see
262 search and destroy tracking below.)
263
264 4)  The user should be allowed to "zoom in" and "zoom out".  Zooming
265 in causes the playing board to be printed at four times the density
266 of the previous display density.  Thus, four squares would be
267 drawn as a single square on the screen.  Zooming out undoes the
268 affects of zooming in.  Actually, there should be multiple
269 levels of zooming; 10 levels would probably more than suffice.
270 This enhancement allows the user to easily get a big picture of what
271 is going on.  Most of the time, the user would be able to play
272 with the board zoomed in.  The user might sometimes need to zoom
273 out to navigate a ship through a "river" or an army over an isthmus.
274
275 Currently, there is a command to display a "zoomed" version of the
276 map.  This command prints a compact display of the map that fits on
277 the screen.  This is not quite the same as the above, because what
278 I'm suggesting is that the user be allowed to make moves on a compact
279 display of the map.
280
281 5)  Search and Destroy.  Here is an idea for a sizeable modification
282 to the user interface.
283
284 Basically, we want the computer to keep track of some information
285 for the user.  The information is possible locations of enemy ships.
286 When the user sees a ship on the screen, the computer would start
287 tracking the ship.
288
289 (Tracking would be implemented as follows:  The initial location
290 of the ship would be stored in a perimeter list.  On each round,
291 the perimeter list would be expanded to encompass all cells which
292 the ship could have reached.  Cells that the user has seen this
293 turn are removed from the perimeter list.  After the user's turn,
294 cells that the user has seen are removed from the list again.
295 Problems arise when a tracked ship moves into unexplored territory.)
296
297 Now the user should be able to give various commands.  Commands
298 would be things like:
299
300 "Describe to me all ships you are tracking."  This command would
301 print a list of ships being tracked, the types, the number of
302 possible locations for the ship, the time the ship was first seen,
303 and any code used to represent that ship in tracking displays.
304 Possibly, the likelihood that the ship has been destroyed would
305 be displayed as well.
306
307 "Display possible locations for a ship."  This command would
308 display the possible locations for a ship.  Possible locations
309 might be printed by highlighting the squares where the ship could
310 be.
311
312 "Stop tracking a ship."  This command would delete information about
313 a ship that the user assumed she had destroyed.  Note that the computer
314 will sometimes be able to tell that a tracked ship has been destroyed.
315 The user might also give this command if a ship was presumed to have
316 gotten itself lost.  The computer might also stop tracking a ship if
317 the number of possible locations for the ship gets large.
318
319 To support the above, the user should be able to place fighters
320 and ships in "Search and Destroy" mode.  Here the user would specify
321 a tracked ship that was to be searched for.  The fighters and ships of
322 the user would move in such a way as to minimize the size of the
323 perimeter list for the tracked ship.
324
325 5)  It has been suggested that all pieces at a location be moved
326 at once instead of skipping around the screen in the order the
327 pieces happen to be allocated.  For example, the user is often
328 asked what to do with each of the armies aboard a transport.  If
329 the user knows there are five armies aboard, she may start hitting
330 the 's' key to put those armies to sleep.  If the user isn't paying
331 enough attention, she may discover that she has just put to sleep
332 some piece on a few squares away.
333
334 6)  When moving a ship or army toward a destination, or when
335 moving a ship toward port to be repaired, the user will often
336 want to avoid land that might contain enemy pieces.  This functionality
337 is partially implemented in that ships prefer to be at sea if there
338 is nothing to explore.  Pieces moving towards a destination also
339 prefer to move so that they are in the middle of all the shortest
340 paths to the destination.
341
342 Despite this, it might be desirable to implement a movement mode
343 whereby ships went out of there way to avoid the enemy.
344
345 7)  It should be possible for the user to obtain information about
346 pieces which are contained within another piece.  For example,
347 it would be nice to know the movement function of every ship
348 contained in a city, or of every army on a transport.
349
350 8)  The big problem...  The user needs to type one hell of a lot
351 of commands to control the movement of her pieces.  I've implemented
352 a lot of stuff to alleviate this problem, but lots more can be
353 done.  If we assume that everything is implemented as a "movement
354 function", the following movement functions would be interesting:
355
356 "load army" -- an army moves toward the nearest loading transport
357 or transport producing city.  Note that this is the same algorithm
358 as that used by the computer.
359
360 (For armies, there are really only
361 three functions that are needed:  "attack" (which is implemented)
362 where the army explores a continent and attackes the enemy or
363 unowned cities; "load" where armies leave a continent; and "unload"
364 where armies leave a boat for some other continent.  Also note that
365 when I play the game, most of the commands that I give are commands
366 to move the army to a place where a transport will pick up the army,
367 commands to have the army wait for the transport and load, commands
368 to put the army to sleep while it is being transported, and command
369 to wake up and unload the armies.)
370
371 "load transport" -- the transport is marked as "loading", and the
372 transport moves toward the nearest loading army.
373
374 "unload army" -- I'm not sure what this does, nor what "unload
375 transport" does.  Basically, I want some pseudo-intelligent mechanism
376 for telling the computer not to ask me questions about armies on
377 a transport until that transport reaches "something interesting".
378 "load army" and "load transport" would be much easier to implement.
379 Unloading is where intelligence and strategy can be important.
380
381 "patrol" -- This causes a piece to move so as to decrease the
382 likelihood that an enemy piece can sneak by.  One method of implementing
383 this would be for the piece to move toward the square two away that
384 had been least recently seen.  It might be desirable to constrain
385 a patrolling piece to a relatively small area of the board.
386
387 Note that the "Grope" command (or "explore" mode) is no longer of
388 much use for armies.  Possibly "attack" mode would be useful for
389 ships and fighters.
390
391 9)  One possibility for all of the above might be to allow the
392 user to specify some algorithm that describes how pieces should
393 move.  I've thought along the lines of letting the user specify
394 some sort of macro, and letting the user specify the arguments
395 to one of the 'vmap_find_*obj' routines.  This might require the
396 ability for the user to place arbitrary labels on any square.
397
398
399 Game Modifications
400 ------------------
401
402 1)  Mobile repair platforms.  Currently a damaged boat moves very
403 slowly towards the nearest city.  A floating platform that could move
404 towards damaged boats might be useful.  Also, this little baby would
405 stay out of cities and so not be capturable.  Hits would be 1; strength
406 zero; and speed might be greater than 2.
407
408 2)  Setting transports to have a strength of zero might be interesting.
409
410 3)  Implementing the world as a torus instead of a rectangle might
411 be better.  This means having the map wrap at the edges instead of
412 terminating at the edges.
413
414 4)  Increase the "logistics" aspects of the game.  What about
415 oil, iron, food, etc?  Oil might be used to determine the range
416 of a boat or ship.  Armies might starve without food.  Iron might
417 be necessary for building a ship.
418
419 5)  One of my goals has been to define lots of highly specialized
420 pieces so that each type of piece must be built and used in order
421 to have an effective strategy.  In the original game of empire,
422 I eventually developed a strategy whereby the only pieces I would
423 build were armies and transports.  The computer basically couldn't
424 beat me unless we both started on the same continent and it lucked out.
425 The game also ended within one hundred turns.
426
427 Now, eventually, I might decide that the current program also has
428 the same faults (in which case I'll tweak the computer movement
429 algorithms so that it plays differently).
430
431 However, I have been making changes to increase the specialization
432 of all the pieces.
433
434 Obviously, armies must be built because they are the only pieces that
435 can capture cities.
436
437 Obviously, transports must be built (on worlds that have a reasonable
438 amount of water) because that's the only way an army can be carried
439 to another city.  Since transports don't move all that fast, and
440 since transports are fairly weak, they aren't good for much else
441 (in theory).
442
443 Beyond this...  Patrol boats and fighters are very similar.  Both
444 are fast, both are quickly produced, both have low hits.
445 I suspect that an effective strategy could be developed where one
446 or the other of these pieces, but not necessarily both, were built.
447 Patrol boats have an advantage in their unlimited range.  This makes
448 them useful for extremely long range exploration.  Fighters have
449 an advantage in their great speed.  This makes them extremely useful
450 for tracking and patrolling.  Fighters also have a sufficient range
451 that they can easily move across the board from one city to another
452 without really needing carriers.  Possibly, the range of fighters
453 is too great.  Possibly, the range of fighters should be 16.
454 (For purposes of user friendliness, the range of fighters should be
455 a multiple of the speed.)
456
457 Now, carriers, destroyers, subs, and battleships are very similar.
458 Carriers and battleships have the advantage that they can take a
459 beating and then be reparied.  Destroyers and subs have the advantage
460 that lots of them can be produced which increases the amount of
461 territory that can be seen at any time.
462
463 Decreasing the range of fighters might increase the utility of
464 carriers, but then the user would probably build more patrol boats
465 instead.
466
467 So, I guess I'm looking for more specialized pieces.  Mobile
468 repair platforms are one idea.  Satellites are an attempt at
469 a second idea, but this idea needs more refinement.  Currently,
470 the computer does just fine without building satellites (as near
471 as I can tell).  Maybe satellites would be more useful if they
472 were faster or scanned a larger area.
473
474
475 User Comments
476 -------------
477 > empire is getting very good about asking me about all the troups on a transport,
478 > etc. before going on to another piece, but its still not perfect.
479
480 > the computer still seems to be spending too much effort fighting, and not enough
481 > exploring.  i think i've got it beat, although i'm not sure yet.  i was burning
482 > transport after transport (of the computers) while he tried to take an island
483 > from me.  he finally succeeded, but i must have killed 8 transports in the
484 > process (he got two of mine).
485
486 > early in the game, he had a real superiority with patrol boats, that was giving
487 > me fits.  but now i think i've got him, and am making it very hard for him to
488 > move around.  also, he still hasn't finished taking islands he's colonized--
489 > hopefully i'll be able to take some away from him.  he should have consolidated
490 > them long ago, and being harassing me.
491
492 > The satellite is fun, although i wish it would head into enemy territory
493 > instead of back into mine.
494
495 The first paragraph is a request that all pieces of a type in
496 one position be moved before moving pieces of that type at
497 another position.  This fix should be combined with the needed fix
498 to move all pieces on the screen before redrawing the screen.
499
500 The second paragraph suggests to me that the computer should
501 move lots of patrol boats and other support craft into an area
502 to clear it out before moving in transports.  The transports are
503 too vulnerable, and the computer isn't defending them very well.
504 Maybe what I mean here is that the computer should have a concept
505 of "escorts".  When moving a transport, a destroyer, sub, or at
506 least a patrol boat should try and remain near by.  Then if our
507 transport gets destroyed by an enemy, at least there is some chance
508 that we can kill off the attacker.
509
510 Other problems probably exist in this area as well.  Early in the
511 game, the computer will see an unowned city and drop some armies on
512 it.  A little later the computer will notice that there is a user
513 city on the same continent.  Now, all the computer's transports
514 go floating around that user city and dump armies on it.  The computer
515 has used massive amounts of resources to take a continent instead
516 of exploring and sweeping up more easily defended continents.
517
518 On the other hand, the computer is very "contentious".  It's kind of
519 fun to have the computer fighting so hard to keep me from taking its
520 cities.  Also, if I don't use the current strategy, there is a danger
521 that the computer will not fight hard enough to keep the user from
522 invading and taking a computer-owned continent.
523
524 Colonization...  The computer takes new continents very slowly.
525 I don't know why.  The computer should be producing armies in
526 the first city it takes, and the computer will produce armies
527 in new cities as long as it sees an unowned city to attack.
528 Potentially, there is a problem in that the computer might not
529 see an unowned city, even though there is lots of unexplored territory,
530 and thus probably an unowned city, on the continent.
531
532 The bigger problem seems to be that the computer is producing too
533 many armies and not enough other stuff.  In the particular game that
534 these comments derived from, the computer had a massive continent
535 that was smothered in armies.  Instead of producing so many armies,
536 the computer should have produced more fighters and non-transport
537 ships.  Tweaking the "ration?" arrays in compmove.c should make things
538 better.
539
540 Note that the user's strategy was to seek and destroy transports.
541 The user would ignore other ships for relatively long periods of
542 time for a chance to destroy one of the computer's transports.  This
543 strategy was quite effective; the user tended to be able to keep
544 many more transports on the board than the computer.
545
546 > planes aren't that useful even as they are--sure they're good for zooming
547 > in and destroying the odd troop transport, but they're not that helpful for
548 > exploration.  i still suspect the optimal strategy is armies, transports,
549 > and patrol boats, with a few planes.  Later in the game planes become
550 > useful because they can be gotten to the scene so quickly.   If you want
551 > to reduce them, how about reducing them to 24?   Also, when a plane is
552 > about to fly past the point of no return (return to anything) how about
553 > a question, a la "troops can't walk on water, Sir?".  as long as i can
554 > override the objection, its not a problem.
555
556 > oh, i think it would suffice to be able to launch satellites in a particular
557 > direction.
558
559 The first paragraph is a response to my suggestion that a fighter's
560 range should be reduced to 16 so as to make patrol boats and carriers
561 more useful.
562
563 Maybe we should crank up the hits on the various objects.  This
564 would make attacks a little more deterministic.  For example:
565
566 armies: 2               armies 10
567 transports: 2           transports 10
568 fighters: 2             fighters 10
569 patrol boats: 2         patrol boats 10
570 submarines: 4           submarines 20
571 destoyers: 6            destroyers 30
572 carriers: 10            carriers 80
573 battleships: 12         battleships 100
574
575 But then we would have to worry about repairing armies?  Or maybe
576 the effectiveness of an army simply goes down when it doesn't have
577 full hit points?  This would also greatly increase the repair time
578 of an object.  Or maybe objects would be repaired two or 10 hits
579 per turn.
580
581 Other bugs...
582 -------------
583
584 Possibly displayed messages should be of two types:  Important messages
585 and non-important messages.  After an important message, the computer
586 would delay for the full amount of delay time.  After an unimportant
587 message, it might not do anything.
588
589
590 1)  The "m" and "n" commands should work in movement mode.
591 They should also work when setting the function of a piece
592 for a city.
593
594 2)  Should there be a way to tell the program you are done
595 attempting to move a fighter, and don't ask me about moves
596 seven more times?
597
598 3)  The program should use environment variables or command line
599 arguments to supply the filenames for "empsave.dat" and "empmovie.dat".
600 A command line argument would also be useful for telling the
601 program how often the game should be saved.  Actually, all
602 command line arguments should have associated environment variables
603 that can be used to set defaults.
604
605 4)  When the user types "q" to quit, the program should exit
606 immediately if the game has been saved.  If the game hasn't been
607 saved, the user should be told, and asked if she really wants to
608 quit.