Language: 
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 11768 times)

0 Members and 1 Guest are viewing this topic.

_people_

« 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_ :)

smacky

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

Yoll

« 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 »

_people_

« 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_ :)

Shroud

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

smacky

« 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),

_people_

« 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_ :)

Paradon

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

_people_

« 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_ :)

_people_

« Reply #24 on: 13, February 2021, 06:52:10 »
I've been making slow but steady progress. The generator now runs as a standalone program which can be called from the reboot scripts and will run indefinitely. It checks the datastore and, if a specific map has too few copies available, will create more copies as necessary.

Presently I have maps divided into 30 difficulty levels. Difficulty will be calculated based on the levels of all players who will be spawning on it as well as the number of players. This will affect number of spawns, linked spawns, level of the spawns, etc.

In addition, I've also added dungeon "tiers".

Players can randomly find throughout the game (both in normal and random dungeons) "expedition scrolls". These start out at tier 1. Once the player (and their party, if applicable) beats the tier 1 dungeon, the boss will drop a tier 2 expedition scroll.

When the player visits a tier 2 map, it will be a similar map to the tier 1, but modifiers are applied to mobs to make it more difficult. Eventually I will also add traps and possibly even player nerfs based on the tier of map. Loot in higher-tier maps will be better, and the boss will have more special abilities.

I'd like to have a "leaderboard" system where players can see who has achieved the highest tier of each map, as well as a global announcement when someone has achieved the highest tier for each map.



ATM the tier system is working well. All I really have left to do before release is:
  • implement boss mobs
  • add expedition scrolls to treasurelists
  • a few bugfixes
  • come up with a few more buffs - ATM the only one I use is giving mobs extra HP

Obviously the balancing aspect of this huge feature will be extremely difficult. The initial release of Expeditions will be pretty rough - likely lots of bugs and the maps will either be too boring, too difficult, or even both. But with enough testing I think this will be a fantastic feature.
-- _people_ :)

Shroud

« Reply #25 on: 14, February 2021, 18:53:42 »
Here are some buffs you can use
1. Mob dps
2. Mob detection range
3. % Linked mobs
4. Reflect spells/missiles
5. Secondary attack types (e.g. drain, depletion etc)
6. Mob resists/protects
7. Respawn speed (if applicable)
8. Trap frequency/damage
9. Mob level
10. Spell restrictions like in towns, potentially weapon restrictions like in grommit's map
Doesn't matter, you'd die anyway. ;D Shroud's a hacker. After many hours of deep thought I have came to that conclusion.

_people_

« Reply #26 on: 24, February 2021, 22:34:49 »
As I'm getting to the final details, I'm thinking I might consolidate difficulty and tier.

My new proposal is:

35 difficulties are generated. Tiers 1-30 correlate to approx. 4-level increments from 1-110. 31-35 are level 110 maps, but feature special buffs which cannot be accomplished via scripts (I've checked - linked spawns can't work with scripts because they are processed at map load).

When a player plays an Expedition for the first time (tracked on a per-mapset basis) they start at the tier corresponding to their current level (ignoring status ailments like drain). So a level 1 player is tier 1, level 50 is tier 13 or so). Each time they complete an Expedition, their tier is increased.

When they load their next Expedition, their "effective tier" (base level + # of tiers beaten) is used to determine map buffs. If their effective tier is > their base tier, the map is either buffed with mob modifiers (+5% HP, etc.), or they are placed on a higher base tier map (so our level 50 player is now on a tier 14 map vice 13), or both if they are at a much higher tier than their base tier.

When they fail to complete an Expedition, they are reset to their base tier, corresponding with their level.

When multiple players are on the same Expedition, the effective tier is raised by some amount based on how many players are participating.

After typing this post, I've realized I'll need to come up with better terminology to prevent confusing even myself :) Doesn't help that I changed the plan a couple times just while writing this post.
« Last Edit: 24, February 2021, 22:40:01 by _people_ »
-- _people_ :)

Shroud

« Reply #27 on: 26, February 2021, 18:37:16 »
Well if aiming to make tiers entirely based on levels then I'll note that while player levels are limited to 110 that mob levels go up to 127 so assuming that a tier is roughly 4 levels then level 127 is already tier 32 that would also put lvl 110 at around tier 27.5.

Just thinking on how it works it means if I were to get to the max tier at lvl 110 and then died I would have to complete 4 expeditions to return to max tier. If tiers are based on mapsets if there are a lot of mapsets then it is possible players could have quite a lot of different tiers. Looking at it from an exploit viewpoint if the rewards don't scale with tier well it might well be viable to suicide to reset the tier.

If looking for terminology it might be easier to think of it as a 5 tier system pegged to the player's base level. So a level 1 player has a 1 to 5 range and a level 110 has a 31 to 35 range. I think that for groups it might be best simply to use the highest tier player for the tier or an average of the combined tiers. It's also maybe worth considering that groups shouldn't be too many tiers apart as being realistic a lvl 70 will have nearly no impact on a lvl 110 map and is likely to die instantly.
Doesn't matter, you'd die anyway. ;D Shroud's a hacker. After many hours of deep thought I have came to that conclusion.

_people_

« Reply #28 on: 01, March 2021, 00:50:12 »
The balancing aspect of this will be extremely difficult regardless and will require plenty of trial and error. I agree that if rewards don't scale, players will be incentivized to die to reset their rewards. However, if players are doing that then feedback should be sent so that I can rebalance.

On the other hand, with infinitely scaling dungeons, there will be 1 of 2 inevitabilities:

(a) Players achieve the best equipment possible and likely get bored, or
(b) Because items can only be level 110, the strength difference between a level 110 player and a level 109 player will get infinitely larger, and the required number of tiers before a player reaches an Expedition difficult enough to be fun will go up infinitely.

Either way, it'll be tough to keep players playing after a certain point. Having leaderboards and in-game announcements ("Shroud has become the first player to reach <dungeon> tier 50!") will incentivize some people, but not many.
-- _people_ :)

Shroud

« Reply #29 on: 01, March 2021, 02:35:43 »
Well as far as balancing goes I think there are two likely scenarios you need to consider

1. Level 110 players who will basically be camping/climbing tiers
2. Players under level 110 that I would assume would be gaining levels as they progress through the dungeon. To take an example if a level 1 player gains 5 levels while completing a dungeon what is their final tier? There is also question of what happens if you get a +5 effective tier, then get 30 levels elsewhere and return to the map.

As far as items go I wouldn't mind the concept of an item's power being proportional to it's level requirement and having different tiers like common, uncommon, rare, epic, legendary, unique etc but as you say eventually people will get the best possible equipment and likely get bored. I don't think there ever was a baseline for what stats items could get and I guess even if there were once Smacky finishes his new attack code that could shake things up.

Leaderboards and in-game announcements are a nice touch. I'm personally all for the "Shroud has become the first player to reach <dungeon> tier 50!" although I don't know if leaderboards will be easily scalable so it might be easier to limit it to a top 10 (or 100)
Doesn't matter, you'd die anyway. ;D Shroud's a hacker. After many hours of deep thought I have came to that conclusion.

Tags:
 

Related Topics

  Subject / Started by Replies Last post
9 Replies
1201 Views
Last post 16, October 2005, 07:09:58
by Carleto
16 Replies
5963 Views
Last post 21, July 2008, 13:07:56
by grommit
0 Replies
2040 Views
Last post 21, February 2009, 05:51:25
by angry
9 Replies
368 Views
Last post 15, October 2021, 03:09:18
by _people_