Posted
by
samzenpus
on Wednesday February 18, 2015 @03:02PM
from the random-encounters dept.

Nerval's Lobster writes Procedural dungeon generation is a fun exercise for programmers. Despite the crude interface, such games continue to spark interest. A quarter century ago, David Bolton wrote a dungeon generator in procedural Pascal; now he's taken that old code and converted it to C#. It's amazing just how fast it runs on a five-year-old i7 950 PC with 16GB of RAM. If you want to follow along, you can find his code for the project on SourceForge. The first part of the program generates the rooms in a multilevel dungeon. Each level is based on a 150 x 150 grid and can have up to 40 rooms. Rather than just render boring old rectangular rooms, there are also circular rooms. "There are a couple of places where corridor placement could have been optimized better," Bolton wrote about his experiment. "However, the dungeon generation is still very fast, and could provide a good programming example for anyone exploring what C# can do." For C# beginners, this could represent a solid exercise.

Even in the bad old days, stuff would occasionally break, but the whole site usually stayed up, and in either case things were fixed very quickly. Outright outages up until Dice took over were pretty damn rare, but now as you said, they've become rather frequent, and when they do happen, it's for hours. Also the alignment of various elements occasionally goes wonkey and comment boxes only fill up half the screen.

I almost wonder if they are trying to degrade the performance of the site

In fact, C# is a conspiracy *against* CPU vendors: the plan was to say bye bye Intel x86 because Windows 32 bits was aging, and be more open to transition to other CPU such x86_64 while keeping the developer base. Just for this reason they succeed.

There are still plenty of people interested in getting stuff to run in 256-512 MB with a 700 MHz ARM. I think about half the tendency for code bloat in the past 15 years has been the decline of cheap hobby PCs - a vacuum that has now been filled. Still seems like a lot to me, but it does at least impose a little restraint and interest in optimization.

(The other half is of course managed languages, but really slimming down C# to work on a RP doesn't seem impractical - just something that MS hasn't had a re

I don't get this submission. I wrote the same thing in 1982 on a TI-99/4A with 16kb RAM and a 3MHz 16 bit chip. It loaded from a cassette deck using an analog stream from the tape. It displayed on my TV. It was written in BASIC. It sucked.

But it *worked* fine, I mean it drew the map in well under 10 seconds, printed it, then used the edge dots of one side as the seed for the next section of the dungeon. Isn't that what this is, and why do we even need an ARM for this, you should be able to get decent performance from a 4004!

This was my first real piece of software, and it worked on the first try (by that I mean I wrote it and bugfixed it, and...it worked). I was 13. You millennials or whatever you call yourselves should be running rings around me - who needs multiple cores or C# for this?? Do it in Minecraft, then I'll be impressed.

I also wrote this, but I wrote it in Pascal in 1987, beating the author by 3 years unless his rounding function is broken.

Mine also sucked.

Still, procedural generation remains the next big thing, and applying it to something as simple as a text-based map, limited to two dimensions and "wall" or "not a wall" is nostalgic for many, and interesting for those who did not do the same project in some fashion.

The need for multiple cores did not exist - it just happened to be the hardware available, I assume. It w

The other half is of course managed languages, but really slimming down C# to work on a RP doesn't seem impractical - just something that MS hasn't had a reason to focus on.

Or if you're impatient, you could just use D - the syntax is virtually identical to C#, but you get the performance of native code. I actually wrote some patches for buildroot a while back that added support for gdc, which make it pretty easy to compile a suitable toolchain for using D on a Raspberry Pi.

It is a big dungeon, mate! A really big dungeon! You know, with torture chambers, torture mistresses and such. Lots of moldy bread and stinking water. Imagine the whimpering and sobbing. Water drops down from the ceiling and flows down at the walls. The stink of excrements and rotting corpses. Then all the guards with warts on their faces, sometimes on the nose, sometimes on the cheek, sometimes on the forehead. All that needs computing power! Especially the stink and the warts, obviously.

Yeah, dungeon keeper!That was awesome!!! Especially if you played late at night: 02:00 at night, the background voice: "your monsters demand cable TV!" 04:00 at night: "Your monsters are tired running around at your command, please go to sleep!" (Well, roughly translated from german).

The very best game intro ever is the start up cinematic of Dungeon Keeper I. A shiny hero in the shiny armor with a friend or two is entering the dungeon... panicking monsters run deeper into the dungeon luring him after them.

I wrote one last week in a single line of BASIC running on a 4MHz Z80 system. Admittedly the level size is only 80x24, and it is more random than procedural (i.e., rooms can be left isolated), but that's the nature of trying to fit that into a single line of code (monster placement and gold placement take up another line).

It takes a few seconds to complete - mainly due to it being interpreted BASIC on a 4MHz Amstrad CPC.

I figure that most "dungeon generating algorithms" are quite unrealistic anyway. If you

From looking at the article, it doesn't actually state how fast it runs. Maybe it's just a comment, that it actually does run very fast. Like it generates a very large and complex dungeon in.1 seconds, whereas on the machine it was originally written on, it would have taken minutes.

There are already lots of shitty dungeon generators, you're probably not doing anything useful like using features that are in sourcebooks, and dungeon building is almost certainly something you should be doing by hand anyway. Even if your party is a bunch of mindless murderhobos. Good dungeons make enough of a difference that people will actually pay real money for them. If you want story on top of an interesting tacti

As an old school DM, I make the "trap" category fit the premise. As stated by the parent I'd have "traps" be a magic mouth that calls the guards. I also might have a "puzzle" that would be solvable for XP. For example, trying to "liberate" a magic sword from a statue. Sometimes I'd bring in a real life puzzle for the players to solve, just as a change of pace.

Of course, traps do come in handy. Grimtooth's books were fun, and I'd have something there so the players can think they outsmarted the DM, espe

The funny thing is that the random kicking of doors, breaking of clay pots, and killing anything that moved, was not the standard trope when I started. I am showing my age, but if PCs tried that in a town, the local watch would be on them in no time. If the PCs dispatched the watch, then they would be marked as bandits, and everyone and their brother would be going for them for the reward (and I'd have the "escape from the royal gaol" campaign at the ready.)

I really don't understand why this article is a thing. For 1, it's a really shitty way to generate dungeons as there are vastly superior ways of doing it: cellular automata http://www.futuredatalab.com/p... [futuredatalab.com] for example can product cave like dungeons, regular rectangular dungeons, etc and not just something made with ASCII that needs to then be converted. I've even seen KDtree's drawn out to represent rooms and such for muds. This article fails on a multitude of fronts. First being the DICE ad tracker embedded in the link to the article. Second, being the fact that he is "impressed" with how fast it runs on a Core-i7. Third, the use of SourceForge, where projects go to die. And finally, the fact that the article says it's geared towards beginners, teaching them bad coding practices and the like with the shitty code that's on sourceforge.

Call me when he re-writes Dwarf Fortress [bay12games.com], which doesn't just build the dungeon but also the countryside around it along with a few more continents and oceans as well as a thousand years of history for each of the major civilizations living there.

I've had some fun with this..Cave Generationhttp://i.imgur.com/grPvlNp.jpg

Classic with random room shapes.http://i.imgur.com/Hjh1dSw.jpg

Maze generation.http://i.imgur.com/36p9jR0.jpg

I can do a 640x640 map under 2 minutes on an i5 1.2ghz with 4 gigs ram. My dungeon rooms are all done with procedures and my rogue maps do boxes, circles, triangles, diamonds, H's, doughnuts. I wrote this in Java for fun and here are some of the references I used.

For each project you could generate a parser for a new programming language with procedurally generated characteristics, and use that to write your program. For example, it could make up a object oriented language where all variable names are required to be nonalphanumeric, and all of the operators are letters. Or a language where every variable is really just a FIFO queue. Or a language where you have to use sockets instead of function calls, with recursion being performed via the loopback interface. M