This random map generator for Left 4 Dead 2 mends predefined tiles together to a new level. The project is based on python and includes a crude VMF (Valve Map File) source reader. Seams are detected by special materials. A script for creating the navigation mesh for the bots and zombies is included. Although created for Left 4 Dead 2, the random map generator can work with any source based game.
The thrill of the unknown – one of the most important aspects exploring a Left 4 Dead map. The uncertainty of not knowing in which direction to go builds up tension. Unfortunately, after playing the same campaign numerous times, you soon know it by heart.
Consequently this project was set up. This random map generator for Left 4 Dead 2 mends predefined tiles together to a new level. The project is based on python and includes a crude VMF (Valve Map File) source reader. Seams are detected by special materials. See the readme in the archive for further technical documentation. A script for creating the navigation mesh for the bots and zombies is included. Although created for Left 4 Dead 2, the random map generator can work with any source based game.
The project is in an early proof-of-concept stage. Due to the lack of spare time, it is not actively developed. In case of updates, the current version is to be found at the author's site. The project is open source, feel free to pick it up. If you want to contribute, contact the author. License is CC BY-SA 3.0
Included Features:
- Nonlinear levels
- Support for more than one door per direction
- Support for doors in arbitrary position
- Support for overlays and cubemaps
- Checks for different door sizes
- Loop detection and mending with self
- Support for rectangular shaped map tiles of arbitrary size
- Map tile collision detection
- Support for more than one ground level
Missing Features:
- proper translation of materials
- fully automated nav mesh generation ("pointer" crosshair is not updated with setpos - player interaction needed)
- to be checked: what else apart from overlays and cubemaps needs IDs to operate
- to be checked: alpha blending on displacements
- Improved layout generation: Calculate distances while generating (Dijkstra?), limit dead-end lengths
- Support ladders: Improve automatic nav mesh generation
Adding map tiles and map tile themes:
A map tile is connected to the next tile with a "portal". To define a portal, create a solid brush within the outmost side of the tile. Apply the material DEV/DEV_BLENDMEASURE (configurable) to the side facing outward only. This markes this exact position to be a "portal". The combiner looks for portals to mend the tiles together. You may place a prop_door_rotating in the vicinity (configurable) of the portal. In case the door leads to nowhere, the combiner will remove the door and leaves the solid in place. In case the door connects to another room, the solid is removed and the door is left in place. A map tile must allow player transit between all portals.
A tile is always translated only, never rotated. Due to the process, all positions will become integers. Angles are unaffected.
There is another random map generator for Half Life 2 based games. The project's site is nonexistant anymore. The project seems to be abandoned.
I must try this someday!
You are a genious!
Sounds like a great idea, I'm curious as to how it actually all functions. I gotta check this out:3
I hope I'll find time to comment the code properly and write a decent description. Until then, feel free to ask me specific questions. I gave a detailed description of how it works here (in german): Thewall.de
Added a more detailed description and commented the code. Happy hacking!
No Gracias.
-Así El "Left 4 Dead 2 Y El 1" Ya Pierde El Sentido De Sobrevivir, También Pierde El Realismo Que Apenas Tiene El Juego...
-En Pocas Palabras Mejor Bájense El "Valve Hammer Editor" O El "Source SDK" Para Crear Sus Propios Mapas, No Es La Gran Cosa Y Son Muy Simple De Usar Solo Busquen Instrucciones En "Youtube" Y Listo
Saludos Y Ese Programa Es Pésimo, Ya E Tenido Para El "Counter-Strike Source" Y No Me Gusto Nada.
-Adiós.
Indeed, the map tiles I supplied are in no way realistic or rich in atmosphere. For this reason I call the project development to be a "proof of concept", not a finished program. Still, I object to your attitude towards generated content. Generated content might not work for Counter Strike as it is a tactic shooter. In Left 4 Dead you are more concentrated on running for your life rather than finding a good spot for an ambush. Take a close look to the existing campaigns. In most cases, you basically move from one building to another. Consequently, a map tile should contain an entire building rather than a single room. The generator then builds a building block you have to find your way out. In my opinion, the fact you don't know where you need to go supports the realistic aspect of Left 4 Dead.
I don't think Hammer is easy to use for everyone. Especially if you want to design maps as large as needed for Left 4 Dead, you need much time to place details. I hoped I somehow could make this effort reusable. The binary BSP map format is rather complicated compared to VMF and hard to edit. Consequently, circumventing the use of the SDK and the map compiler would be incredibly tedious.
I would love to see this done in a different approach. You seem to like the idea of having fixed elevation and grid .vmf placement for non-linear placement.
I understand where you're coming from, but ugh. While you're simplifying so much how the room placement is handled, you also make the layout so strict. Not to mention L4D works in a way everything follows one course, the choice of action should be made inside rooms individually (IE a medium-large room with 2 floors with one exit on each levels, only one of them is open ETC)
While a proof of concept, the chances are for someone to pick this project alone is rather slim, and it has to involve the fact that they have Python knowledge.
If you really care, I'd love to see this re-done in a flash from you in a very simple-minded and linear "Non-grid based" room placement system that works with any elevation based on the picked room's exit and one exit only. Room prefix is probability in % (IE 100_Corridor is very common, 5_SpecialRoom is very rare). The users places their room in the appropriate folder, double click a file, it outputs a VMF file, they open it in Hammer, compile, generate the navs and voila.
My knowledge is limited to UE3 Kismet as far as scripting goes. I can't afford to learn scripting and learn how to simulate a layout generator at this current time.
So nonetheless.. I assumed this proof of concept was grid-based (like Alien Swarm TileGen) and it seems I was wrong. I downloaded/installed Python and Numpy because I was curious, that alone required some digging online to set up properly.
Every time I generate a level with any seeds, the stair case room is always picked first at the same door every time. The Exit location is only 3 tiles away and there are dead ends everywhere. The exit is always at the north-most location. I cannot add nor remove rooms without the combiner not liking it. (As if the VMF files are specified somewhere)
If I were to pick it up I would have to get rid of most concepts while keeping the portal and collision aspects, those are brilliant by the way.
I hope someone picks it up as a kick-starter concept. Or if you ever feel like coming back, work on the successful aspects of your project.
Thank you for your appreciating thoughts. :) Sorry I did not reply to your comments at once (in case there is a subscribe button somewhere, I haven't found it yet). I'll try to look into the problems you describe (the generation not being random, not accepting less/more/custom tiles). I am busy with my actual work, but I am not really "gone". Unfortunately I also cannot see that I will "come back" to this project anytime soon. :(
Hello, it's a shame you're not "coming back any time soon". But if you do...
I figured why the custom tiles I was adding didn't work properly, it was because while rotating them, the nearest portal to 0,0,0 wasn't aligned properly. That was an amazing discovery.
After using and appreciating your system for a while and enduring the thousand of manual processes involved, all I'd like you to change is make it Linear ; one path and one only. Add probabilities for specific rooms (for instance, all rooms with the "rare_" prefix would have a 5% chance of being picked and so on)
And most important of all, a starting room First rule, then ending with a finale at the end of the branch.
Lastly, I see you have attempted to get around the nav_generate complications... I really wished the navigations could be built outside of the game (3rd party software), manually loading the levels individually is a pain. Unfortunately nav_generate seems to be only possible from within the game with all the resources loaded.
Your encouraging words tricked me into spending another hour on this project. It's good to hear someone is actually toying with (and creating tiles for!) this. :)
I added more detailed instructions for python and numpy. Sorry for the inconvenience.
I changed the tile chooser so the level becomes more linear. Dead ends are still possible (and will be until I implement a recursive and deterministic approach). However, it now is rather unlikely to have more than one tile leading to a dead end.
Your idea for probability prefixes is good. I added a feature to put a tile in the pool more than once to increase it's likelihood to be chosen. Additionally, I added a flag for a tile to be added only once (for big tiles with crescendo events and alike).
The nav_generate issue is one problem that made me abandon this project. I wanted my server to create a random map every week. At some point I found out, the creation of the navigation mandatorily needs user interaction because the crosshair position is only updated by keystrokes, not by scripts. More annoying, the process involves the game client. Almost impossible to achieve this fully automated on a server that has not even a graphic output. :(
I also looked into the issue of the generator not being random enough and very picky. Actually, I forgot to remove some lines I addeed for debugging. They interfered with the tile selection. Also, especially due to the new "more linear" placement, it is quite possible for the generation to fail. If you are unlucky and the first three tiles are placed in a loop with no portals left, no more tiles can be added. This actually happens more often than I expected (as said, an recursively retrying implementation is pending).
Nice! Glad to hear about all these changes, be sure I will have a look into it soon enough.
where i can download it????
Use the big download button above Moddb.com or visit my site Hehoe.de
Here's more feedback for your tool after much testing and shortly about to complete procedural content using it:
1) Texture tiling is necessary? If the reason for it being there is related to not having texture seems between rooms, could it please be optional or stripped out of the code? It creates all sort of misalignment everywhere in the tiles, including precise texturing work all ruined.
2) starting from the middle of the editor limitations often results in brushes being deleted and out of bounds. This a common and irritating issue occurring because there's not enough space for the rooms to expend further. I was thinking about a south-to-north option in the combined.py file.
3) As mentioned in previous comment, an option for room probability would be very useful.
Here's a sample of the project I'm working on, it's VERY WIP and is wonky, but it works and all nav was generated by one hit of the keyboard using these tiles.
Mega.co.nz
Hi there again. Sorry it took me so long to respond. I am still pretty tied up in work. I hope to find time to work on this in during the winter holidays.
1) Texture tiling is not necessary. Texture translation does not work reliable in general. The tiling made it better in some circumstances, but I absolutely believe it can produce problems at other ends. I'll dike it out. I am not sure if the compiler will like infinitively huge offsets, though.
2) I'd like to investigate this problem further. The dead project mentioned above had the same issue. As of today, I never ran into it myself. I am eager to try it with your projekt, however, the provided link expired. I'll be in touch with you.
3) I added such a feature already, but I forgot to update the README in the archive. My bad. The paragraph reads as follows:
Tile Naming Convention:
The files may utilize prefixes to define their contents:
"start" marks the tile to be a start (saferoom or open area).
"finale" marks the tile to be the final (rescue or saferoom) tile.
"once" marks the tile to be inlcuded only once (if at all, for crescendo events or special tiles)
"10_" or any other integer followed by an underscore to increase the likelihood of this tile to occur (for repetitive standard tiles).
Can you make it easy to launch? i'm not that good at coding and stuff.
To put it short: No, I probably won't do so.
Right now this project has a variety of issues making the whole workflow cumbersome and error-prone. :( For the unlikely case I find time to improve the basic functionality, I surely can add commands which run the map compiler and the game after map generation. Right now, putting effort in the ease of use (with the actual use being close to zero) just makes no sense.
This comment is currently awaiting admin approval, join now to view.