rec.games.roguelike.development FAQ
Ray Dillinger
rec.games.roguelike.development FAQ
Administrivia:
rec.games.roguelike.development is an unmoderated newsgroup.
Anybody has the right to post anything there, although it is
widely agreed that only losers spam, post offtopic, crosspost
excessively, add hundred-line signatures to their posts, or
become directly abusive and insulting to other non-loser
posters on the newsgroup.
If you disagree with anything in this FAQ, or think that
something ought to be added, removed, or changed, you are
free to reply to it saying so, and the maintainer is free to
create a new version either heeding or ignoring your
suggestions. Although the maintainer agrees that if the
maintainer of a FAQ for a newsgroup ignores the opinions of
the majority of posters on the newsgroup then that
maintainer is a loser, there is no formal process for
resolution of these issues in place.
Furthermore, the maintenance of this FAQ, or any other for
this group, is strictly a volunteer effort; if you want to
create a different FAQ, by all means do so. It'll be just
as official as this one, which is to say ... not at all.
1. What is a roguelike game?
You may figure there's no point in having this question
in the FAQ, since after all everybody knows what a
roguelike game is or they wouldn't be here. But even
though "everybody knows", most of them don't agree. So,
while you "know" what a roguelike game is, don't expect
everyone else to share your opinion.
The original Rogue, by Michael Toy and Glenn Watchman,
was a game made for UNIX systems in 1980, designed to
be played using the keyboard only (mice weren't around
yet) on a text-mode screen (windowing systems and
graphical user interfaces weren't around yet either).
It was a dungeon exploration and combat game, where
the player character was represented by an '@' and
various kinds of monsters by alphabetic characters.
They interacted in "The Dungeons of Doom" -- a randomly
generated map represented by ascii characters on the
screen -- and various treasures were scattered about
the dungeon for the player to find.
One of these, the Amulet of Yendor, was special; to
retrieve the Amulet of Yendor successfully was to win
the game.
"Roguelike games" are games that are like Rogue, in
whatever ways the designer of the particular game
feels are important. But different designers disagree
about what is important, and Rogue itself was spartan
compared to most current roguelikes. Some of the
"important features" that most roguelike games preserve
are:
1A. Roguelike games are designed to be replayed a lot.
The assumption behind the interfaces of roguelike
games is that most games will be played by people
who have played many times before. This drives
most of the other decisions that typify the genre,
such as...
1B. Randomized dungeons. A game would be no fun if
you knew the map of the dungeon in advance, so
replayability demands that the dungeons and mazes
(and treasures) be generated new for each game.
1C. Permanent death. In most roguelike games, when
you die, the game is over. The game is designed for
replay, and the assumption is that when you die
you'll start a replay.
1D. Keyboard Interface. Now there are mice, and many
roguelike games use them. But the keyboard is still
faster and easier when you have taken the time to
learn the keyboard interface, and I know of no
roguelike games that *require* the user to ever
touch the mouse.
1E. Character Display. Most roguelike games can be played
on a telnet or SSH connection using a character display.
We have graphics now, and most of the "leading"
roguelikes offer one or more graphical interfaces,
such as a 2D tiled interface or a pseudo-3d isometric
interface. But lots of players, and lots of game
designers, still prefer character displays.
1F. Roguelike games are really really hard to win. They're
designed to be replayed by people who have played them
a thousand times before and still be challenging to those
people. It's not surprising that to beginners they seem
impossible.
2. Permanent death is stupid! Why shouldn't I let players
save and restore?
No reason. After all, it's your game. You do what you
need done for your game. Proponents of permanent death
say there's greater player involvement with the
characters, and that they like the ability to have
surprises and mysteries that people encounter when
they play better than they've ever played before, and
that they like the ability to have "meaningful"
tournaments and highscore lists, and several other
benefits.
3. Save and restore is stupid! Why shouldn't players who
die stay dead?
No reason. After all, it's your game. You do what you
need done for your game. Opponents of permanent death
say they get bored playing the first few levels over
and over again, they want players to be able to experience
everything in their game even if the players aren't very
good, they're afraid of losing players' interest if they
require them to repeat the early levels every time they
die, they don't expect the game to be used with a common
highscore file or in tournaments, all modern games have
save and restore, players want save and restore, and
that allowing save and restore is the only practical
way to prevent savescumming.
4. What is savescumming?
Savescumming is when someone cheats by saving a game,
continuing to play until they die, then restoring the
saved game even though the rules do not allow this use
of save and restore. Savescumming is cheating. If
the rules of the game do allow this use of save and
restore, then by definition it isn't cheating, and
therefore isn't scumming.
5. How do players savescum?
Typically, they abuse a "save" feature that is supposed
to allow them to restore after a program crash or to
continue an unfinished game later. They save a game
and continue playing, then make a copy of the saved
game. When the character dies, the system erases the
saved game, but they restore it from their copy and
reload it.
6. How can I prevent savescumming?
There are only two ways: First, you can allow restoring
saved games after death.
Second, you can avoid storing the saved game, the game
saving code, the game restoring code, or the binary
image of your running program with the game data, on
the scummer's machine and either distribute a
specialized network client instead of the actual game,
or let people play by SSH, telnet, or remote Xwindows
and have the game itself actually run only on machines
that you own.
These are the *ONLY* ways to absolutely prevent a
sufficiently determined and sophisticated loser from
savescumming your game.
Most roguelike designers agree that neither way is
worth it.
7. How can I make savescumming hard?
The usual method of expressing the "no save and restore
after death" rule is to have your program delete the
saved game file (or mark it ineligible for the highscore
list) the instant the player character dies.
You can make savescumming somewhat harder by having the
program remember (in some other file) some identifying
features of the "killed" savefile, and reject that
savefile if someone attempts to load it again. A
determined loser can circumvent this by finding the
other file and saving/ restoring it too.
You can make savescumming harder (on UNIX systems) by
having the game run SUID as its own user, where the
player doesn't have read access to the savefiles but the
game does. A determined loser can circumvent this by
being root.
You can make savescumming hard by not having a save and
restore feature in your code. Players who exit the
program before the game is finished, in this scheme,
simply lose their games. This is impractical if you
intend to release your games for operating systems where
people reboot daily or more frequently, makes no
allowance for recovering if the game or OS crashes, and
can still be circumvented by a determined loser who uses
the 'mem' device to capture, save, and restore the
binary image of your running program including their
game's data.
You can make savescumming very hard by using statistical
methods to calculate the probability that a player could
possibly have played the game your system now remembers
without cheating, and drop the game when the odds exceed
a million-to-one.
This involves constructing a tree of all possible
outcomes with their probabilities each turn, calculating
the resulting probability, on every turn, that the
player given a "true" random number generator would
survive until the next time he gets an opportunity to
act, and multiplying the result by the cumulative
probability so far calculated to obtain a new cumulative
probability.
When the cumulative probability drops below 1/1E6, mark
the game a cheat. A determined loser can circumvent
this by patching your program to ignore or lie about the
result of the calculation, or by patching the
probability number which, presumably, is saved in the
savefile or some other file. But the calculation (and
the game itself) can be repeated on other machines if
the savefile also contains the entire keystroke sequence
of the game, so this has some applicability to
"preventing" scumming for purposes of tournaments and
highscore lists. The drawback is that a bit less than
once for every million games or so, it will mark a
legitimate player as a cheat, and considerably more
often, players who cheat but don't cheat too much will
be mistaken for legitimate players.
If you go the statistical route, you can make
savescumming even harder by using the cumulative
probability as an input to the PRNG. This means that if
the player edits the probability number in the savefile,
it will cause him to face a different sequence of events
and possibly maps later in the game, so if you're also
saving a keystroke record of the entire game, it won't
check when run against an unpatched version of the game.
A sufficiently determined loser, however, can circumvent
the statistical method, including this addition, by
altering the style of his/her scumming. Using a
debugger to monitor the value of the cumulative
probability, a determined loser can save and restore
whenever the probability drops, rather than just on
death, and produce, albeit with great tedium, a scummed
savefile that checks on your remote or "tournament"
machine.
There are other ways, of escalating complexity and
escalating obnoxiousness, to try to make your game hard
to savescum while having the executable on the user's
machine instead of yours. Each can be circumvented by a
loser with some combination of root access, an editor,
programming skills, and a debugger, whether or not you
provide the source code.
7. Is it worthwhile to make savescumming hard?
Opinions vary, but to the extent that consensus exists,
not really. If someone is determined to cheat, s/he
will cheat, and development time spent attempting to
prevent cheating is development time not spent on making
the gameplay better. If you're giving away prizes, it
might be worth your time and effort to make savescumming
hard. Of course, if you're giving away prizes, you
probably want to go ahead and have the contestants play
by SSH so savescumming isn't possible in the first
place.
Highscore lists and tournaments aside, someone cheating
doesn't disrupt anyone else's enjoyment of the game.
On the contrary, depending on what you do to try to
prevent savescumming, you may also prevent game restore
after a program crash (or after an OS crash on machines
prone to such), or make the game itself hard to use, and
that *does* interfere with everyone's enjoyment of the
game.
8. Character displays? Come on, it's not 1980 anymore!
Why would anyone use a character display?
Many longtime players prefer character displays, for
various reasons, even when graphical interfaces to the
game are available. In fact, many longtime players
refuse to play games they can't play in character
display mode. Among the most frequently cited reasons
for liking a character display are the greater size of
the displayable map, greater ease of distinguishing
glyphs by eye as compared to typical tilesets, the
ability to play via SSH or telnet in environments where
installing software is forbidden or inappropriate, and
the ability to play via SSH or telnet in order to
continue a saved game not available locally.
Many game designers also prefer character displays, for
various reasons, even when graphical interfaces are
possible. Among the most frequently cited reasons are
ease of development, better portability in languages
other than Java, lack of art skill, personal preference
for playing in ascii mode, small executable size,
limited environments such as small PDA's and pocket
calculators, feeling that players who prefer graphical
mode are unworthy of their games or won't
understand/appreciate roguelikes anyway, inability to
pay graphic artists, the desire to learn to use the
ncurses or conio library or equivalent for their
preferred environment, and a preference for spending
their limited time on making gameplay deeper instead of
prettier.
9. Graphical displays? Come on, we're talking about
roguelike games here! Why would anyone use a graphical
display?
Many longtime players prefer graphical displays, for
various reasons, even when character displays show more
of the map. In fact, many longtime players refuse to
play games they can't play in graphical mode. Among the
most frequently cited reasons for liking a graphical
display are the greater detail allowed by graphics,
lower level of player imagination and memory required,
and a ubiquitous expectation that any game that isn't
graphical must therefore suck.
Many game designers also prefer graphical displays, for
various reasons, even when character displays are easier
to code. Among the most frequently cited reasons are
the abundant availability of the computer resources
required to support graphics, the limitations of the
repertoire of displayable characters available on
non-unicode terminals, a desire to expand the appeal to
potential players beyond the hardcore roguelike fans
accustomed to character displays, the availability of
free graphical tilesets, and the desire to learn
graphics programming.
10. Where can I get a good free graphical tileset?
David E. Gervais has done several tilesets for Angband
and has posted on rgrd in the past saying that he will
allow game developers to use them. Check
http://www.bitmine.net/~bayard/angbandTk/
to look at his tiles, and get in touch with him
from there to make sure about permissions.
And there is a nice tileset at http://www.idevgames.com
that is licensed free to any roguelike developer, on the
condition that you release your new versions for the
Macintosh Operating system before releasing for other
systems. This is a lot easier now that the latest
Macintosh Operating systems and libraries have a lot in
common with UNIX systems and libraries.
I've seen references to a "Lost Dragon Free Tileset" in
the group, but I don't have a URL for it.
Google can find lots of hits for "nethack tiles" and
"angband tiles", many of which lead to tilesets which
are available under various opensource licenses.
11. Where can I find a lot of good information about making
roguelike games?
Visit http://www.roguelikedevelopment.org .
It is without a doubt the single best and most
authoritative website on the net with regard to the
topic of creating roguelike games.
12. How long does it take to make a roguelike game?
As long as you want to spend on it. DungeonMonkey was
coded just over 20 hours; Nethack has been in
continuous development for just over 20 years. If you
want to produce a game complex enough to satisfy
people's current expectations of the genre, plan on
spending at least a year on it. Two or three years if
your effort is part-time or hobby-level and you have a
day job. More than two or three years, if like the
author of this FAQ your interest waxes and wanes at
pseudorandom intervals.
13. What's the easiest way to make a roguelike game?
Download a simple roguelike game that already exists,
like Angband or DungeonMonkey, and start editing.
This is called making a 'variant' because your game
will be a variation of an already existing game.
You can change monsters or items in Angband just by
editing data files.
The main issue with this is making sure that the
game you're making a variant of has its code
available under a license you can live with.
For example, Angband is a popular game for variant
makers because its code is relatively 'clean.' But
the Angband license states that nobody can charge
money for distributing Angband code, and that's a
restriction that some folks in the opensource crowd
can't live with.
Another issue is that some of the greatest and most
beloved roguelike games have source code and build
processes that are unbelievably baroque and complex,
and making variants starting from these games is
not easy or simple. Nethack is notorious for having
source code and a build process that are extremely
hairy, and although it is a most beloved roguelike
game, only one known variant [slash'em] has been
successfully made.
14. I said something about license terms, and people
were mean to me! Why??
The merits and benefits of open source and commercial
licensing is offtopic on this group, arguments about
it have been long and acrimonious in the past, and
nobody wants to have that argument again.
In fact, most of us would be vastly more entertained
by speculating about the parentage, personal habits,
and method of conception resulting in the sort of
person who would start that argument again, than by
a repetition of the argument. It is, after all, no
*more* offtopic than arguing about licensing, and
hasn't yet been done as creatively as some of us are
capable of.
If you don't understand how heated this topic can
become, consider this fact: ADOM's source code is not
available, precisely and solely because partisans
insisting that of course all roguelike code must be
open-sourced made themselves excessively annoying to
ADOM's creator.
You make your own decision about what kind of license
you need or want or will make your code available
under. If you want some particular kind of license
for making a variant from, people on RGRD may help
you find some available game that has that kind of
license, if one exists.
But if you *complain* about the license of some
existing game or insist that some roguelike author
ought to *change* the licensing of their game, or hold
forth that some type of license is better or worse for
the industry, the programmers, the users, the nation,
or the world, don't be too surprised if the most
topical and polite response you get on RGRD is from
someone speculating about the respective species of
your parents or what color underwear you were wearing
when you made the post.
15. I said things that were true, and someone told me I
was making "argument from realism." What does that
mean?
When someone on RGRD says you're making an argument from
realism, they mean you're missing the point. Roguelike
games are not, at their core, simulations that are made
better by being more accurate as simulations. They are
games that are made better by providing better gameplay.
So, an argument from realism may be a good reason to
try something or experiment with something; but the
only reason you should add something to your game or
keep something in your game is if it makes it a better
game.
16. How should time work in a roguelike game?
First, visit again the website
http://www.roguelikedevelopment.org .
They have an entire section on timetracking.
The original rogue was turn-based, in that when your
turn comes around, you can take as long as you want to
decide what to do before you do anything. Most game
designers feel that this is such an important and
defining feature of roguelike games that games which
are not turn-based are not roguelike.
That said, there are a lot of different kinds of
turn-based time systems for these games. Most fall
into four categories, which I name as follows: Pure
Turn-based, Segmented, Discretized, and Continuous.
17. What is Pure Turn-based timing?
In Pure Turn-based timing, everything in the dungeon
has a turn, and then the sequence repeats. This is
the easiest system to code.
In pure turn-based timing, the slowest monster moves
once per turn, and faster monsters move more than
once when it is their turn. A monster's "speed" is
the number of actions it gets per turn.
18. What is Segmented Timing?
In Segmented Timing, the turn is broken up into a
series of "segments," and monsters that have different
speeds get to act on different segments. For example,
in a Segmented timing system with 12 segments, you
might get:
monsters with speed 1 acting on segment 1,
monsters with speed 2 acting on segments 2 and 7,
monsters with speed 3 acting on segments 4, 8, and 12,
monsters with speed 4 acting on segments 3, 6, 9, and 12,
and so on. For each speed N, there would be a set of
N evenly distributed segments on which creatures of
that speed acted. Some segments will wind up being
shared, as segment 12 is shared between monsters with
speed 3 and speed 4 above.
19. What is Discretized Timing?
With Discretized timing, you have each monster in the
dungeon getting a small integer number of "energy"
points each round depending on its speed, and spending
a relatively large integer number of these points in
order to perform actions. Each time the creature gets
energy points, the game checks to see whether it has
enough energy to do its next action, and if it does,
performs the action and deducts the energy cost from
the monster's total. Fast monsters often perform
actions when they actually have more energy than they
need; the extra is saved to the next round, where it
may make a subsequent action happen sooner.
When different actions take different numbers of energy
points, and monsters of different speeds get different
numbers of energy points per round, Discretized timing
is the simplest timing system that allows for both
monsters of different speeds and actions that take
different lengths of time to perform.
A very precise and possibly more efficient variation of
Discretized timing is to have every monster in the
dungeon getting exactly one energy point each time it
gets a segment in a segmented turn. In this case the
energy point costs for various actions can be
relatively small compared to the basic Discretized
timing described above, and the timing will be more
"sensible and fair" since monsters will always move
when they have *exactly* the required number of energy
points instead of when they have *more than* the
required number leaving some random amount saved to the
next round.
20. What is Continuous Timing?
In continuous timing, each monster has an intrinsic
speed, which is a ratio between dungeon minutes and
opportunities for that monster to act. Different
actions take different amounts of "turns" to perform,
and the turns required are divided by a monster's speed
to find out exactly how long in dungeon seconds it
takes that particular monster to perform that action.
The effect is a simple, continuous model of dungeon
time. But it's not suitable for games where floating-
point operations are being avoided, nor for games where
counted moves like pillardancing are intended to be
useful to players.
20. Which method of timing is best?
It depends on what you think "best" means. Pure
turn-based systems are best if best means easiest to
code. Segmented is best if best means you favor that
particular tradeoff between speed and flexibility.
Discretized is best if you want a semi-realistic timing
system that avoids floats and allows people to use and
abuse the timing system to gain advantage over monsters
by counting and timing moves. Continuous timing is
best if you want an absolute time scale that doesn't
necessarily fall into integer ratios.
21. What data structures should I use to keep track of
who goes next?
Well, there are several good ones. The important thing
to understand first is that there will be moments when
you want to find a monster based on when its turn to
act is, and there will be moments you want to find a
monster depending on where it's standing. So, in a
straightforward design, you might have pointers to the
monster's data from both places, and you need to be
careful not to mess up one reference by manipulating
the monster using the other one.
An important question that you should decide early in
your software design is whether you will ever need to
change the time of a monster's next action when it
isn't that monster's turn. For example, will you have
"slow" spells that make a monster move at half speed
take effect instantly, by doubling the time until the
monster's next action? If that's the case, you need to
have a strategy to handle it.
I prefer an array, indexed by the time of next action,
combined with a "next action time" field in the monster
record. That way, I can look at the reference from the
map to find the affected monster when the "slow" spell
gets zapped at a particular square, then look at the
monster's record to find the time of the next action,
then look at the array for that time to find the timing
reference to the monster and delete it, then change the
"next action time" field and add the monster to the
list of timing references at the new time index.
The dungeon iterator moves through the array giving
things a turn as it gets to them and then placing them
at a later (or earlier) index in the array depending on
when their next turn is. When it reaches the end of
the array, it starts over from the beginning with the
next "cycle" of time. This works well for discretized
time. In continuous time you need to have floating
point fields for "next action time" in the monster
record, and these numbers will be rounded off to find
the array indexes.
For segmented time, you don't have to ever move the
timing references to the monster; you can just build
one array for every segment, and traverse the arrays in
order each round. And for pure turn-based time, it's
the same idea, except that there's only one "segment."
22. Why hasn't anybody thought of making a multiplayer
roguelike game? That would be cool!
Well, people have thought of it. We hear from about
one new person every couple of weeks on RGRD who wants
to do it. It's an interesting idea, and people will be
glad to discuss it with you, and we'd be happy to see
it done successfully and well. But so far, almost none
of the people who want to do this have produced working
games, and unfortunately most of them haven't hung
around on RGRD.
23. Are there multiplayer roguelikes that I could make a
variant of or take over?
Yes, but it's been a long time since the last release
for most of them, and not very many people, if any,
play them. Mangband exists for Windows and linux,
Crossfire for linux only, Myth for linux and SPARC, and
Phantasia for BSD and linux. You might need to do some
work to get any of these games working on the current
versions of their respective operating systems before
you can make a variant; on the other hand, it's likely
to be a variant of something nobody has ever seen
before, so you'd get extra egoboo if you make one of
them into a cool and popular game.
Opinions vary as to whether these games are actually
roguelike; the key issue seems to be about how they
handle time.
It's tough for a multi-user game to be turn based,
because different players will want to take turns at
different rates. If you make all the players wait for
their turns while the player whose turn it is takes a
lunch or bathroom break, it's turn based, but most of
the players won't be having much fun. Conversely, if
someone wants to take a moment to consider his action,
but his buddies all submit turns and the round moves
forward without his action being sent in, he's not
going to have the experience of playing a turn-based
(roguelike) game.
24. What are some strategies for handling time in
multiplayer roguelike games?
Well, the best known strategies are: Surreal time,
clock-driven timeouts, and play-driven timeouts. Any
of these can be modified with 'Halt actions' that are
either hard or have timeouts.
25. What is surreal time?
In a multiplayer roguelike with Surreal Time, time is
held to the same rate for player characters who are
together, but player characters who are separated and
played at different rates use up different amounts of
time.
The effect is is that when Machine-gun Mike, who makes
four keystrokes a second, is playing the paladin, and
Slowpoke Sam, who makes about one keystroke per five
seconds, is playing the thief, as long as the
characters are in sight of each other they are held to
the same time rate; that is, Machine-gun Mike has to
wait on Slowpoke Sam (using clock-driven or play driven
timeouts) before he gets a turn. But when they're out
of sight of each other, the game separates into two
games; Mike goes charging down one corridor using up
ten game minutes per wall minute, and Sam moves down a
different corridor using up two wall minutes per game
minute. Twenty wall minutes later, when the two
characters meet again, the paladin is three hours and
twenty minutes older, and the thief is only ten minutes
older. In the areas the paladin has been moving
through, over three hours have passed; monsters within
sight of him move at the same rate he does. And in the
areas the thief has been moving through, only ten
minutes have passed; monsters within sight of him move
at the same rate he does too.
26. How do clock-driven timeouts work?
In a multiplayer roguelike with clock-driven timeouts,
there is a maximum amount of time the server will wait
for a player to make a move. If the moves are to be
made one at a time, then there is always a player whose
move the server needs before it can advance time at
all; that player, and no other, will be working under a
clock-driven timeout.
If the server gets the move before the timeout expires,
it moves the player instantly, advances time to the
next "sticking point", and starts the timeout for the
player whose action will break that sticking point; if
the player doesn't move before the end of that time,
the game advances time regardless and the character
either stands there like an idiot, or makes some move
driven by his tactical settings and a "default player
AI." Either way, when the server cannot advance time
until it gets a move from that particular player, the
clock starts again.
Note that with Discretized or Continuous time, you can
allow players to move out of turn, as long as they
don't advance their character's time "too far" ahead of
the player that the game is waiting on. So while you
may have clock-driven timeouts, a player whose action
always comes in quickly will never be the player the
game is waiting on.
With segmented time, a player's move is slotted into
the player's next segment, even if other segments have
to happen first; but when all earlier segments have
been done, the game can simultaneously make all the
moves it has recieved for the current segment and start
a clock-driven timeout affecting multiple players for
any remaining actions in the current segment.
27. How do player-driven timeouts work?
Player-driven timeouts are an approach for multiplayer
roguelikes where player characters are supposed to move
simultaneously. This is simpler than clock-driven
timeouts, but, like simultaneous moves in segmented
movement, has attendant problems like characters moving
into the same space or trap, or overkilling the same
goblin, or other such stuff.
The way this works is that when the server has received
some threshold number of moves, it starts a timeout
clock. All moves it receives before or within the
timeout period are made when the timeout period
expires, or instantly if it gets moves from all the
players who are supposed to move at this moment. And
then the server waits, until it gets the threshold
number of moves again and starts a new timout period.
So, for example, in a five-player game where the
threshold is 3, the timeout clock doesn't start until
the server has received moves from 3 players. While
the timeout clock is running, it's waiting for moves
from the other two players. If it receives them, the
game advances instantly; if it doesn't, the game
advances when the timeout clock expires.
It's possible to combine player-driven timeouts with
segmented or discretized movement, where characters who
move on the same segment, or players who will otherwise
lose energy points if they don't move, form the pool of
players for each player-driven timeout.
28. What are halt actions?
In a multiplayer roguelike, or any roguelike which is
not strictly turn-based (ie, if game time can advance
even if the player doesn't do anything) a player who
wants some extra time to do stuff can make a "halt
action," like pausing an ordinary videogame. In
multiplayer roguelike games, a halt action notifies the
server (and the server notifies the other players) that
someone is holding up the game by requesting an
extension on the usual timeout that would otherwise
force an action or inaction after a given time. This
can be for time to inspect the contents of his backpack
or have a conference with the other players or
whatever, outside of game time.
29. When people mention Genrogue and ShockFrost, what are
they talking about?
Shockfrost was (and perhaps still is) a roguelike game
developer, and his "dream project" was (and perhaps
still is) a game called GenRogue. It was a very
ambitious project and design when he was posting on
RGRD, and he was very excited about it. But Shockfrost
no longer posts on RGRD, and so far, the game has not
appeared, and most spectators believe that it will not.
Perhaps he was not able to sustain his ambition.
Perhaps he has given up or set himself smaller goals.
and perhaps he is somewhere still working on his own.
But he and his project have passed from our knowledge
on RGRD.
It may be unfair to Shockfrost, but on RGRD, his nym,
and the name of Genrogue, have become warnings against
excessively complex designs. GenRogue has become, for
now, a cautionary tale for new roguelike developers;
set yourself achievable and incremental goals.
Whatever lofty aspirations you may have for your
eventual game, start simple, produce something
playable, and then worry about making improvements.
Most of us are mere mortals, and while we may have lots
of good ideas for making a game cooler, if we set out
to do all of them at once, in great detail, we are
setting ourselves a herculean task. And at such tasks,
unfortunately, we mere mortals tend to fail.
You may have some idea for a perfect dungeon generation
routine that does "the right thing" and produces a good
plausible architecture for the designed homes and
cities of your intelligent monsters or the races of the
departed builders; but if it's hard to do, get a quick,
dirty, and functioning random dungeon generator in
there now as a place holder. You may think you can
crack "strong AI" for your monsters; well, that'll be
really cool, but it'll be really hard too, so first
spend a week or two on getting a simple state-machine
AI running so your game is playable until you do.
The point is that until you have a functioning game,
none of the amazingly cool perfect features you have in
mind has a context in which it can exist and be
meaningful. So build a functioning simple game first,
before you spend too much sweat on those amazingly cool
perfect features. It's hard to focus on the mundane
when you have so many great ideas, but it seems to be
the only way that any of us actually get working games
produced.
Still, for all we know, GenRogue may still someday
appear and blow us all away with its coolness. And if
that happens, then we'll have to find something else to
name our cautionary tale.
30. How do you handle line-of-sight?
http://www.roguelikedevelopment.org.
Click the link that says LOS, and read articles about
the leading methods for doing the process of finding
out exactly what the player can see from a given
location.
The most efficient general methods are those that
process each visible square only once, and do not visit
squares which are not visible. There are only two such
methods; they are recursive shadowcasting (*NOT* the
ordinary variety of shadowcasting) and the spiral path
method.
But other methods can be extremely efficient for
restricted cases, or easy to code, or whatever, so
have a look around and see if you find something else
you'd prefer, or something else you can live with.
31. What's wrong with the random number generator that came
with my programming language?
Most roguelike games feature a lot of "sequential
rolling", where further random rolls are made depending
on the outcome of earlier rolls.
A typical programming language random number generator
stores an integer "seed" that is 32 bits wide. Each
time a random number is called for, this seed is
multiplied by some number X, modulo some other number
Y, to give the result, which is also the new seed. If
X and Y are chosen carefully, this will give every
possible 32-bit number, in an "obscure" order, before
the cycle repeats. And that's usually good enough for
simulated random numbers, right?
Well, no, not if you do a lot of sequential rolling.
The key problem is that if the generator gives a
particular 32-bit number, then _the sequence of other
numbers that follows that number is predetermined_.
So, while it may be a nice "random" seeming number for
multiple single trials, sequences of "random" rolls
constrain the possibilities of further rolls until you
can literally "run out of numbers" in a way that
distorts the probabilities in the last few rolls.
Let's see how this works in a dungeon scenario. Say
the player character turns over a rock. You consult
the random number generator to resolve a one in a
thousand chance that there was something under the
rock, and find that there is something there.
32 bits is about 4 billion numbers: that means that we
are now in one of about 4 million number sequences
where there would have been something under the rock.
So, what general category of item was under the rock?
Back we go to our random number generator, to resolve
possibilities like, it could be armor, or a weapon, or
junk, or a magic item, or a treasure. Most of what you
find under rocks will be junk, but let's say that about
2 percent of the time, including this time, it's a
magic item. Okay, we were in one of 4 million
sequences; the two percent chance cuts out 98 percent
of those, meaning we're now in one of just eighty
thousand possible sequences that could have led to this
point. That is, there are 80 thousand subsequences or
thereabouts in the entire cycle of 4 billion 32-bit
numbers where there was a magic item under the rock.
What kind of a magic item was it? The next roll sends
us to "rods, wands, and rings", which was about ten
percent likely. Now we can tell by the fact that we're
here that we're in one of just 8 thousand possible
subsequences that could have led to this point.
Another roll sends us to the rings subtable. Was that
about 25 percent likely? Okay, now we're talking about
one sequence chosen of about 2 thousand sequences in
the cycle of 32-bit numbers that could have gotten us
here. A magic ring is under a rock.
Rings of speed are rare; let's say that we find a ring
of speed, and one ring out of every two hundred or so
rings is a ring of speed. That means there's just ten
(on average) possible sequences that could have gotten
us to this point: A ring of speed is under a rock.
Finally, we roll to find the ring's bonus. And we have
a final table that attempts to make +1 50 percent
likely, +2 25 percent likely, +3 12 percent likely, +4
6 percent likely, +5 3 percent likely, and +6 1 percent
likely. But, in fact, it turns out there are only ten
sequences that lead here, and in 2 of them, the next
number means +1, and in 5 of them, the next number
means +2, and in 3 of them the next number means +6.
So, your probability table notwithstanding, no one will
ever find a +3, +4, or +5 speed ring under a rock, no
matter how many rocks they turn over. Thirty percent
of all speed rings found under rocks though, will be
+6! Or, a worse possibility, perhaps, although the
odds were for "about ten" sequences leading here out of
4 billion, maybe there aren't *any* sequences leading
here and nobody will ever find a ring of speed under a
rock!
You may think this example is contrived; but it's not.
In fact, it's oversimplified, and most roguelikes will
constrain things even further.
In fact, lots of roguelike games in the past have
behaved so differently under different random number
generators that the balance and playability,
inadvertently tuned to a particular generator, was
upset.
If you don't want to have a problem running out of
numbers after a long sequence of dependent rolls, then
you need to provide a *GOOD* random number generator
that takes a long time (way longer than 4 billion
numbers) to cycle.
I recommend a lagged-fibonacci generator, as described
in Knuth v2, as a pseudorandom generator that is fast,
easy to code, and has a very long period.
But there's lots of code for good RNG's floating around
the net these days, much of it borrowed from the
cryptography community. Pick one and build it into
your project; the one that came with your programming
language is almost certainly inadequate.
32. Can you tell me how to write a good map generator?
Map generators in most games result from lots of
experimentation and tweaking.
But here are a few simple classics, with pseudocode, to
give you a place to start tweaking from.
The 'Random Walk' Cave Generator.
Pick two parameters Q and R.
Let Xinit and Yinit be the center of
where you want the cavern.
For 1 to Q
x = Xinit
y = Yinit
For 1 to R
switch(d4)
1: x++
2: x--
3: y++
4: y--
hctiws
if rock?(x,y)
dig(x,y)
fi
rof
rof
This generates cool-looking caverns and caves. Play
with different values of Q and R, to get anything from a
few twisty caves wandering hither and yon, to giant
caverns with stalactites around the edges. You'll need
to make a few adjustments to make sure the door or
stairs get connected. Usually you just check to see
whether it's connected, and if not, pick the connected
spot closest to the door, start there, and make more
caves with more random walking.
You'll usually want a "rooms & tunnels" generator too;
this can be harder to code. But here's another classic.
The 'Spanning Tree' rooms & tunnels generator;
start by putting a room on the map. It can be random,
or you can start at the stairs. Now,
repeat
select a random wall tile from among those
so far placed.
select a random dungeon feature from your
repertoire of room & tunnel sizes.
If there's room to place it behind the wall
tile, without overlapping anything else,
dig out the squares to make the feature.
fi
Until you've placed enough stuff.
This seems simple but it has a lot of fiddly bits. To
make it run reasonably efficiently, you want a way to
remove wall tiles from consideration if there's no room
behind them to put anything. (if they're part of walls
one or two squares thick). Lots of people add rules for
truncating' tunnels if they don't fit, effectively
placing a shorter tunnel than the one they set out to
place.
It makes a 'spanning tree', which means there's exactly
one way to get from anywhere in the dungeon to anywhere
else. You then add some additional tunnels or break a
few walls randomly until you get the *right* degree of
confinedness and tactical choice.
And here's another classic, if you want honest to
goodness mazes in your dungeon:
The "depth first" maze generator. This creates a
"simply connected" maze.
Start with a rectangular array of cells half the size
of your intended maze area.
Select any cell in the array as the current cell. Set
the count of cells visited to one. repeat If one or
more neighbor cells exist that have not been visited,
Pick one at random as the next cell. Remove the walls
between the current and next cell. Make the next cell
the current cell. Increment count of cells visited.
else make the previous cell the current cell
(backtrack). fi Until the count of cells visited equals
the number of cells.
Once you have this maze, map it onto your dungeon where
each "cell" is 2x2 dungeon squares with the lower left
square open (dug out). If it's connected to the cell
above, the top left square is also open. If it's
connected to the right, then the bottom right dungeon
cell is also open.
35. What's the hardest part of creating a good roguelike
game?
Believe it or not, it's the data entry. Make no
mistake, coding the "engine" is hard. But filling it in
with monsters and magic items is harder; it requires
continued attention for a long time. And having done
that, you have endless cycles of playtest and balance
and adjusting probabilities to get the game to "work"
and design good gameplay.
The Sheep
>
> rec.games.roguelike.development FAQ
Really, really great work!
Thank you very much!
What are the copyrights? ;)
> after a program crash (or after an OS crash on machines
> prone to such)
lol
> 8. Character displays? Come on, it's not 1980 anymore!
> Why would anyone use a character display?
...
> possible. Among the most frequently cited reasons are
> ease of development, better portability in languages
> other than Java
:)
> and a ubiquitous expectation that any game that isn't
> graphical must therefore suck.
:))
> In fact, most of us would be vastly more entertained
> by speculating about the parentage, personal habits,
> and method of conception resulting in the sort of
> person who would start that argument again, than by
> a repetition of the argument. It is, after all, no
> *more* offtopic than arguing about licensing, and
> hasn't yet been done as creatively as some of us are
> capable of.
Show'em Ray! ^^))
--
Radomir @**@_ Bee! .**._ .**._ .**._ .**._ zZ
`The Sheep' ('') 3 (..) 3 (..) 3 (..) 3 (--) 3
Dopieralski .vvVvVVVVVvVVVvVVVvVvVVvVvvVvVVVVVVvvVVvvVvvvvVVvVVvv.v.
Slash
>
> rec.games.roguelike.development FAQ
>
> Administrivia:
SNIP
Hello!
Can I post portions of this at the rogueBasin????
Thanks
--
Slash
http://www.livejournal.com/~szdev
copx
> 29. When people mention Genrogue and ShockFrost, what are
> they talking about?
>
> Shockfrost was (and perhaps still is) a roguelike game
> developer, and his "dream project" was (and perhaps
> still is) a game called GenRogue.
GenRogue is Kornel's mega-lo-mania project. ShockFrost's project didn't
even have a name.
copx
Ray Dillinger
> Ray Dillinger schrieb:
>
>> 29. When people mention Genrogue and ShockFrost, what are
>> they talking about?
>>
> GenRogue is Kornel's mega-lo-mania project. ShockFrost's project didn't
> even have a name.
wups. Sorry. Corrected below, along with a couple of
other problems.
Bear
(and yes, anybody can use chunks of this FAQ wherever
the development of roguelike games is discussed. Just
be sure to mention where it came from. )
rec.games.roguelike.development FAQ
Administrivia:
4. What is savescumming?
8. Is it worthwhile to make savescumming hard?
Opinions vary, but to the extent that consensus exists,
not really. If someone is determined to cheat, s/he
will cheat, and development time spent attempting to
prevent cheating is development time not spent on making
the gameplay better. If you're giving away prizes, it
might be worth your time and effort to make savescumming
hard. Of course, if you're giving away prizes, you
probably want to go ahead and have the contestants play
by SSH so savescumming isn't possible in the first
place.
Highscore lists and tournaments aside, someone cheating
doesn't disrupt anyone else's enjoyment of the game.
On the contrary, depending on what you do to try to
prevent savescumming, you may also prevent game restore
after a program crash (or after an OS crash on machines
prone to such), or make the game itself hard to use, and
that *does* interfere with everyone's enjoyment of the
game.
9. Character displays? Come on, it's not 1980 anymore!
10. Graphical displays? Come on, we're talking about
roguelike games here! Why would anyone use a graphical
display?
Many longtime players prefer graphical displays, for
various reasons, even when character displays show more
of the map. In fact, many longtime players refuse to
play games they can't play in graphical mode. Among the
most frequently cited reasons for liking a graphical
display are the greater detail allowed by graphics,
lower level of player imagination and memory required,
and a ubiquitous expectation that any game that isn't
graphical must therefore suck.
Many game designers also prefer graphical displays, for
various reasons, even when character displays are easier
to code. Among the most frequently cited reasons are
the abundant availability of the computer resources
required to support graphics, the limitations of the
repertoire of displayable characters available on
non-unicode terminals, a desire to expand the appeal to
potential players beyond the hardcore roguelike fans
accustomed to character displays, the availability of
free graphical tilesets, and the desire to learn
graphics programming.
11. Where can I get a good free graphical tileset?
David E. Gervais has done several tilesets for Angband
and has posted on rgrd in the past saying that he will
allow game developers to use them. Check
http://www.bitmine.net/~bayard/angbandTk/
to look at his tiles, and get in touch with him
from there to make sure about permissions.
And there is a nice tileset at http://www.idevgames.com
that is licensed free to any roguelike developer, on the
condition that you release your new versions for the
Macintosh Operating system before releasing for other
systems. This is a lot easier now that the latest
Macintosh Operating systems and libraries have a lot in
common with UNIX systems and libraries.
I've seen references to a "Lost Dragon Free Tileset" in
the group, but I don't have a URL for it.
Google can find lots of hits for "nethack tiles" and
"angband tiles", many of which lead to tilesets which
are available under various opensource licenses.
12. Where can I find a lot of good information about making
roguelike games?
Visit http://www.roguelikedevelopment.org .
It is without a doubt the single best and most
authoritative website on the net with regard to the
topic of creating roguelike games.
13. How long does it take to make a roguelike game?
As long as you want to spend on it. DungeonMonkey was
coded just over 20 hours; Nethack has been in
continuous development for just over 20 years. If you
want to produce a game complex enough to satisfy
people's current expectations of the genre, plan on
spending at least a year on it. Two or three years if
your effort is part-time or hobby-level and you have a
day job. More than two or three years, if like the
author of this FAQ your interest waxes and wanes at
pseudorandom intervals.
14. What's the easiest way to make a roguelike game?
Download a simple roguelike game that already exists,
like Angband or DungeonMonkey, and start editing.
This is called making a 'variant' because your game
will be a variation of an already existing game.
You can change monsters or items in Angband just by
editing data files.
The main issue with this is making sure that the
game you're making a variant of has its code
available under a license you can live with.
For example, Angband is a popular game for variant
makers because its code is relatively 'clean.' But
the Angband license states that nobody can charge
money for distributing Angband code, and that's a
restriction that some folks in the opensource crowd
can't live with.
Another issue is that some of the greatest and most
beloved roguelike games have source code and build
processes that are unbelievably baroque and complex,
and making variants starting from these games is
not easy or simple. Nethack is notorious for having
source code and a build process that are extremely
hairy, and although it is a most beloved roguelike
game, only one known variant [slash'em] has been
successfully made.
15. I said something about license terms, and people
16. I said things that were true, and someone told me I
was making "argument from realism." What does that
mean?
When someone on RGRD says you're making an argument from
realism, they mean you're missing the point. Roguelike
games are not, at their core, simulations that are made
better by being more accurate as simulations. They are
games that are made better by providing better gameplay.
So, an argument from realism may be a good reason to
try something or experiment with something; but the
only reason you should add something to your game or
keep something in your game is if it makes it a better
game.
17. How should time work in a roguelike game?
First, visit again the website
http://www.roguelikedevelopment.org .
They have an entire section on timetracking.
The original rogue was turn-based, in that when your
turn comes around, you can take as long as you want to
decide what to do before you do anything. Most game
designers feel that this is such an important and
defining feature of roguelike games that games which
are not turn-based are not roguelike.
That said, there are a lot of different kinds of
turn-based time systems for these games. Most fall
into four categories, which I name as follows: Pure
Turn-based, Segmented, Discretized, and Continuous.
18. What is Pure Turn-based timing?
In Pure Turn-based timing, everything in the dungeon
has a turn, and then the sequence repeats. This is
the easiest system to code.
In pure turn-based timing, the slowest monster moves
once per turn, and faster monsters move more than
once when it is their turn. A monster's "speed" is
the number of actions it gets per turn.
19. What is Segmented Timing?
In Segmented Timing, the turn is broken up into a
series of "segments," and monsters that have different
speeds get to act on different segments. For example,
in a Segmented timing system with 12 segments, you
might get:
monsters with speed 1 acting on segment 1,
monsters with speed 2 acting on segments 2 and 7,
monsters with speed 3 acting on segments 4, 8, and 12,
monsters with speed 4 acting on segments 3, 6, 9, and 12,
and so on. For each speed N, there would be a set of
N evenly distributed segments on which creatures of
that speed acted. Some segments will wind up being
shared, as segment 12 is shared between monsters with
speed 3 and speed 4 above.
20. What is Discretized Timing?
21. What is Continuous Timing?
In continuous timing, each monster has an intrinsic
speed, which is a ratio between dungeon minutes and
opportunities for that monster to act. Different
actions take different amounts of "turns" to perform,
and the turns required are divided by a monster's speed
to find out exactly how long in dungeon seconds it
takes that particular monster to perform that action.
The effect is a simple, continuous model of dungeon
time. But it's not suitable for games where floating-
point operations are being avoided, nor for games where
counted moves like pillardancing are intended to be
useful to players.
22. Which method of timing is best?
It depends on what you think "best" means. Pure
turn-based systems are best if best means easiest to
code. Segmented is best if best means you favor that
particular tradeoff between speed and flexibility.
Discretized is best if you want a semi-realistic timing
system that avoids floats and allows people to use and
abuse the timing system to gain advantage over monsters
by counting and timing moves. Continuous timing is
best if you want an absolute time scale that doesn't
necessarily fall into integer ratios.
23. What data structures should I use to keep track of
who goes next?
24. Why hasn't anybody thought of making a multiplayer
roguelike game? That would be cool!
Well, people have thought of it. We hear from about
one new person every couple of weeks on RGRD who wants
to do it. It's an interesting idea, and people will be
glad to discuss it with you, and we'd be happy to see
it done successfully and well. But so far, almost none
of the people who want to do this have produced working
games, and unfortunately most of them haven't hung
around on RGRD.
25. Are there multiplayer roguelikes that I could make a
26. What are some strategies for handling time in
multiplayer roguelike games?
Well, the best known strategies are: Surreal time,
clock-driven timeouts, and play-driven timeouts. Any
of these can be modified with 'Halt actions' that are
either hard or have timeouts.
27. What is surreal time?
28. How do clock-driven timeouts work?
29. How do player-driven timeouts work?
30. What are halt actions?
In a multiplayer roguelike, or any roguelike which is
not strictly turn-based (ie, if game time can advance
even if the player doesn't do anything) a player who
wants some extra time to do stuff can make a "halt
action," like pausing an ordinary videogame. In
multiplayer roguelike games, a halt action notifies the
server (and the server notifies the other players) that
someone is holding up the game by requesting an
extension on the usual timeout that would otherwise
force an action or inaction after a given time. This
can be for time to inspect the contents of his backpack
or have a conference with the other players or
whatever, outside of game time.
31. When people mention Genrogue and ShockFrost, what are
they talking about?
Shockfrost was (and perhaps still is) a roguelike game
developer, and his "dream project" was (and perhaps
still is) a very ambitious project and design when he
was posting on RGRD, and he was very excited about it.
But Shockfrost no longer posts on RGRD, and so far, the
game has not appeared, and most spectators believe that
it will not.
Genrogue was another very ambitious project, initially
undertaken by Kornel Kisielewicz, who is still a
regular on RGRD and who has gone on to produce smaller
and simpler projects, including DoomRL, which most
players consider great fun.
It may be unfair to Shockfrost and Kornel, but on RGRD,
the nym Shockfrost, and the name of Genrogue, have
become warnings against excessively complex designs.
These are, for now, a cautionary tale for new roguelike
developers; set yourself achievable and incremental
goals. DoomRL may not be Genrogue, but it's a heck of a
lot closer to it than Shockfrost (as far as we know)
ever got to making his project work.
Still, for all we know, Shockfrost's game may still
someday appear and blow us all away with its coolness.
And if that happens, then we'll have to find something
else to name our cautionary tale. But for right now,
I'm betting Genrogue, while we haven't seen it yet, has
a thousand times better chance of being completed,
because its author actually started making playable
games instead of continuing with ever-escalating
design.
32. How do you handle line-of-sight?
Visit
http://www.roguelikedevelopment.org .
Click the link that says LOS, and read articles about
the leading methods for doing the process of finding
out exactly what the player can see from a given
location.
The most efficient general methods are those that
process each visible square only once, and do not visit
squares which are not visible. There are only two such
methods; they are recursive shadowcasting (*NOT* the
ordinary variety of shadowcasting) and the spiral path
method.
But other methods can be extremely efficient for
restricted cases, or easy to code, or whatever, so
have a look around and see if you find something else
you'd prefer, or something else you can live with.
33. What's wrong with the random number generator that came
with my programming language?
34. Can you tell me how to write a good map generator?
Brent Ross
In article <gGUKd.4436$m31....@typhoon.sonic.net>,
Ray Dillinger <be...@sonic.net> wrote:
// 2. Permanent death is stupid! Why shouldn't I let players
// save and restore?
// 3. Save and restore is stupid! Why shouldn't players who
// die stay dead?
// 4. What is savescumming?
// 5. How do players savescum?
// 6. How can I prevent savescumming?
// 7. How can I make savescumming hard?
// 8. Is it worthwhile to make savescumming hard?
There seem to be obvious sections to the questions... it'd be nicer
if they were numbered and presented as such. For example, these could
be subsections of a larger permadeath/savescum section. OH, and a
table of contents at the top would be nice too.
[Time]
// An important question that you should decide early in
// your software design is whether you will ever need to
// change the time of a monster's next action when it
// isn't that monster's turn. For example, will you have
// "slow" spells that make a monster move at half speed
// take effect instantly, by doubling the time until the
// monster's next action? If that's the case, you need to
// have a strategy to handle it.
This is what I call an internal time distortion. This is pretty minor
compared to some of the larger distortions that happen unknowingly to
the designer. Although you mention player and monster speeds, you're
really skipping over effect durations (another very important part of
the time system)... and that's where a lot of the unexpected distortions
can creap in. It'd be nice to have a paragraph somewhere in here to
inform new developers of those and duration system options.
You should also probably mention the option of using a priority queue/heap
system for implemention... it can give energy/tick systems that fine 1/per
granularity while skipping all the boring turns when nothing happens
(which turns them into a more continous system). They do have some
problems, though... serializing them can be a bit of a pain for one,
and they also change things into an event driven paradigm which can be
confusing if you've never worked with one before.
// 32. How do you handle line-of-sight?
//
// The most efficient general methods are those that
// process each visible square only once, and do not visit
// squares which are not visible. There are only two such
// methods; they are recursive shadowcasting (*NOT* the
// ordinary variety of shadowcasting) and the spiral path
// method.
I think perhaps adding a warning about optimizing too soon might be worth
it here. LoS/FoV is something that I think ends up being something that's
overwhelming for newbies... simple systems, even pretty sloppy ones that
aren't efficient, are going to be powerful enough on today's machines.
Crawl had an evil handrolled system of if-statements specially designed
to handle each grid in a quadrant. It wasn't pretty, but it was good
enough to run multiplayer on busy machines that weren't all that powerful.
It did, however, give a looser, peek a bit around corners, feel that
other RLs didn't have in their nicely coded algorithms (which was
mostly recaptured when LoS was rewritten). This also meant it didn't
have the asymetrical targeting problems between doorways and rooms the
fancy algorithms had... so at least in some ways, it was better.
Also note, that you can use the player's FoV to track monster->player
LoS which typically covers a lot of the usage for LoS... you can use
tracker beams to do monster to monster/item which is pretty efficient
(compared to doing FoV for everyone) if used reasonably sparingly.
The important thing is getting it out of the way, you can go back and
tighten it up later if need be.
Maybe we need to add a section about geometries and distortions... ie how
nice circular FoVs end up contrasting with square movement. Add a bit
on weighted diagonal systems (which produce octagons of equal distance)
and their problems and pitfalls.
// 33. What's wrong with the random number generator that came
// with my programming language?
//
// Finally, we roll to find the ring's bonus.
The ring example should be edited to be shorter... it's too long.
// If you don't want to have a problem running out of
// numbers after a long sequence of dependent rolls, then
// you need to provide a *GOOD* random number generator
// that takes a long time (way longer than 4 billion
// numbers) to cycle.
You need more than that. You need good spectrals (ie coverage of the
range) as well as high dimension (ie number of sequential numbers (n)
that still give a good spectral of the resultant n-dimensional hypercube).
The sequence actually only needs to be much larger than the number of
calls in the game and so some games might do quite well with cycles
less than 4G (providing the dimension and spectrals are good enough and
the random number calls are significantly small).
// I recommend a lagged-fibonacci generator, as described
// in Knuth v2, as a pseudorandom generator that is fast,
// easy to code, and has a very long period.
There are problems with LFGs... especially ones that have been hand
coded. They can be very tempermental as they are extremely sensitive
to initial conditions... they also can't be theoretically verified,
you need to test them extensively and carefully. PRNGs are a lot
like cryptography... it's very easy to shoot yourself in the foot
and end up with something remarkable broken if you don't know what
you're doing.
My suggestion would be to use the Mersenne Twister (MT). It's faster
than a most PRNGs, has a dimension > 600 (for 32-bit, you can get more
if you use smaller ints... which is possible because the bits are shown
to be independantly random), a massive period (the new one is called MT
19937, since it's period is 2^19937 - 1), and is freely available.
// But there's lots of code for good RNG's floating around
// the net these days, much of it borrowed from the
// cryptography community.
Cryptographical PRNGs aren't really neccessary... they also tend to
be a lot slower because they also need to try and prevent the output
from being recognisable as generated (MT isn't crypto safe... there
are algorithms that can spot a sequence as being MT generated fairly
quickly). The best ones for RLs come from those designed for use in
simulations... they value all the same things a RL does.
[Maps]
Actually, it might be worth it to mention the tilish approach of rogue
itself here. In general, you divide up the map into a grid of large
areas. Decide what to put in each area (room, through corridors, maze),
and then link the adjacent objects to each other (rogue actually did a
little bit of additional checking... levels would be discarded unless
they had 3 rooms in a row). Very simple, fairly effective, and it gets
something functional down... again, you can always go back and do more
creative level plans later.
Brent Ross
Björn Bergström
>
> rec.games.roguelike.development FAQ
>
Good work! Do you think it would be possible to merge this with
http://www.roguelikedevelopment.org/development/FAQ.php ? Also, can I
reproduce the FAQ at roguelikedevelopment.org?
BR,
Björn Bergström
roguelike development [http://roguelikedevelopment.org]
dweller - cellphone roguelike [http://roguelikedevelopment.org/dweller]
Jeff Lait
Ray Dillinger wrote:
>
> 9. Graphical displays? Come on, we're talking about
> roguelike games here! Why would anyone use a graphical
> display?
How about: "Curses is called Curses for a reason. Blitting tiles is
sometimes just easier." :>
> 10. Where can I get a good free graphical tileset?
Note that a collection of Public Domain roguelike tiles seems to be at:
http://rltiles.sourceforge.net/
> 24. What are some strategies for handling time in
> multiplayer roguelike games?
>
> Well, the best known strategies are: Surreal time,
> clock-driven timeouts, and play-driven timeouts. Any
> of these can be modified with 'Halt actions' that are
> either hard or have timeouts.
You are missing one of the well proven systems: real time.
This is what Diablo uses. Time flows on remorselessly from the main
server, requiring players to always give new actions. The difficulties
for traditional roguelikes is that:
1) Their unit of space is highly discretized.
2) Their unit of action is highly discretized.
One needs to break these apart by letting users specify more granular
actions. Many roguelike authors do not like the implication you can't
take the time to think of your course of action, as they consider this
an important part of the genre.
> You may think this example is contrived; but it's not.
> In fact, it's oversimplified, and most roguelikes will
> constrain things even further.
As a note, the default MSVC rand() function *really* sucks.
> 35. What's the hardest part of creating a good roguelike
> game?
>
> Believe it or not, it's the data entry. Make no
> mistake, coding the "engine" is hard. But filling it in
> with monsters and magic items is harder; it requires
> continued attention for a long time. And having done
> that, you have endless cycles of playtest and balance
> and adjusting probabilities to get the game to "work"
> and design good gameplay.
Amen!
>From what I've said before:
"You are misunderstanding what I mean by data entry. Data enÂtry
isn't merely filling the tables. It is filling the tables with thÂe
right values. Which are not necessarily the ones from your originÂal
specification. They are the values that come out of extensiÂve play
testing.
Having daggers that are now defined by 4 material types rathÂer than 1
means that the number of things that have to be tweaked to bÂalance
daggers has gone up by a factor of four. If the effect of tÂhe
different materials is small enough to not pose a balance issue, it
won't be noticed by any but the most compulsive of players, Âso be
entirely wasted. If it is big enough for the average player to care
about, it is going to require balancing."
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
Brent Ross
Jeff Lait <torespon...@hotmail.com> wrote:
// Amen!
//
// >From what I've said before:
// "You are misunderstanding what I mean by data entry. Data enè² ry
// isn't merely filling the tables. It is filling the tables with thè‹Ÿ
// right values. Which are not necessarily the ones from your originè‹”l
// specification. They are the values that come out of extensièµ³e play
// testing.
It's the terminology you're using. You're not really just talking
about the values... in fact, you're hardly talking about those at all
(especially not the entry of them), but really more about how they get
used. It's not the data that's the difficulty... it's the game mechanics.
Once you have those worked out you can write a few scripts and use a few
spreadsheets to get reasonable ranges and values and just fill in the
blanks on the table. For example, once you've worked out what qualifies
as small, medium, and large melee damage and you decided how skills
and stats work with melee... you can quickly pull up a spreadsheet to
work those back into numbers that you can assign in your weapon table.
The real trick is in that those skills and stats are vaiable (and
typically increasing) over the course of the game... you need to design
mechanics for that which will give the player a feeling of development,
yet aren't overly exposive (as that makes assigning HPs to monsters
tricky, because you need to match the curves carefully).
I've been hit with a few times with a similar terminology
problem myself. I occasionally forget that if you use the word
"simulation" you'll be blindly targeted as "arguing from realism"
and a raging simulationalist... regardless of anything else you said.
I argue for simulation of the abstract game world, not simulation of
reality... there's a big difference. The value of simulating realistic
and logical things in the game world is that the world makes sense
and allows for intuitive jumps of reasoning to work... RLs tend to be
complicated little systems with a lot of interacting variables, a simple
but well defined and strongly implemented world philosophy can go a long
way towards not making that mentally burdensome on the players.
Brent Ross
Martin Read
>Ray Dillinger wrote:
>> 9. Graphical displays? Come on, we're talking about
>> roguelike games here! Why would anyone use a graphical
>> display?
>
>How about: "Curses is called Curses for a reason. Blitting tiles is
>sometimes just easier." :>
Curses *is* easy to use. Initialising it takes a little effort, but IME
of attempting to write roguelikes, the curses-based display code is much
easier than the rest of the game.
MPR7DRL's curses display module, display.c, is 275 lines.
--
Martin Read - my opinions are my own. share them if you wish.
The Sheep
> Ray Dillinger wrote:
>>
>> rec.games.roguelike.development FAQ
>>
> [snip]
>
> Good work! Do you think it would be possible to merge this with
> http://www.roguelikedevelopment.org/development/FAQ.php ? Also, can I
> reproduce the FAQ at roguelikedevelopment.org?
How about putting the FAQ at some wiki, so actually anyone of us can add
bits and correct pieces...
And it would be much easier to navigate.
Then you can merge the wiki into a single text file once a month and post
it here as a remainder for newbies...
Ray Dillinger
> I'll make a couple of comments.
>
> In article <gGUKd.4436$m31....@typhoon.sonic.net>,
> Ray Dillinger <be...@sonic.net> wrote:
> // 2. Permanent death is stupid! Why shouldn't I let players
> // save and restore?
> // 3. Save and restore is stupid! Why shouldn't players who
> // die stay dead?
> // 4. What is savescumming?
> // 5. How do players savescum?
> // 6. How can I prevent savescumming?
> // 7. How can I make savescumming hard?
> // 8. Is it worthwhile to make savescumming hard?
>
> There seem to be obvious sections to the questions... it'd be nicer
> if they were numbered and presented as such. For example, these could
> be subsections of a larger permadeath/savescum section. OH, and a
> table of contents at the top would be nice too.
You're right about that. Will do. I had planned on a TOC
eventually, but figured that for the first few drafts it's
still a bit too much in flux.
> // An important question that you should decide early in
> // your software design is whether you will ever need to
> // change the time of a monster's next action when it
> // isn't that monster's turn. For example, will you have
> // "slow" spells that make a monster move at half speed
> // take effect instantly, by doubling the time until the
> // monster's next action? If that's the case, you need to
> // have a strategy to handle it.
>
> This is what I call an internal time distortion. This is pretty minor
> compared to some of the larger distortions that happen unknowingly to
> the designer. Although you mention player and monster speeds, you're
> really skipping over effect durations (another very important part of
> the time system)... and that's where a lot of the unexpected distortions
> can creap in. It'd be nice to have a paragraph somewhere in here to
> inform new developers of those and duration system options.
Hmmm. This type of distortion caused me to change the
representation of the time queue from a priority queue to
an array of segment lists. No other type of distortion
caused me to need to change the design in such a fundamental
way. The issue was that I couldn't lay hands on the reference
to the monster from the timing queue when I needed to change
the timing of its next action, when the timing queue was a
simple priority queue.
Durations didn't give me a problem. Can you elaborate on
what happened with durations and how it conflicted with
your initial design?
> You should also probably mention the option of using a priority queue/heap
> system for implemention... it can give energy/tick systems that fine 1/per
> granularity while skipping all the boring turns when nothing happens
> (which turns them into a more continous system). They do have some
> problems, though... serializing them can be a bit of a pain for one,
> and they also change things into an event driven paradigm which can be
> confusing if you've never worked with one before.
Hmmm. Well, I had considered it good to direct people
away from those, actually, unless you have a good method
of handling internal time distortions while using them.
> // 32. How do you handle line-of-sight?
<clip>
> I think perhaps adding a warning about optimizing too soon might be worth
> it here. LoS/FoV is something that I think ends up being something that's
> overwhelming for newbies... simple systems, even pretty sloppy ones that
> aren't efficient, are going to be powerful enough on today's machines.
True enough.
> Crawl had an evil handrolled system of if-statements specially designed
> to handle each grid in a quadrant. It wasn't pretty, but it was good
> enough to run multiplayer on busy machines that weren't all that powerful.
> It did, however, give a looser, peek a bit around corners, feel that
> other RLs didn't have in their nicely coded algorithms (which was
> mostly recaptured when LoS was rewritten). This also meant it didn't
> have the asymetrical targeting problems between doorways and rooms the
> fancy algorithms had... so at least in some ways, it was better.
>
> Also note, that you can use the player's FoV to track monster->player
> LoS which typically covers a lot of the usage for LoS... you can use
> tracker beams to do monster to monster/item which is pretty efficient
> (compared to doing FoV for everyone) if used reasonably sparingly.
> The important thing is getting it out of the way, you can go back and
> tighten it up later if need be.
Very good point. I actually take it a step further, having the
LOS code add "marks" to a square that monsters can then use both
to determine line of sight at an instant and to track the player
later.
> Maybe we need to add a section about geometries and distortions... ie how
> nice circular FoVs end up contrasting with square movement. Add a bit
> on weighted diagonal systems (which produce octagons of equal distance)
> and their problems and pitfalls.
Still in the works.
>
> // 33. What's wrong with the random number generator that came
> // with my programming language?
> //
> // Finally, we roll to find the ring's bonus.
>
> The ring example should be edited to be shorter... it's too long.
Noted.
> // If you don't want to have a problem running out of
> // numbers after a long sequence of dependent rolls, then
> // you need to provide a *GOOD* random number generator
> // that takes a long time (way longer than 4 billion
> // numbers) to cycle.
>
> You need more than that. You need good spectrals (ie coverage of the
> range) as well as high dimension (ie number of sequential numbers (n)
> that still give a good spectral of the resultant n-dimensional hypercube).
Hm. I understand you completely, but I didn't expect roguelikedev
newbies to know about spectral analysis of PRNG's. Shall I insert a
small tutorial about random numbers in place of the ring example?
> There are problems with LFGs... especially ones that have been hand
> coded. They can be very tempermental as they are extremely sensitive
> to initial conditions... they also can't be theoretically verified,
> you need to test them extensively and carefully.
FWIW, no spectral test on the output of an LFG constructed with
primitive polynomials has ever shown a regularity in its output
stream, so its spectrals as far as we can tell, approximate
perfection in any dimension.
The only problem I can see with them from a roguelike perspective
is that if you have an LFG generator with a length of 97, then the
having gotten 97 consecutive rolls out of it, the 98th and subsequent
are predetermined. But that's a whole lot more "breathing room" for
consecutive rolling than you get from the default PRNG's built into
most languages.
Still, I should probably not be so cavalier as to assume that my
satisfaction is enough for others.
> My suggestion would be to use the Mersenne Twister (MT). It's faster
> than a most PRNGs, has a dimension > 600 (for 32-bit, you can get more
> if you use smaller ints... which is possible because the bits are shown
> to be independantly random), a massive period (the new one is called MT
> 19937, since it's period is 2^19937 - 1), and is freely available.
It's good. It'll work. Nothing wrong with it.
Bear
Kornel Kisielewicz
> rec.games.roguelike.development FAQ
<>
> this group, is strictly a volunteer effort; if you want to
> create a different FAQ, by all means do so. It'll be just
> as official as this one, which is to say ... not at all.
It will be if we pass a vote on it. I purpose to vote on it in a month or
so, when you finish adding changes.
> 8. Character displays? Come on, it's not 1980 anymore!
> Why would anyone use a character display?
>
> Many longtime players prefer character displays, for
> various reasons, even when graphical interfaces to the
> game are available. In fact, many longtime players
> refuse to play games they can't play in character
> display mode. Among the most frequently cited reasons
> for liking a character display are the greater size of
> the displayable map, greater ease of distinguishing
> glyphs by eye as compared to typical tilesets, the
> ability to play via SSH or telnet in environments where
> installing software is forbidden or inappropriate, and
> the ability to play via SSH or telnet in order to
> continue a saved game not available locally.
What abbout greater immersion? Games still have graphics that are far from
reality (especially when considering animation a part of graphics), eg. for
me a Dragon in any game looks silly and breaks the feeling of immersiveness.
It's only a game it shouts. But in an ASCII game, it is just a D -- so I
must use my imagination. And imagination can produce horrors far more
frightening then even the best game (duh, even movie!). It's like the
difference between movies and books. Why do people still read books, when we
have movies? Because their imagination can produce far more realistic
visions then any movie can.
> And there is a nice tileset at http://www.idevgames.com
> that is licensed free to any roguelike developer, on the
> condition that you release your new versions for the
> Macintosh Operating system before releasing for other
> systems. This is a lot easier now that the latest
> Macintosh Operating systems and libraries have a lot in
> common with UNIX systems and libraries.
And using portable languages like FreePascal with portable libraries like
SDL ;-).
> 13. What's the easiest way to make a roguelike game?
>
> Download a simple roguelike game that already exists,
> like Angband
LOL! A simple game like Angband!!! ;-D
> or DungeonMonkey, and start editing.
Better say Thomas Biskup game -- there are very little people who want to
code in FreePascal :-( ... how was it called? Qhack.
> 15. I said things that were true, and someone told me I
> was making "argument from realism." What does that
> mean?
>
> When someone on RGRD says you're making an argument from
> realism, they mean you're missing the point. Roguelike
> games are not, at their core, simulations that are made
> better by being more accurate as simulations. They are
> games that are made better by providing better gameplay.
>
> So, an argument from realism may be a good reason to
> try something or experiment with something; but the
> only reason you should add something to your game or
> keep something in your game is if it makes it a better
> game.
Duh, that's a paragraph for those shotgun/chaingun guys ;-)
> 29. When people mention Genrogue and ShockFrost, what are
> they talking about?
>
> Shockfrost was (and perhaps still is) a roguelike game
> developer, and his "dream project" was (and perhaps
> still is) a game called GenRogue.
Duh, I should kill you for that ;-). But you already were pointed that
mistake :-D.
> 35. What's the hardest part of creating a good roguelike
> game?
>
> Believe it or not, it's the data entry. Make no
> mistake, coding the "engine" is hard. But filling it in
> with monsters and magic items is harder; it requires
> continued attention for a long time. And having done
> that, you have endless cycles of playtest and balance
> and adjusting probabilities to get the game to "work"
> and design good gameplay.
Not exactly. Data entry is fun. The hardest part is polishing it up, and
saying Enough! let's go public ;-). Or no, the hardest part is making the
mess of sourcecode you have and tons of data-files ... playable.
regards,
Kornel Kisielewicz
Brent Ross
Martin Read <mpr...@chiark.greenend.org.uk> wrote:
// "Jeff Lait" <torespon...@hotmail.com> wrote:
// >Ray Dillinger wrote:
// >> 9. Graphical displays? Come on, we're talking about
// >> roguelike games here! Why would anyone use a graphical
// >> display?
// >
// >How about: "Curses is called Curses for a reason. Blitting tiles is
// >sometimes just easier." :>
//
// Curses *is* easy to use. Initialising it takes a little effort, but IME
// of attempting to write roguelikes, the curses-based display code is much
// easier than the rest of the game.
It's true... curses has a lot of listed functions, but you really need
only a handful of them to get up and going on a RL (overall, it's about
the same as tiles... perhaps a bit easier as you don't need a layer to
calculate the screen positions for the tile coords). Curses does have
some limitations that come about because it's designed to be universal
and work on any terminal.
For example, you don't get low level access to keyboard input... what you
do get are escape sequences, and although curses does have the ability to
convert (via setting keypad() to TRUE), I've never been convinced of it's
ability to do that portably (I had a simple program to output the returned
converted values and ran it across six different terminals... with six
different results). This adds some limitations because it means that the
keypad/function/special keys aren't guaranteed to be functional... there's
also no reliable way to tell which shifting keys (shift, ctrl, alt, etc)
are down (unless it generates a unique glyph). Thus shift-1 can be
read if it's the keyboard one that (depending on layout) sends !, but
shift-keypad-4 can't be counted on to send a different escape sequence
than keypad-4 itself (or what that sequence might be... it could even
be the digit itself, thus making it indistinguishable from the keyboard
number key).
// MPR7DRL's curses display module, display.c, is 275 lines.
Compiled nicely here under Debian. It's not such a bad example of
curses usage... it even has windows/panels. I see you kept out of
colour like you said you were going to. That's a bit of a shame, because
it's really not that hard to do. A call to start_color, followed by a
couple calls to init_pair at the start and then using attrset with the
COLOR_PAIR macro to actually set the colour later (note that color_set()
takes the pair index as a param, not the attribute "flags" returned via
the COLOR_PAIR macro... thus you can't use that to set other attributes
at the same time, like A_BOLD (see below)).
Colour does add additional portability problems... different terminals
have different quirks, the largest concern being that on some terminals 16
colours are implimented via shifting with the A_BOLD attribute (A_BLINK
to do the background colour). Some colour terminals only do 8, which
means that if you try for the extra colours you get bold (or worse yet,
blinking) text). The worst case here is when characters end up matching
their background (typically darkgrey on black... there are some really odd
terminals I've seen that have a problem with this pair, despite having 16
colours... this makes detection of this problem via COLORS non-absolute).
However, it's not hard to have an option to remap darkgrey to something
else to help the few people that might actually hit this problem.
Brent Ross
Kornel Kisielewicz
> 31. When people mention Genrogue and ShockFrost, what are
> they talking about?
>
> undertaken by Kornel Kisielewicz,
Initially? So who runs it now? I'm scared!
> It may be unfair to Shockfrost and Kornel, but on RGRD,
> the nym Shockfrost, and the name of Genrogue, have
nym=name
> become warnings against excessively complex designs.
They did? ;-)
> These are, for now, a cautionary tale for new roguelike
> developers; set yourself achievable and incremental
> goals. DoomRL may not be Genrogue, but it's a heck of a
> lot closer to it than Shockfrost (as far as we know)
> ever got to making his project work.
Not to mention the fact that GenRogue is spelled with a capital R ;-).
> Whatever lofty aspirations you may have for your
> eventual game, start simple, produce something
> playable, and then worry about making improvements.
... of which the designer of GenRogue is now a radical crusader
> Most of us are mere mortals, and while we may have lots
> of good ideas for making a game cooler, if we set out
> to do all of them at once, in great detail, we are
> setting ourselves a herculean task. And at such tasks,
> unfortunately, we mere mortals tend to fail.
That's what we have DarkGod's and Anubis' for ;-).
> Still, for all we know, Shockfrost's game may still
> someday appear and blow us all away with its coolness.
> And if that happens, then we'll have to find something
> else to name our cautionary tale. But for right now,
> I'm betting Genrogue, while we haven't seen it yet, has
> a thousand times better chance of being completed,
> because its author actually started making playable
> games instead of continuing with ever-escalating
> design.
Well thank you ;-). Anyway, I must agree that what you wrote has the power
of truth, so I agree as using me as a negative example.
regards,
Kornel Kisielewicz
P.S. GenRogue dev-group opening soon ;-)
Ray Dillinger
>
>>10. Where can I get a good free graphical tileset?
>
>
> Note that a collection of Public Domain roguelike tiles seems to be at:
> http://rltiles.sourceforge.net/
>
Yay! I've added this information. Thank you!
>
>>24. What are some strategies for handling time in
>> multiplayer roguelike games?
>
> You are missing one of the well proven systems: real time.
>
> This is what Diablo uses. Time flows on remorselessly from the main
> server, requiring players to always give new actions.
But that makes a twitch game, not a roguelike game. I think it
falls too far out of canon to even mention in a faq about
developing roguelikes. If we were talking in general about
developing multiplayer interactive games, sure, but this is
roguelike dev, not MMORPG dev.
>> You may think this example is contrived; but it's not.
>> In fact, it's oversimplified, and most roguelikes will
>> constrain things even further.
>
> As a note, the default MSVC rand() function *really* sucks.
I find that so unsurprising as to be not worth mentioning, although
on investigation, I see what you mean. It points out a new,
exciting, and different way PRNG's can suck, in that one bit
has a period of 2, another bit has a period of 4, etc....And
while I'll probably avoid naming names, I should include a
warning that default PRNG's can suck in this exciting,
incredible, and unexpected way. :-)
Bear
Brent Ross
// Brent Ross wrote:
// > // An important question that you should decide early in
// > // your software design is whether you will ever need to
// > // change the time of a monster's next action when it
// > // isn't that monster's turn. For example, will you have
// > // "slow" spells that make a monster move at half speed
// > // take effect instantly, by doubling the time until the
// > // monster's next action? If that's the case, you need to
// > // have a strategy to handle it.
// >
// > This is what I call an internal time distortion. This is pretty minor
// > compared to some of the larger distortions that happen unknowingly to
// > the designer. Although you mention player and monster speeds, you're
// > really skipping over effect durations (another very important part of
// > the time system)... and that's where a lot of the unexpected distortions
// > can creap in. It'd be nice to have a paragraph somewhere in here to
// > inform new developers of those and duration system options.
//
// Hmmm. This type of distortion caused me to change the
// representation of the time queue from a priority queue to
// an array of segment lists. No other type of distortion
// caused me to need to change the design in such a fundamental
// way. The issue was that I couldn't lay hands on the reference
// to the monster from the timing queue when I needed to change
// the timing of its next action, when the timing queue was a
// simple priority queue.
Part of the "catch" to using a priority queue in a RL is to recognise
that some events will become invalid. A simple way to do that is to have
the events check if they're still valid when they get popped. However,
to do that you need a reference of some sort to the thing (ie monster)
that it wants to act on... so you can't use a dynamic pointer (monster
goes away and is deallocated) or a reference into a static table (monster
in that slot might be a different monster). What you need is a handle
abstraction layer... this can be dirt simple, just give each monster a
number and have the events use that to verify that it's the same monster.
However, that doesn't help much if you need to promote an event to an
earlier time (ie the monster gets hasted from an external source... the
slow case could be hacked by having the event calculate and reschedule
itself for the right time... not that I'd do that, it's just not as
tricky an issue as moving an event up). This does mean that you do need
the ability to scan your heap to find the next action of the monster and
have it adjusted... it's a concern, but using the handle system above it
shouldn't be too bad. It's really only the "action" event that needs
to be done (assuming that we're placing all durations on the absolute
clock... probably the case as that's what a priority queue is best at).
There should be only one of them in the queue for any monster at a time,
and so the monster could store a pointer to that event object for quick
access if needed.
// Durations didn't give me a problem. Can you elaborate on
// what happened with durations and how it conflicted with
// your initial design?
Oh, it's a common thing in a lot of the RLs out there using
energy/tick systems with counters for duration (which is not uncommon).
Carelessness can tie those decrements into either the monster's or the
PC's timeframe... and if moves have different weights that means that
the durations get distorted along with it. For example, if you tie the
decrements to when each monster action then faster monsters shake off
durations a lot faster in the absolute timeframe than slow monsters.
If you're careful enough to call it only once for each set of multiple
moves you might still be tying it to the PC's timeframe. For example,
if you take the time for the PC's action and use that to determine
how much energy the monsters get... in the absolute timeframe the
frequency of those energy doles warps around with the speed of the PC.
Thus the duration of effects changes when the speed of the PC changes.
Add a magitude effect that goes off periodically during the duration
(eg poisoning damage) and things get further compilcated since the
magnitude can also get warped. This is a common pitfall of energy/tick
systems... you need to either come up with a way to decrement duration
counters in the absolute timeframe, or you need to move away from
measuring duration in turns (and perhaps use ticks instead... although
that still leaves the internal distortions to worry about).
Of course, systems which are intrinsically based on turns of a fixed
absolute time length (eg segment/phase systems) can avoid this problem
with counter based durations easily (they just need to make sure that
effects are only done on a specific segment/phase and that guarantees
no warping). You're quite right that the internal distortions become
the bigger concern here... after all, you either need to find a way
to handle those fragments at the beginning/end of the duration or you
need to accept a little distortion there. Personally, I think this is
forgivable, and something that can be put off till much later in favour
of a simple initial design... time warps caused by tying effects into the
PC or monster time frame can warp entire durations and be much larger,
so I find it better to think about avoiding them from the start.
// > You should also probably mention the option of using a priority queue/heap
// > system for implemention... it can give energy/tick systems that fine 1/per
// > granularity while skipping all the boring turns when nothing happens
// > (which turns them into a more continous system). They do have some
// > problems, though... serializing them can be a bit of a pain for one,
// > and they also change things into an event driven paradigm which can be
// > confusing if you've never worked with one before.
//
// Hmmm. Well, I had considered it good to direct people
// away from those, actually, unless you have a good method
// of handling internal time distortions while using them.
See above.
[PRNGs]
// > You need more than that. You need good spectrals (ie coverage of the
// > range) as well as high dimension (ie number of sequential numbers (n)
// > that still give a good spectral of the resultant n-dimensional hypercube).
//
// Hm. I understand you completely, but I didn't expect roguelikedev
// newbies to know about spectral analysis of PRNG's. Shall I insert a
// small tutorial about random numbers in place of the ring example?
The ring example is a good lead-in, and it certainly shows the need
for PRNGs which are well equidistributed over multiple dimensions.
I'd just shorten it to a quick list of points to better highlight how
seemingly simple things can become long random number sequences. A brief
overview of the technical terms will help them if they go shopping for
replacements. It might also be useful to mention that the library rand()
that they're using is probably an LCG with a dimension that might easily
be no greater than 5.
Another thing might be a quick mention of how to use the output
correctly... ie scaled division with RAND_MAX (or whatever constant
the PRNG you're using uses for that). Never modulo... a quick mention
that the standard Unix rand() for a long time had a period of 2 in its
lowest bit should point out why that can be a problem (I had a friend
get hit with this bug... his I Ching generator was only producing two
different hexagrams).
// > There are problems with LFGs... especially ones that have been hand
// > coded. They can be very tempermental as they are extremely sensitive
// > to initial conditions... they also can't be theoretically verified,
// > you need to test them extensively and carefully.
//
// FWIW, no spectral test on the output of an LFG constructed with
// primitive polynomials has ever shown a regularity in its output
// stream, so its spectrals as far as we can tell, approximate
// perfection in any dimension.
The problem is that the theory isn't complete on them. This means that
all the evidence for the reliablity of a given implimentation comes
from empirical testing, not theoretical validation.
In the world of science, empirical/inductive rules are considered a
necessary evil. They don't like them, they'd prefer to not have them
at all, but they admit that they can be useful and are occasionally the
only option. This is why Big Tabacco didn't have many problems in the
court after empirical tests tied them to lung cancer. They could always
bring up their own scientists to question those results (the classic
example is "all swans are white, providing you never go to Australia").
But 1997, science came up with a solid connection from proven facts, and
almost immediately you had several states suing them them for health
costs, Big Tabacco trying to make deals to keep them out of the courts,
and those 7 previous BT CEOs coming out with evidence of questionable
business practices.
Back on topic, LFGs are also unproven. Their very chaotic nature which
makes them so nice for PRNGs also means that it's very hard to prove
things with them. Thus, even if you do have extensive testing, you
can't say much about any untested seed conditions beyond that they're
"probably also white swans". You certainly can't say anything at all if
you change the LFG itself... you'd need to do extensive testing to get
that confidence interval back up. The end lession is that you want to
use a LFG you want to grab a pre-existing one that's been extensively
tested by people that live and breath PRNGs... don't try handrolling
one unless you're really sure of what you're doing and are willing to
do a lot of testing (in this way, they are very much like crypto... bad
things can easily happen in the hands of amateurs).
// Still, I should probably not be so cavalier as to assume that my
// satisfaction is enough for others.
Well, LFGs are pretty nice... and eventually they're bound to be
theorectically sound (again induction means that this is probably the
case given the amount of results so far). They're certainly worth a
mention... perhaps with examples of some good implementions. I know
the GSL has at least one LFG (and MT19937 as well) in it among several
other decent PRNG options.
Brent ROss
Brent Ross
Ray Dillinger <be...@sonic.net> wrote:
// Jeff Lait wrote:
// >
// > You are missing one of the well proven systems: real time.
// >
// > This is what Diablo uses. Time flows on remorselessly from the main
// > server, requiring players to always give new actions.
//
// But that makes a twitch game, not a roguelike game. I think it
// falls too far out of canon to even mention in a faq about
// developing roguelikes. If we were talking in general about
// developing multiplayer interactive games, sure, but this is
// roguelike dev, not MMORPG dev.
Well, from my perspective just about anything done to make a multiplayer
roguelike truly "work" is pretty much going to be a straight tradeoff
against the traditional definition of the genre (not that that's a
bad thing). The problem with multiplayer RLs, as I see it, is that
traditional RLs have an awkward granularity for such things... moves are
often too simple to allow a long timeout, but the tradition of giving the
ability to consider options runs counter to short timeouts. Furthermore,
playing styles have developed independantly so that players run at
different speeds from each other, and vary largely even with the same
player during play. The resulting tempo is chaotic with a large variance.
But, since multiplayer RLs do come up fairly often, they're worth some
coverage in the FAQ (at the very least it will point out why they're not
common... it's simply easier to start with a MMORPG and graft some things
from RLs into it, than it is to make a true RL that plays multiplayer).
Likewise, I think that at least a short mention of realtime as an option
is proably not so bad... along with a mention that such systems have
been well explored in MMORPG dev, and that's where they're most likely
to get real help on how to do that. The focus items in the FAQ should
still be the more unique systems that try to recapture the traditional
RL features in a system which they simply weren't designed for.
Brent Ross
Ray Dillinger
> Ray Dillinger wrote:
>
>> It may be unfair to Shockfrost and Kornel, but on RGRD,
>> the nym Shockfrost, and the name of Genrogue, have
>
>
> nym=name
>
No, Shockfrost was certainly a nym, not a name.
Bear
Jeff Lait
> Jeff Lait wrote:
> >
> >>24. What are some strategies for handling time in
> >> multiplayer roguelike games?
> >
> > You are missing one of the well proven systems: real time.
> >
> > This is what Diablo uses. Time flows on remorselessly from the
main
> > server, requiring players to always give new actions.
>
> But that makes a twitch game, not a roguelike game. I think it
> falls too far out of canon to even mention in a faq about
> developing roguelikes. If we were talking in general about
> developing multiplayer interactive games, sure, but this is
> roguelike dev, not MMORPG dev.
I wouldn't call Diablo a MMORPG, it really doesn't classify as massive
if each instance has only a dozen players in it. MMORPGs have a huge
slew of problems completely unrelated to those faced by roguelikes or
Diablo clones.
Further, real time does not imply a twitch game. Your forced timeout
systems all are similar to real time (except in some ways worse, as
play can occur *faster* than real time, but never slower)
You are also ignoring the well established fact that a large number of
people *do* think Diablo is a Roguelike. Thus, I would not call it so
far out of canon as to preclude mentioning.
Courtney Campbell
Ray Dillinger <be...@sonic.net> wrote:
I've been on the sidelines lately, looking forward to a real stable
release of my variant, which should be in feature freeze for a while.
It just seems to me that perhaps it's time to see Bear's code, since
we're on the subject of put up. :-) I mean every time he writes anything
about his game, it sounds like golden ambrosia from yon high - and he
always talks in past tense, as in "I have goblin villages/new card
system etc."
Any chance of a release? ever?
-Campbell
"Who only asks because he _really_ wants to play"
Hansjoerg Malthaner
> 35. What's the hardest part of creating a good roguelike
> game?
>
> Believe it or not, it's the data entry. Make no
> mistake, coding the "engine" is hard. But filling it in
> with monsters and magic items is harder; it requires
> continued attention for a long time. And having done
> that, you have endless cycles of playtest and balance
> and adjusting probabilities to get the game to "work"
> and design good gameplay.
Even if this is the last, and one of the shorter paragraphs, to me it
seems to be the most important.
Jeff Lait already discussed the problem, but there is one more aspect I
want to add:
I believe to remember DarkGod once had to add (corpse-) weights to all
1000+ monsters of ToME.
In any case, it can be a lot of work, if you have a rather long monster
or item list and have to add new values. I think you should try to
complete the game mechanics with a rather short list of monsters and
items, and grow them not sooner than you are fairly sure you have all
fields that you need.
I assume you'll have to do it once or twice anyways. Juts make sure it
doesn't become a major time-sink in your project.
--
c.u. Hajo
Ray Dillinger
> I've been on the sidelines lately, looking forward to a real stable
> release of my variant, which should be in feature freeze for a while.
>
> It just seems to me that perhaps it's time to see Bear's code, since
> we're on the subject of put up. :-) I mean every time he writes anything
> about his game, it sounds like golden ambrosia from yon high - and he
> always talks in past tense, as in "I have goblin villages/new card
> system etc."
>
> Any chance of a release? ever?
> -Campbell
> "Who only asks because he _really_ wants to play"
laugh... I've been telling about the things I got obsessive about and
made to work in a new, cool, or nifty way.
I haven't been telling about the things that aren't implemented yet, or
the things that get ripped out after I talk about them because they're
not compatible with something else I'm building. I also haven't been
mentioning the six-month and sometimes longer gaps in the coding process
before I pick it up again and say, "now where was I?..." I haven't
mentioned losing all the work I did on it for one whole year to a
backup/restore failure.
The implementation log starts in 2001. It's now 2005. Work proceeds
in fits and starts, slowly, as ideas come to me and slowly get worked
into the fabric where they can coexist with the other stuff that's going
on. The code is frankly disorganized, has fragmentary bits of lots of
stuff that isn't currently working, and isn't adequately errorchecked.
In the current version, game save and restore doesn't work, there's
no highscore list, there's no recognized winning condition, monsters
and magic items are sparse, (less than 2 dozen of each) and levels
and skills is in the middle of a(nother) rewrite/rebalance.
*sigh*. Point: I ought to start aiming for a playable release.
There's just so *MUCH* new stuff that I want to have working before
it goes out, and I am so *SLOW* to get it done. And I guess I'm
falling into the Shockfrost/perfectionist syndrome myself....
Bear
Martin Read
>*sigh*. Point: I ought to start aiming for a playable release.
>There's just so *MUCH* new stuff that I want to have working before
>it goes out, and I am so *SLOW* to get it done. And I guess I'm
>falling into the Shockfrost/perfectionist syndrome myself....
Write a 7DRL! :)
Kornel Kisielewicz
Sorry, didn't know that word. What's a "nym"?
regards,
Kornel Kisielewicz
David Damerell
> Another issue is that some of the greatest and most
> beloved roguelike games have source code and build
> processes that are unbelievably baroque and complex,
> and making variants starting from these games is
> not easy or simple. Nethack is notorious for having
> source code and a build process that are extremely
> hairy, and although it is a most beloved roguelike
> game, only one known variant [slash'em] has been
> successfully made.
Notorious mostly amongst people who haven't looked at the code in the last
ten years. The build process is a bit ugly, I admit, but the code's
complexity is not disproportionate to the game's complexity.
Variants; there's Lethe, the old NH+ variant, two Japanese variants...
--
David Damerell <dame...@chiark.greenend.org.uk> Distortion Field!
Today is Oneiros, February.
Ray Dillinger
> Ray Dillinger wrote:
>
>>Kornel Kisielewicz wrote:
>>
>>>Ray Dillinger wrote:
>>>
>>>
>>>> It may be unfair to Shockfrost and Kornel, but on RGRD,
>>>> the nym Shockfrost, and the name of Genrogue, have
>>>
>>>nym=name
>>
>>No, Shockfrost was certainly a nym, not a name.
>
>
> Sorry, didn't know that word. What's a "nym"?
It means something that someone chooses to be known by,
which is not actually his or her name. My name, for
example, is Ray Dillinger. But my nym (or nickname)
is Bear.
Like most English words it's all about shadings of meaning.
"Alias" tends to imply criminal intent or use. "Pseudonym"
tends to imply the intent to deceive. "Nickname" tends to
imply that most people you deal with actually know your
real name. If "nym" has an implication, it's much milder;
it's more a name taken for purposes of privacy only.
Bear
R. Dan Henry
wrote:
>Kornel Kisielewicz wrote:
>> Ray Dillinger wrote:
>>
>>>Kornel Kisielewicz wrote:
>>>
>>>>Ray Dillinger wrote:
>>>>
>>>>
>>>>> It may be unfair to Shockfrost and Kornel, but on RGRD,
>>>>> the nym Shockfrost, and the name of Genrogue, have
>>>>
>>>>nym=name
>>>
>>>No, Shockfrost was certainly a nym, not a name.
>>
>>
>> Sorry, didn't know that word. What's a "nym"?
>
>It means something that someone chooses to be known by,
>which is not actually his or her name. My name, for
>example, is Ray Dillinger. But my nym (or nickname)
>is Bear.
Actually, that's "nym" used as a contraction of "pseudonym" ("false
name"), which should really therefore be written "'nym" with an
apostrophe. The "-nym" element itself means "name" so really the only
reason to write "nym" is an attempt to appear current and hip, which
will likely look terribly dated in twenty years, should anyone read
your FAQ then.
The statement "nym = name" is quite correct, they are the same word,
with a slightly different evolution of the pronunciation and spelling.
>Like most English words it's all about shadings of meaning.
>"Alias" tends to imply criminal intent or use. "Pseudonym"
>tends to imply the intent to deceive.
No, it does not. Many literary pseudonyms are quite openly known and
may be chosen to *avoid* deception (as when a writer known for one
genre publishes in another under another name). And outside of
literary pseudonyms, the term "pseudonym" was rare until the Internet
made them widely popular.
R. Dan Henry
danh...@inreach.com