Scripted approach to dungeon generation

Archived from groups: rec.games.roguelike.development (More info?)

I'm currently piecing together some RL development modules, to make
future projects of mine easier to work with. Right now, I'm trying to
work out a different way of doing dungeon generation.

Firstly, I'm going to have the entire dungeon generation process done
through Lua, with the output (actual dungeon map) getting sent back to
the main C++ program. By doing this, it will be easier for the
end-user to both tweak the general algorithm for the dungeon layout,
but can also tweak the individual rooms and halls.

Each room and hall will be stored in their individual script file.
These script files will store any room specific game scripts, as well
as the actual room design. This will give the game more of a
distinctly different look. Most RLs use random dungeon generators to
produce the layout of the map only, and just use generic, plain rooms
and halls. This will allow for unique, handcrafted rooms to be placed
all throughout the levels, as opposed to the bland, ordinary
rectangular rooms.

Anyone could freely write a new room file, allowing them to create any
room they could think of and could freely plug it into the main
generation script. For example, someone could toss out a room like this:

############
#..........#
#...#..#...#
#...#..#...#
#.###..###.#
#....==....#
#.###..###.#
#...#..#...#
#...#..#...#
#..........#
############

Where '.' is floor, '#' is wall, and '=' is water. Then they could
write a script to cause the water to slowly expand, causing a sort of
drowning deathtrap.

The options would really be fantastic. Granted, the above example was
weak, but it was just a quick random idea. It'd be nice to play a
game where every room was interesting, and unique, and full of options.

Anyways, I'm nearing completion with this module, and then I hope to
be able to release a walkaround demo, with random dungeons, within the
next week or so, to show it off.

Anybody who has a cool idea for a room, or hall, please post it.
Likewise, anyone with a good suggestion, or critique of my idea,
please post it as well. I'm looking for all the feedback I can get.


--
My projects are currently on hold, but I do have
some junk at the site below.

http://www.freewebs.com/timsrl/index.htm

--
49 answers Last reply
More about scripted approach dungeon generation
  1. Archived from groups: rec.games.roguelike.development (More info?)

    Timothy Pruett wrote:
    > I'm currently piecing together some RL development modules, to make
    > future projects of mine easier to work with. Right now, I'm trying to
    > work out a different way of doing dungeon generation.
    >
    > Firstly, I'm going to have the entire dungeon generation process done
    > through Lua, with the output (actual dungeon map) getting sent back to
    > the main C++ program. By doing this, it will be easier for the
    > end-user to both tweak the general algorithm for the dungeon layout,
    > but can also tweak the individual rooms and halls.
    >
    > Each room and hall will be stored in their individual script file.
    > These script files will store any room specific game scripts, as well
    > as the actual room design. This will give the game more of a
    > distinctly different look. Most RLs use random dungeon generators to
    > produce the layout of the map only, and just use generic, plain rooms
    > and halls. This will allow for unique, handcrafted rooms to be placed
    > all throughout the levels, as opposed to the bland, ordinary
    > rectangular rooms.
    >
    > Anyone could freely write a new room file, allowing them to create any
    > room they could think of and could freely plug it into the main
    > generation script. For example, someone could toss out a room like this:
    >
    > ############
    > #..........#
    > #...#..#...#
    > #...#..#...#
    > #.###..###.#
    > #....==....#
    > #.###..###.#
    > #...#..#...#
    > #...#..#...#
    > #..........#
    > ############
    >
    > Where '.' is floor, '#' is wall, and '=' is water. Then they could
    > write a script to cause the water to slowly expand, causing a sort of
    > drowning deathtrap.

    You'll find that other dungeon generators also allow handcrafted rooms.
    Not new but well worth doing.

    Linking events into the map generation, like your 'drowning deathtrap',
    would really be a new feature, I'd be interested to see what came of
    that.

    You should also allow the script to influence the AI of the monsters
    (either scripted or random) within the room. For example, when you
    stand on a certain tile, the monsters will come after you, but will not
    leave a certain area. Or, the monsters patrol in circuits around a
    particular track through the room. And soo on.

    A.
  2. Archived from groups: rec.games.roguelike.development (More info?)

    >It'd be nice to play a game where every room was interesting
    'When everybody is special, nobody is special' , The incredibles ;)

    Anway, I am also thinking about a Java Interface for layout generators
    that could be generic enough to be used by multiple projects but
    specific
    enough that sharing generators would actually be usefull.

    Have you checked out the angband vault file ?

    T.
  3. Archived from groups: rec.games.roguelike.development (More info?)

    It's a cool idea!

    I've been playing with random generation in Lua for a while now also.
    I have some things that work pretty well, but am still refining the
    ideas. I'm very interested to see someone else's approach.

    That being said, a lot of the "unique" room ideas I would have would
    have to be tied to gameplay. Simple "interesting" rooms would simply
    add some patterns, or change room geometry slightly, but the more
    interesting ones should add cool gameplay options.

    Some of my approaches to spice things up:
    * Rooms can specify treasure spots as well as monster spawn spots (not
    actually specifying what goes in those spots)
    * pillers
    * moats in the middle
    * Special things around doors: Pillars, candles, water
    * Flooded rooms with pads that can be moved on to
    * Highly flavored rooms, like throne rooms, libraries, storage areas,
    healing areas.
    * Dens or barracks where creatures sleep - beds, sleeping creatures,
    etc

    On a slightly different topic - the part that could really add some
    nice stuff to random levels is dependencies. Think rogue-like meets
    Zelda. Doors and keys could be separated with pathfinding algorthms.
    I've played around with this a bit, and it gives some really nice
    results.

    Doors and keys can be generalized more to be "problem" and "solution",
    so that a "problem" could be a room flooded with Lava, while the
    "solution" could be a medalion that needs to be inserted into a
    particular block. Pathfinding would assure that the solution was
    accessable in the proper order.

    That could be beyond what you're looking for though. so far, I've been
    having some fun playing with it though, and it seems to be a solid
    idea.

    My current framework is more "heavy" then I intended though - I was
    looking for ways of making more interesting overall layouts (Castle
    style, cave like, with "complexes" attached, etc), and I fear I over
    enginered.

    Good luck, and looking forward to seeing what you come up with!
  4. Archived from groups: rec.games.roguelike.development (More info?)

    Timothy Pruett wrote:
    > I'm thinking about implementing pillars a little differently, compared
    > to the standard RL approach. I think that I'll have them block LOS
    > only a little bit, so that the main use for pillars is for tactical
    > reasons, and not for hiding.

    Interesting. Here's a question: If you have digging in your game, and
    if you dig out all spaces around a certain piece of wall:

    ....
    ..#.
    ....

    does it become a pillar? Or is it just a small section of wall.


    > > * Highly flavored rooms, like throne rooms, libraries, storage areas,
    > > healing areas.
    >
    > That's part of the reason I decided to do this in the first place. I
    > wanted to see some thematic dungeons, with all the rooms you would
    > expect in a castle/tower/forest/whatever.

    Make sure, then, that your dungeon generator is oriented around
    generating interesting *levels*, with interesting rooms just being a
    means to that end. Don't make it too room-oriented, cos a bunch of
    interesting rooms stuck together does not necessarily make an
    interesting coherent level. I think this has to be built into the code
    at a deep level.

    A.
  5. Archived from groups: rec.games.roguelike.development (More info?)

    Antoine wrote:

    <snip>

    > You'll find that other dungeon generators also allow handcrafted rooms.
    > Not new but well worth doing.

    Oh, I know. I have no delusions of actually creating anything new. ;-)

    > Linking events into the map generation, like your 'drowning deathtrap',
    > would really be a new feature, I'd be interested to see what came of
    > that.

    It's a tricky feature, and it's a pain to iron out all the bugs in it.
    But, once the bugs are out, I see some great gameplay potential there.

    > You should also allow the script to influence the AI of the monsters
    > (either scripted or random) within the room. For example, when you
    > stand on a certain tile, the monsters will come after you, but will not
    > leave a certain area. Or, the monsters patrol in circuits around a
    > particular track through the room. And soo on.

    I hadn't thought of allowing the AI to be influenced. I'm not sure
    how I'd implement that, since, as of now, each creature has his own AI
    script, which is stored individually. Maybe allow the room scripts to
    make on-the-fly adjustments to the AI scripts of monsters that are
    within range? Could be tricky, but doable. Good idea!


    --
    My projects are currently on hold, but I do have
    some junk at the site below.

    http://www.freewebs.com/timsrl/index.htm

    --
  6. Archived from groups: rec.games.roguelike.development (More info?)

    konijn_ wrote:
    >>It'd be nice to play a game where every room was interesting
    >
    > 'When everybody is special, nobody is special' , The incredibles ;)
    >
    > Anway, I am also thinking about a Java Interface for layout generators
    > that could be generic enough to be used by multiple projects but
    > specific
    > enough that sharing generators would actually be usefull.

    I'd be interested in checking it out, if/when you get it done. I'm no
    Java coder myself, but I'm familiar enough to read code written in it,
    thanks to it's syntactical simmilarities to C++.

    > Have you checked out the angband vault file ?

    No, I haven't. I'm assuming you're referring to the source code file
    that handles vaults, right? If so, I'll have to give it a look.


    --
    My projects are currently on hold, but I do have
    some junk at the site below.

    http://www.freewebs.com/timsrl/index.htm

    --
  7. Archived from groups: rec.games.roguelike.development (More info?)

    Arakon wrote:
    > It's a cool idea!
    >
    > I've been playing with random generation in Lua for a while now also.
    > I have some things that work pretty well, but am still refining the
    > ideas. I'm very interested to see someone else's approach.

    I always love to see what other people have done. It's a great way to
    learn new ways to handle implementation problems, as well as get some
    fresh ideas. It's a pity yours isn't released yet, cause I'd love to
    take a glance at that, too. :-)

    > That being said, a lot of the "unique" room ideas I would have would
    > have to be tied to gameplay. Simple "interesting" rooms would simply
    > add some patterns, or change room geometry slightly, but the more
    > interesting ones should add cool gameplay options.

    My system should allow for some rather generic gameplay possibilities,
    such as water, lava, shifting platforms, etc. Stuff that many games
    can take advantage of. But, in the end, the basis for the whole
    project is to allow interesting room designs, with scripted room
    events coming second.

    > Some of my approaches to spice things up:
    > * Rooms can specify treasure spots as well as monster spawn spots (not
    > actually specifying what goes in those spots)

    I was thinking of doing the same thing. Possibly even allowing a
    "gauntlet"-style spawn point, where monsters keep flowing until the
    generator is broken, or some other condition is met.

    > * pillers

    I'm thinking about implementing pillars a little differently, compared
    to the standard RL approach. I think that I'll have them block LOS
    only a little bit, so that the main use for pillars is for tactical
    reasons, and not for hiding. Basically, the only way you could avoid
    being seen, is if you are flush with the pillar, and exactly opposite
    of the other entity. For example:

    ....S..o@.. ('o' is the pillar. The player can not be seen here.)

    ....S..o.@. ('o' is the pillar. The player _can_ be seen.)

    In reality, most pillars do a poor job of obscuring view, unless
    they're thicker than normal. This way, stealth becomes tricky, and
    that should make things more interesting, given my games strong focus
    on stealth.

    > * moats in the middle
    > * Special things around doors: Pillars, candles, water
    > * Flooded rooms with pads that can be moved on to

    Definitely. I'm hoping to have moving/floating platforms, that add an
    extra level of excitement to the game. Fighting on moving platforms
    can be quite a tricky endeavor. ;-)

    > * Highly flavored rooms, like throne rooms, libraries, storage areas,
    > healing areas.

    That's part of the reason I decided to do this in the first place. I
    wanted to see some thematic dungeons, with all the rooms you would
    expect in a castle/tower/forest/whatever.

    > * Dens or barracks where creatures sleep - beds, sleeping creatures,
    > etc

    Same idea as above. Enhances the mood, and deepens the immersion.
    Not counting the gameplay benefits. How could an "assassin" character
    resist the urge to slaughter half the king's guards while they slept.
    Rather delightful possibilities. :-)

    > On a slightly different topic - the part that could really add some
    > nice stuff to random levels is dependencies. Think rogue-like meets
    > Zelda. Doors and keys could be separated with pathfinding algorthms.
    > I've played around with this a bit, and it gives some really nice
    > results.
    >
    > Doors and keys can be generalized more to be "problem" and "solution",
    > so that a "problem" could be a room flooded with Lava, while the
    > "solution" could be a medalion that needs to be inserted into a
    > particular block. Pathfinding would assure that the solution was
    > accessable in the proper order.
    >
    > That could be beyond what you're looking for though. so far, I've been
    > having some fun playing with it though, and it seems to be a solid
    > idea.

    I like it, but in moderation. Nothings more aggravated than playing
    one of the later "Tomb Raider" games, which always devolves into a
    game of "run across the level, grab the key, run all the way back,
    unlock door, run back across the level, grab the other key, run all
    the way back, unlock the door, ad infinitum". In moderation, like, in
    Zelda, would be fine indeed, though. I always loved those little
    puzzle game elements. Especially if they're made into actual puzzles,
    like some of the "Resident Evil" games did (although they went way
    overboard, and got kind of silly).

    > My current framework is more "heavy" then I intended though - I was
    > looking for ways of making more interesting overall layouts (Castle
    > style, cave like, with "complexes" attached, etc), and I fear I over
    > enginered.

    *sigh* The curse of all programmers. My current goal is to try and
    live by the old KISS philosophy. The system should be fairly simple.
    It's up to the room scripter to make it as complex as they wish,
    even though the implementation should be simple.

    > Good luck, and looking forward to seeing what you come up with!

    Likewise. :-)


    --
    My projects are currently on hold, but I do have
    some junk at the site below.

    http://www.freewebs.com/timsrl/index.htm

    --
  8. Archived from groups: rec.games.roguelike.development (More info?)

    Timothy Pruett <drakalor.tourist@gmail.com> wrote:
    > I'm currently piecing together some RL development modules, to make
    > future projects of mine easier to work with. Right now, I'm trying to
    > work out a different way of doing dungeon generation.

    You could always do away with scripts... and make every room and hallway
    it's own object... (as in OOP) so that there could be different types
    with different effects.

    --
    Jim Strathmeyer
  9. Archived from groups: rec.games.roguelike.development (More info?)

    Dnia Tue, 07 Jun 2005 17:08:43 -0400,
    Timothy Pruett napisal(a):

    > Each room and hall will be stored in their individual script file.
    > These script files will store any room specific game scripts, as well
    > as the actual room design. This will give the game more of a
    > distinctly different look. Most RLs use random dungeon generators to
    > produce the layout of the map only, and just use generic, plain rooms
    > and halls. This will allow for unique, handcrafted rooms to be placed
    > all throughout the levels, as opposed to the bland, ordinary
    > rectangular rooms.

    Isn't doing your own room files, or rooms with scripts, going to break
    the thing as a whole? I mean those scripts have to interact. You can't
    just come in there and write a new piece of script (and a new map) and
    expect that it all works?

    Look at your own example. What's supposed to happen when the flood reaches
    doors? And if there's a lava room next door?

    > The options would really be fantastic. Granted, the above example was
    > weak, but it was just a quick random idea. It'd be nice to play a
    > game where every room was interesting, and unique, and full of options.

    I'm not sure whether the rooms make an interesting game by itself. It
    could turn the game into room-based puzzle solving.
    As I see roguelike maps, they offer three things:

    1. Tactically interesting information. This could be, with some effort and
    a lot of interaction between room scripts achieved with this approach,
    I guess. Things like counting the number of exits form the room, pillars,
    long corridors, corners, loops, traps, obstacles, open spaces, etc. are
    examples of elements that could be used to make the map tactically
    interesting.

    2. Strategically interesting information. This can be achieved to some
    extent by use of themes (there are mummies on this level, I better get
    some fire-based weapons/spells), varying the algorithms for picking,
    placing and connecting rooms, etc. Also, to use strategy, you need some
    information in advance.

    3. Food for my imagination. If it's supposed to be caves, let it look like
    caves. If it's forest, I want at least a couple of trees. If it's a tower,
    it could be round, etc.

    > Anybody who has a cool idea for a room, or hall, please post it.
    > Likewise, anyone with a good suggestion, or critique of my idea,
    > please post it as well. I'm looking for all the feedback I can get.

    You might look for a discussion on maps that took place several months
    ago on this group. A nice format for maps was designed. Plus some maps
    were posted.

    --
    Radomir `The Sheep' Dopieralski @**@_
    (^^) 3 Bee!
    . . . ..v.vVvVVvVvv.v.. .
  10. Archived from groups: rec.games.roguelike.development (More info?)

    The Sheep wrote:
    > Dnia Tue, 07 Jun 2005 17:08:43 -0400,
    > Timothy Pruett napisal(a):
    >
    >
    >>Each room and hall will be stored in their individual script file.
    >>These script files will store any room specific game scripts, as well
    >>as the actual room design. This will give the game more of a
    >>distinctly different look. Most RLs use random dungeon generators to
    >>produce the layout of the map only, and just use generic, plain rooms
    >>and halls. This will allow for unique, handcrafted rooms to be placed
    >>all throughout the levels, as opposed to the bland, ordinary
    >>rectangular rooms.
    >
    >
    > Isn't doing your own room files, or rooms with scripts, going to break
    > the thing as a whole? I mean those scripts have to interact. You can't
    > just come in there and write a new piece of script (and a new map) and
    > expect that it all works?

    New maps would work fine. My only concern is how to handle the
    scripts. I still haven't found a solution for the problem. On the
    one hand, I could keep room scripts local to the rooms they originate
    in, but that would be a rather ugly solution, and would be far too
    exploitable. Alternatively, I'm considering taking the more complex
    route, and establishing a system of "canceling effects".

    > Look at your own example. What's supposed to happen when the flood reaches
    > doors? And if there's a lava room next door?

    Still working on that. One option would be to keep the flood local to
    the room. But that seems like a weak solution. What I'll probably
    end up doing is establishing a system of "canceling effects". With
    that system, it would determine what would happen when different
    effects hits each other. Continuing with your above example, if the
    water hit the lava, several things would likely happen. I'd probably
    determine that a certain amount of water flowing into lava would cause
    the lava to cool, turning it into a normal floor space. Perhaps it
    would take 50 tiles worth of water to cool one lava space.

    The benefit of such a system would be that the player would have more
    solutions to a particular problem. The downside of such a system
    would be the increased chance of bugs popping up. But, bugs are a
    part of the development process, and can always be fixed and ironed
    out later.

    >>The options would really be fantastic. Granted, the above example was
    >>weak, but it was just a quick random idea. It'd be nice to play a
    >>game where every room was interesting, and unique, and full of options.
    >
    >
    > I'm not sure whether the rooms make an interesting game by itself. It
    > could turn the game into room-based puzzle solving.
    > As I see roguelike maps, they offer three things:
    >
    > 1. Tactically interesting information. This could be, with some effort and
    > a lot of interaction between room scripts achieved with this approach,
    > I guess. Things like counting the number of exits form the room, pillars,
    > long corridors, corners, loops, traps, obstacles, open spaces, etc. are
    > examples of elements that could be used to make the map tactically
    > interesting.

    Yeah. Tactical elements are one of the big reasons I'm choosing this
    approach. Tactics in many RLs (at least the tactics concerning the
    dungeon layout) are limited greatly, and usually consist of leading
    the enemies down hallways. From a level standpoint, most RLs don't
    reward or allow creative tactical behavior, or even allow varied
    tactical behavior.

    > 2. Strategically interesting information. This can be achieved to some
    > extent by use of themes (there are mummies on this level, I better get
    > some fire-based weapons/spells), varying the algorithms for picking,
    > placing and connecting rooms, etc. Also, to use strategy, you need some
    > information in advance.

    This is of less concern to me, but will end up being a natural
    occurance, without my involvement in facilitating it. Since I'm
    hoping to eventually produce thematic, interesting levels, strategetic
    information should sort of fall right into place.

    > 3. Food for my imagination. If it's supposed to be caves, let it look like
    > caves. If it's forest, I want at least a couple of trees. If it's a tower,
    > it could be round, etc.

    This was my main priority. Thematic levels help with the "mood" of
    the game, and help provide an immersive atmosphere. Plus, I'd really
    like my game to be "role-playing friendly", and that's harder without
    interesting variation and strong immersive elements.

    >>Anybody who has a cool idea for a room, or hall, please post it.
    >>Likewise, anyone with a good suggestion, or critique of my idea,
    >>please post it as well. I'm looking for all the feedback I can get.
    >
    >
    > You might look for a discussion on maps that took place several months
    > ago on this group. A nice format for maps was designed. Plus some maps
    > were posted.

    Yes, that thread actually sort of seeded my idea. I've toyed around
    with this idea for a long while now, but that thread made it seem like
    an outstanding idea, and provided some fresh inspiration for it.

    I'd definitely appreciate some fresh map/room ideas, since that thread
    was relatively lacking in maps. IIRC only a few were posted, which is
    a shame.


    --
    My projects are currently on hold, but I do have
    some junk at the site below.

    http://www.freewebs.com/timsrl/index.htm

    --
  11. Archived from groups: rec.games.roguelike.development (More info?)

    Dnia 7 Jun 2005 15:21:31 -0700,
    Arakon napisal(a):

    > Doors and keys can be generalized more to be "problem" and "solution",
    > so that a "problem" could be a room flooded with Lava, while the
    > "solution" could be a medalion that needs to be inserted into a
    > particular block. Pathfinding would assure that the solution was
    > accessable in the proper order.

    Be careful. If you add too much interlocking problems and solutions,
    you come up with something similar to the Tower of Hanoi -- a pretty
    simple problem, which can be solved mechanically, but gets rather tedious
    for mere humans because of it's size.

    Like, you know, figure out the right order of opening the locked doors,
    so that you never end up with no keys.

    --
    Radomir `The Sheep' Dopieralski @**@_
    (==) 3 Yawn?
    . . . ..v.vVvVVvVvv.v.. .
  12. Archived from groups: rec.games.roguelike.development (More info?)

    The Sheep wrote:
    > Dnia 7 Jun 2005 15:21:31 -0700,
    > Arakon napisal(a):
    >
    >
    >>Doors and keys can be generalized more to be "problem" and "solution",
    >>so that a "problem" could be a room flooded with Lava, while the
    >>"solution" could be a medalion that needs to be inserted into a
    >>particular block. Pathfinding would assure that the solution was
    >>accessable in the proper order.
    >
    >
    > Be careful. If you add too much interlocking problems and solutions,
    > you come up with something similar to the Tower of Hanoi -- a pretty
    > simple problem, which can be solved mechanically, but gets rather tedious
    > for mere humans because of it's size.
    >
    > Like, you know, figure out the right order of opening the locked doors,
    > so that you never end up with no keys.

    I dunno. Most games don't run into this problem. Granted, most games
    aren't random at all, so that could be why. One could always go the
    Zelda route, and make all keys generic, so that any key (excluding the
    boss room key) could be used to unlock any room. Personally, I think
    Metroid had a good way of handling the "doors and keys" situation, by
    making certain weapons/powerups necessary to access new areas, so that
    as the player grew in power, new parts of the game opened up. It
    seemed so better than certain games, which, when a player tries to
    enter the new area, just respond with a lame "must be level 15 or
    higher to enter the mountain pass".


    --
    My projects are currently on hold, but I do have
    some junk at the site below.

    http://www.freewebs.com/timsrl/index.htm

    --
  13. Archived from groups: rec.games.roguelike.development (More info?)

    In article <XamdnfCfUtQK_TvfRVn-2A@adelphia.com>, strathWHATEVERIGETENOUGHSPAMANYWAYS@ipass.net (Jim Strathmeyer) wrote:
    >Timothy Pruett <drakalor.tourist@gmail.com> wrote:
    >> I'm currently piecing together some RL development modules, to make
    >> future projects of mine easier to work with. Right now, I'm trying to
    >> work out a different way of doing dungeon generation.
    >
    >You could always do away with scripts... and make every room and hallway
    >it's own object... (as in OOP) so that there could be different types
    >with different effects.

    For those that think OOP is the answer to everything:
    http://www.dcs.shef.ac.uk/~tom/Objects/toaster.html
    :^)

    Alan
  14. Archived from groups: rec.games.roguelike.development (More info?)

    "Timothy Pruett" <drakalor.tourist@gmail.com> wrote:
    > I'm currently piecing together some RL development modules,
    > to make future projects of mine easier to work with.
    > Right now, I'm trying to work out a different way of doing
    > dungeon generation.
    >
    > Firstly, I'm going to have the entire dungeon generation
    > process done through Lua, with the output (actual dungeon
    > map) getting sent back to the main C++ program. By doing
    > this, it will be easier for the end-user to both tweak the
    > general algorithm for the dungeon layout, but can also
    > tweak the individual rooms and halls.
    >
    > Each room and hall will be stored in their individual
    > script file. These script files will store any room
    > specific game scripts, as well as the actual room design.
    > This will give the game more of a distinctly different look.
    > Most RLs use random dungeon generators to produce the layout
    > of the map only, and just use generic, plain rooms and
    > halls. This will allow for unique, handcrafted rooms to be
    > placed all throughout the levels, as opposed to the bland,
    > ordinary rectangular rooms.

    The scripts could be either be completely detailed for unique
    rooms (like the one you mentioned below), or be somewhat
    templatized. An initial template could be something that
    generates 'bland, ordinary rectangular rooms' to get a
    working prototype going of the script interpreter. And then
    after development time, the script could be further detailed
    to add some intelligence to situations when the rng
    generates bland rooms.


    > Anyone could freely write a new room file, allowing them to
    > create any room they could think of and could freely plug it
    > into the main generation script. For example, someone could
    > toss out a room like this:
    >
    > ############
    > #..........#
    > #...#..#...#
    > #...#..#...#
    > #.###..###.#
    > #....==....#
    > #.###..###.#
    > #...#..#...#
    > #...#..#...#
    > #..........#
    > ############
    >
    > Where '.' is floor, '#' is wall, and '=' is water. Then they
    > could write a script to cause the water to slowly expand,
    > causing a sort of drowning deathtrap.
    >
    > The options would really be fantastic. Granted, the above
    > example was weak, but it was just a quick random idea. It'd be
    > nice to play a game where every room was interesting, and
    > unique, and full of options.
    >
    > Anyways, I'm nearing completion with this module, and then I
    > hope to be able to release a walkaround demo, with random
    > dungeons, within the next week or so, to show it off.
    >
    > Anybody who has a cool idea for a room, or hall, please post
    > it. Likewise, anyone with a good suggestion, or critique of my
    > idea, please post it as well. I'm looking for all the feedback
    > I can get.

    Map generation and script interaction could get really complex if
    scripts have a lot of different features and if room placement is
    completely random. I would initially ignore the random dungeon
    generation portion and write several scripts, and then write
    one or more map scripts that each detail one level of the game,
    using the room scripts as modules. That would be the quickest
    easiest way to create a walkaround demo of your idea.

    As far as the random map generation portion, I do have a suggestion
    of something that I'm currently designing. In the field of
    computer-generated music there is a concept called convolution.
    A computer program randomly composes (and possibly plays) music in
    real-time in the style of some composer. The program would be
    written such that phrases of music from a song or songs written by
    the composer (for example, Bach, Beethoven, etc.) are recorded as
    an event history. The program runs a while loop, and given the
    last n events or notes or phrases, the program determines that
    there are certain percentage possibilities of what note should
    occur next. The next note is added to the event history, and the
    program looks at the most recent n notes, which in essence changes
    the seed of the rng.

    Map generation could be done similarly. There would be a starting
    room or area, possibly from a set of scripts that are reserved for
    the entrance room of a dungeon/castle/cave/level/etc. Then there
    would be certain possibilities as to what the next script or data
    the generator picks to add to the map. following a certain path
    (since music is time-linear while maps are spatial and can branch)
    would determine the current 'map history' for the generation algo.

    Then there could be some tweaks to make it all work, if one path of
    the algo runs into pre-existing space, randomly determine if the
    areas are connected or not. And if a specific theme is necessary
    (e.g. lava rooms and water rooms shouldn't be on the same level),
    make that an attribute of the level.


    Those are my thoughts, hopefully they are helpful. You're script
    idea is actually a really good idea. I'm somewhat considering
    script possibilities for my project, although I haven't decided
    yet on a specific scripting language. You'd recommend Lua?


    crichmon
  15. Archived from groups: rec.games.roguelike.development (More info?)

    "crichmon" <crichmon@gmail.com> wrote:
    >
    > As far as the random map generation portion, I do have a suggestion
    > of something that I'm currently designing. In the field of
    > computer-generated music there is a concept called convolution.
    > A computer program randomly composes (and possibly plays) music in
    > real-time in the style of some composer. The program would be
    > written such that phrases of music from a song or songs written by
    > the composer (for example, Bach, Beethoven, etc.) are recorded as
    > an event history. The program runs a while loop, and given the
    > last n events or notes or phrases, the program determines that
    > there are certain percentage possibilities of what note should
    > occur next. The next note is added to the event history, and the
    > program looks at the most recent n notes, which in essence changes
    > the seed of the rng.
    >
    > Map generation could be done similarly. There would be a starting
    > room or area, possibly from a set of scripts that are reserved for
    > the entrance room of a dungeon/castle/cave/level/etc. Then there
    > would be certain possibilities as to what the next script or data
    > the generator picks to add to the map. following a certain path
    > (since music is time-linear while maps are spatial and can branch)
    > would determine the current 'map history' for the generation algo.

    Arg! I forgot to mention something else about that idea. It
    requires several pre-existing level designs. So after desiging some
    script rooms, and then designing some script levels, create the event
    possibilities based on those designs. The more levels you design,
    the smarter the generation algo.


    crichmon
  16. Archived from groups: rec.games.roguelike.development (More info?)

    Ian Badcoe wrote:
    > Hi,
    > [[assuming doors are paired with specific keys and its not any
    > key for any door]]
    >
    > The problem of "puzzles" and random dungeon generation is a
    > matter of topology. e.g. every "key" or key-like object (switch,
    > teleporter-battery...) has to be:
    >
    > 1) on the right side of its door
    > 2) not blocked by any door who's key is on the far side of its door
    >
    > If the dungeon is constructed topologically instead of
    > geometrically (e.g. first create a graph of nodes and edges, then in a
    * SNIP *

    Ahh! Yes, thanks. I was just about to post that.
    That's basically how I'm doing it, but went for a simpler scheme of
    just numbering the puzzle systems to make sure that a key to a puzzle
    cannot be placed in a path the player cannot reach.

    I'm using unique keys of course, but the point is it is not just
    "keys". It is a more general "solution". Solutions can be anything
    from a physical key, to a torch that needs to be lit. It can also be
    more action oriented, like kill-the-boss, or clear-the-room of specific
    monsters, or move the statue.

    I'll agree, too many of these puzzles would be quite annoying. Putting
    a few in though can make things more interesting for the player,
    instead of the same-old-same-old.
  17. Archived from groups: rec.games.roguelike.development (More info?)

    Dnia Tue, 07 Jun 2005 19:38:28 -0400,
    Timothy Pruett napisal(a):

    > konijn_ wrote:
    >> Have you checked out the angband vault file ?
    > No, I haven't. I'm assuming you're referring to the source code file
    > that handles vaults, right? If so, I'll have to give it a look.

    I think he rather meant the data file that Angband uses to store
    predefined rooms.

    --
    Radomir `The Sheep' Dopieralski @**@_
    (: ) 3 Snap!
    . . . ..v.vVvVVvVvv.v.. .
  18. Archived from groups: rec.games.roguelike.development (More info?)

    Dnia Tue, 07 Jun 2005 19:57:25 -0400,
    Timothy Pruett napisal(a):

    > I'm thinking about implementing pillars a little differently, compared
    > to the standard RL approach. I think that I'll have them block LOS
    > only a little bit, so that the main use for pillars is for tactical
    > reasons, and not for hiding. Basically, the only way you could avoid
    > being seen, is if you are flush with the pillar, and exactly opposite
    > of the other entity. For example:
    >
    > ...S..o@.. ('o' is the pillar. The player can not be seen here.)
    >
    > ...S..o.@. ('o' is the pillar. The player _can_ be seen.)

    Where should you hide in this situation? Is it somehow marked?

    ..S.........
    ........o1..
    ........32..

    --
    Radomir `The Sheep' Dopieralski @**@_
    (TT) 3 Waaah!
    . . . ..v.vVvVVvVvv.v.. .
  19. Archived from groups: rec.games.roguelike.development (More info?)

    Timothy Pruett wrote:
    >
    > I'm not too concerned. All rooms have special "type" flags and unique
    > IDs. The flags dictate things such as setting type, room type,
    > suggested rarity, etc. Coupled with unique IDs, generating thematic
    > levels becomes a relatively easy task, for the level scripter.
    >
    > For example, if I wanted to make an abandoned castle, I'd probably
    > create a level script that minimizes empty space, as well as arrange
    > rooms more closely together, to give it the "feel" of a real
    > building's layout. Then, when I needed to place a room, I'd fill it
    > with randomly chosen rooms, that contain Castle, Fortress, or Military
    > flags, also taking note of their suggested rarity. To ensure the
    > proper castle feel, I'd probably require at least one room of each
    > specific type: Armory, Treasury, Stables, Barracks, etc. And then, if
    > I wanted a specific look to the main throne room, I'd ensure that it
    > was placed far from the entrance, and ensure that a specific throne
    > room was placed, by calling it's specific ID.

    This is the part that has always seemed the most complex to me.
    Requirements, and specifics. Placing specific rooms at specific
    places, and then connecting them with specific rooms, and, on top of
    it, possibly specific LAYOUT to those rooms: Caves would wind,
    buildings would want nice orderly hallways (with other rooms scattered
    about), etc.

    It seems to me that most would have something like this: Layout main
    structure, place start room, place special rooms, place exit.

    So, my next question:

    Are you defining the levels via a structure (table/etc), or are you
    requiring some hand scripting with functions that abstract the entire
    thing?

    Currently I'm going with table structure, which is making things more
    complex, instead of less complex like I intended. I don't know if it
    would help to use function calls, but maybe it is worth a try? Doing
    state-based changes, with parameters, seems like it would be simple to
    understand. The support structure I have would accept either OK.

    > The limitations imposed by the system are relatively few, mainly
    > because I'm trying to keep the system simple. Any behavior that's
    > desired, that's not in the base system, could be added through game
    > logic scripting. But I'm getting a little ahead of myself. ;-)

    I'm quite interested in how you handled/are-handling the Requirements
    and such. especially if you'd allow certain rooms to be joined to only
    other rooms. What about rooms that need to be next to eachother?
    Audience Chamber to Throne Room to Vault ?

    You mentioned in a previous post - My stuff is somewhat released. I've
    done all the random map parts for RandEgoboo (3d roguelike). The newer
    stuff I've been playing with, such as doors/puzzles is still
    unreleased, and not quite ready for public viewing yet. Part of the
    problem is Egoboo is quite limited at moment, and the new version is
    still very much under construction.

    I could post it if you're interested though. The code is large - I
    have a stand-alone EXE that can generate an HTML file to make testing
    possible though.
  20. Archived from groups: rec.games.roguelike.development (More info?)

    Dnia Tue, 07 Jun 2005 20:01:48 -0400,
    Timothy Pruett napisal(a):

    > The Sheep wrote:
    >> Dnia 7 Jun 2005 15:21:31 -0700,
    >> Arakon napisal(a):
    >> Like, you know, figure out the right order of opening the locked doors,
    >> so that you never end up with no keys.
    > One could always go the
    > Zelda route, and make all keys generic, so that any key (excluding the
    > boss room key) could be used to unlock any room.

    That's exactly what I mean. If the all the keys are unique, the worst
    you can come up with is just running across all the level back and forth
    to open door, get key, open door, etc.

    But when all the keys fit, and what's worse, they get used up, you come
    up with a rather nasty puzzle, and a one that the player doesn't have
    enough information to solve. Look at this map (it's simplified):

    #########################
    #...#...#...#...#...#...#
    #&&&#.&.#.&&#.&.#...#.&&#
    #...#...#...#...#...#...#
    ##+###+###+###+###+###+##
    #...#...#.......#...#...#
    #...+...+..&<...+.&.+.&.#
    #...#...#.......#...#...#
    ##+###+###+###+###+###+##
    #...#...#...#...#...#...#
    #&&&#&&.#...#.&&#&&&#&&&#
    #...#...#...#...#...#...#
    #########################

    ..: Floor
    #: Wall
    <: Floor, up staircase
    +: Locked Door
    &: Floor, key

    Can you figure out the proper order of opening the doors so that
    you can open them all? Can you do it when you don't know what's
    inside a room before you open it?

    --
    Radomir `The Sheep' Dopieralski @**@_
    (><) 3 Ouch!
    . . . ..v.vVvVVvVvv.v.. .
  21. Archived from groups: rec.games.roguelike.development (More info?)

    Dnia Tue, 07 Jun 2005 20:33:45 -0400,
    Timothy Pruett napisal(a):

    > The Sheep wrote:
    >> Dnia Tue, 07 Jun 2005 17:08:43 -0400,
    >> Timothy Pruett napisal(a):

    >> You might look for a discussion on maps that took place several months
    >> ago on this group. A nice format for maps was designed. Plus some maps
    >> were posted.
    >
    > Yes, that thread actually sort of seeded my idea. I've toyed around
    > with this idea for a long while now, but that thread made it seem like
    > an outstanding idea, and provided some fresh inspiration for it.
    >
    > I'd definitely appreciate some fresh map/room ideas, since that thread
    > was relatively lacking in maps. IIRC only a few were posted, which is
    > a shame.

    Well, it's hard to make a 'general purpose room' when you don't know
    how it should be used anyways.

    Oh, you could check out my old attempt at writing a roguelike game,
    it used a level generator similar to what you describe -- and it gave
    pretty nice results despite the fact the room file was pretty small.

    You can find it at http://atos.wmid.amu.edu.pl/~sheep/projects/yarg/
    I can't remember if I posted the source... If you're interested, I'll
    look for it and put there. It's turbo pascal ;)

    --
    Radomir `The Sheep' Dopieralski @**@_
    (Xx) 3 ...
    . . . ..v.vVvVVvVvv.v.. .
  22. Archived from groups: rec.games.roguelike.development (More info?)

    Yes. Thanks.
  23. Archived from groups: rec.games.roguelike.development (More info?)

    The Sheep wrote:
    > Dnia Tue, 07 Jun 2005 19:57:25 -0400,
    > Timothy Pruett napisal(a):
    >
    >
    >>I'm thinking about implementing pillars a little differently, compared
    >>to the standard RL approach. I think that I'll have them block LOS
    >>only a little bit, so that the main use for pillars is for tactical
    >>reasons, and not for hiding. Basically, the only way you could avoid
    >>being seen, is if you are flush with the pillar, and exactly opposite
    >>of the other entity. For example:
    >>
    >>...S..o@.. ('o' is the pillar. The player can not be seen here.)
    >>
    >>...S..o.@. ('o' is the pillar. The player _can_ be seen.)
    >
    >
    > Where should you hide in this situation? Is it somehow marked?
    >
    > ..S.........
    > ........o1..
    > ........32..

    It'd be 2, in that case. The only "safe" square, in terms of hiding,
    will always be the opposite square adjacent to the pillar.
    Unfortunately, because of the discrete units of measurement/distance
    present in any ASCII/tiled game, it isn't always so obvious, and the
    player just has to make a leap of faith, I suppose. I don't know.
    Looking at your example, I may expand it to 2 squares, in instances
    like this, since the player should be able to hide behind either 1 or
    2. My pathfinder would currently only see 2 as being a possibility,
    though.


    --
    My projects are currently on hold, but I do have
    some junk at the site below.

    http://www.freewebs.com/timsrl/index.htm

    --
  24. Archived from groups: rec.games.roguelike.development (More info?)

    Timothy Pruett wrote::

    > Anybody who has a cool idea for a room, or hall, please post it.
    > Likewise, anyone with a good suggestion, or critique of my idea, please
    > post it as well. I'm looking for all the feedback I can get.

    H-World uses room templates, too. But there aren't so many good rooms yet.

    If you want to take a look, download the latest package from sourceforge:

    https://sourceforge.net/projects/h-world/

    and look into the "default/data/rooms" folder, there most of the room
    templates are stored.

    For historical reasons a few are stored in the "default/data" directory
    itself :(

    A guide to H-World room templates can be found here:
    http://h-world.simugraph.com/pmwiki/pmwiki.php?n=Hw.FileBasedLevels

    The room templates started as level templates therefore the name, but
    later were mostly used for single rooms or small buildings/structures
    withing larger, random and non-random, maps.

    --
    c.u. Hajo
  25. Archived from groups: rec.games.roguelike.development (More info?)

    Timothy Pruett wrote:

    > I generally use a set of algorithms, which produce a crude layout of
    > the desired level, all the while making sure that certain rooms get
    > included, and, if necessary, that certain rooms are connected in some
    > way, and the rest is just filler.

    Do you assure that everything has connections as it is built, or do you
    add the connections later? Aka, do you place the "required" rooms,
    and then worry about hallways and connections, or do you keep adding
    rooms in various directions, sprinkling in required rooms as you go?

    > One of the things that made things a bit easier to work with was my
    > shift from static map dimensions, to dynamic map dimensions. In its
    > current state, it's possible to create the map exactly how you want
    > it, without any size constraints, and when the map is finished, the
    > white space along the edges gets shaved off, and the map size gets
    > locked into place, and passed into C++ to handle from then on. A lot
    > of my old problems with map algorithms was that I'd run out of space
    > where I needed it, and would end up with a huge gap of unused space
    > off to the side, or something like that.

    I have this problem occasionally. The format I'm working with is
    limited to 128x128 though, or preferably 64x64. I was thinking about
    allowing the ability to dynamically recenter things for same reason you
    gave.

    > The algorithm used by that particular level script would handle such
    > requirements. The way I have it set up (currently, but it could
    > change), the rooms are placed in "zones", and then, when all rooms are
    > placed as necessary, they are all pushed together to eliminate white
    > space as necessary, and halls/doors are put in when needed. This
    > process is a bit slow though, and I may change it later.


    > I'd love to read the code. :-)

    I've posted it: arakon.m6.net/uploads/scripts.zip
    It's messy - I've been experimenting with all sorts of different
    methods to do things, trying to find the best solutions. The code
    needs trimming and cleaning badly. Your best bet is to email for info
    on what files are important to look at, or general philosophy..
    layout_themes.lua would probably be the one your most interested in.
    It does not include the executable - it's tied to some other stuff, and
    I'm not sure how to separate them nicely w/out a huge download.

    Part of the reason for the mess is from wanting explicit control over
    some of the overall layout though - If I want a castle-like layout, I
    want a set of hallways running around the entire thing, and then
    specific things in the center, and specific things outside. Doing all
    this in a data-driven table-fashion may not have been the best choice.
    There's lots of other options too.

    A basic rundown on my design:

    My systems based around Layout Generators, and Room Types (which have
    optional Features), and a Layout Template.

    The layout template specifies a generator to use (boxed-hallway,
    random-by-tag, grid-based, etc), and then which rooms to add in a
    weighted list. The individual room entries basically contain a type,
    as well as lots of other options: Name, which "phase" to allow the room
    to be added, children the room is required to have, enemy tags (none,
    specific ones, etc), door preferences, etc. Rooms can have tags of
    what they don't like to be around as well, and limits, and requirements
    (though they arn't strictly enforced - it only means it is selected
    first if possible)

    "structures" can also be used as a room - four hallways arranged as a
    box would be one type of structure, and is treated like a room during
    layout generation. The generator takes specified rooms to use as the
    hallways, and to join on the inside. There's also other "structures",
    but too much to go into here.

    I'm going to try to make a minimal interface to doing a more scripted
    approach to generation. I think now that some hand-tuned scripts will
    have better results then what I am doing now. Plus, learning the
    format for the layout theme is more complicated then doing it in
    straight script.

    I'm definitly looking forward to seeing how you go about things though!
  26. Archived from groups: rec.games.roguelike.development (More info?)

    "Antoine" <mail@guildgame.com> wrote in message
    news:1118191481.811372.241590@g43g2000cwa.googlegroups.com...
    >
    >> > * Highly flavored rooms, like throne rooms, libraries, storage
    >> > areas,
    >> > healing areas.
    >>
    >> That's part of the reason I decided to do this in the first place. I
    >> wanted to see some thematic dungeons, with all the rooms you would
    >> expect in a castle/tower/forest/whatever.
    >
    > Make sure, then, that your dungeon generator is oriented around
    > generating interesting *levels*, with interesting rooms just being a
    > means to that end. Don't make it too room-oriented, cos a bunch of
    > interesting rooms stuck together does not necessarily make an
    > interesting coherent level. I think this has to be built into the code
    > at a deep level.
    >

    In my opinion, the proper places in a level to script are larger:
    some regions of a level may be controlled by a certain subgenus of
    critter, then the scripts to generate regions for those critters can be
    used with thematic rooms. The border between various regions can be
    generic: say caves or hewn rooms left by some more civilised people.
    Of course fighting among the types of creature can be rampant or they
    can be united against the player. Some levels may be abandoned: no
    particular hideouts for specific creatures, and on these levels you may
    find rarer wandering solitary creatures. Other levels may be completely
    infested by a dominant species. The possibilities are endless: one
    really good excuse for a bunch of puzzles all after eachother is an
    ancient abandoned castle (slash ruin) with treasure still locked inside
    the vaults. I guess you could have ghostly things cruising around
    anyway.

    As Antoine correctly said all this needs to be orchestrated at a much
    deeper level than just room generation. The level generation code needs
    to be significantly altered. If you want several levels to be thematic
    as a whole, then the entire dungeon generation needs to be changed.

    It's a really, really big undertaking.

    --
    Glen
    L:Pyt E+++ T-- R+ P+++ D+ G+ F:*band !RL RLA-
    W:AF Q+++ AI++ GFX++ SFX-- RN++++ PO--- !Hp Re-- S+
  27. Archived from groups: rec.games.roguelike.development (More info?)

    Glen Wheeler wrote:
    > "Antoine" <mail@guildgame.com> wrote in message
    > news:1118191481.811372.241590@g43g2000cwa.googlegroups.com...
    >
    >>>>* Highly flavored rooms, like throne rooms, libraries, storage
    >>>>areas,
    >>>>healing areas.
    >>>
    >>>That's part of the reason I decided to do this in the first place. I
    >>>wanted to see some thematic dungeons, with all the rooms you would
    >>>expect in a castle/tower/forest/whatever.
    >>
    >>Make sure, then, that your dungeon generator is oriented around
    >>generating interesting *levels*, with interesting rooms just being a
    >>means to that end. Don't make it too room-oriented, cos a bunch of
    >>interesting rooms stuck together does not necessarily make an
    >>interesting coherent level. I think this has to be built into the code
    >>at a deep level.
    >>
    >
    >
    > In my opinion, the proper places in a level to script are larger:
    > some regions of a level may be controlled by a certain subgenus of
    > critter, then the scripts to generate regions for those critters can be
    > used with thematic rooms. The border between various regions can be
    > generic: say caves or hewn rooms left by some more civilised people.
    > Of course fighting among the types of creature can be rampant or they
    > can be united against the player. Some levels may be abandoned: no
    > particular hideouts for specific creatures, and on these levels you may
    > find rarer wandering solitary creatures. Other levels may be completely
    > infested by a dominant species. The possibilities are endless: one
    > really good excuse for a bunch of puzzles all after eachother is an
    > ancient abandoned castle (slash ruin) with treasure still locked inside
    > the vaults. I guess you could have ghostly things cruising around
    > anyway.
    >
    > As Antoine correctly said all this needs to be orchestrated at a much
    > deeper level than just room generation. The level generation code needs
    > to be significantly altered. If you want several levels to be thematic
    > as a whole, then the entire dungeon generation needs to be changed.
    >
    > It's a really, really big undertaking.

    I'm not too concerned. All rooms have special "type" flags and unique
    IDs. The flags dictate things such as setting type, room type,
    suggested rarity, etc. Coupled with unique IDs, generating thematic
    levels becomes a relatively easy task, for the level scripter.

    For example, if I wanted to make an abandoned castle, I'd probably
    create a level script that minimizes empty space, as well as arrange
    rooms more closely together, to give it the "feel" of a real
    building's layout. Then, when I needed to place a room, I'd fill it
    with randomly chosen rooms, that contain Castle, Fortress, or Military
    flags, also taking note of their suggested rarity. To ensure the
    proper castle feel, I'd probably require at least one room of each
    specific type: Armory, Treasury, Stables, Barracks, etc. And then, if
    I wanted a specific look to the main throne room, I'd ensure that it
    was placed far from the entrance, and ensure that a specific throne
    room was placed, by calling it's specific ID.

    If I (or anybody) wanted to create, say, a volcanic dungeon, created
    in the hollowed-out mountainside of an active volcano, and I couldn't
    find rooms that were appropriate, than I could simply create new rooms
    that fit the theme, and go through a similar process as above.

    Since the entire dungeon generation process is scripted, no changes
    will ever need to be made to the base C++ code, unless a special
    gameplay feature was desired, in which case, that could be scripted as
    well.

    That's part of the beauty of using scripts. One could create levels
    of any level of complexity. It's really up to the level scripter
    (which would probably be me, unless someone was interested in
    modding/quest creation/level creation/whatever) to decide how much
    effort will be expended making the level script, and how much
    complexity is desired. Someone, with little scripting experience,
    could concievably create a simple, interesting dungeon, filled with
    interesting rooms, in a very short amount of time.

    The limitations imposed by the system are relatively few, mainly
    because I'm trying to keep the system simple. Any behavior that's
    desired, that's not in the base system, could be added through game
    logic scripting. But I'm getting a little ahead of myself. ;-)

    Anyways, I hate to sound like I'm clinging onto some industry fad, but
    I really feel that *proper* scripting implementation is the magic
    bullet to solve many of the game development issues out there.
    Unfortunately, many games feature poorly implemented Lua (or
    whatever), and treat scripting as an afterthought. My goal is to
    design the entire project, from the ground up, with full integration
    with Lua. I have a feeling that my C++ code base will end up being
    relatively minimal. The only things that will likely be hardcoded in
    the game will be the display/sound code, the Lua bindings, and the
    core of the main game loop. But, once again, I'm getting a little
    ahead of myself, since this thread is about dungeon generation. ;-)


    --
    My projects are currently on hold, but I do have
    some junk at the site below.

    http://www.freewebs.com/timsrl/index.htm

    --
  28. Archived from groups: rec.games.roguelike.development (More info?)

    Hi,
    [[assuming doors are paired with specific keys and its not any
    key for any door]]

    The problem of "puzzles" and random dungeon generation is a
    matter of topology. e.g. every "key" or key-like object (switch,
    teleporter-battery...) has to be:

    1) on the right side of its door
    2) not blocked by any door who's key is on the far side of its door

    If the dungeon is constructed topologically instead of
    geometrically (e.g. first create a graph of nodes and edges, then in a
    second phase implement that graph as actual tiles, walls etc) then you
    can arrange rewrite rules for the graph such that the integrity of
    puzzles is maintained. Random dungeon generation can now proceed by
    starting with a minimal dungeon, and iteratively applying randomly
    chosen rewrites until sufficient complexity is reached.

    How I imagine this would work in practise is that all rewrites
    would take the form of inserting a new section into the existing
    graph. The insertion point can either be at prearranged "empty nodes"
    or found by analysis of the existing structure. Each section inserted
    would form a puzzle (or other feature) in itself. If a "well formed"
    puzzle, is one where all keys can be reached by travelling the graph
    in some order then the insertion of another well formed puzzle within
    it results in puzzle which is still well formed, e.g:

    Minimal dungeon:

    IN -> * -> OUT

    [[IN = stairs up, OUT = stairs down, * = insertion point]]

    Insert a "fight for the key" puzzle:

    IN -> * -> J -> * -> Door1 -> OUT
    |
    -> * -> Lair -> * -> Key1

    [[J = junction]]

    Insert an "annoying maze puzzle":

    -> * -> MAZE -> Key2
    |
    IN -> * -> J -> * -> J -> * -> Door2 -> * -> Door1 -> OUT
    |
    -> * -> Lair -> * -> Key1

    etc etc. Note how puzzles can get hidden behind other
    puzzles, complicated by the need to solve sub-puzzles, etc etc.

    I didn't cover the subject of loops or whether edges can be
    traversed in both directions, but neither is very complex and I can
    explain them to anyone interested. Also teleports, secret doors and
    traps will fit this scheme. Calculation/control of the level's
    overall difficulty is a little more complex, but only if, like me, you
    get the sudden urge to use the topology to work it out in a
    more-sophisticated way than previously.

    Also, this is not limited to puzzle creation, e.g. each "*"
    can be labelled with what kinds of expansion are allowed, in which
    case:

    -> shop* ->

    would indicate that any type of shop can be inserted, and:

    -> gate* -> house* -> house* -> house* -> house* ->
    | | | |
    shop* -> shop* -> WELL -> house*
    | | | |
    shop* -> elder* -> temple* -> dungeon_entrance*

    is a village. Actually this is a very crude way to encode a
    village and with a little more thought they can be variable size,
    layout or even socio-economic make-up :)

    Ian Badcoe


    Ian Badcoe (triangleigbgeneralaccount@yahoo.square.co.uk)
    (remove two shapes from this address to contact me)
    (do not use the reply address...it's full of spam)
  29. Archived from groups: rec.games.roguelike.development (More info?)

    The Sheep wrote:
    > Dnia Tue, 07 Jun 2005 20:33:45 -0400,
    > Timothy Pruett napisal(a):
    >
    >
    >>The Sheep wrote:
    >>
    >>>Dnia Tue, 07 Jun 2005 17:08:43 -0400,
    >>> Timothy Pruett napisal(a):
    >
    >
    >>>You might look for a discussion on maps that took place several months
    >>>ago on this group. A nice format for maps was designed. Plus some maps
    >>>were posted.
    >>
    >>Yes, that thread actually sort of seeded my idea. I've toyed around
    >>with this idea for a long while now, but that thread made it seem like
    >>an outstanding idea, and provided some fresh inspiration for it.
    >>
    >>I'd definitely appreciate some fresh map/room ideas, since that thread
    >>was relatively lacking in maps. IIRC only a few were posted, which is
    >>a shame.
    >
    >
    > Well, it's hard to make a 'general purpose room' when you don't know
    > how it should be used anyways.

    Not necessarily. Basic room architecture can certainly be applied to
    any game. Beyond that, you run into implementation specific issues.

    > Oh, you could check out my old attempt at writing a roguelike game,
    > it used a level generator similar to what you describe -- and it gave
    > pretty nice results despite the fact the room file was pretty small.
    >
    > You can find it at http://atos.wmid.amu.edu.pl/~sheep/projects/yarg/
    > I can't remember if I posted the source... If you're interested, I'll
    > look for it and put there. It's turbo pascal ;)

    I can't run the Windows binary, until I get a chance to go over to my
    friend's apartment, so I can use his PC. But yes, I'd _definitely_ be
    interested in seeing the source. :-)

    I may not be fully conversant in Pascal, but I can certainly read it.
    So yes, I'd definitely like to see the source. If you do put it up
    on your page, I'd appreciate it if you marked it as being source,
    maybe in parentheses after it, in English, since I can't read a word
    of Polish. ;-)


    --
    My projects are currently on hold, but I do have
    some junk at the site below.

    http://www.freewebs.com/timsrl/index.htm

    --
  30. Archived from groups: rec.games.roguelike.development (More info?)

    Dnia Wed, 08 Jun 2005 12:00:01 +0100,
    Ian Badcoe napisal(a):

    > If the dungeon is constructed topologically instead of
    > geometrically (e.g. first create a graph of nodes and edges, then in a
    > second phase implement that graph as actual tiles, walls etc) then you
    > can arrange rewrite rules for the graph such that the integrity of
    > puzzles is maintained. Random dungeon generation can now proceed by
    > starting with a minimal dungeon, and iteratively applying randomly
    > chosen rewrites until sufficient complexity is reached.

    Alternatively, you can create the graph either while generating the
    dungeon, or, with some effort, even after you've got it generated.

    Then just apply a bunch of path-finding, flow-counting and similar
    algorithms to modify already generated dungeon (add/remove/lock doors,
    drop keys, generate treasure-guarding monsters, etc.).

    Nice description of a method for generating the graph of dungeon. Thanks.

    --
    Radomir `The Sheep' Dopieralski @**@_
    (^^) 3 Bee!
    . . . ..v.vVvVVvVvv.v.. .
  31. Archived from groups: rec.games.roguelike.development (More info?)

    R. Alan Monroe wrote:
    > In article <XamdnfCfUtQK_TvfRVn-2A@adelphia.com>, strathWHATEVERIGETENOUGHSPAMANYWAYS@ipass.net (Jim Strathmeyer) wrote:
    >
    >>Timothy Pruett <drakalor.tourist@gmail.com> wrote:
    >>
    >>>I'm currently piecing together some RL development modules, to make
    >>>future projects of mine easier to work with. Right now, I'm trying to
    >>>work out a different way of doing dungeon generation.
    >>
    >>You could always do away with scripts... and make every room and hallway
    >>it's own object... (as in OOP) so that there could be different types
    >>with different effects.
    >
    >
    > For those that think OOP is the answer to everything:
    > http://www.dcs.shef.ac.uk/~tom/Objects/toaster.html
    > :^)

    Outstanding link! It took me a while to finally get a grip on OO
    madness, and I feel I'm finally at a point where I have control over
    OOP, instead of it controlling me. Very funny article. I think
    everyone who learns OOP suffers from this problem at the start.


    --
    My projects are currently on hold, but I do have
    some junk at the site below.

    http://www.freewebs.com/timsrl/index.htm

    --
  32. Archived from groups: rec.games.roguelike.development (More info?)

    Arakon wrote:
    >
    > Timothy Pruett wrote:
    >
    >>I'm not too concerned. All rooms have special "type" flags and unique
    >>IDs. The flags dictate things such as setting type, room type,
    >>suggested rarity, etc. Coupled with unique IDs, generating thematic
    >>levels becomes a relatively easy task, for the level scripter.
    >>
    >>For example, if I wanted to make an abandoned castle, I'd probably
    >>create a level script that minimizes empty space, as well as arrange
    >>rooms more closely together, to give it the "feel" of a real
    >>building's layout. Then, when I needed to place a room, I'd fill it
    >>with randomly chosen rooms, that contain Castle, Fortress, or Military
    >>flags, also taking note of their suggested rarity. To ensure the
    >>proper castle feel, I'd probably require at least one room of each
    >>specific type: Armory, Treasury, Stables, Barracks, etc. And then, if
    >>I wanted a specific look to the main throne room, I'd ensure that it
    >>was placed far from the entrance, and ensure that a specific throne
    >>room was placed, by calling it's specific ID.
    >
    >
    > This is the part that has always seemed the most complex to me.
    > Requirements, and specifics. Placing specific rooms at specific
    > places, and then connecting them with specific rooms, and, on top of
    > it, possibly specific LAYOUT to those rooms: Caves would wind,
    > buildings would want nice orderly hallways (with other rooms scattered
    > about), etc.
    >
    > It seems to me that most would have something like this: Layout main
    > structure, place start room, place special rooms, place exit.

    I generally use a set of algorithms, which produce a crude layout of
    the desired level, all the while making sure that certain rooms get
    included, and, if necessary, that certain rooms are connected in some
    way, and the rest is just filler.

    One of the things that made things a bit easier to work with was my
    shift from static map dimensions, to dynamic map dimensions. In its
    current state, it's possible to create the map exactly how you want
    it, without any size constraints, and when the map is finished, the
    white space along the edges gets shaved off, and the map size gets
    locked into place, and passed into C++ to handle from then on. A lot
    of my old problems with map algorithms was that I'd run out of space
    where I needed it, and would end up with a huge gap of unused space
    off to the side, or something like that. Now, I don't need to ever
    worry about the size, because the system handles all that for me.
    Before, the constructor for the map object (or one of the map methods)
    would set the dimensions dynamically, and then all scripting would be
    called to fill in the map. Plus, the maps look more believable, since
    real buildings and structures expand when they need the space, as
    well. It adds some consistancy and believability to the maps.

    > So, my next question:
    >
    > Are you defining the levels via a structure (table/etc), or are you
    > requiring some hand scripting with functions that abstract the entire
    > thing?

    Both, sort of.

    > Currently I'm going with table structure, which is making things more
    > complex, instead of less complex like I intended. I don't know if it
    > would help to use function calls, but maybe it is worth a try? Doing
    > state-based changes, with parameters, seems like it would be simple to
    > understand. The support structure I have would accept either OK.
    >
    >
    >>The limitations imposed by the system are relatively few, mainly
    >>because I'm trying to keep the system simple. Any behavior that's
    >>desired, that's not in the base system, could be added through game
    >>logic scripting. But I'm getting a little ahead of myself. ;-)
    >
    >
    > I'm quite interested in how you handled/are-handling the Requirements
    > and such. especially if you'd allow certain rooms to be joined to only
    > other rooms. What about rooms that need to be next to eachother?
    > Audience Chamber to Throne Room to Vault ?

    The algorithm used by that particular level script would handle such
    requirements. The way I have it set up (currently, but it could
    change), the rooms are placed in "zones", and then, when all rooms are
    placed as necessary, they are all pushed together to eliminate white
    space as necessary, and halls/doors are put in when needed. This
    process is a bit slow though, and I may change it later.

    > You mentioned in a previous post - My stuff is somewhat released. I've
    > done all the random map parts for RandEgoboo (3d roguelike). The newer
    > stuff I've been playing with, such as doors/puzzles is still
    > unreleased, and not quite ready for public viewing yet. Part of the
    > problem is Egoboo is quite limited at moment, and the new version is
    > still very much under construction.
    >
    > I could post it if you're interested though. The code is large - I
    > have a stand-alone EXE that can generate an HTML file to make testing
    > possible though.

    I'd love to read the code. :-)


    --
    My projects are currently on hold, but I do have
    some junk at the site below.

    http://www.freewebs.com/timsrl/index.htm

    --
  33. Archived from groups: rec.games.roguelike.development (More info?)

    Timothy Pruett wrote:
    >
    > I deal with connections after all the rooms are placed. One of my
    > biggest issues that kept coming up was when I'd place two "required"
    > rooms near each other, and require a connection between the two of
    > them. The problem was, if the doors to the rooms were facing away,
    > like this:

    OK, I see. That does make things easier in a way, atleast for specific
    types of dungeon designs.

    > It's definitely a change worth making. It's a relatively quick and
    > easy code fix, and makes things _so_ much easier to work with.

    Yeah - I see ways that would make it fairly straight forward to add.
    I'd still have to constrain the size of the entire map, but that should
    be easier then hoping it doesn't get "blocked in" at an edge like it
    does now.

    > Yeah. The key is to know which parts are best left data-driven, and
    > which parts are best scripted. I think I have a pretty good balance,
    > but I guess we'll all know in a week or two, when my walkaround demo
    > is out.

    I believe now that I went to far with the data-driven approach. You'll
    see for yourself. The templates for a dungeon layout are not very self
    explainitory.

    > It sounds like a good system, although a bit complicated. My original
    > plan used a heavily templated system like yours, but it eventually
    > became a bit too unwieldy for me, and I scrapped it in favor of a more
    > scriptable approach.

    The biggest problem is the overall dungeon template. Everything else
    is pretty straight forward to understand. It's quite powerful in a lot
    of ways, and most of it will be reusable as I switch to a more
    script-based approach.

    > Hmm... I'll have to read the code before I can formulate much of an
    > opinion on this one. Not quite sure what you mean by "structures".
    > By "structures", are you referring to some sort of architectural
    > constraint system?

    Constrait like, yes. It's more of a.. procedural type thing. An
    overall fixed design for multiple rooms. For example, you have a start
    room, and above it is added a boxed-hall "structure". This acts like a
    room in a way - it has a fixed size, but, instead of actually being a
    single room, it creates four rooms:

    ---------------
    | 1 |
    ---------------
    | | | |
    | 3 | | 4 |
    | | | |
    ---------------
    | 2 |
    ---------------
    | Start |
    | Room |
    ---------

    What it uses to make the hallways of the "structure" are parameterized
    as well. There's also a "Tiled" one, which takes multiple rooms and
    puts them in a line, aligned with a parent's room side (several rooms
    across the top of a room, or on the side, etc).


    > Yeah. I think Kornel would have ran into the same problem with his
    > data-driven Carceri engine. Luckily, he realized early on the power
    > of scripting. ;-)

    I agree, very much so.

    > I'll be interested how the final product looks myself, since it's been
    > rapidly changing and evolving. Not to sound too confident, but I
    > think it'll be quite an interesting sight!

    Looking forward to it!
    I've already started experimenting with a script-driven approach, and
    it is looking nice already. Almost all of my base system is reusable,
    though I may simplify parts of it, and I will definitly be deleting
    large portions of it later.
  34. Archived from groups: rec.games.roguelike.development (More info?)

    Arakon wrote:
    >
    > Timothy Pruett wrote:
    >
    >
    >>I generally use a set of algorithms, which produce a crude layout of
    >>the desired level, all the while making sure that certain rooms get
    >>included, and, if necessary, that certain rooms are connected in some
    >>way, and the rest is just filler.
    >
    >
    > Do you assure that everything has connections as it is built, or do you
    > add the connections later? Aka, do you place the "required" rooms,
    > and then worry about hallways and connections, or do you keep adding
    > rooms in various directions, sprinkling in required rooms as you go?

    I deal with connections after all the rooms are placed. One of my
    biggest issues that kept coming up was when I'd place two "required"
    rooms near each other, and require a connection between the two of
    them. The problem was, if the doors to the rooms were facing away,
    like this:

    ####### #######
    #.....# #.....#
    +.....# #.....+
    #.....# #.....#
    ####### #######

    The algorithm would act really screwy in situations like these, and
    would occasionally have bizarre results.

    I think I found a solution to the problem, though, and I'll be able to
    test it out this evening. I wrote a quick utility function that is
    capable of rotating a room. Before, the room would be oriented the
    same way it was in the room script file, but now, any room can be
    rotated 90, 180, or 270 degrees. So now, if faced with the above
    situation, I could simply rotate the room to the right until they fit
    properly. Also, there's a flag in the room script files that
    describes whether or not the level script should be able to ignore the
    already present doors, and create new one's on the fly.

    >>One of the things that made things a bit easier to work with was my
    >>shift from static map dimensions, to dynamic map dimensions. In its
    >>current state, it's possible to create the map exactly how you want
    >>it, without any size constraints, and when the map is finished, the
    >>white space along the edges gets shaved off, and the map size gets
    >>locked into place, and passed into C++ to handle from then on. A lot
    >>of my old problems with map algorithms was that I'd run out of space
    >>where I needed it, and would end up with a huge gap of unused space
    >>off to the side, or something like that.
    >
    >
    > I have this problem occasionally. The format I'm working with is
    > limited to 128x128 though, or preferably 64x64. I was thinking about
    > allowing the ability to dynamically recenter things for same reason you
    > gave.

    It's definitely a change worth making. It's a relatively quick and
    easy code fix, and makes things _so_ much easier to work with.

    >>The algorithm used by that particular level script would handle such
    >>requirements. The way I have it set up (currently, but it could
    >>change), the rooms are placed in "zones", and then, when all rooms are
    >>placed as necessary, they are all pushed together to eliminate white
    >>space as necessary, and halls/doors are put in when needed. This
    >>process is a bit slow though, and I may change it later.
    >
    >
    >
    >>I'd love to read the code. :-)
    >
    >
    > I've posted it: arakon.m6.net/uploads/scripts.zip
    > It's messy - I've been experimenting with all sorts of different
    > methods to do things, trying to find the best solutions. The code
    > needs trimming and cleaning badly. Your best bet is to email for info
    > on what files are important to look at, or general philosophy..
    > layout_themes.lua would probably be the one your most interested in.
    > It does not include the executable - it's tied to some other stuff, and
    > I'm not sure how to separate them nicely w/out a huge download.

    Awesome! I'll check it out later this evening. Much obliged, sir. :-)

    > Part of the reason for the mess is from wanting explicit control over
    > some of the overall layout though - If I want a castle-like layout, I
    > want a set of hallways running around the entire thing, and then
    > specific things in the center, and specific things outside. Doing all
    > this in a data-driven table-fashion may not have been the best choice.
    > There's lots of other options too.

    Yeah. The key is to know which parts are best left data-driven, and
    which parts are best scripted. I think I have a pretty good balance,
    but I guess we'll all know in a week or two, when my walkaround demo
    is out.

    > A basic rundown on my design:
    >
    > My systems based around Layout Generators, and Room Types (which have
    > optional Features), and a Layout Template.
    >
    > The layout template specifies a generator to use (boxed-hallway,
    > random-by-tag, grid-based, etc), and then which rooms to add in a
    > weighted list. The individual room entries basically contain a type,
    > as well as lots of other options: Name, which "phase" to allow the room
    > to be added, children the room is required to have, enemy tags (none,
    > specific ones, etc), door preferences, etc. Rooms can have tags of
    > what they don't like to be around as well, and limits, and requirements
    > (though they arn't strictly enforced - it only means it is selected
    > first if possible)

    It sounds like a good system, although a bit complicated. My original
    plan used a heavily templated system like yours, but it eventually
    became a bit too unwieldy for me, and I scrapped it in favor of a more
    scriptable approach.

    > "structures" can also be used as a room - four hallways arranged as a
    > box would be one type of structure, and is treated like a room during
    > layout generation. The generator takes specified rooms to use as the
    > hallways, and to join on the inside. There's also other "structures",
    > but too much to go into here.

    Hmm... I'll have to read the code before I can formulate much of an
    opinion on this one. Not quite sure what you mean by "structures".
    By "structures", are you referring to some sort of architectural
    constraint system?

    > I'm going to try to make a minimal interface to doing a more scripted
    > approach to generation. I think now that some hand-tuned scripts will
    > have better results then what I am doing now. Plus, learning the
    > format for the layout theme is more complicated then doing it in
    > straight script.

    Yeah. I think Kornel would have ran into the same problem with his
    data-driven Carceri engine. Luckily, he realized early on the power
    of scripting. ;-)

    > I'm definitly looking forward to seeing how you go about things though!

    I'll be interested how the final product looks myself, since it's been
    rapidly changing and evolving. Not to sound too confident, but I
    think it'll be quite an interesting sight!


    --
    My projects are currently on hold, but I do have
    some junk at the site below.

    http://www.freewebs.com/timsrl/index.htm

    --
  35. Archived from groups: rec.games.roguelike.development (More info?)

    Dnia Wed, 08 Jun 2005 12:28:26 -0400,
    Timothy Pruett napisal(a):

    > The Sheep wrote:
    >> You can find it at http://atos.wmid.amu.edu.pl/~sheep/projects/yarg/
    >> I can't remember if I posted the source... If you're interested, I'll
    >> look for it and put there. It's turbo pascal ;)

    > I can't run the Windows binary, until I get a chance to go over to my
    > friend's apartment, so I can use his PC. But yes, I'd _definitely_ be
    > interested in seeing the source. :-)

    > I may not be fully conversant in Pascal, but I can certainly read it.
    > So yes, I'd definitely like to see the source. If you do put it up
    > on your page, I'd appreciate it if you marked it as being source,
    > maybe in parentheses after it, in English, since I can't read a word
    > of Polish. ;-)

    Ok, I found it and uploaded. I also added a small disclaimer to this page,
    it sticks out like a sore thumb but I won't change it, because it has
    sentimental value to me.

    Be warned that it's from the days when I just recently switched to Pascal
    from QBasic, so the code might a little weird. No, there are no gotos. But
    there are no comments either.

    If something is unclear, just ask -- I'll take a look at it, try to
    remember what it is, consult my fortune teller and give some vague answer
    ;)
    --
    Radomir `The Sheep' Dopieralski @**@_
    ($s) 3 Ching!
    . . . ..v.vVvVVvVvv.v.. .
  36. Archived from groups: rec.games.roguelike.development (More info?)

    The Sheep wrote:
    > Dnia Wed, 08 Jun 2005 12:28:26 -0400,
    > Timothy Pruett napisal(a):
    >
    >
    >>The Sheep wrote:
    >>
    >>>You can find it at http://atos.wmid.amu.edu.pl/~sheep/projects/yarg/
    >>>I can't remember if I posted the source... If you're interested, I'll
    >>>look for it and put there. It's turbo pascal ;)
    >
    >
    >>I can't run the Windows binary, until I get a chance to go over to my
    >>friend's apartment, so I can use his PC. But yes, I'd _definitely_ be
    >>interested in seeing the source. :-)
    >
    >
    >>I may not be fully conversant in Pascal, but I can certainly read it.
    >> So yes, I'd definitely like to see the source. If you do put it up
    >>on your page, I'd appreciate it if you marked it as being source,
    >>maybe in parentheses after it, in English, since I can't read a word
    >>of Polish. ;-)
    >
    >
    > Ok, I found it and uploaded. I also added a small disclaimer to this page,
    > it sticks out like a sore thumb but I won't change it, because it has
    > sentimental value to me.
    >
    > Be warned that it's from the days when I just recently switched to Pascal
    > from QBasic, so the code might a little weird. No, there are no gotos. But
    > there are no comments either.

    I cut some QB code back in the day, myself. _Way_ back in the day,
    mind you, but I've been where you've been ;-). You should have seen
    my first bit of C code, coming from QB. What a mess it was.
    Craziness abounds, I tell you.

    Anyways...

    Just grabbed it, and, whew! I was afraid for a moment that the code
    would be in Polish as well. I can deal with difficult to understand
    variable naming and such, but I think I'd have trouble handling it in
    a whole other language! I do find it interesting that most foreign
    coders naturally seem to code (and comment) in English, Linus Torvalds
    being one of the most famous examples. I don't really know why that
    is, but it's definitely an interesting phenomenon.

    > If something is unclear, just ask -- I'll take a look at it, try to
    > remember what it is, consult my fortune teller and give some vague answer
    > ;)

    Sounds good. :-)

    I'm paging through it now, and I haven't had a problem yet. For
    someone who had just switched from a language as garish and hideous as
    QB, you had sure put together some clean, readable code.


    --
    My projects are currently on hold, but I do have
    some junk at the site below.

    http://www.freewebs.com/timsrl/index.htm

    --
  37. Archived from groups: rec.games.roguelike.development (More info?)

    Timothy Pruett wrote:
    > The Sheep wrote:

    <snip>

    Oh, I almost forgot to mention, I browsed through the rest of your
    site, and *damn* you got some good art skills! Very well done stuff!
    I can't handle drawing stick figures without screwing them up. ;-)

    'Tis a pity that your comics were in Polish, though. Damned all you
    crazy Polish people, and your crazy non-English language! ;-P


    --
    My projects are currently on hold, but I do have
    some junk at the site below.

    http://www.freewebs.com/timsrl/index.htm

    --
  38. Archived from groups: rec.games.roguelike.development (More info?)

    Dnia Wed, 08 Jun 2005 13:37:26 -0400,
    Timothy Pruett napisal(a):
    > The Sheep wrote:
    >> Be warned that it's from the days when I just recently switched to Pascal
    >> from QBasic, so the code might a little weird. No, there are no gotos. But
    >> there are no comments either.

    > I cut some QB code back in the day, myself. _Way_ back in the day,
    > mind you, but I've been where you've been ;-). You should have seen
    > my first bit of C code, coming from QB. What a mess it was.
    > Craziness abounds, I tell you.

    You can see my first C code right next to the pascal download. It's
    this one huge source file in .tar.gz.

    > Anyways...
    >
    > Just grabbed it, and, whew! I was afraid for a moment that the code
    > would be in Polish as well. I can deal with difficult to understand
    > variable naming and such, but I think I'd have trouble handling it in
    > a whole other language! I do find it interesting that most foreign
    > coders naturally seem to code (and comment) in English, Linus Torvalds
    > being one of the most famous examples. I don't really know why that
    > is, but it's definitely an interesting phenomenon.

    It's pretty simple for me. There isn't many good sources of programming
    knowledge available in Polish. Well, there are some excellent books now,
    like 'Symfonia C++' i 'Pasja C++' for example, but there weren't any when
    I was learning programming. When you read, you don't translate every new
    word you see into your language, especially if the word would be new for
    you anyways. You just try to understand it's meaning from it's context
    and descriptions, and proceed. This way I don't even know proper Polish
    words for most of computer-related terminology. I don't even know how
    you pronounce the English words I know for them -- I've never heard them.
    The are just a bunch o letters put together that have this meaning.

    Second, once you're in a team, it's easier to talk about the project when
    you use Polish for real-life objects and English for those in you program.
    It's sort of like using quotation marks and everybody knows what you mean.

    Third, Polish looks bad stripped off it's national characters. Most of the
    time you can guess the positions of national letters, but it isn't very
    comfortable to read it. Sometimes you stop and try to guess what word it's
    supposed to be. There are things like 'petla glowna' (main loop) that look
    really awful (it should be 'pêtla g³ówna').

    >> If something is unclear, just ask -- I'll take a look at it, try to
    >> remember what it is, consult my fortune teller and give some vague answer
    >> ;)
    >
    > Sounds good. :-)
    >
    > I'm paging through it now, and I haven't had a problem yet. For
    > someone who had just switched from a language as garish and hideous as
    > QB, you had sure put together some clean, readable code.

    It's a year's effort, half of the time dedicated to code cleanups.
    I wrote the code with the hope I can more people to help in the project,
    so I really tried to keep it clean.

    Still, linked lists and the tree of items is a mess -- mostly because my
    poor understanding of the ideas at the time I wrote this. I still hate
    the way pointers are treated in Pascal. Like they were added later, by
    force, to the language.

    --
    Radomir `The Sheep' Dopieralski @**@_
    (TT) 3 Waaah!
    . . . ..v.vVvVVvVvv.v.. .
  39. Archived from groups: rec.games.roguelike.development (More info?)

    Dnia Wed, 08 Jun 2005 12:28:26 -0400,
    Timothy Pruett napisal(a):

    > I can't run the Windows binary, until I get a chance to go over to my
    > friend's apartment, so I can use his PC. But yes, I'd _definitely_ be
    > interested in seeing the source. :-)

    It's a DOS binary, and it runs nicely in dosbox, just checked.
    Oh boy, that brings back the old days...

    --
    Radomir `The Sheep' Dopieralski @**@_
    (: ) 3 Snap!
    . . . ..v.vVvVVvVvv.v.. .
  40. Archived from groups: rec.games.roguelike.development (More info?)

    crichmon wrote:
    > "Timothy Pruett" <drakalor.tourist@gmail.com> wrote:
    >
    >>I'm currently piecing together some RL development modules,
    >>to make future projects of mine easier to work with.
    >>Right now, I'm trying to work out a different way of doing
    >>dungeon generation.
    >>
    >>Firstly, I'm going to have the entire dungeon generation
    >>process done through Lua, with the output (actual dungeon
    >>map) getting sent back to the main C++ program. By doing
    >>this, it will be easier for the end-user to both tweak the
    >>general algorithm for the dungeon layout, but can also
    >>tweak the individual rooms and halls.
    >>
    >>Each room and hall will be stored in their individual
    >>script file. These script files will store any room
    >>specific game scripts, as well as the actual room design.
    >>This will give the game more of a distinctly different look.
    >>Most RLs use random dungeon generators to produce the layout
    >>of the map only, and just use generic, plain rooms and
    >>halls. This will allow for unique, handcrafted rooms to be
    >>placed all throughout the levels, as opposed to the bland,
    >>ordinary rectangular rooms.
    >
    >
    > The scripts could be either be completely detailed for unique
    > rooms (like the one you mentioned below), or be somewhat
    > templatized. An initial template could be something that
    > generates 'bland, ordinary rectangular rooms' to get a
    > working prototype going of the script interpreter. And then
    > after development time, the script could be further detailed
    > to add some intelligence to situations when the rng
    > generates bland rooms.

    That's what I'm hoping to do. I have a mix between templatized rooms
    and fully handcrafted rooms. As of now, the templatized rooms are a
    bit less interesting, but that will change as more possibilities are
    added, and as more templates are created.

    >>Anyone could freely write a new room file, allowing them to
    >>create any room they could think of and could freely plug it
    >>into the main generation script. For example, someone could
    >>toss out a room like this:
    >>
    >>############
    >>#..........#
    >>#...#..#...#
    >>#...#..#...#
    >>#.###..###.#
    >>#....==....#
    >>#.###..###.#
    >>#...#..#...#
    >>#...#..#...#
    >>#..........#
    >>############
    >>
    >>Where '.' is floor, '#' is wall, and '=' is water. Then they
    >>could write a script to cause the water to slowly expand,
    >>causing a sort of drowning deathtrap.
    >>
    >>The options would really be fantastic. Granted, the above
    >>example was weak, but it was just a quick random idea. It'd be
    >>nice to play a game where every room was interesting, and
    >>unique, and full of options.
    >>
    >>Anyways, I'm nearing completion with this module, and then I
    >>hope to be able to release a walkaround demo, with random
    >>dungeons, within the next week or so, to show it off.
    >>
    >>Anybody who has a cool idea for a room, or hall, please post
    >>it. Likewise, anyone with a good suggestion, or critique of my
    >>idea, please post it as well. I'm looking for all the feedback
    >>I can get.
    >
    >
    > Map generation and script interaction could get really complex if
    > scripts have a lot of different features and if room placement is
    > completely random. I would initially ignore the random dungeon
    > generation portion and write several scripts, and then write
    > one or more map scripts that each detail one level of the game,
    > using the room scripts as modules. That would be the quickest
    > easiest way to create a walkaround demo of your idea.

    It's not too complex, as of now. The way it works, is as follows:
    First, the appropriate level creation script is run, which calls the
    appropriate room script as necessary. Any rooms which contain extra
    scripts (i.e. information besides the map layout) will cause a flag to
    be set in the main map structure. When the level creation script is
    done, the map data gets returned into the main C++ code. When the
    level is entered in the game, first, the map handler checks whether a
    level script flag was set. If so, the level script is run, which
    handles all level specific scripting effects (quests, special AI
    features, special level features, etc.). All rooms which are flagged
    as containing an extra script, will have their scripts run continuously.

    My only concern is that a level with _lots_ of rooms containing
    scripted events might run slowly. I haven't run into this problem
    yet, thankfully, and I'm running this all on a Pentium II with 128MB
    RAM, so it might be a silly thing to worry about. However, if it does
    become a problem, I think that I'll not allow scripts to run unless
    the player is within a certain distance from the room. As the player
    nears the room, the script will start up. When a player goes too far
    from a room, the script will pause. When he nears a room with a
    paused script, the script will run several cycles, to give the
    appearance of activity while the player was gone.

    > As far as the random map generation portion, I do have a suggestion
    > of something that I'm currently designing. In the field of
    > computer-generated music there is a concept called convolution.
    > A computer program randomly composes (and possibly plays) music in
    > real-time in the style of some composer. The program would be
    > written such that phrases of music from a song or songs written by
    > the composer (for example, Bach, Beethoven, etc.) are recorded as
    > an event history. The program runs a while loop, and given the
    > last n events or notes or phrases, the program determines that
    > there are certain percentage possibilities of what note should
    > occur next. The next note is added to the event history, and the
    > program looks at the most recent n notes, which in essence changes
    > the seed of the rng.
    >
    > Map generation could be done similarly. There would be a starting
    > room or area, possibly from a set of scripts that are reserved for
    > the entrance room of a dungeon/castle/cave/level/etc. Then there
    > would be certain possibilities as to what the next script or data
    > the generator picks to add to the map. following a certain path
    > (since music is time-linear while maps are spatial and can branch)
    > would determine the current 'map history' for the generation algo.
    >
    > Then there could be some tweaks to make it all work, if one path of
    > the algo runs into pre-existing space, randomly determine if the
    > areas are connected or not. And if a specific theme is necessary
    > (e.g. lava rooms and water rooms shouldn't be on the same level),
    > make that an attribute of the level.

    Hmm, interesting concept. I may have to try that out for one of the
    level scripts in my walkaround demo, to see how it turns out. It
    might be a little tricky, but should certainly be doable, and it might
    prove to be a better approach than I am currently taking. :-)

    > Those are my thoughts, hopefully they are helpful. You're script
    > idea is actually a really good idea. I'm somewhat considering
    > script possibilities for my project, although I haven't decided
    > yet on a specific scripting language. You'd recommend Lua?

    Yes, I would definitely recommend Lua. I found it to be very easy to
    use, with some powerful language features, and it has a very shallow
    learning curve. Not to mention how easy it was to embed in C/C++.
    Other benefits: open-source, cross-platform, and, from what I can
    tell, pretty damn fast for a scripting language.


    --
    My projects are currently on hold, but I do have
    some junk at the site below.

    http://www.freewebs.com/timsrl/index.htm

    --
  41. Archived from groups: rec.games.roguelike.development (More info?)

    crichmon wrote:
    > "crichmon" <crichmon@gmail.com> wrote:
    >
    >>As far as the random map generation portion, I do have a suggestion
    >>of something that I'm currently designing. In the field of
    >>computer-generated music there is a concept called convolution.
    >>A computer program randomly composes (and possibly plays) music in
    >>real-time in the style of some composer. The program would be
    >>written such that phrases of music from a song or songs written by
    >>the composer (for example, Bach, Beethoven, etc.) are recorded as
    >>an event history. The program runs a while loop, and given the
    >>last n events or notes or phrases, the program determines that
    >>there are certain percentage possibilities of what note should
    >>occur next. The next note is added to the event history, and the
    >>program looks at the most recent n notes, which in essence changes
    >>the seed of the rng.
    >>
    >>Map generation could be done similarly. There would be a starting
    >>room or area, possibly from a set of scripts that are reserved for
    >>the entrance room of a dungeon/castle/cave/level/etc. Then there
    >>would be certain possibilities as to what the next script or data
    >>the generator picks to add to the map. following a certain path
    >>(since music is time-linear while maps are spatial and can branch)
    >>would determine the current 'map history' for the generation algo.
    >
    >
    > Arg! I forgot to mention something else about that idea. It
    > requires several pre-existing level designs. So after desiging some
    > script rooms, and then designing some script levels, create the event
    > possibilities based on those designs. The more levels you design,
    > the smarter the generation algo.

    That's what I figured. Sort of an interesting genetic algorithm-like
    approach to dungeon design.


    --
    My projects are currently on hold, but I do have
    some junk at the site below.

    http://www.freewebs.com/timsrl/index.htm

    --
  42. Archived from groups: rec.games.roguelike.development (More info?)

    On Wed, 08 Jun 2005 12:00:01 +0100, Ian Badcoe wrote:

    > Hi,
    > [[assuming doors are paired with specific keys and its not any
    > key for any door]]
    >
    > The problem of "puzzles" and random dungeon generation is a
    > matter of topology. e.g. every "key" or key-like object (switch,
    > teleporter-battery...) has to be:
    >
    > 1) on the right side of its door
    > 2) not blocked by any door who's key is on the far side of its door
    >
    > If the dungeon is constructed topologically instead of
    > geometrically (e.g. first create a graph of nodes and edges, then in a
    > second phase implement that graph as actual tiles, walls etc) then you
    > can arrange rewrite rules for the graph such that the integrity of
    > puzzles is maintained. Random dungeon generation can now proceed by
    > starting with a minimal dungeon, and iteratively applying randomly
    > chosen rewrites until sufficient complexity is reached.

    <snip stuff about topological generation of dungeons>

    I read your previous post about this and was inspired to try to recreate
    the graph grammar system described in David Adams' university project
    (www.dcs.shef.ac.uk/teaching/eproj/ug2002/pdf/u9da.pdf).

    Do you have any more information on this technique? I've done some
    googling, but mostly come up with L-system stuff for generating fractals
    and plants.

    Incidentally, what was the problem that thwarted David's implementation?

    --
    Andy
    andy@pagezero.net
    www.pagezero.net
  43. Archived from groups: rec.games.roguelike.development (More info?)

    On Thu, 09 Jun 2005 15:41:29 +0100, Andy Driver <andy@pagezero.net>
    wrote:

    ><snip stuff about topological generation of dungeons>
    >
    >I read your previous post about this and was inspired to try to recreate
    >the graph grammar system described in David Adams' university project
    >(www.dcs.shef.ac.uk/teaching/eproj/ug2002/pdf/u9da.pdf).
    >
    >Do you have any more information on this technique? I've done some
    >googling, but mostly come up with L-system stuff for generating fractals
    >and plants.
    >
    >Incidentally, what was the problem that thwarted David's implementation?

    >
    >I read your previous post about this and was inspired to try to recreate
    >the graph grammar system described in David Adams' university project
    >(www.dcs.shef.ac.uk/teaching/eproj/ug2002/pdf/u9da.pdf).
    >
    >Do you have any more information on this technique? I've done some
    >googling, but mostly come up with L-system stuff for generating fractals
    >and plants.
    >
    >Incidentally, what was the problem that thwarted David's implementation?

    Hi,
    It was a long time ago now but it's a technique I am very keen
    to see properly tested somewhere, so I remember quite well what the
    issues were.

    I don't think you'll find much online about it. It doesn't
    seem to have been properly tried before, or at least not written up.
    There are some things that border on it here and there, e.g.
    graph-based rewrite-rules for design problems, but not for dungeons.

    David's problem was that we started from the point-of-view of
    a parser-like approach. e.g. so that, conceptually at least, we could
    look at an existing dungeon and parse it into topology, then try to
    deduce some rules that would be able to generate it.

    He found a structure something like this:

    -> D2 -> K1
    |
    IN -> J -> D1 -> OUT
    |
    -> K2

    And concluded that this could only be added as a single
    complex rule -- because K1 from rule 1, was "outside" D2, a feature of
    rule 2. This was unfixable in his scheme because the "parser"
    approach lead us to assume a single entrance and exit from each rule
    (e.g. in the same way text in a source file has a single piece of
    previous text and a single piece of next text). e.g. rules could
    create junctions, but they could not be _applied_ to junctions.

    A more general graph-based approach, however, supports the
    idea of rules with three connections. Then we can parse the previous
    into:

    IN -> * -> OUT

    Apply rule 1:

    -> K1
    |
    IN -> J* -> D1 -> OUT

    Apply rule 2 to J* (which has three connections):

    -> D2 -> K1
    |
    IN -> J -> D1 -> OUT
    |
    -> K2

    e.g. the "*"s in the existing graph can have different numbers of
    edges leading to them -- and even different tags on the edges to say
    things like "in only", "out only", "two way", "secret" and the rules
    have similar variable numbers of edges whcih must be matched against
    the existing ones. In this case, rule one needs two edges but rule 2
    needs three. All the edges in this case are two way but you can
    construct schemes where there are more properties on the edges and the
    rules match up accordingly.

    He had other cases where it failed but they all would work with more
    edges on the rules.

    I would be more than happy to help out if you are working on this.

    Ian


    Ian Badcoe (triangleigbgeneralaccount@yahoo.square.co.uk)
    (remove two shapes from this address to contact me)
    (do not use the reply address...it's full of spam)
  44. Archived from groups: rec.games.roguelike.development (More info?)

    On Thu, 09 Jun 2005 17:41:50 +0100, I
    <RealAddressThatIDontRead@hotmail.com> wrote:

    >On Thu, 09 Jun 2005 15:41:29 +0100, Andy Driver <andy@pagezero.net>
    >wrote:

    <snip>

    >>I read your previous post about this and was inspired to try to recreate
    >>the graph grammar system described in David Adams' university project
    >>(www.dcs.shef.ac.uk/teaching/eproj/ug2002/pdf/u9da.pdf).

    <snip>

    > David's problem was that we started from the point-of-view of
    ^^^^^

    Ah! Sorry, I was mixing up which of the the two projects you were
    interested in. The approach I was describing was the previous one by
    Simon Ince. It was much simpler and less mathematical in its scope,
    and used context-free grammars. It had the one simple flaw that could
    have been fairly easily fixed if we'd had more time.

    David came in with a far heavier approach and I'm not sure I ever
    fully understood it :)

    I've just grabbed his thesis and will scan it again and see if I
    recall more details. Personally I would probably start at the Simon
    Ince level, however, but I'm not sure his thesis is still on line.

    I'll try to find a copy of Simon's as well...

    Ian


    Ian Badcoe (triangleigbgeneralaccount@yahoo.square.co.uk)
    (remove two shapes from this address to contact me)
    (do not use the reply address...it's full of spam)
  45. Archived from groups: rec.games.roguelike.development (More info?)

    On Fri, 10 Jun 2005 10:12:03 +0100, Ian Badcoe wrote:

    > On Thu, 09 Jun 2005 17:41:50 +0100, I
    > <RealAddressThatIDontRead@hotmail.com> wrote:
    >
    >>On Thu, 09 Jun 2005 15:41:29 +0100, Andy Driver <andy@pagezero.net>
    >>wrote:
    >
    > <snip>
    >
    >>>I read your previous post about this and was inspired to try to recreate
    >>>the graph grammar system described in David Adams' university project
    >>>(www.dcs.shef.ac.uk/teaching/eproj/ug2002/pdf/u9da.pdf).
    >
    > <snip>
    >
    >> David's problem was that we started from the point-of-view of
    > ^^^^^
    >
    > Ah! Sorry, I was mixing up which of the the two projects you were
    > interested in. The approach I was describing was the previous one by
    > Simon Ince. It was much simpler and less mathematical in its scope,
    > and used context-free grammars. It had the one simple flaw that could
    > have been fairly easily fixed if we'd had more time.
    >
    > David came in with a far heavier approach and I'm not sure I ever
    > fully understood it :)

    I'm having a bit of difficulty with it myself. I've studied formal
    languages and graph theory a bit, but most of this is a little over my
    head :)

    >
    > I've just grabbed his thesis and will scan it again and see if I
    > recall more details. Personally I would probably start at the Simon
    > Ince level, however, but I'm not sure his thesis is still on line.
    >
    > I'll try to find a copy of Simon's as well...

    I'd love to read it if you can find a copy! I've searched for it, but it's
    not available from Sheffield University's site. :(

    After gaining a rough understanding of this process, it struck me that it
    would be quite useful for plot generation as well. Imagine combining a
    context free grammar with something like Polti's 36 Dramatic Situations
    (http://www.gamedev.net/reference/articles/article255.asp) or The
    Hero's Journey (http://en.wikipedia.org/wiki/Monomyth) as your starting
    expression. E.g:

    Call-to-adventure -> Refusal-of-the-Call -> Supernatural-aid -> etc...

    where

    Call-to-adventure: Gandalf-comes-to-tea | Leia's-message-to-Obiwan | etc..

    Perhaps I'm getting a bit too far ahead of myself on that one...

    --
    Andy
    andy@pagezero.net
    www.pagezero.net
  46. Archived from groups: rec.games.roguelike.development (More info?)

    On Fri, 10 Jun 2005 15:47:57 +0100, Andy Driver <andy@pagezero.net>
    wrote:

    >On Fri, 10 Jun 2005 10:12:03 +0100, Ian Badcoe wrote:
    >
    >> On Thu, 09 Jun 2005 17:41:50 +0100, I
    >> <RealAddressThatIDontRead@hotmail.com> wrote:
    >>
    >>>On Thu, 09 Jun 2005 15:41:29 +0100, Andy Driver <andy@pagezero.net>
    >>>wrote:
    >>
    >> <snip>
    >>
    >>>>I read your previous post about this and was inspired to try to recreate
    >>>>the graph grammar system described in David Adams' university project
    >>>>(www.dcs.shef.ac.uk/teaching/eproj/ug2002/pdf/u9da.pdf).
    >>
    >> <snip>
    >>
    >>> David's problem was that we started from the point-of-view of
    >> ^^^^^
    >>
    >> Ah! Sorry, I was mixing up which of the the two projects you were
    >> interested in. The approach I was describing was the previous one by
    >> Simon Ince. It was much simpler and less mathematical in its scope,
    >> and used context-free grammars. It had the one simple flaw that could
    >> have been fairly easily fixed if we'd had more time.
    >>
    >> David came in with a far heavier approach and I'm not sure I ever
    >> fully understood it :)
    >
    >I'm having a bit of difficulty with it myself. I've studied formal
    >languages and graph theory a bit, but most of this is a little over my
    >head :)

    I'm actually finding it easier going now that I did before. I think a
    lot of the complexity is formed by him coming at it from a complex
    subject area (graph grammars) but I'm sure the problem doesn't
    actually _require_ that, it's just what the principal supervisor was
    already interested in.

    For example, he searches for a graph of the right size by trying ans
    discarding productions that both increase and decrease the number of
    nodes. Personally I probably would not have any that decreased the
    size (or kept it the same!), then one could just iteratively apply
    productions until we reached "big enough" and then stop.

    Similarly I think he feels the need to discard all non-terminal
    symbols before calling the graph complete. But if we take a leaf from
    L-systems we see that when the graph is big enough, any remaining
    non-terminal symbols can be regarded as nops and ignored...

    >> I've just grabbed his thesis and will scan it again and see if I
    >> recall more details. Personally I would probably start at the Simon
    >> Ince level, however, but I'm not sure his thesis is still on line.
    >>
    >> I'll try to find a copy of Simon's as well...
    >
    >I'd love to read it if you can find a copy! I've searched for it, but it's
    >not available from Sheffield University's site. :(

    I'm making enquiries...

    >After gaining a rough understanding of this process, it struck me that it
    >would be quite useful for plot generation as well. Imagine combining a
    >context free grammar with something like Polti's 36 Dramatic Situations
    >(http://www.gamedev.net/reference/articles/article255.asp) or The
    >Hero's Journey (http://en.wikipedia.org/wiki/Monomyth) as your starting
    >expression. E.g:
    >
    >Call-to-adventure -> Refusal-of-the-Call -> Supernatural-aid -> etc...
    >
    >where
    >
    >Call-to-adventure: Gandalf-comes-to-tea | Leia's-message-to-Obiwan | etc..
    >
    >Perhaps I'm getting a bit too far ahead of myself on that one...

    I don't think so. I almost introduced this as an idea earlier in the
    discussion.

    I wouldn't look to predefined plot-theories as the source of
    productions, however. All one really need do is generalise a bit:

    "puzzle" generalizes to "potential event in the world"
    "door" generalizes to "anything impeding progress"
    "key" generalizes to "anything that opens a door"

    So, for example, in this structure the whole of "discovering
    attempting and completing the quest to find the grand McGuffin to
    satisfy the elder in the village" collapses into a "puzzle". The
    outermost "door" is that the elder won't even tell you about it at
    first. The outermost "key" is the conditions you have to meet before
    he will tell you (meet him, be powerful enough, be virtuous
    enough...).

    Thus all the parts for the quest have been built into the world from
    the start but are not available until the "door" is open. Which is
    conceptually no different from the idea of a real door with things
    behind it (you might defer creation of the quest contents until the
    player reaches them). The player might even be able to access a few
    parts of the quest as teasers (e.g. some parts lying outside the
    "outermost" door). And if the random quest generation happens to
    insert another quest inside it, so much the better...

    If you do experiment with this, will it be open source and what
    language would you use, Ruby?

    Ian


    Ian Badcoe (triangleigbgeneralaccount@yahoo.square.co.uk)
    (remove two shapes from this address to contact me)
    (do not use the reply address...it's full of spam)

    In fifteen minutes, everybody will be in the future.
  47. Archived from groups: rec.games.roguelike.development (More info?)

    On Fri, 10 Jun 2005 17:18:44 +0100, Ian Badcoe wrote:

    <snip graph grammar dungeon generation stuff>

    <snip my idea about plot generation using CFGs>

    >>
    >>Perhaps I'm getting a bit too far ahead of myself on that one...
    >
    > I don't think so. I almost introduced this as an idea earlier in the
    > discussion.
    >
    > I wouldn't look to predefined plot-theories as the source of
    > productions, however. All one really need do is generalise a bit:
    >
    > "puzzle" generalizes to "potential event in the world" "door"
    > generalizes to "anything impeding progress" "key" generalizes to
    > "anything that opens a door"

    Hm, you're right there.

    <snip more on plot devices being specific puzzles>

    > If you do experiment with this, will it be open source and what language
    > would you use, Ruby?

    Yes and yes! How did you guess?

    --
    Andy
    andy@pagezero.net
    www.pagezero.net
  48. Archived from groups: rec.games.roguelike.development (More info?)

    On Fri, 10 Jun 2005 17:41:03 +0100, Andy Driver <andy@pagezero.net>
    wrote:

    >> If you do experiment with this, will it be open source and what language
    >> would you use, Ruby?
    >
    >Yes and yes! How did you guess?

    I read your web-pages :)

    I've mailed you with where you can find Simon's dissertation.

    But I only had the email address at the top of these articles, so if
    that's a spam-trap you'll have to figure out my cryptic address in the
    sig and contact me with a better address.

    Ian


    Ian Badcoe (triangleigbgeneralaccount@yahoo.square.co.uk)
    (remove two shapes from this address to contact me)
    (do not use the reply address...it's full of spam)

    In fifteen minutes, everybody will be in the future.
  49. Archived from groups: rec.games.roguelike.development (More info?)

    On 2005-06-08 00:24:30, The Sheep <thesheep@ sheep.prv.pl> wrote:

    > 2. Strategically interesting information. This can be achieved to some
    > extent by use of themes (there are mummies on this level, I better get
    > some fire-based weapons/spells), varying the algorithms for picking,
    > placing and connecting rooms, etc. Also, to use strategy, you need some
    > information in advance.

    The biggest weakness with the Sangband approach (and other variants such as
    Unangband) is that the monster AI algorithms are so good that you usually
    encounter the strategic information after you have fought the monsters.

    > 3. Food for my imagination. If it's supposed to be caves, let it look like
    > caves. If it's forest, I want at least a couple of trees. If it's a tower,
    > it could be round, etc.
    >
    > > Anybody who has a cool idea for a room, or hall, please post it.
    > > Likewise, anyone with a good suggestion, or critique of my idea,
    > > please post it as well. I'm looking for all the feedback I can get.
    >

    Have a look at Unangband's admittedly very crude take on this. Also look at
    Sangband's bit more sophisticated approach.


    Andrew

    --
    Unangband L:C E+ T- R- P+ D-- G+(+) F:Sangband RL-- RLA-- W:F Q++
    AI+(++) GFX++ SFX++ RN+++(+) PO++ Hp+++ Re--(+) S++ C- O* KG--
Ask a new question

Read More

Development Games Video Games