To browser these website, it's necessary to store cookies on your computer.
The cookies contain no personal information, they are required for program control.
  the storage of cookies while browsing this website, on Login and Register.

Author Topic:  Procedurally-generated dungeons  (Read 3198 times)

0 Members and 1 Guest are viewing this topic.


« Reply #15 on: 26, September 2020, 01:41:04 »
Minor point but imo at 1pix/msp this mapset is way too big.

Related: the non-play area:play area and passage:room ratios are too high.  Also can u add to the algo a chance to merge 2+ nearby rooms (not nec completely so we get topographically interesting shapes.

I agree. I haven't yet done fine-tuning on that but if I can increase the density of the rooms we can fit it in a much smaller grid and have fewer and shorter corridors. As it is now, they are randomly positioned but if place them all at the center and use separation steering they should be more tightly packed.

Merging rooms will be pretty tough but maybe possible. I'll look into it.

Shroud: I think plan B is the better of the two. Plan A is pretty impractical for reasons I won't go into quite yet.

So when the server crashes, use the seeds from the previous startup to generate its supply of maps. It's somewhat unfair, anyway, if the players are fighting the boss of a dungeon and the server crashes and they lose all their progress. With this fix, it'll still be inevitably a bit unfair because boss's HP will be restored (though that can probably be worked around) and the players will log in individually making for a tough fight, but that's the best we can do.

IDK what Smacky could possibly have been thinking of that would make egoitems help this situation though. :)
« Last Edit: 26, September 2020, 01:45:32 by _people_ »
-- _people_ :)


« Reply #16 on: 26, September 2020, 10:34:00 »
In outline, we have a uint32 rdg id. so 1-42949672950. when a playet/group starts a new rdg 'instance' we incr this global id (and save it to disk) and write it to each player. as pl shuffle around the  mapset we load each map with pl's rdg id.

the unique rdg drops are also assigned this id. the deal is similar to egoitems: if item has id > 0 it can't be picked up/applied unless pl  id matches.

when an rdg is completed [eg, boss is defeated] we go thru each pl with that id, set it to 0 and every matching item in pl's inv (theyre normal now). and we delete the mapset instance forever.

this shld mean rdgs persist in terms of maps, pl, and itemcs across reboots/crashes and (optionally) are leavable/reenterable.


« Reply #17 on: 26, September 2020, 14:39:09 »
I think I understand that, maybe I have a different language here,  the instance can be such that once a player enters, a new set of values or a new set of variables is created and assigned, in other words all the values of qualities and quantities are prevalent until the entering to the instance, the player enters an instance with a fixed set of values (Naked), achievements on the instance at all stages will then be written exclusive; you only need a fixed set of values once you live the instance and go back to where you started. reboot/crash cases make no significant problem (imo), because you can always keep a dim for variables at start point, where Bob can simply compare the sets to determine rewards, and such performs only if your exit from the instance is valid. Death=Reset, meaning if you fail, it all goes back to "A", and if you succeed, it all goes back to "A", there are no changes, only  the fixed value of achievement within the instance, so in case of failure, as well as in case of server crash or reboot, you will need to start the instance from "A". I don't see (imo) that there is conflict of uint32 vs int, because I don't see the difference,  no sequence will require increment... But then again, I'm just a newb, and I am new here, and maybe I have no right perspective on what you guys are talking about, if that is the case please let me know...

« Last Edit: 26, September 2020, 14:46:59 by Yoll »


« Reply #18 on: 06, October 2020, 00:09:24 »
(click to show/hide)

Slow progress this past week or so because of real life but I've made rooms slightly more densely-packed and also started filling in corridors. I think there should still be more density than shown in the above pic but I've got a plan for that. Corridors are difficult to make interesting so I'd like to maximize room density.

I haven't yet added Perlin noise to corridors, so they still look mostly straight and boring. As with everything else in this project, noisiness/windy-ness of corridors will be easy to fine-tune by changing a few Lua variables on a per-dungeon basis. So you can have straight and boring, or you can have twisty and crazy.
« Last Edit: 06, October 2020, 00:11:26 by _people_ »
-- _people_ :)


« Reply #19 on: 06, October 2020, 00:29:29 »
That does look a bit harder to navigate although the size has also increased quite a bit.

As an aside there was one potential flaw from my idea of regenerating the dungeon using the same seed in the event of a crash. If for example there is a treasure chest with a valuable item in it then potentially a player could open the chest, then logout and wait for a server crash to infinitely camp same chest. It could be viewed as a trade off but thought it was worth mentioning as a hypothetical scenario.
Doesn't matter, you'd die anyway. ;D Shroud's a hacker. After many hours of deep thought I have came to that conclusion.


« Reply #20 on: 06, October 2020, 10:47:50 »
Lookimh hood p. <---------- FFS!

s, server is already wise to such tricks. eg, true one drops that only drop once over the lifetime of a player. my rdg/ego sugg above was an extn of this idea (well not technically an extn -- rdgs wld use both),


« Reply #21 on: 18, October 2020, 04:39:44 »
Bit of an update:
(click to show/hide)

Only notable progress is a few bugfixes, some code tidyup, and making it actually generate map files in addition to the debug view I've been posting.

EDIT: Now I've added mob spawning as well.
« Last Edit: 18, October 2020, 08:18:31 by _people_ »
-- _people_ :)


« Reply #22 on: 19, October 2020, 16:02:49 »
Nice, looking great.


« Reply #23 on: 02, January 2021, 18:05:24 »
Been a bit since I've made real progress, but I'm back at it.

(click to show/hide)

I've done quite a few changes to the internals of how the generator works. It now generates proper graphs of connections between each room, which is useful for determining start/end locations, validating the maps, and more.

I've also managed to get static rooms working nicely. These are rooms which have been pre-made by a mapper and can be substituted in place of random rooms. They can either be required (the program will re-generate a dungeon until it successfully generates one which can have that room) or optional.

I've also got it generating a datastore of all available mapsets which an in-game script can select a mapset from based on dungeon name and difficulty.
-- _people_ :)


Related Topics

  Subject / Started by Replies Last post
9 Replies
Last post 16, October 2005, 07:09:58
by Carleto
16 Replies
Last post 21, July 2008, 13:07:56
by grommit
0 Replies
Last post 21, February 2009, 05:51:25
by angry