Randomly Generating Levels

[ddm]

I've been toying with this idea of creating a map in Hammer that isn't actually a map, but instead a tileset of templates that is turned into a map using the RandomCase input on logic_cases. I've recently produced my first prototype for testing the concept (a simple CS:GO map that randomly chooses 1 of 4 terrorist spawn locations, then picks 2 of 4 available door positions in 4 buildings - of course, bots loathe it as they just try to walk through walls), but I am intrigued by the capabilities of the Source engine and templates.

For example, is it possible to generate a HL2 SP level using a non-randomised start, followed by a randomly chosen first sector with randomly chosen walls in preplanned areas which contains a template maker to choose the next sector so that the sector is dependent on the previous one (for example, if the first sector has an easily available crossbow, the second sector has a 40% chance of being a sniping area, a 40% chance of being a standard area, and a 20% chance of being more CQC dependent, whereas if the first sector contains a shotgun regularly, there is a 0% chance of the second sector being sniping, a 40% of it being standard, and 60% chance of CQC)?

In fact, speaking of 'regularly', it's theoretically possible to use math_counters to accurately work out those percentages using how hidden each weapon is, the amount of ammo for it, and how common it is.

I mean, a HL2 map wouldn't work THAT well, because bots won't generate themselves a mesh on the go - they restart the map (and change the level from the randomness so that mesh doesn't work) - meaning only brush entities could be used as essentially cardboard enemies.

Minus the blindingly obvious bot problem (which might even be able to be fixed using a bit of code, a few hundred employees to spare and a highly successful video gaming company who made the engine in the first place *cough* *cough* and a new game engine getting ready for the first game with a 3 in it - come on, it's not like it's that difficult - he says with no experience coding bots - yet), with the current surge in the want for randomly generated content, randomly generated FPS levels probably aren't that far away...

I mean, Payday did it slightly with objectives moving so you couldn't just guess and essentially cheat the game and kinda break your own fourth wall, and I thought it was a well executed design decision.

And no TL;DRs, plz... (You either care about what I'm trying to say, or you don't. If you do, whoo! If you don't, I ain't happy with checking this - only to read a thousand posts simply saying TL;DR...)

[Dmitriy]

YOu can achieve it by using func_brush and prop_dynamic which are both movable entities. But it will be not optimized as using prop_static and world brushes. You will not have lightmaps, you will not have visleafs.
As for the bots, you'll have to code their navigation algorithms, to probably use some dynamic info_nodes for navigation or rework the navigation mesh to be dynamic.

[Dmitriy]

well, I'm not sure about lightmaps for func_brush because I didn't check it.

[Wazanator]

Yes, very possible someone did it for alien swarm http://www.moddb.com/mods/alien-swarm-director-mod

The only downside is it almost has to be done in single player as compiling then distributing a map on the fly in a multiplayer setting can be messy.

I suggest checking out Alien Swarms Tilegen tool and poking around its code if you want to learn more :)

[Dmitriy]

yeah, another possible aproach is to compile every area in a single map. Then when player reaches next area you choose which area will this be and load a specific map for that area. It will be like playing HL2 when you wait some time for next area to load. YOu can also code to load each area in the background so player will not notice a loading progress bar.
In this case you will not have any navigation problems or perfomance issues, you will just have a bunch of small maps ^^

[Rectus]

Another option could be to connect the tiles with teleporters or portals.

Teleporting has some severe limitations though. The connections between the areas have to be duplicated, and have to be in low visibility areas like s-bends. NPCs and other players also can't follow through seamlessly unless you teleport everyone at the same time. If the game uses nav meshes, the nav flow won't work between separated areas, and bots can't navigate through.

Having dynamic pathing, like the doors on your prototype map, can work with nav meshes, but only if the game has ways to block areas and recalculate flow. Currently only the L4D games have the entities to do it, but I don't think it would be a too big effort for Valve to implement it in CS:GO.