18 Jul, 2006, Justice wrote in the 1st comment:
Votes: 0
Alright, just wondering if anybody uses room generation…

How you handle things and why.

I personally don't like pure generated content… but like time saving tools for builders. Now, I'm starting a new mud… writing all original areas. To help builders, I've implemented a couple of commands to speed things up.

Basically, I have 2 commands, one copies rooms onto other vnums. It gets everything except exits and can be used in 2 ways. Either it copies a single room onto a set of vnums, or it copies a set of vnums onto another. When copying multiple vnums, it randomly selects a room from the copy set for each new room.

The other command links rooms. For now it can handle grids (ocean/plains), or random linkages (forests/tunnels/mountains). It can also delete all the exits if you don't like the initial results.

Anyway, still adding new features to the room linker, but the idea is to give a builder control over how it works. You can for example… build a room with the proper sector, name, and flags, copy it onto each of the vnums, and then simply add any unique features for that room.
08 Aug, 2006, Davion wrote in the 2nd comment:
Votes: 0
I've been meaning to respond to this for awhile! But didn't have the time at date of post! The only form of room generation I use is from a png. The world I've been building is coordinate and distance based. It came with one of my builders showing me how he mapped out his area via paint before he ever built anything. Then going through the menial task of using walkabout to map the area. I figured, why not cut out the step! I use each pixel as a room. Some say this makes it hard to build, but if you zoom in enough, a pixel can be about 1"x1" on your screen. If you can't fill those in, you need a better percription! It uses the rgb values to determine the sector type, and offsets of the base colour to determine the exits. I have a small snippet of code (I coined it SmrtExits™ ) that builds the exits in the rooms based off that offset, and the adjacent sector types eg. If a city wall is next to a field, no exit is built in that diretion. If the city walls green value is +1 it becomes a gate. Little things like that. It took a bit to get the fine tuning done, and once finished I was the only one who could make heads or tails of it (due to the no documentation thing). It worked out quite nicely for me when I was building a test world, with simple test towns and forests in the world.

On the MUD side of things, I had a 'paste' function, where you sent me the .png. I throw it in a image file on the server (didn't setup a web interface) and then they stand in the place they want the area, and 'paste whatever.png' and bam! It was overlayed onto the map. They could then walk through the area and fix up any of the exits that didn't make sense, add progs and all that jazz.

Another idea I've been thinking about is having mobs reset very similar to this one. One map could be for the rooms, another for the mobs. Each area could have 765 different mobs (255x3) r255b5 = vnum 260 (each area's vnums start at 0) and have things reset like that. I was even going to do it for the entire world map to populate the wilderness, but I have yet to get that far… it's on that wonderful todo plate.
15 Aug, 2006, Justice wrote in the 3rd comment:
Votes: 0
I've seen a few systems similar to this, using either an image, or an ASCII map to generate rooms. How do you interpret the individual pixels into a room? It's it simply… "this color gets these settings" with some kind of description generator? Or do you calculate values off the color and surrounding pixels?

I'm guessing that with your system, as with mine… the real work is in the exit generation. My system doesn't really generate rooms, a builder either makes the room, or copies it. I've almost gotten the linkroom command tied off, still needs more testing, I may release it later, but since I use some of the C++ standard containers, it'll require the SmaugFUSS C++ conversion (I should split that off into it's own snippet). It also uses the coordinate stuff from my ranged search code, but that can be duplicated easily enough.

The linkroom command has 6 primary functions. clear, random (no coord), random (coord), grid, directional, maze.

Clear deletes all exits. I'm adding an exit flag to allow builders to mark exits that cannot be cleared using this. The primary purpose of this function is to allow builders to start over if they don't like the results of the exit generation.

random (no coord) generates a series branching exits with no concept of spatial positioning… ie… rooms could overlap, etc. The process is simple… take the first room and put it in the "used" list, for each room that is provided, pick a random room in the "used" list and add a 2-way exit in a random direction. This is good for generating paths/roads, tunnels, caves, etc. Note that no branch will ever connect to any other branch. Although a builder can add these later.

random (coord) works identically to the previous, except that each room is given a coordinate that represents it's offset from first room. No 2 rooms can have the same coordinate (preventing overlaps). The builder can specify a "link-back" percentage… when a new room is adjacent to another room, the "link-back" is the chance that a 2-way exit will be formed between them.
This is good for parks, forests, swamps, mountains, etc… fairly open spaces that have multiple paths through them.

grid is used to link rooms into a grid… You pass in a range of rooms and a "width", it starts at the "southwest" corner, linking to the east. When it reaches the "width" it returns to the western side, and adds a row north of the previous row until it runs out of rooms. The grid optionally wrap exits on east/west or north/south creating areas that seem to go on infinitely.
This is good for oceans, plains, fields, squares, etc…

directional is used to create 2 way exits in the same direction between 2 sets of rooms. It's original purpose was to link 2 "grids" vertically… Basically, given 2 sets of rooms, it links each room in the first set to the corresponding room in the second set using the given direction. By offsetting the sets by 1, you can create a long straight path, or using 2 grids of the same side, you can fully link them vertically.
This was requested by a builder who is making an ocean with a "surface", "underwater", and "oceanfloor"… outside of linking massive grids together, I don't see it being too useful… My "walk to link" code can handle long straight lines without requiring the rooms be sequential.

maze is used to generate random exits with little or no form. Basically you provide 2 sets of rooms. For every room in the first set, it checks each direction and if no exit exists, it creates a 1-way link to a random room in the second set. It can optionally set the randomize exit reset on the room. The idea is to build the correct path through the maze, and then fill out all the other exits.

Anyway, that's the basically what I'm doing, besides the ability to copy rooms that I mentioned before. I'm contemplating the ability to "overlay" aspects of rooms on top of each other. So you can take existing rooms and copy parts of another room onto them… like progs, or sector/flags, etc. This would be used by builders to fine-tune areas, or to add effects to them as new progs are written and new features. this idea came about when I generated a "test" forest and thought, hrmm, wouldn't it be nice to change some of these rooms to a road without having to set everything manually.