⟦d1cc54401⟧

TextFile

omega implementor's notes.

PRERELEASE VERSION: 0.71 (beta).

This version is now, in overall structure, more or less the way
the final release version will look. It is still basically
a test version, but most of the bugs from 0.6x are gone,
mainly because the internal architecture was changed, and the
buggy functions had to all be rewritten anyway.... Naturally,
new bugs have taken the place of the old ones. Hopefully
omega is more or less playable now.

Notes on Game Structure:

I'm now keeping track of the last edit in odate.h -- if you hack
omega, you might conceivably want to do the same. The #definition
of LAST_OMEGA_EDIT_DATE is printed by the 'V' command....

Right now the structure of guilds, dungeons, quests, etc. is not
really the way I want it. The player winds up doing basically all the
same things each game, no matter which guild he may be in, because
there is not enough detail to the world of omega. It is a LOT of
painstaking work to sort out threads of narrative structure (such as
for example the beginning attempts I've made with the LawBringer and
the way he interacts with the Circle of Sorcerors and the Order of
Paladins).

Theoretically, one need not do any questing at all to become a Total
Winner (ie, become an adept); this is also not desirable.

There are any number of ways to mechanically "crack" the game, i.e.,
to do something to take advantage of omega for the player's benefit in
some deviant way. At least you can't drop a 32 bit number of negative
gold pieces like in hack.... Anyhow, making sure these loopholes are
filled is a low priority except when they are really blatant; I'd much
rather enhance game play for people who don't cheat....

At the moment I have several goals for the next major version of
omega (0.80):

	* Enhanced game structure -- more dungeons, more detail
	within guilds, pristhoods, etc. that will make the game
	very different for different characters.

	* More player interaction. I still don't intend to have
	omega be an online multiplayer game, but it would be nice
	to have more effect on the game from the actions of 
	previous characters.

	* X and/or NeWS and/or Sunview II front-end(s). It would be nice
	to have a separate inventory window, be able to click destinations,
	have monster and terrain fonts, etc. If I get really
	overexcited, how about a perspective view of the dungeon....

As always, I welcome suggestions. It is very easy to add more monsters,
magic items, magic spells, etc....

Notes on the Code:

As far as I can tell, all this should work on any Unix* system, but
I've never tried it on anything but a Sun-3, not having enough disk
space to my name anywhere else to try.... It uses curses for I/O, and
tries to use as few OS-dependent functions as it can elsewhere. It
should be pretty easy to port to any Unix* variant that has curses.
omega has now been implemented not only on Suns, Vaxen, and Pyramids,
but even on machines such as Amdahls running unix over the normal
operating system. It has also been ported to MS-DOS machines
(send mail to Nathan@xx.lcs.mit.edu for info).

Identifier Convention:
UPPERCASE CONSTANTS are all #defined in odefs.h
Capitalized Globals are all defined in o.c and externally declared in oglob.h
other identifiers are lowercase

I have attempted to keep extremely system-dependent stuff segregated
from the rest of the code.

For example, all screen manipulation functions are in oscr.c, for
those of you who want to port omega to something that doesn't have
curses. (Well, there's a little in ofile.c)

Almost all file manipulation is done in ofile.c, and I have attempted
to keep this simple and consistent.

A few other system calls are in o.c and outil.c, and that's about it.

Unfortunately, commenting is pretty minimal, mostly stupid things like:

  /* this routine shows a monster */
  void showmonster(m)

...and abstruse reminders to myself. As I clean the code up for the
final release version, this will improve. I usually try to avoid
cleverness in my c code, preferring two assignments and an if
statement to a single complex line with three nested conditional
expressions. Still, there are some places where the code is pretty
opaque... sorry about that. Also, I will probably switch over
to ANSI style c pretty soon.

Each module has a short description of its contents at the top, and
mostly functions tend to stay where it is reasonable to find them.
There are a few grab-bag modules, though, such as oaux1, oaux2 and
oaux3 (utility functions for ocom and other modules), oetc (total
grab-bag), and outil (mostly more general utility functions used by
everything).  To save on module size, I have broken a couple of
modules (such as ocom and osite) into pieces. I never got around to
stating precisely which functions that used to be in ocom are now in
ocom1, ocom2, or ocom3, but grep and ^s always work.... Anyhow,
one of these days I will clean up. Really.

oextern.h has all the function declarations. Unfortunately, some of
these are incorrect as to which module the function is contained
in -- I split a number of modules and rearranged others, so
while all the declarations are in fact correct, the comments stating
where things are are sometimes off. I'll get around to fixing things
one of these days. 

odefs.h has all the CPP stuff, structure definitions, and typedefs.

oglob.h has all the external global variable declarations, and
also includes the preceding two header files.

Those of you wishing to port omega to machines without virtual memory
will probably want to keep only one dungeon level in memory at a time;
you ought to be able to use the save_level and restore_level routines
in olev.c to get that working. A lot of memory (primary and
secondary), is currently required to play a full game; you could
probably run for a while with a good deal less, though. However,
you'll need a good deal of disk space if you don't have a lot of
memory; it's just not practicable to play with under several meg of
combined memory and disk space. Actually, I should probably make
up standard #define to save all levels but the current one to disk
as an option (rendering the moria-like lossage of previously entered
dungeons nugatory), but see the previous note about laziness....

KNOWN BUGS AND MISFEATURES: 

	* When you exit to the countryside, there is often one extraneous
	character drawn somewhere on the screen. I have no idea why.

	* Sometimes monsters leave echos behind as they move. This
	occurs sufficiently rarely that I have not yet felt a need
	to rewrite my display code in oscr.c; for some reason it happens
	less when compiled with gcc than with cc.... Actually,
	this problem has hopefully just gone away, but one never knows....

	* It is apparently occasionally possible to juggle two-handed
	weapons so as to either duplicate or destroy an object. For
	some reason this seems to happen to other people than me,
	mostly. I am not sure if it is still possible to do this.

	* There are still some circumstances where the message
	display overwrites a line too fast to read it; there are other
	places where you have to hit the space bar an extra time.
	This is partly due to the fact that I have not fully converted
	to the three-line message display area, and partly due to 
	laziness in tracking down the instances where this occurs.

	* It is occasionally possible to destroy a game on save/restore;
	you save, and on restore you get a core dump signal. Sometimes
	when you save again it goes away; sometimes it doesn't.

	* Sometimes there seems to be an (unintentional) party room
	effect in some rooms in dungeon levels, ie, a bunch of monsters
	are having a party. I am not certain why this happens, but
	I guess it's just another one of the risks the adventurer takes...

	* For some bizarre reason, it is sometimes possible to have
	strange behavior from boots. Some boots will grant permanent
	effects, even when taken off -- this is pretty intermittent.
	7 league boots sometimes just stop working.

	* As far as I know (ha ha), there aren't any core dump bugs
	in actual play at the moment.
	

UNKNOWN BUGS:

There are an awful lot of features and the number of game states you
can get into is very large. In addition, many of the more
"interesting" bugs will probably only occur after long periods of play
since the "higher level" a feature, effect, or state is, the less
it's probably been tested. While I have not encountered any
core-dump bugs recently, there undoubtably are some, not to mention
lesser problems such as hacks to get high scores mechanically,
misfeatures, poor game interface occasions, etc.

I am always anxious to hear about any problems you have had with
omega, be they problems with compilation, gameplay, or whatever.
Suggestions for fixes are always welcome, as are wish-lists for
additional features. The most useful things are new monsters, new
items, and new magical effects, as these can be added without
disrupting existing features.

I hope you enjoy the game.

-Laurence,

			 Laurence R. Brothers
		      brothers@paul.rutgers.edu
            {anywhere}!rutgers!paul.rutgers.edu!brothers
		       "One life -- one arrow."


* Ha, I bet you were expecting some different message. Well, this is not
a commercial document or a public net announcement, so I don't see
why I have to credit Bell Labs or UCB. So there.
DataMuseum.dk

DKUUG/EUUG Conference tapes

⟦d1cc54401⟧ TextFile

Derivation

TextFile
