Initial revision

diff --git a/NEWS b/NEWS
new file mode 100644 (file)
index 0000000..cc936b1
--- /dev/null
+++ b/NEWS
@@ -0,0 +1,111 @@
+                       vms-empire news
+
+1.4: Thu Aug  1 14:53:41 EDT 2002
+       Packaging tweaks.  RPM spec fixes.  READ.ME broken up into
+       READ.ME and NEWS.  Obsolete bug notes removed.  Option -f to
+       set savefile added.  I'd like to move the documentation to XML, 
+       but can't yet because db2man doesn't render tables.
+
+1.3: Fri Apr 19 05:13:33 EDT 2002
+       Walt Stoneburner's cleanup patch addressing all compiler errors and 
+       warnings, both in debug and in production mode; works with GCC v3.0.3.
+
+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 up code.
+
+1.1: 1994/12/01 16:07:03 
+       I colorized and speed-tuned this and added a
+       save-interval option. 
+
+The rest of this history is Chuck Simmons's original notes.  Because
+there are so many other Empire games out there now (all descended from
+this one!), I've reverted to the VMS Empire name.
+
+                                       -- 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.
+
+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
+
+       The low-end PCs of 2002 are more powerful than Chuck's 1987 mainframe.
+       Performance tuning isn't the issue it once was. :-)
+
+       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 could be
+       applied much more widely in the code.  If efficiency matters that much
+       to you, maybe you need to get outside more.
+
+Eric S. Raymond
+esr@thyrsus.com
+(home page: //www.tuxedo.org/~esr/)