Slashdot Mirror


An Algorithm To Randomly Generate Game Dungeons

An anonymous reader writes: Game developers frequently turn to procedural algorithms to generate some of their game's content. Sometimes it's to give the game more diverse environments, or to keep things fresh upon subsequent playthroughs, or simply just to save precious development time. If you've played a game that had an unpredictable layout of connected rooms, you may have wondered how it was built. No longer; a post at Gamasutra walks through a procedural generation algorithm, showing how random and unique layouts can be created with some clever code. The article is filled with animated pictures demonstrating how rooms pop into existence, spread themselves out to prevent overlap, finds a sensible series of connections, and then fill in the gaps with doors and hallways.

38 of 77 comments (clear)

  1. Yesteryears Algorithms by Anonymous Coward · · Score: 2, Insightful

    While I agree that the animations are nice to look at fore a minute, such concepts have been around for 30 years, since the early days of Rogue and Hack. Why is this on Slashdot in 2015???

    1. Re:Yesteryears Algorithms by ledow · · Score: 2

      Exactly my thoughts.

      Sorry, but a lot of it is obvious (don't stomp over other rooms, etc.). A lot of it has been around for decades. And I was writing things to do this over 20 years ago for HOBBY projects, so I'm damn sure anyone who needs to write these sorts of things can find the material online, come up with it themselves, and/or already knows it.

      Honestly, "geek site" does not equate to "let's just regurgitate 20 year old articles on the basis of programming that people were doing back in the 1980's". The EXACT opposite.

      Fuck, I'm pretty sure the Marshal Cavendish INPUT magazine I read back in the 80's - aimed at kids - describes this sort of shit, and more, and is at least 50% assembly language of various kinds (6502, Z80, etc.). This would barely rate a full page article from thousands, with some BASIC example code, in a weekly series, aimed at teaching kids programming, 20 years ago.

    2. Re:Yesteryears Algorithms by i.r.id10t · · Score: 1

      Indeed, on the surface this appears to be nothing more than an updated version of nethack

      --
      Don't blame me, I voted for Kodos
    3. Re:Yesteryears Algorithms by Half-pint+HAL · · Score: 2

      The interesting point to draw from this is surely how the internet has really, really, dumbed us down. I'm constantly infuriated by the amount of repetitive superficial crap that pops up in computer tutorials, and lament the fact that even expensive programming textbooks are seemingly less sophisticated than the magazines of the 80s.

      While I agree that it's wrong that our current environment makes this sort of stuff into front-page news, surely we should at least be thankful that there are materials on interesting problems, and we should look at how we can expand on that to try to improve the quality of programming education...?

      I see this as an interesting programming problem for learners. In the past, room placement would have been the sticking point for most beginners, so while physics engines are overkill, they get the job done. Let's call that the "blunt instrument" solution, and once it's in place, we can start using modular programming techniques to come up with alternative strategies, which can then lead to discussions over execution time and efficiency, and even the trade-off between programming time efficiency vs execution efficiency.

      --
      Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
    4. Re:Yesteryears Algorithms by hsa · · Score: 2

      Yeah, old algorithms and I wouldn't use this guy's work for my projects. You read about this stuff on a magazine. Kids these days read about this stuff on the net. I am hoping, that other media outlets have covered this as well. This article gives great ideas and hopefully inspires some future game developers, who are now in their teens.

      Too bad it has some fairly advanced concepts, like Delaunay triangulation, which has been taken from a library and quite frankly - useless. Carmack himself speculated some years ago, that just pushing every wall in Doom to a modern GPU without any visibility checking would result in faster performance than raycasting or portals or any other 90s technique. And why do you need triangles, when the graphics pipeline supports quads? And why do they have to be roughly the same size? Have some faith in the GPU.

      Good article. Would have been great, if it would have stuck with the trivial algorithms that do not require advanced CS courses. Spanning tree, anyone? I have have worked as a TA in university for a course teaching those subjects, but I didn't have a faintest idea about those in my teens.

    5. Re:Yesteryears Algorithms by Sloppy · · Score: 5, Insightful

      Damn, what a sad attitude to see.

      Say there's some 11 year old newbie programmer. She hasn't done any of this yet, and hears, "a lot of people who are into the stuff you're into, are on a place called Slashdot." Yeah, let's agree that our position is: fuck off, newbie, go get your learning and inspiration somewhere else.

      I remember reading articles kind of like this, a few decades ago in "COMPUTE!" magazine and similar things. The topics were even old then, and some graybeard from the 1960s might have scoffed with "oh, I was doing that 10-20 years ago." Well, guess what, 1960s graybeard: maybe you didn't leave enough accessible notes, much less, code. And yes, someone can look at (or imagine) results, and make up how they'll do it, without needing to know how you did it. But maybe some kid wants to learn from your mistakes and successes.

      Anybody who writes up decent problems and solutions is welcome, IMHO. I don't give a fuck if it's stuff we were doing decades ago. And honestly, most of that source code isn't around anyway. And when I think of my 1980s code, even if I had my old source, you sure-as-fuck wouldn't want to try to read it.

      --
      As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
    6. Re:Yesteryears Algorithms by JustAnotherOldGuy · · Score: 1

      Indeed, on the surface this appears to be nothing more than an updated version of nethack

      Yeah, but this is webscale. Huge difference.

      --
      Just cruising through this digital world at 33 1/3 rpm...
    7. Re:Yesteryears Algorithms by Anonymous Coward · · Score: 1

      I'm the AC you replied to. You got my attitude totally wrong. I'm a high school lecturer and am quite used to regurgitating yesteryears concepts to undergraduate students. I like to do it, I take pride in being good at that, I thoroughly enjoy my job.

      But: This is not a 1980s (or 60s) textbook, neither a newbie programmer's ideas-for-a-summer-project collection. This is slashdot, and I expect slashdot to be different. Your expectation may vary.

    8. Re:Yesteryears Algorithms by rochrist · · Score: 3

      That's great and all, but whatever happened to, you know....just skipping the articles that don't interest you? You on a 300 baud modem or something?

    9. Re:Yesteryears Algorithms by allcoolnameswheretak · · Score: 1

      Obviously you have accumulated too much knowledge for anything to be still interesting to you.

      You're getting old. If you're lucky you will develop altzheimers and all of this old stuff will be exciting for you once again.

  2. Re:Oh just like Sword of Fargoal? by Half-pint+HAL · · Score: 1

    Yeah, you could really code up a great physics engine using the 3D GPU in the Vic-20...

    --
    Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
  3. Re:Oh just like Sword of Fargoal? by UPi · · Score: 3, Informative

    That, and many others. Procedural generation is not new.

    I did enjoy the article, though. It was well written, well illustrated and fun to read. I have recently written some 2D game code that was generating a different kind of dungeon (not rectangular rooms, more organic / cave like environment. That was a fun project.

    An article doesn't have to be about the cutting edge latest smart phone to be interesting. (I admit to have very little interest in smart phone news. I might read some articles when the time comes to buy a new handset...)

  4. I have a better title: by bistromath007 · · Score: 1

    A Complicated Algorithm to Build a Crappy Looking Dungeon

    Any "hallways" in any area but the periphery are going to be wonky and stupid agglomerations of whatever rooms happened to be shoved in there. Attempting to control for that factor would just make all the rooms too similarly square. And frankly, randomized connectivity is just silly to begin with. Other map generators tend to focus on sticking modules together, in part because the connectivity always makes sense that way. It makes for samey architecture, but that isn't actually boring if you're properly doing your job of filling those rooms with interesting stuff.

    Mass Effect had very noticeably lazy level design for its exploration/filler material. Hey, it's that one grey box again, sitting next to its grey box friend. Oh boy, I'm going down this hole for the tenth time, I wonder if the door will open left or right. I did it all anyway, because I found the contents of these little adventure capsules at least somewhat engaging, and I was interested in the mechanical rewards from them which I could apply to the prettier parts of the game.

    1. Re:I have a better title: by bistromath007 · · Score: 1

      NB: If a core gameplay element of your game is maze navigation or something similar to it, then this isn't so bad. Though I think it could still be improved.

  5. Re:Oh just like Sword of Fargoal? by thogard · · Score: 1

    Rogue was the most popular and cloned by many others. Moria on the Vax (780?) pushed the limits of the machine at the time and aparently the limit of the game features was based on what could be tested using the test program that would check that new changes could be won. The odd thing is that it was written on a one off VAX (ouvax?) that had been an odd upgrade research project when DEC had a crazy idea that they could do field updagrades from PDPs to VAXen.

  6. Re:Oh just like Sword of Fargoal? by Half-pint+HAL · · Score: 2

    The physics engine in Exile was pretty basic, but used to good effect. The procedural generation of the map was heavily specialised and optimised, otherwise it wouldn't have fitted in 32K. The sort of physics engine that the article seems to be referring to is pretty heavy stuff, and is computationally overkill for the task at hand. However, it's "efficient" in programming terms because it already exists, so is "free" to the programmer. Sword of Fargoal had a minimal and highly efficient solution custom-coded to do the job.

    --
    Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
  7. But with no taunt you have no tank! by Impy+the+Impiuos+Imp · · Score: 1

    Focusing Without Seeing
    A Play in One Act

    Beowulf17: "OH BOY! Another random dungeon. Cool! Ok, lads, here we go!"

    (send in the tank to start taunting)

    (everyone else enters)

    (sigh)

    --
    (-1: Post disagrees with my already-settled worldview) is not a valid mod option.
  8. Re:Not a fan.. by Half-pint+HAL · · Score: 1

    Casual phone games have come up with an interesting variation on procedural generation -- I suppose you could call it "shuffling". One of my favourite examples is called "Platform Panic", and it looks like a very retro flick-screen platformer on first play. On second play, however, you notice that the screens are in a different order. As you play and get further, you get more screen types, and more variations on them, and they generally get more difficult as you progress. I've seen this same approach taken with games using one-touch flying interfaces (flying snakes, rocket ships etc) where you run a continuous track made of predefined blocks that have been shuffled, and rolling-ball balance games moving from one predefined problem block to another (again shuffled).

    What makes this approach interesting is that your game now gets more challenging without necessarily taking any longer to play, but as most people will still want to see their high score increase over time, you have to balance the increasing difficulty carefully to ensure that games do still get longer.

    --
    Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
  9. 1980 called and wants their story back by luvirini · · Score: 1

    This story is about approximately 35 years old stuff. (I think Rogue came out in 1980)

    1. Re:1980 called and wants their story back by freeze128 · · Score: 1

      Hunt the wumpus in 1972.

    2. Re:1980 called and wants their story back by redlemming · · Score: 2

      This story is about approximately 35 years old stuff. (I think Rogue came out in 1980)

      The ADND Dungeon Master's Guide (a book first published in 1979) had a pretty complex random dungeon (and wilderness) generation system, so the idea is certainly nothing new. There may have been even earlier variants on this theme, I haven't read all the earlier books.

      The ADND system was intended for use by a human, but I'm sure lots of people ended up writing computer variants (most of which probably never got published).

      It's always nice to have people publish their versions of this kind on thing. There's still lots of room for innovation in this area.

  10. Carmack said... by Fragnet · · Score: 2

    All procedural generation is is a really, really, really tight form of compression. It's also lossy compression, so what you recover from it is almost always lots of different things that are all basically the same. Artist created content may be expensive, but it's superior to procedural generation in almost every way.

    1. Re:Carmack said... by jbeaupre · · Score: 2

      Physicists might counter that artists are procedural generated.

      --
      The world is made by those who show up for the job.
    2. Re:Carmack said... by Fragnet · · Score: 1

      They would probably be wrong.

    3. Re:Carmack said... by ultranova · · Score: 1

      All procedural generation is is a really, really, really tight form of compression. It's also lossy compression, so what you recover from it is almost always lots of different things that are all basically the same.

      But they need not. Chaos theory means that a deterministic system is capable of generating endless variation. Fractals are a famous example, and in fact games could be seen as systems which procedurally generate a timeline of events based on user input along the way.

      Also, I'm not at all sure that "lossy compression" is a meaningful term here. What is the original you're comparing against? Surely not real life, unless you're day-to-day experience is pretty "interesting".

      Artist created content may be expensive, but it's superior to procedural generation in almost every way.

      So how does an artist generate his art? Magic? It's either that or some sort of procedural generation algorithm.

      --

      Forget magic. Any technology distinguishable from divine power is insufficiently advanced.

    4. Re:Carmack said... by Fragnet · · Score: 1

      What I mean is that this variation is all different in the same way. If you've ever spent time flying around the Elite Dangerous universe, you'll find that once you've seen one system, you're more or less seen them all. Only artists and animators are able to genuinely surprise you.

    5. Re:Carmack said... by ultranova · · Score: 2

      What I mean is that this variation is all different in the same way. If you've ever spent time flying around the Elite Dangerous universe, you'll find that once you've seen one system, you're more or less seen them all.

      But this has more to do with current state of procedural generators rather than the concept of general. Try Dwarf Fortress, and you do get extremely varied environments to get your dwarfs killed in.

      Only artists and animators are able to genuinely surprise you.

      That is untrue. Any game with sufficiently complex mechanics will create surprising situations, through glitching if nothing else.

      What humans can currently do that computers can't is recognize and combine tropes, or generic thematic elements, and adapt them to current situation. However, there is no known reason why an algorithm couldn't do so too.

      An intermediate step might be to move the gameworld over from curent scripted and otherwise static model to a strategic simulation. Imagine, for example, an open-world game where the computer was playing a game of Civilization in the background and a procedural generator was responsible for rendering the results - city growth, roads, marching armies, etc - in the player-explorable environment, along with quests to affect the game either way (for example, the player could sneak into a besieged city to open the gates, or assassinate the army's general). Space Rangers does something like this: the missions you do affect how the game world develops, the war goes on in the background, and as you get stronger you become more and more important player in it.

      The whole reason everyone and their dog is investing in physics engines is precisely that they can procedurally generate behaviour as it's needed, thus freeing the artist from having to guess everything the player might do (which is impossible). Procedurally generating animation is currently under development - beyond current ragdoll physics, that is - and then, of course, there's games like Victoria which are about generating alternate world histories. Then there's the ancient Neverwinter Nights Aurora toolset where the designer laid down rooms and procedural generator filled them with semi-random details.

      The future of gaming is procedural generation, both because automation is the only way to keep costs under control and because the end result is superior. That doesn't mean those games won't require artists, it simply means those artists will be doing high-level design of thematic elements and interacting systems rather than hand-painting every pixel and modeling every room.

      --

      Forget magic. Any technology distinguishable from divine power is insufficiently advanced.

  11. Re:yawn. by mark-t · · Score: 4, Interesting

    The algorithm is new... or at least it's one I've never seen before, and I've been a fairly avid follower of game programming algorithms since the early 1990's, and reading rec.games.programmer every single day.

    Using steering behaviors or a physics engine to separate randomly generated rooms is a different approach from anything I've ever seen for dungeon generation.

    I'm not convinced that the approach is necessarily superior to anything else that has been done so far, however. It is innovative, yes... interesting, even. Useful? I'm not so sure about that.

  12. Not new, not news. by rickb928 · · Score: 1

    The third major rev of Avatar brought an extensible maze generated as needed. One team explored 800+ to the east. Coming from a game that was in a maze 30 by 30 and 15 floors deep (and everybody and their mother knew it), this was a revelation. And annoying.

    --
    deleting the extra space after periods so i can stay relevant, yeah.
  13. Re:gamasutra my ass by Fragnet · · Score: 1

    Well said, sir.

  14. Re:gamasutra my ass by rochrist · · Score: 1

    Wow, what are you Coward? 12 years old?

  15. PLATO Circa 1975-78: Mines of Moria by Baldrson · · Score: 1

    Probably the first massive multiplayer dungeon game to employ random algorithm "room" generation was the Mines of Moria on the PLATO system circa 1975-78.

  16. Re:Better Interview w/ the Creator of Brogue on To by Purity+Of+Essence · · Score: 1

    Big fan of Brogue and I find that the author did a great interview explaining how it works in his game here:

    http://www.rockpapershotgun.com/2015/07/28/how-do-roguelikes-generate-levels/

    He gets more into how the terrain is generated as well.

    That is a MUCH better article. Brian Walker has a good overview of dungeon pathfinding too.

    http://www.roguebasin.com/inde...

    --
    +0 Meh
  17. New tools in the game engine by metaforest · · Score: 1

    It is easy to argue that all of the ideas in the article are not new.

    What I found interesting is that rather than reinventing the wheel with custom built functions this author took advantage of
    library element that are already in the game engine. Using the physics engine is only a heavyweight solution if you don't have a
    preexisting API for handling physics. Since all modern game engines come with these tools it makes sense to adapt the crusty
    old process of generating mazes to the tools that are right in front of your nose.

    And all you fellow graybeards kvetching about this kid's solution... get stuffed. He's doing something and sharing his solutions. /rant

  18. Oh this is SO important... by iq145 · · Score: 1

    NOT

  19. Re:Oh just like Sword of Fargoal? by Half-pint+HAL · · Score: 1

    Oh, I definitely agree with that. Just saying it's not quite like Sword of Fargoal...

    --
    Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
  20. Re:Oh just like Sword of Fargoal? by hattig · · Score: 1

    This is a more advanced algorithm than what would have been used back then! Placement was an integral part of the algorithm (rather than being done by a physics engine to 2D areas within a 2D space).

    One example is the "mining" algorithm. Start off with a room, then from one of its walls, dig a corridor or another room. Repeat n times. Dungeon generated.

    Obviously you could then do things for object placement. The article's algorithm can make use of the minimum spanning tree endpoints to place items at the end of long paths in the dungeon, for maximum playability. You could alternatively use some form of graph colouring. Back on the VIC-20, placement would probably have been random.

    There's loads of dungeon generating algorithms on RogueBasin if you're interested.

  21. Re:Overkill by hattig · · Score: 1

    Actually it's a different mechanism to generating non-overlapping rooms than other algorithms that either place rooms, or divide up areas. Overkill - probably. Does it matter? No, not on today's hardware. Also this algorithm isn't portable to very old computers, not that most people care.

    There is always a desire to create 'realistic' dungeons. The truth is, most real dungeons are small and compact, so the entire concept of 'realistic dungeon' is rather silly.