Randomizers that are actually random?

I've found several cool randomizers, but it seems that they all rely upon replacing monsters in spawn locations that already exist in a map. Is there such a thing as a randomizer that spawns monsters anywhere in a map totally at random?

If there is such a thing, it wouldn't be particularly practical, as it's hard to programmatically detect where would be valid to place monsters and avoid either game-breaking issues or monsters stuck in comical places they shouldn't be.

esselfortium said:

If there is such a thing, it wouldn't be particularly practical, as it's hard to programmatically detect where would be valid to place monsters and avoid either game-breaking issues or monsters stuck in comical places they shouldn't be.

Yes but perhaps this problem could be avoided by using existing positions as a guide. So long as a map has monsters / items to begin with the algorithm could randomize their positions within the sector / neighbouring sectors that the monsters / items are in. A move to a candidate neighbouring sector would be restricted by the path to it (monster / item fits through gap) but also line flags i.e. sound block could prevent it. I may try this one day.

I guess you could just have a ton of spawn spots everywhere and spawn randomly on those. Isn't this basically what Left 4 Dead does?

What would be a good UI for a randomizer program?

I guess the obvious thing to do would be: the user twiddles some settings and presses a 'Start' button, an open-file dialog will ask for the input wad, then when finished a save-file dialog would ask for the output filename. But I wonder if there is a better way?

Yeah, I had a feeling that the random placements would be problematic from a programming standpoint, but I know things like Oblige do it when generating maps so I just assumed that it must be possible somehow.

It's generally a lot easier for a program to know the properties of something it is making than to analyze the properties of something else.

Another idea for randomizing monster positions would be to use a modified version of the physics code already present in Doom after picking a random angle and distance. If the thing hits any restrictions just have it reflect off like a billiard ball. Also perhaps a check that the monster has a certain amount of free movement before doing this (ignore monsters waiting in traps, just randomize the type if possible).

andrewj said:

I guess the obvious thing to do would be: the user twiddles some settings and presses a 'Start' button, an open-file dialog will ask for the input wad, then when finished a save-file dialog would ask for the output filename. But I wonder if there is a better way?

Yes, I think the user would want to choose:
Difficulty / monster types.
Power-ups / health / weapons.

Drag and drop support would be nice as an additional way to select a wad / start the program.
Maybe an option to auto-generate the output file name or perhaps configure a source port and have the program act as a launcher as well.

I'm thinking about making my own randomizer program, using OBLIGE as the basis. Not sure whether I'll actually finish it (but it's something I'd personally find useful, and that's always a good motivator).

Mock-up of what it might look like:

That would be so cool! To be honest, I had Oblige in mind when I started the thread!

That would be an interesting program to have, for an alternative to those certain maps in the shovelware collections.

On the subject of batch-processing maps, I've always wondered if a batch program could find a clear 512x512x512 (or specified size) void space in each map (the distance from the 0,0 origin needs to be a multiple of 512) and add in a sector there with specified textures and flats, for easy addition of sector-based skyboxes to every map.

phi108 said:

On the subject of batch-processing maps, I've always wondered if a batch program could find a clear 512x512x512 (or specified size) void space in each map (the distance from the 0,0 origin needs to be a multiple of 512) and add in a sector there with specified textures and flats, for easy addition of sector-based skyboxes to every map.

This could be done but if you don't mind using a GL based port that supports GLDEFS (glBoom+, GZDoom) you could create a wad that only contains the skybox (GLDEFS + images). Then use it with any map you want to add a skybox to i.e.
-file example.wad skybox.wad

phi108 said:

On the subject of batch-processing maps, I've always wondered if a batch program could find a clear 512x512x512 (or specified size) void space in each map

To me that seems like a feature for a source port (and already possible in some judging by 4mer's post).

With my program I would draw the line at modifying the structure of a map, since that would require rebuilding the nodes and I'd rather not do that (because the new nodes may not work as well, or mess up some special trick).

However I am interesting in being able to change the textures, either a small degree (e.g. swap around the STARTAN textures in tech maps), or a large degree (convert tech maps to castley maps and vice versa).

On a very well-formed map you could do in-out tests on sectors or subsectors, but I think it would be a pretty slow process - something an editor can do, but you wouldn't want to do at runtime. As for finding a box that does not intersect the level, you'd only have to determine the level's bounding box, as is done for the blockmap calculation, and then place your new sector(s) outside of that bounding box (checking to make sure there is room between the edge of the map and the +32767/-32768 boundaries might be good for fail-safeness).

I haven't tested this but I was thinking:

Take the head node.
Using it's bounding box pick a side that runs perpendicular to the partition line.
Check there is enough space.
Use the side as a partition line for a new head node.
Put the skybox in the new half.
Update the rest of the map data as necessary.

Edit:
Ignore the bit about picking a perpendicular side.
Create a rectangle that encloses both child bounding boxes of the head node (this will be used as one of the bounding boxes for the new node).
Pick any side from that which can be extruded to contain the sky box sector.
The head node partition line would be chosen from one of the egdes of the skybox sector.

4mer: ahhh, just rejigging the existing nodes is a good idea, should work fine (for bonus points: do any GL nodes as well heh), and there's no need to adjust the blockmap since nothing will be moving there.