Re: A roguelike system in Perl

At Thu, 07 Jul 2005 10:56:59 GMT,
Da-Breegster wrote:

> On 2005-07-07, The Sheep <thesheep@xxxxxxxxxxxx> wrote:
>> At 6 Jul 2005 16:05:15 -0700,
>> dabreegster@xxxxxxxxx wrote:

>> There's also slrn :)
> I'm using that now. Much easier. Hope I'm doing this right, finally.
Yes, much easier on this side too. Thanks.

> Well, right now, I start by building a random room somewhere in this big
> blank cave. (In my system, a cave is like one level of the dungeon) The
> borders of the room are created automatically and added to a list of
> coordinates with borders. Then, the generator decides randomly to create
> different excavations (rooms, hallways, mazes) and stuff. To make sure
> all rooms are connected, it chooses a random coordinate from the border
> list then looks to the left, right, up, and down of that tile. Whichever
> direction has free space first is returned to the excavation generator.
> (Right now there are only rooms though.) It'll build the room starting
> from that point. I was even hoping to pull off some fancy stuff to where
> it could scan outward from that point in advance and know how much room
> there is. But so there wouldn't be boring rooms, I was going to have it
> mark some spaces in the mini-map it returned as un-writable. So
> basically it would end up skipping some spaces in order to look
> interesting.

As I see it, maybe you could get the benefits of the second approach while
still using your original approach. Just store the backreferences to the
rooms in the lists of coordinates with borders (or have a way to determine
in which room given coordinate is) -- you can then do some fancy stuff
with this list:

1. Don't add all the borders when making a room -- add only the preffered
ones, probably marked on the room's template.
2. To limit the number of doors on the given wall, you can scan the list
of coordinates and remove all from that wall once there's enough doors.
3. You can do similar thing to limit the number of doors in a room, or
even in some area...
4. You can give the coordinates (may I call them hotspots?) priorities,
and sort their list, trying the ones from the beginning first.
5. Once you determine given hotspot is wrong (doesn't have enough room),
you can remove it from the list.


> The other way is pretty much the same, but, in the cave generator,
> instead of choosing a random place to start from (well, semi-random:
> it's determined by the list of borders so far.), it'd make a sort of
> queue and for each room, build 1 to 4 connections leading out of the
> rooms (in a cool sort of way, not just plain old doors and blank spaces
> all the time), and then new excavations (rooms, remember) would be built
> starting from these connections.

Including 'connections' is a good idea, but for a reason you didn't
mention. You need loops in your dungeon, or it will be a nightmare to
navigate in. With the approach you described, it's really hard to connect
a room (or any other feature) with more than one other room -- you end up
with a tree-like structure.

The 'connections' should help here, but I have no idea on how to make
them?

> Anyway, the problem is, again, free space. Any clues? That's all, I
> guess.

The computers doesn't view 'space' as people do. I had similar ideas and
similar problems -- I think that just trying to fit a room is the fastest
way to determine free space.

> Totally unrelated, but you know how sometimes you're trying to describe
> something to somebody else that you're making and you end up sort of
> making stuff up along the way, really thinking it out yourself, and
> end up with ideas that seem decent? Well, this isn't the first time. If
> anything here makes no sense, it's because it's 5:40 AM here and I'm
> listening to 'Tomorrow Never Knows' by the Beatles on the headphones.
> Makes sense now, right? :P

It's good to explain something in details -- you'll sometimes see the
spots you've overlooked previously before, and generally get a better
picture of your idea.

When my ideas reach the state of this one here, I usually ponder just
think about them a few days, sketch things (usually totally unrelated to
the idea ;) ), think about implementation issues, like how to divide it
into procedures and what datastructures to use, etc, etc.

Then, after a few days, try to explain the idea again, in a form of an
article -- some of them make it to this newsgroup, others don't.

People here have usually some valueable notes, or totally different
ideason how to do things -- I read them and rethink the problem, etc.

Finally, Iget bored with the idea and leave it alone. I'm aware that it
would be much better to code it, even in a 3drl or something, but there
are other ideas I've got to take care of ;)

--
Radomir `The Sheep' Dopieralski @**@_
(`') 3 Grrr!
. . . ..v.vVvVVvVvv.v.. .
.

Relevant Pages

  • Re: A roguelike system in Perl
    ... >> blank cave. ... >> coordinates with borders. ... > rooms in the lists of coordinates with borders (or have a way to determine ... >> starting from these connections. ...
    (rec.games.roguelike.development)
  • Re: A roguelike system in Perl
    ... coordinates with borders. ... direction has free space first is returned to the excavation generator. ... build 1 to 4 connections leading out of the ... rooms (in a cool sort of way, not just plain old doors and blank spaces ...
    (rec.games.roguelike.development)
  • Panic, a strange behavior of lisp program
    ... when SORT is called with a parameter that includes some that ... No actually although CLtL ... this apparent mistake in conversion from CLtL to ANSI-CL. ... Web page that lists all such "obvious" mistakes. ...
    (comp.lang.lisp)
  • RE: Incident investigation methodologies
    ... However, what sort of reaction ... Speculation gets you nowhere. ... > malware we encounter. ... > of what makes public lists useful - you can get some ...
    (Incidents)
  • Re: Detailed explanation of how a QuickSort Works
    ... Firstly, if you consider the simple "Bubble Sort" algorithm, it works by running through the entire data set, one item at a time, comparing each item to the previous item and swapping them if they are not already in the correct order. ... by simply running through the entire list just once (and splitting it into two smaller lists) you have cut the sorting time in half. ...
    (microsoft.public.vb.general.discussion)