Next generation of games...
Per Abrahamsen
followups to rec.games.programmer. ]
There is a lot of people who start writing a ``next generation'' rogue
game, but only few (like Laurence R. Brothers) ever get a stable
prototype created. I will assume that you are serious about writing
this game, and not just designing it.
The following is some random comments, partially based on my own
experience from writing a ``next generation'' rogue game.
* It takes more work and time than you think.
I started more than 3 years ago. First version, which is not going to
make people stop playing nethack, will be released Very Soon Now :-|
* You do not need *more* features.
Try to identify the important features, which distinguish your game
from all the other rogue games, and implement only those in the first
version.
* Start implementation early.
If this is the the 117'th AD&D game you write, then you can delay the
implementation until you have finished the design. Otherwise, you will
have to write prototypes in order to find out if
- the work required to implement the feature is worth it?
- the feature can be implemented efficiently?
- the feature works in actual play?
- etc.
* Parties
One player controlling a complete party? Nice idea!
* AD&D
I don't think it is legal to stay to close to AD&D (copyright etc.)
* Light
I like it, but it is expensive. Lots of recalculation each time a
light source is moved or extinguished. Also difficult to get right
when several light sources exists.
* Dungeon Language
It would be nice to be able to use a machine generated dungeon as
well...
-----
Again, you have more than enough exciting ideas yourself. Try to
implement some of the ideas in a prototype first...
--
Per Abrahamsen, ama...@iesd.auc.dk, {...}!uunet!mcvax!dkuug!iesd!amanda
Multi-player NetHack is a myth. -- a fortune cookie.
Neil Gilmore
ama...@iesd.auc.dk (Per Abrahamsen) writes...
>[ The original article appeared in rec.games.hack. I am directing
> followups to rec.games.programmer. ]
(intro deleted)
>* It takes more work and time than you think.
Doesn't it always?
>* You do not need *more* features.
No, you need different features. The similarities between Hack, Rogue,
Moria, Larn et al. are so many that in essence they are the same game.
>Try to identify the important features, which distinguish your game
>from all the other rogue games, and implement only those in the first
>version.
I hope you mean that the distinguishing features are of primary
importance, rather than that such features as movement and combat be
left out. If you don't consider those things to be features, then I
misunderstood.
>* Start implementation early.
>If this is the the 117'th AD&D game you write, then you can delay the
>implementation until you have finished the design. Otherwise, you will
>have to write prototypes in order to find out if
>- the work required to implement the feature is worth it?
>- the feature can be implemented efficiently?
>- the feature works in actual play?
>- etc.
I must strongly disagree here. Always wait until the design is complete
enough before implementation. This will ensure that the system as a
whole can support the features you want. By the time that a complete
design is done, you will know the answers to the first 2 above, and the
third can really only be known by extensive play by other people. I
don't mean necessarily that you must wait until every detail is worked
out to begin coding, although that is the preferred way. If you're the
type who will lose interest in the project because design is boring,
you're probably not the type to do such a large-scale project.
>* Parties
>One player controlling a complete party? Nice idea!
Maybe, but multi-player is much nicer.
>* AD&D
>I don't think it is legal to stay to close to AD&D (copyright etc.)
Not to mention that it is a lousy system which owes its popularity
largely to the fact that it was the first of many. With the resources of
even the meanest computer, a better system could be devised. For
instance, AD&D tables exist because it is tedious for a player to make
calculations, but using proper formulaic calculations on a machine is no
harder than a lookup, and allows for a greater range of results, not to
mention saving space for more useful things.
>* Light
>I like it, but it is expensive. Lots of recalculation each time a
>light source is moved or extinguished. Also difficult to get right
>when several light sources exists.
Yeah, nice, but mostly impractical.
>* Dungeon Language
>It would be nice to be able to use a machine generated dungeon as
>well...
Creating code to write a dungeon in dungeon language shouldn't be too
hard...
>Again, you have more than enough exciting ideas yourself. Try to
>implement some of the ideas in a prototype first...
I seem to have missed the original article, but here are some other
ideas.
No more rectangular rooms.
It is easy, when generating a level, rather than disallowing
overlapping rooms, to allow them to overlap. It takes some more code,
but gives a much more interesting appearance to the level. As soon as I
can get my home machine to convince my work machine it is not a
line-oriented device, I post the method.
Outdoors.
Dungeons are all well and good, but there's more to life than slimy
basements.
Trash the AD&D-like system.
1. Get rid of the ridiculous armor system. From experience, armor
does not make it harder to hit you! Actually, it should become easier.
Armor which absorbs damage is much nicer.
2. Abolish the level system. Use detailed formulas for doing things
using the characters exp.
3. Don't give the numbers on screen. This gives a better feel for
playing a character. If they think,"Oh ho, I didn't used to beat that
monster so quickly before, I must be getting better", I think it would
be an improvement.
4. Get rid of 'You hit, the monster hits, you miss, the monster
misses" kinds of combat systems. Allow for maneuvers or something.
5. Change the magic system. I don't like the present systems, but I
don't have many ideas. Maybe a subset of the Spell Description Language?
6. Don't make the character fight everything. Better NPCs.
>--
>Per Abrahamsen, ama...@iesd.auc.dk, {...}!uunet!mcvax!dkuug!iesd!amanda
>Multi-player NetHack is a myth. -- a fortune cookie.
Not in my crystal ball.
+-----------------------------------------------------------------------+
| Kitakaze Tatsu Raito Neil Gilmore internet:gil...@macc.wisc.edu |
| Jararvellir, MACC, UW-Madison bitnet: gilmore@wiscmac3 |
| Middle Kingdom Madison, Wi |
+-----------------------------------------------------------------------+
Joseph N. Hall
>The following is some random comments, partially based on my own
>experience from writing a ``next generation'' rogue game.
>
>* It takes more work and time than you think.
>* Light
>
>I like it, but it is expensive. Lots of recalculation each time a
>light source is moved or extinguished. Also difficult to get right
>when several light sources exists.
Hmm. MY framework allows multiple moving light sources with varying
radii. LOTS of recalculation is required but you can do some optimizations
that make a big difference.
The critical link is your line-of-sight routine. I don't know how many
of these I've seen written using floating-point arithmetic. Moria, for
example. PC-Moria's slowness is probably 90% due to this. You can
write a simple LOS routine that uses only integer arithmetic; in fact, it's
simpler than the FP version, and it always works.
Another interesting item is that you have to keep track of the direction(s)
from which a wall or other opaque object is illuminated. Otherwise, thin
walls (1 block thick) light up when there's a light behind them ...
v v sssss|| joseph hall || 4116 Brewster Drive
v v s s || j...@ecemwl.ncsu.edu (Internet) || Raleigh, NC 27606
v sss || SP Software/CAD Tool Developer, Mac Hacker and Keyboardist
-----------|| Disclaimer: NCSU may not share my views, but is welcome to.
Per Abrahamsen
[ This is part of a discussion about the Next Generation rogue games ]
Per> [ Implement the distinguishing features first... ]
Neil> I hope you mean that the distinguishing features are of primary
Neil> importance, rather than that such features as movement and combat be
Neil> left out. If you don't consider those things to be features, then I
Neil> misunderstood.
I think we agree on this. It is possible to improve the basic features
like movement and combat, but it is the new features which is going to
make the game the Next Generation.
Per> Start implementation early.
Neil> I must strongly disagree here. Always wait until the design is complete
Neil> enough before implementation.
I guess we disagree about how complete "complete enough" is. There is
a large chance that you get the design wrong unless you test it
(depending on your experience).
[ This probably belong to comp.soft-eng, but they would support Neil :-) ]
Actually, all the large popular unix games (eg. NetHack and Omega) I
know has evolved, rather than being created from scratch.
Neil> If you're the type who will lose interest in the project because
Neil> design is boring, you're probably not the type to do such a
Neil> large-scale project.
Design is fun (all those wonderful features...), but implementation
something when the design is complete is boring. Especially if the
program is large.
Neil> Maybe, but multi-player is much nicer.
And much, much harder...
See the recent discussions in this newsgroup.
Neil> No more rectangular rooms.
Why have rooms at all?
Neil> Outdoors.
Try Omega
Neil> 1. Get rid of the ridiculous armor system. From experience, armor
Neil> does not make it harder to hit you! Actually, it should become easier.
Neil> Armor which absorbs damage is much nicer.
In Omega, heavy armor makes you easier to hit. This is strictly
speaking the correct thing to do, but it does not really work. It
makes all (non-magical) armor about equally useful/useless.
Neil> 2. Abolish the level system. Use detailed formulas for doing things
Neil> using the characters exp.
I find experience levels is easier to use in formulas than experience
point. Some way to show the player that he is making progress is also
needed.
Neil> 3. Don't give the numbers on screen. This gives a better feel for
Neil> playing a character. If they think,"Oh ho, I didn't used to beat that
Neil> monster so quickly before, I must be getting better", I think it would
Neil> be an improvement.
Yes, no numbers. Use English names if you have to. But don't make the
same error as NetHack: about 60 different kinds of weapons. It is
almost impossible to figure out the difference between such a large
number of items, without reading the source.
Neil> 4. Get rid of 'You hit, the monster hits, you miss, the monster
Neil> misses" kinds of combat systems. Allow for maneuvers or something.
Again, Omega tried this. It failed. The usual combat system was much
more playable.
Neil> 6. Don't make the character fight everything. Better NPCs.
Does anyone know any cheap ways to make NPC's appear more intelligent?
It must be efficient, since NPC movement often is the most expensive
part of the game.
Per> Multi-player NetHack is a myth. -- a fortune cookie.
Neil> Not in my crystal ball.
"Multi-player NetHack is a myth", but
"Myth is not multi-player NetHack". Myth is Real!
Joseph N. Hall
>In article <AMANDA.89S...@hilbert.iesd.auc.dk> ama...@iesd.auc.dk (Per Abrahamsen) writes:
>>The following is some random comments, partially based on my own
>>experience from writing a ``next generation'' rogue game.
>>
>>* It takes more work and time than you think.
>>...
>>* Light
>>
>>I like it, but it is expensive. Lots of recalculation each time a
>>light source is moved or extinguished. Also difficult to get right
>>when several light sources exists.
>
>Hmm. MY framework allows multiple moving light sources with varying
>radii. LOTS of recalculation is required but you can do some optimizations
>that make a big difference.
>
>The critical link is your line-of-sight routine. I don't know how many
>of these I've seen written using floating-point arithmetic. Moria, for
>example. PC-Moria's slowness is probably 90% due to this. You can
>write a simple LOS routine that uses only integer arithmetic; in fact, it's
>simpler than the FP version, and it always works.
>
Following up to my own article, imagine that!
I got a few requests for the integer LOS routine yesterday, so
I went home and modified my point-to-point LOS routine for general
consumption. It follows. A few caveats:
This is about as well as you can do point-to-point calculating LOS. There
are no divides, multiplies, etc., in the tight loop. Even a table-based
algorithm will not do the basic iteration that much faster (because of the
overhead involved in your SeeThru() routine).
It is vitally important to use a suitable "clipping" range, and just as
important to make sure that your distance table covers that range fully.
Your program should never rely on repeated calls to any fp routine (e.g.,
sqrt()) if it is to be ported to a normal microcomputer.
This approach is particularly suited to register optimization
(you need about 6 of them), and I'm inclined to think that rewriting it
in assembly language would produce a routine that was, say, a couple of
times faster, allowing for improvement due to reduction of instruction
count, faster addressing modes, etc.
There ARE faster ways to compute visiblity, lighting, etc., "en masse," and
when I get one of these reduced to a digestible form I will probably post
it for your amusement/edification. I expect these to be very fast in their
final forms. Having a room full of monsters carrying around lights with
significant radii (4 or 5), a few static lights in the room, spells of
darkness, etc., should not be a problem even on a lowly Mac Plus or turbo
PC-grade machine. Sure, you have to iterate over many tiles of the floor,
but with the proper approach you don't have to do much work per iteration.
Although the appropriate techniques are tricky, they are not unmanageable.
It would be nice if the moria folks replaced the lousy fp los() with
something similar to this ... don't you think?
Finally, although I checked this code considerably in situ, and somewhat
after I extracted it, there is always the possibility that I screwed it up
somewhere in the process of getting it here. I hope not, but use it with
care at first!
Anyway, here goes ...
---- cut here -----
/*
* los.c
*
* A simple, fast, integer-based line-of-sight algorithm and some useful
* support functions.
*
* By Joseph Hall, 4116 Brewster Drive, Raleigh NC 27606. Email to
* j...@ecemwl.ncsu.edu. As author of this document I have released it
* into the public domain. Please feel free to comment on it and/or
* suggest improvements. If you do so I will try to respond to you
* in a timely manner. Naturally, I make no guarantees as to its
* correctness or suitability for any purpose, although I would hope
* that it is both correct and suitable for something ...
*
* Although it is entirely optional, I would appreciate it if you would
* leave my name attached to this humble hack.
*
*/
#include <stdio.h>
#include <math.h>
#ifndef TRUE
#define TRUE 1
#endif
#ifndef FALSE
#define FALSE 0
#endif
/*
* Table of floor(sqrt(x * x + y * y) + .5). This wastes a null at
* the end of each "string," but it's hard to initialize sensibly
* any other way.
*/
static char *distances[] = {
"\000",
"\001\001",
"\002\002\003",
"\003\003\004\004",
"\004\004\004\005\006",
"\005\005\005\006\006\007",
"\006\006\006\007\007\010\010",
"\007\007\007\010\010\011\011\012",
"\010\010\010\011\011\011\012\013\013",
"\011\011\011\011\012\012\013\013\014\015",
"\012\012\012\012\013\013\014\014\015\015\016",
"\013\013\013\013\014\014\015\015\016\016\017\020",
"\014\014\014\014\015\015\015\016\016\017\020\020\021",
"\015\015\015\015\016\016\016\017\017\020\020\021\022\
\022",
"\016\016\016\016\017\017\017\020\020\021\021\022\022\
\023\024",
"\017\017\017\017\020\020\020\021\021\021\022\023\023\
\024\025\025",
"\020\020\020\020\020\021\021\021\022\022\023\023\024\
\025\025\026\027",
"\021\021\021\021\021\022\022\022\023\023\024\024\025\
\025\026\027\027\030",
"\022\022\022\022\022\023\023\023\024\024\025\025\026\
\026\027\027\030\031\031",
"\023\023\023\023\023\024\024\024\025\025\025\026\026\
\027\030\030\031\031\032\033",
"\024\024\024\024\024\025\025\025\026\026\026\027\027\
\030\030\031\032\032\033\034\034",
"\025\025\025\025\025\026\026\026\026\027\027\030\030\
\031\031\032\032\033\034\034\035\036",
"\026\026\026\026\026\027\027\027\027\030\030\031\031\
\032\032\033\033\034\034\035\036\036\037",
"\027\027\027\027\027\030\030\030\030\031\031\031\032\
\032\033\033\034\035\035\036\036\037\040\041",
"\030\030\030\030\030\031\031\031\031\032\032\032\033\
\033\034\034\035\035\036\037\037\040\041\041\042",
"\031\031\031\031\031\031\032\032\032\033\033\033\034\
\034\035\035\036\036\037\037\040\041\041\042\043\043"
};
/*
* IntHypot--
* Returns floor(sqrt(x * x + y * y) + .5). Uses a table for
* x and y <= 25 for best speed.
*/
int IntHypot(dx, dy)
register int dx, dy;
{
register int tmp;
/*
* Take the absolute values of the arguments.
*/
dx = (dx < 0) ? -dx : dx;
dy = (dy < 0) ? -dy : dy;
/*
* Since the distance table is symmetric, save space by requiring
* that dx >= dy.
*/
if (dx < dy) {
tmp = dy;
dx = dy;
dy = tmp;
}
/*
* Use the table if dx is small enough; otherwise (groan) use
* the math library.
*/
if (dx <= 25)
return distances[dx][dy];
else
return (int) floor(sqrt((double)(dx * dx + dy * dy)) + .5);
}
/*
* InRange--
* Returns TRUE if floor(sqrt((x1 - x0)^2 + (y1 - y0)^2) + .5)
* <= range
*/
int InRange(x0, y0, x1, y1, range)
int x0, y0, x1, y1;
register int range;
{
register int dx, dy;
dx = x1 - x0;
dx = (dx < 0) ? -dx : dx;
dy = y1 - y0;
dy = (dy < 0) ? -dy : dy;
if ((dx <= range) && (dy <= range) && (IntHypot(dx, dy) <= range))
return TRUE;
else
return FALSE;
}
/*
* SeeThru--
* Dummy function in this case. Ordinarily, returns TRUE if
* the tile [x, y] is transparent, FALSE if it's opaque. This is
* frequently called and should be a macro, and a fast one at that.
*/
int SeeThru(x, y)
int x, y;
{
printf("[%02d, %02d]\t", x, y);
return TRUE;
}
/*
* LOS--
* Returns TRUE if InRange(x0, y0, x1, y1, range) AND a line of sight
* can be traced from x0, y0 to x1, y1.
*
* The LOS begins at the center of the tile [x0, y0] and ends at
* the center of the tile [x1, y1]. If LOS() is to return TRUE, all of
* the tiles this line passes through must be transparent, WITH THE
* EXCEPTIONS of the starting and ending tiles. A tile at [x, y] is
* transparent if SeeThru(x, y) = TRUE.
*
* We don't consider the line to be "passing through" a tile if
* it only passes across one corner of that tile.
*/
int LOS(fromX, fromY, toX, toY, range)
int fromX, fromY, toX, toY, range;
{
char stepX;
int tmp, /* for swapping */
deltaX = toX - fromX,
deltaY = toY - fromY;
deltaX = toX - fromX;
deltaY = toY - fromY;
/*
* Out of range?
*/
if (!InRange(fromX, fromY, toX, toY, range))
return(FALSE);
/*
* Adjacent?
*/
if ((deltaX < 2) && (deltaX > -2) && (deltaY < 2) && (deltaY > -2))
return TRUE;
/*
* Handle the cases where deltaX or deltaY == 0.
*/
if (deltaX == 0) {
register int py; /* y position -- loop variable */
if (deltaY < 0) {
tmp = fromY;
fromY = toY;
toY = tmp;
}
for (py = fromY + 1; py < toY; py++)
if (!SeeThru(fromX, py))
return FALSE;
return TRUE;
} else if (deltaY == 0) {
register int px; /* x position -- loop variable */
if (deltaX < 0) {
tmp = fromX;
fromX = toX;
toX = tmp;
}
for (px = fromX + 1; px < toX; px++)
if (!SeeThru(px, fromY))
return FALSE;
return TRUE;
}
/*
* Now, we've eliminated all the degenerate cases.
*
* In the computations below, dy (or dx) and m are multiplied by a
* scale factor, scale = abs(deltaX * deltaY * 2), so that we can use
* integer arithmetic.
*/
{
register int px, /* x position */
py, /* y position */
scale2; /* above scale factor / 2 */
int scale, /* above scale factor */
xSign, /* sign of deltaX */
ySign, /* sign of deltaY */
m; /* slope or 1/slope of LOS */
scale2 = abs(deltaX * deltaY);
scale = scale2 << 1;
xSign = (deltaX < 0) ? -1 : 1;
ySign = (deltaY < 0) ? -1 : 1;
/*
* Travel from one end of the line to the other, oriented along
* the longer axis.
*/
if (abs(deltaX) >= abs(deltaY)) {
register int dy; /* "fractional" y position */
/*
* We start at the border between the first and second tiles,
* where the y offset = .5 * slope. Remember the scale
* factor. We have:
*
* m = deltaY / deltaX * 2 * (deltaY * deltaX)
* = 2 * deltaY * deltaY.
*/
dy = deltaY * deltaY;
m = dy << 1;
px = fromX + xSign;
/*
* Consider the special case where slope == 1.
*/
if (dy == scale2) {
py = fromY + ySign;
dy -= scale;
} else {
py = fromY;
}
while (toX - px) {
if (!SeeThru(px, py))
return FALSE;
dy += m;
if (dy < scale2) {
px += xSign;
} else if (dy > scale2) {
py += ySign;
if (!SeeThru(px, py))
return FALSE;
px += xSign;
dy -= scale;
} else {
/*
* This is the case, dy == scale2, where the LOS
* exactly meets the corner of a tile.
*/
px += xSign;
py += ySign;
dy -= scale;
}
}
return TRUE;
} else {
register int dx; /* "fractional" x position */
dx = deltaX * deltaX;
m = dx << 1;
py = fromY + ySign;
if (dx == scale2) {
px = fromX + xSign;
dx -= scale;
} else {
px = fromX;
}
while (toY - py) {
if (!SeeThru(px, py))
return FALSE;
dx += m;
if (dx < scale2) {
py += ySign;
} else if (dx > scale2) {
px += xSign;
if (!SeeThru(px, py))
return FALSE;
py += ySign;
dx -= scale;
} else {
px += xSign;
py += ySign;
dx -= scale;
}
}
return TRUE;
}
}
/*
* Shouldn't be here!
*/
return TRUE;
}
main()
{
int x0, y0, x1, y1;
printf("Enter starting coordinates: ");
scanf("%d %d", &x0, &y0);
printf("Enter ending coordinates: ");
scanf("%d %d", &x1, &y1);
printf("SeeThru tests these tiles: \n");
LOS(x0, y0, x1, y1, 20);
printf("\nDone...\n");
}
--- cut here ---
Joseph N. Hall
[ This is part of a discussion about the Next Generation rogue games ]
Per> [ Implement the distinguishing features first... ]
Neil> I hope you mean that the distinguishing features are of primary
Neil> importance, rather than that such features as movement and combat be
Neil> left out. If you don't consider those things to be features, then I
Neil> misunderstood.
game-writers concentrate intensely on the "features" of games and not at
all on the underlying implementation issues.
I think we agree on this. It is possible to improve the basic features
like movement and combat, but it is the new features which is going to
make the game the Next Generation.
Like a decent internal structure. The current crop of games are abominations.
A notable exception is xconq. Half to a quarter the size of, say, moria or
hack, but vastly more versatile, and certainly more expandable.
Per> Start implementation early.
Neil> I must strongly disagree here. Always wait until the design is complete
Neil> enough before implementation.
I guess we disagree about how complete "complete enough" is. There is
a large chance that you get the design wrong unless you test it
(depending on your experience).
Rapid prototyping is essential to good game design, especially when there
are speed concerns, and also when there are structural concerns. But it's
also important to THROW AWAY THE CODE THAT DOESN'T WORK.
Actually, all the large popular unix games (eg. NetHack and Omega) I
know has evolved, rather than being created from scratch.
Mutated, or metastasized, is a term I prefer to "evolved." If animals
evolved like NetHack and Omega we'd probably have (for example) one eye for
each type of thing we were able to see.
Neil> If you're the type who will lose interest in the project because
Neil> design is boring, you're probably not the type to do such a
Neil> large-scale project.
Design is fun (all those wonderful features...), but implementation
something when the design is complete is boring. Especially if the
program is large.
Yeah, maybe this is why the source code to all of these games looks like it
was written by someone who a) was bored and b) couldn't wait to implement a
new feature and play with it.
Neil> Maybe, but multi-player is much nicer.
And much, much harder...
See the recent discussions in this newsgroup.
Multi-player doesn't make sense in the conventional context of rogue-like
games, which don't operate in realtime. Gauntlet is one example of a
successful multi-player game in realtime. Xconq, netwars, etc., are
examples of successful turn-oriented, strategic multi-player games. The
question is NOT whether hack could be made a multiplayer game (it can, and
the result would be garbage), but what kind of game LIKE Hack could function
successfully as a multiplayer game. Personally, I'd rather play it alone
against more intelligent critters and NPCs.
Neil> No more rectangular rooms.
Why have rooms at all?
Well, you need rooms in order to provide specialized contexts for player
actions. This hasn't been exploited much by the rogue-like games, but is
a key feature of text adventure games. There are huge possibilities in this
area and most of them aren't too hard to implement.
As for the shape of rooms, well, I doubt it makes much difference what
shape they are. The simplest thing to do is to have the program generate
a few standard layouts (say, rectangular rooms, maze levels/rooms,
irregularly shaped caverns), and then add a provision for separately-defined
special rooms (a la xconq, omega, and to some extent NetHack 3.0).
Neil> Outdoors.
Try Omega
Nice concept, fair game, poor implementation.
Neil> 1. Get rid of the ridiculous armor system. From experience, armor
Neil> does not make it harder to hit you! Actually, it should become easier.
Neil> Armor which absorbs damage is much nicer.
It should be obvious that there is a difference between "hitting your armor"
and "hitting you." A game should define what a "hit" is and stick with it.
Neil> 2. Abolish the level system. Use detailed formulas for doing things
Neil> using the characters exp.
I find experience levels is easier to use in formulas than experience
point. Some way to show the player that he is making progress is also
needed.
Agreed. I prefer being able to know whether or not I can stand up to a
particular opponent. With weird, continuous formulas it isn't always
easy to guess.
Neil> 3. Don't give the numbers on screen. This gives a better feel for
Neil> playing a character. If they think,"Oh ho, I didn't used to beat that
Neil> monster so quickly before, I must be getting better", I think it would
Neil> be an improvement.
Yes, no numbers. Use English names if you have to. But don't make the
same error as NetHack: about 60 different kinds of weapons. It is
almost impossible to figure out the difference between such a large
number of items, without reading the source.
No, I strongly disagree here. THE PLAYER SHOULD NOT BE DEPRIVED OF USEFUL,
CRITICAL INFORMATION SIMPLY TO MAKE THE GAME HARDER or more "realistic."
This is incredibly irritating to me. Those of us who work for a living,
for example, like to know what our position is and how much we are being
paid. What if you weren't told? What if you weren't told how much money
you had in the bank? How much credit you had? How much weight you could
lift? By the same token, I think that players should not have to discover
many features of monsters by peeking through the source code. The number
of hit dice (or a close approximation), for example.
Make the game challenging and enjoyable by improving it strategically, not
by forcing your players to drag around a ball and chain while wearing
a blindfold (although this are two of my favorite NetHack features, in
a different context :-)).
Neil> 4. Get rid of 'You hit, the monster hits, you miss, the monster
Neil> misses" kinds of combat systems. Allow for maneuvers or something.
Again, Omega tried this. It failed. The usual combat system was much
more playable.
I agree; overly-verbose combat isn't worthwhile in a rogue-like game.
How many of you have used the real hand-to-hand combat rules in AD&D?
Uh huh. Sure.
Neil> 6. Don't make the character fight everything. Better NPCs.
Does anyone know any cheap ways to make NPC's appear more intelligent?
It must be efficient, since NPC movement often is the most expensive
part of the game.
There are no "cheap" ways. Good NPC and critter behavior is difficult to
implement -- almost impossible in the "synchronous", big-loop programming
model of NetHack and Moria, and fraught with bugs when written in that
environment. Has anyone ever thought to write an event-driven core for
a rogue-like game? With a queue, asynchronous execution, and a little
OOP thrown in? Gosh ...
Per> Multi-player NetHack is a myth. -- a fortune cookie.
Neil> Not in my crystal ball.
Well, it'll probably come to pass, but it won't be much fun it's really a
different game in its multi-player incarnation.
Chuq Von Rospach
>Personally, i think it's interesting how the vast majority of prospective
>game-writers concentrate intensely on the "features" of games and not at
>all on the underlying implementation issues.
I don't care how well it's written. If it's a boring game, nobody will play
it. Internal structure (and I agree, many games are really hacks internally)
is important, but a beautifully written failure is a beautifully written
failure.
>Rapid prototyping is essential to good game design, especially when there
>are speed concerns, and also when there are structural concerns. But it's
>also important to THROW AWAY THE CODE THAT DOESN'T WORK.
Definitely. Computer games should be playtested just like real games are.
When you have something set up, get the code ready and try it out. You may
well find out it doesn't work like you envisioned -- and you have time to
rethink it or fix it before it's too late.
On the other hand, don't start prototyping and believe you can design the
game at the keyboard. down that road lays disaster.
> Neil> No more rectangular rooms.
> Why have rooms at all?
>Well, you need rooms in order to provide specialized contexts for player
>actions. This hasn't been exploited much by the rogue-like games, but is
>a key feature of text adventure games. There are huge possibilities in this
>area and most of them aren't too hard to implement.
Well, I've been hacking on a rogue-like game for the Mac. The idea is to get
the flavor of rogue into a mac-atmosphere. I've got a prototype dungeon
floor up with no rooms, and while I thought it was a good idea, it's not
working. So I'm going to go and make irregular shaped rooms with
passageways. I'm definitely not going to go as far as the "let's see how
cluttered we can make it" style as Nethack, but if nothing else, it keeps
all 50 monsters on the floor from coming and stomping on you all at once.
>As for the shape of rooms, well, I doubt it makes much difference what
>shape they are.
Actually, it does. regular shaped rooms are trivial to explore, and don't
give monsters (and things) nooks and crannies to hide in.
> Neil> 2. Abolish the level system. Use detailed formulas for doing things
> Neil> using the characters exp.
>
> I find experience levels is easier to use in formulas than experience
> point. Some way to show the player that he is making progress is also
> needed.
>
>Agreed. I prefer being able to know whether or not I can stand up to a
>particular opponent. With weird, continuous formulas it isn't always
>easy to guess.
Levels are nice. I'd suggest enforcing the original idea of D&D, though --
you don't *get* the level until you complete your studies, no matter what
your XP says. You want level five, you go back to the town and pay the
tutor. Then you get the HP and spells.
> Neil> 3. Don't give the numbers on screen.
>No, I strongly disagree here. THE PLAYER SHOULD NOT BE DEPRIVED OF USEFUL,
>CRITICAL INFORMATION SIMPLY TO MAKE THE GAME HARDER or more "realistic."
Not giving numbers doesn't imply not giving the player information they
need. It just implies coming up with a way of giving them that information
in context of the game. "Wow, I'm a level 4 mage" is easy. "Wow, I just hit
journeyman necromancer" is period. The same can be done for everything with
some though, including hit points and XP.
--
Chuq Von Rospach <+> Editor,OtherRealms <+> Member SFWA/ASFA
ch...@apple.com <+> CI$: 73317,635 <+> AppleLink: CHUQ
[This is myself speaking. No company can contr
Segmentation Fault. Core dumped.
Christopher T. Dodd
>Your program should never rely on repeated calls to any fp routine (e.g.,
>sqrt()) if it is to be ported to a normal microcomputer.
... and then he goes on to use fp sqrt in his routine.
For game purposes, it should never be necessary to resort to fp
routines. Tables are good if they aren't too big, but for something
like sqrt, they aren't really practacal. The below isqrt function is
very fast, unless you deal with very large integers. On a micro with no
fp support, this is definitely the sort of thing you want to use.
Chris Dodd
do...@neon.stanford.edu
--------------------cut here---------------cut here------------------
/*
** Integer square root function -- isqrt(n) calculates
** the square root of n to the nearest integer. Equal
** to (int)floor(sqrt((double)n)+0.5)
** returns 0 if n is negative
** requires O(sqrt(n)) time, so for numbers larger than
** 1000000 or so it may be faster to use fp routines...
**
** Written by Chris Dodd
*/
isqrt(n)
register int n;
{
register int s,t;
s = t = 0;
while (n>0) {
s++;
t += 2;
n -= t; }
return(s);
}
Keith Hanlan
>In article <AMANDA.89S...@hilbert.iesd.auc.dk>,
>ama...@iesd.auc.dk (Per Abrahamsen) writes...
>>implementation until you have finished the design. Otherwise, you will
>>have to write prototypes in order to find out if
>
>>- the work required to implement the feature is worth it?
>>- the feature can be implemented efficiently?
>>- the feature works in actual play?
>>- etc.
>I must strongly disagree here. Always wait until the design is complete
>enough before implementation. This will ensure that the system as a
>whole can support the features you want. By the time that a complete
>design is done, you will know the answers to the first 2 above, and the
>third can really only be known by extensive play by other people.
that has lots of man-machine-interaction is better built (evolved)
using an interative prototyping approach. You'll find supporting
arguments in CACM and appropriate SIGs. The 'spec-first' approach
has been demonstrably unsatisfactory in most large software projects
of the last 15 years.
>Maybe, but multi-player is much nicer.
Do you really think so? I can't imagine when I'm going to be able to
find people to play with. It my friends have leisure time at the
same time as I do, I suspect that we would not collectively agree to
spend this time on the computer.
Besides: how would it work? Do you want to accidently meet a
Real-Person monster and be unable to continue because the person
playing that monster can't play right now? Is the game real-time or
turn-time? I think a solo game is still much better 99% of the time.
>AD&D
>With the resources of
>even the meanest computer, a better system could be devised. For
>instance, AD&D tables exist because it is tedious for a player to make
>calculations, but using proper formulaic calculations on a machine is no
>harder than a lookup, and allows for a greater range of results, not to
>mention saving space for more useful things.
See my earlier posting...
>No more rectangular rooms.
> It is easy, when generating a level, rather than disallowing
>overlapping rooms, to allow them to overlap. It takes some more code,
>but gives a much more interesting appearance to the level. As soon as I
>can get my home machine to convince my work machine it is not a
>line-oriented device, I post the method.
I agree that more interesting floor-plans are a Big-Bang-For-Buck
improvement.
Later...
Neil Gilmore
>In article <AMANDA.89S...@hilbert.iesd.auc.dk> ama...@iesd.auc.dk (Per Abrahamsen) writes:
>>* Light
>>I like it, but it is expensive. Lots of recalculation each time a
>>light source is moved or extinguished. Also difficult to get right
>>when several light sources exists.
>Hmm. MY framework allows multiple moving light sources with varying
>radii. LOTS of recalculation is required but you can do some optimizations
>that make a big difference.
>The critical link is your line-of-sight routine. I don't know how many
>of these I've seen written using floating-point arithmetic. Moria, for
>example. PC-Moria's slowness is probably 90% due to this. You can
>write a simple LOS routine that uses only integer arithmetic; in fact, it's
>simpler than the FP version, and it always works.
So don't keep us in the dark about it!
(tell us how)
>v v sssss|| joseph hall || 4116 Brewster Drive
> v v s s || j...@ecemwl.ncsu.edu (Internet) || Raleigh, NC 27606
> v sss || SP Software/CAD Tool Developer, Mac Hacker and Keyboardist
>-----------|| Disclaimer: NCSU may not share my views, but is welcome to.
+-----------------------------------------------------------------------+
| Kitakaze Tatsu Raito Neil Gilmore internet:gil...@macc.wisc.edu |
| Jararvellir, MACC, UW-Madison bitnet: gilmore@wiscmac3 |
| Middle Kingdom Madison, Wi |
+-----------------------------------------------------------------------+
(filler following)
John J. Feiler
'Nuff said.
==============
John Feiler "Life's like a jigsaw, you get the
709 Locust #7 straight bits, but there's something
Pasadena, CA 91101 missing in the middle..."
jjfe...@tybalt.caltech.edu -- XTC
What's the difference between a duck?
==============
Felix Lee
Joseph N. Hall <j...@ecemwl.UUCP> writes:
> Has anyone ever thought to write an event-driven core for a
> rogue-like game? With a queue, asynchronous execution, and a little
> OOP thrown in? Gosh ...
I have, a good deal. You really need garbage collection. Unless you
cripple the internal structure. Concurrency would be nice too, but
that's easier to fudge. Anyone want to suggest the Right Language?
--
Felix Lee fl...@shire.cs.psu.edu *!psuvax1!flee
Jon W{tte
>Has anyone ever thought to write an event-driven core for a rogue-like game?
In article <FLEE.89Se...@shire.cs.psu.edu> fl...@shire.cs.psu.edu (Felix Lee) writes:
> Anyone want to suggest the Right Language?
How about IBM/360 assembler ? ;')
--
You're at the end of the road again.
Joseph N. Hall
>In article <39...@ncsuvx.ncsu.edu> j...@ecemwl.UUCP (Joseph N. Hall) writes:
>>Your program should never rely on repeated calls to any fp routine (e.g.,
>>sqrt()) if it is to be ported to a normal microcomputer.
>
>... and then he goes on to use fp sqrt in his routine.
>
per turn or less), yes.
I'll agree that replacing the last-resort call to sqrt with an integer
sqrt routine (like yours) is a good idea. In my application it doesn't
matter ...
Norman Ramsey
> Joseph N. Hall <j...@ecemwl.UUCP> writes:
>> Has anyone ever thought to write an event-driven core for a
>> rogue-like game? With a queue, asynchronous execution, and a little
>> OOP thrown in? Gosh ...
>
>I have, a good deal. You really need garbage collection. Unless you
>cripple the internal structure. Concurrency would be nice too, but
>that's easier to fudge. Anyone want to suggest the Right Language?
The right language is the SML of New Jersey implementation of Standard ML.
This gives you garbage collection, polymorphism, and
pseudo-concurrency (i.e. simulation of concurrency on a sequential
machine). Objects are communications channels (or sets of channels);
when you want an object to do something to send a message on the
channel.
Norman Ramsey
n...@princeton.edu
Keith Hanlan
>The truth is, plain and simple, that I am in the process
>of designing a game much like our favorites (NetHack, Moria, Omega, etc.).
>I am basing the game on the older editions of AD&D texts, ...
I have a few suggestions:
o Don't base it on AD&D. D&D deficiencies exist largely to
reduce complexity. There are many other systems with much
more flexible and 'realistic' combat. Many of them would
be much more appropriate for a computer - take advantage of
them. I'd recommend I.C.E.'s Rolemaster or Rune-Quest.
The most important characteristic of these systems is that
they are skill-based - not just class/attribute-based. This
allows players to improve the skills that they exercise.
Instead of orienting everything to a single skill - combat -
allow the user to train separate skills like:
o one-handed sword
o two-handed weapon
o pole-arms
o missile weapons
o thrown weapons
o unarmed combat
o manoevering in light armour
o manoevering in heavy armour
o listening
o climbing
o swimming
o trap-detection
o disarming traps
o picking locks
o various classes of magic skills
You get the idea.
o If you want the code to be freely distributed and a 'group'
project - set coding standards - and comment the damn stuff.
Nethack is a mess.
o Don't design it for the least capable target platform
(assuming that you want it to be portable.) Pick a
moderately sophisticated platform; it will be tomorrow's
basic machine.
o In the same vein, make sure that you separate the
user-interface layer so that you can provide a better UI
for suitable machines. At a minimum plan for curses and X11
displays.
o Do not distinguish between monsters and the player (as in
nethack). Write all your action code to handle both - this
will save you a lot of code.
I'd like to hear how your project progresses. Good luck.
Mr P Johnson Baddow
> I have, a good deal. You really need garbage collection. Unless you
> cripple the internal structure. Concurrency would be nice too, but
> that's easier to fudge. Anyone want to suggest the Right Language?
When I first came to GEC I learned (amongst other things) a language named
"CONIC", an experimental language from Imperial College, London. This is
Pascal with real-time multi-tasking and distributed system support: message
primitives can be used to send either local messages within a process or
UNIX IPC messages.
To learn this language, I wrote a small game based on Essex Uni. MUD. It
worked and had reasonable performance. Unfortunately it did not have
inheritance and so every object had to be written from scratch.
When I learned C++, I wrote a set of classes to emulate the CONIC messaging
and timer primitives. If I were to write a MUG today, this is what I would
use.
Unfortunately I cannot post any of this as it is all GEC copyright.
--
Paul Johnson, | `The moving finger writes, And having writ, moves on,'
GEC-Marconi Research | Omar Kyham when contemplating `vi'.
------------------------------------------------------------------------------
The company has put a radio inside my head: it controls everything I say!