Scripted approach to dungeon generation

[Guest]

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

--

 

[Antoine]

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.

 

[Guest]

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.

 

[Guest]

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!

 

[Antoine]

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.

 

[Guest]

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

--

 

[Guest]

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

--

 

[Guest]

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

--

 

[Guest]

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

 

[Guest]

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.. .

 

[Guest]

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

--

 

[Guest]

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.. .

 

[Guest]

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

--

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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.

 

[Guest]

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.. .

 

[Guest]

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.. .

 

[Guest]

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.

 

[Guest]

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.. .

 

[Guest]

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.. .

 

[Guest]

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

Yes. Thanks.

 

[Guest]

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

--

 

[Guest]

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