A random dungeon generator in C, small enough to fit on a business card (gist.github.com)

Very cool.

To try and understand it I reformated it to make it somewhat readable:

https://gitlab.com/snippets/1832264

Previously: https://news.ycombinator.com/item?id=19290215

I really hope Ginny was a dog or a cat or some other pet. Terrifying thought, it might have been a child.

...still waiting for the google maps to for instance counterstrike map generator that must not fit on a business card...

Fucking black magic obfuscation. Is it possible to learn this power?

I want to see someone try to rewrite C++'s entire syntax in the form of another language (I just have to assume it has already been done.)

  #define r return
  #define l(a, b, c, d) for (i y = a; y < b; y++) for (int x = c; x < d; x++)
  typedef int i;

He's the same guy that wrote the book Game Programming Patterns. http://gameprogrammingpatterns.com/

I have written an obfuscated cryptographically secure random password generator:

https://github.com/samboy/rg32hash/blob/master/C/tinyrg32.c

The file has test cases, documentation:

https://github.com/samboy/rg32hash/blob/master/C/tinyrg32.md

and I even have a 12-page de-obfuscation of an earlier version of this program:

https://github.com/samboy/rg32hash/blob/master/C/nanorg32.md

(I have since then come up more size optimizations)

Does anyone know of a dungeon generated tool that takes a few, or many inputs? Type of creatures, terrain, season, presence of water, etc etc?

here is one in python(a very very basic version, big enough to fill an A4 size sheet :D ) https://github.com/anekix/dungeon-generator

Backported this to run on MS Visual Studio 2008 in case anyone is equally constrained and still wants to give it a go. Did it based on @Joker-vD's deobfuscated gist

https://gist.github.com/airstrike/66e0152e75c3a81fd1496bfbf5...

So this creates random maps? What does one do with the output of this thing?

Author here. I love all of the deobfuscations. Usually, when I put code online, I try to make it as clear as possible. It's really interesting to see that going the other direction actually makes it a more interactive experience for the reader.

This one is great: https://gist.github.com/airstrike/66e0152e75c3a81fd1496bfbf5...

A couple of remarks:

    // The door should not be created in the cave's corner or over
    // another door, or in another cave's corner. It's impossible
    // to make a cave without a door, because randInt(1) always
    // returns 0.
    if (atWallButNotAtCorner && FIELD[y][x] == TILE_WALL) {
        doorCounter++;
        if (randInt(doorCounter) == 0) {
            doorX = x;
            doorY = y;
        }
    }

The randInt() part here is pretty confusing. Here's the intent of the code. It picks a random boundary for the new room. Then it walks over the edges and finds every tile where the room's wall overlaps the wall of an existing room. Those are candidates where a door can be placed to connect this room to the existing one.

If no candidates are found, the room is discarded. This ensures the dungeon is always connected.

If there are multiple candidates, we only need to pick one. We want to pick one randomly because otherwise you'd get obviously biased choices where the door always appeared at the left-most edge between two rooms or something. The obvious way to do that is to build a list of the candidate coordinates and then choose a random element from the list.

But that's a lot of code. Instead, I use Algorithm R [0]. It's a streaming algorithm for selecting a random item as you walk the set of items being sampled. The idea is that you keep a running winner. Each new element, you have a random chance of replacing the winner. As the number of elements visited increases, the chances of replacing the winner decreases. So the first element has a 1/1 chance of being the winner. The second has a 1/2 chance of replacing the winner, the third 1/3, etc.

    // If the cave's walls were made completely out of corners
    // and doors, don't make such a cave
    if (doorCounter == 0) { return; }

This case actually means the new room didn't share a wall with any existing room.

    // We need to somehow record corners of all caves to check
    // for intersections later, so we use a special tile for it
    FIELD[y][x] = atCorner
        ? TILE_CORNER
        : (atWallButNotAtCorner ? TILE_WALL : TILE_FLOOR);

For a room to connect to an existing one, they need to share a tile on their actual sides, like:

    #####
    #...#
    #...#####
    #...X...#
    #####...#
        #...#
        #####

That's leaves at least one tile where we can place a door. If only the corners overlap, there may not be enough room to connect them:

    #####
    #...#
    #...#
    #...#####
    #####...# ???
        #...#
        #...#
        #####

    #####
    #...#
    #...#
    #...#
    ######### ???
        #...#
        #...#
        #...#
        #####

So, during room placement, the corners are not treated as part of the room:

     ###
    #...#
    #...####
    #...X...#
     ####...#
        #...#
         ### 

     ###
    #...#
    #...#
    #...####
     ####...# ???
        #...#
        #...#
         ### 

     ###
    #...#
    #...#
    #...#
     ### ###  ???
        #...#
        #...#
        #...#
         ### 

But, when rendering the rooms, I want them to look rectangular. So the special "!" means "render like a wall, but don't act like a wall".

    // 1d6 of entities to...