• Random level generation
    49 replies, posted
v [b]What I've programmed so far[/b] [url]http://facepunch.com/showthread.php?t=1468899&p=48294059&viewfull=1#post48294059[/url] [url]http://shrinker.beyond-veils.de/projects/IterationX/Fluffderg/[/url] ^ ---- Hello. I've looked around a lot and came to the conclusion that there is no random level generator project alive for HL2 at the moment. That is a real shame because this is a rather interesting topic with so many approaches. So I'm now pondering how I would do this, and came up with this rough idea so far, for a very specific type of map with a very specific design: 1. define a rough floor grid of varying row and column sizes - then generate a maze through the intersections of the grid cells, essentially laying out corridors that reach every corner of every cell; also add a few extra connections for loops here and there 2. repeat (1) for a few floors upwards and then add stairs 3. decorate the overall thing with a bunch of rooms, partly spanning multiple floors too, and extensions to the corridors for variations in lighting and design, and for providing cover spots 4. add a bunch of enemies and junk, laid out so that the farther we depart from the player's starting position, the tougher it gets That does not seem all too difficult... and makes me wonder why there are not many living projects like that around at the moment. The closest I got to such a thing for an FPS (besides playing STRAFE, [url=http://strafedevblog.com/post/93056717598/how-we-are-handling-level-generation-in-strafe]which has a rather interesting approach too[/url]!) was using an old version of [url=http://oblige.sourceforge.net/]Oblige (I think it was 4.X)[/url] to generate a level for Quake 1, but the style of level it outputs, while looking fancy in Doom, just doesn't work so well in Quake. Using a bit of modularization, this should be possible: [img]http://shrinker.beyond-veils.de/temp15f/2015-06-03%20gen%201.jpg[/img] Extracted modules: [img]http://shrinker.beyond-veils.de/temp15f/2015-06-03%20gen%202.jpg[/img] -S
[QUOTE=Shrinker42;47864388]Hello. I've looked around a lot and came to the conclusion that there is no random level generator project alive for HL2 at the moment. That is a real shame because this is a rather interesting topic with so many approaches. So I'm now pondering how I would do this, and came up with this rough idea so far, for a very specific type of map with a very specific design: 1. define a rough floor grid of varying row and column sizes - then generate a maze through the intersections of the grid cells, essentially laying out corridors that reach every corner of every cell; also add a few extra connections for loops here and there 2. repeat (1) for a few floors upwards and then add stairs 3. decorate the overall thing with a bunch of rooms, partly spanning multiple floors too, and extensions to the corridors for variations in lighting and design, and for providing cover spots 4. add a bunch of enemies and junk, laid out so that the farther we depart from the player's starting position, the tougher it gets That does not seem all too difficult... and makes me wonder why there are not many living projects like that around at the moment. The closest I got to such a thing for an FPS (besides playing STRAFE, [url=http://strafedevblog.com/post/93056717598/how-we-are-handling-level-generation-in-strafe]which has a rather interesting approach too[/url]!) was using an old version of [url=http://oblige.sourceforge.net/]Oblige (I think it was 4.X)[/url] to generate a level for Quake 1, but the style of level it outputs, while looking fancy in Doom, just doesn't work so well in Quake. Using a bit of modularization, this should be possible: [img]http://shrinker.beyond-veils.de/temp15f/2015-06-03%20gen%201.jpg[/img] Extracted modules: [img]http://shrinker.beyond-veils.de/temp15f/2015-06-03%20gen%202.jpg[/img] -S[/QUOTE] While I love the idea, Optimization would be finicky, and you'd have to keep it within certain dimensions as it cannot extend forever. There are some work-arounds, but you'll have to do some slick stuff as far as optimization goes. For instance, lets say we agree that the max room size will be 1024^3, rather than using fog, we can then just set the "-radius_override" to around 1280 to be safe. It's a rather sharp culling technique, as it just cuts off past that distance, and it does it in every few units, rather than constantly pushing back the cull. Now, lets say every room is connected by doors, rather than halls and corridors. Now when a player opens said door, we can fire outputs to move a room(probably a func_brush would work well here.) to said location. Lighting will fucking suck, mind you. You could have nearly all dynamic lights(Ow...), you could have models with baked lighting, or if all of the rooms are going to be on the same elevation, you could have just the floor be a normal brush. I'm sure there is another solution, as I just thought this up on the fly, and this is avoiding all coding, and just relying on the map itself(ie. without any modding whatsoever). I hope this helps a bit, and I'm by no means trying to discourage you!
If you do this in gmod use Lua to actually put the pieces in place. If you are still fussy about optimisation consider a culling technique as follows. for each grid square you are using, use bsp to work out which other grid squares the square can see, then when a player enters a new square redraw the map (clientside) only actually showing the pieces the player cab actually see from their current position. off this is unclear I'll rewrite later when I'm not on my phone.
I've attempted that in the past. Made nice framework that allowed adding rooms with ease, did not need grid, could go 3d, and generated whole thing in like, 1-2 seconds tops. It also supported easy setup. You could set how 'deep' you want level to be (in rooms), what rooms to use during generation, and also objectives(Kill all enemies/press all buttons then get out of level, and process repeats). Had to abandon that project after I found out that source completely messed up the way I used to generate rooms. And sheer amount of trouble with this doesn't help, too. Some context: Generation with 3 types of rooms: [img]http://images.akamai.steamusercontent.com/ugc/719790399128733052/B9598221CFFA7B5D954E5E3AA621C57920048E25/[/img] Where source's bugs screwed me over(This shouldn't happen, I even checked that in the sourcecode!): [img]http://images.akamai.steamusercontent.com/ugc/719790399128745525/ACEFFD2691EAB53FAF9E1E88C4249B2C845605EB/[/img] List of problems you will be facing while making this, with EXCEPTION of aforementioned generation bug: - Inline models(brush models, aka *12 etc.) SHARE shadows, decals and lighting. Shoot enemies in one corridor, and bullet/blood decals will appear on each one with same model. This can be solved with Propper, but then you need to sort out lighting(see below). - Lighting on regular models will not work as expected, as you cannot parent light entity directly to brush. You can use triggers + relative lighting ents for each room, but beware source bugs, and be advised that relative lighting ent works well only if there are worldspawn lightmapped surfaces present near, i.e. you cannot have original rooms suspended in giant black room(like I did) and use their original positions as lighting hack point. Found out that the hard way. - AI will be able to navigate to player within a clear walkable line to them. Don't expect them to take cover, jump or perform all that Smart AI goodness source once boasted. - NPC ragdolls and other temp ents will fall through brushes. Fixable with huge serverside ragdoll trigger, but take precaution: too many serverside ragdolls will either crash server(Ragdolls have separate limit) or make it grind to a halt. - There may be really weird flashlight/projected texture artefacts. - You cannot use static props or decals in rooms(decals are debatable, but they screw up everytime I try to slap them on any brush entity). - Be wary of ED_Alloc: No free edicts. Gmod had 4192 networkable edicts last time I checked, every other source game has 2048 of them. Logic ents(logic_relay, logic_case, etc) DO NOT count towards that number. Also, you need to make sure that all points of level are connected, which is a very complicated task in itself. I circumvented that via very specific generation approach, but I'm not even sure how you're going to deal with that issue. Good luck with this project, I really want to see someone tackle this issue in source.
Thank you for the constructive input so far. It's good to see other people messing around with this topic too. :3 I should point out here though: I want to generate VMF files, and not do this live ingame. I didn't even think of that possibility in the first place. :D Will post more here when there is more from me. :)
[QUOTE=Shrinker42;47868739]Thank you for the constructive input so far. It's good to see other people messing around with this topic too. :3 I should point out here though: I want to generate VMF files, and not do this live ingame. I didn't even think of that possibility in the first place. :D Will post more here when there is more from me. :)[/QUOTE] So youd want some program which, when run, generates a vmf? presumably of a "dungeon" type thing, not an open world type thing. Such a dungeon would be generated from previously built blocks of coridoor and rooms. Is that correct?
[url=https://developer.valvesoftware.com/wiki/Swarm_TileGen]TileGen[/url] in Alien Swarm is very similar to what you're describing. Its source code is available when you make an Alien Swarm mod.
Yes, I want to make a little program on my own that outputs that specific type of level, no outdoor areas for now. Can't tackle all that is possible by hand at once. :) It can always be likened to a dungeon generator, though it should not feel much like a dungeon in the end.
As cool as this would be, wouldn't your biggest problem be the inconsistent structure of a BSP? I thought there were alot of problems with it; like that grid units can get misaligned?
[QUOTE=SimplePlanz69;47873267]As cool as this would be, wouldn't your biggest problem be the inconsistent structure of a BSP? I thought there were alot of problems with it; like that grid units can get misaligned?[/QUOTE] vmf works on coordinates mainly. So stuff being unaligned from grid wouldn't be an issue. Something which might be an issue is overlapping brushes (not an issue once you finish bsp compiling) and generally poor optimisation (stuff like long corridors with too much visibility) Thin brushes would also make for a messy vmf but would no longer be an issue once you finish the bsp compile. (anything outside of the map is ignored anyway) As far as i see it there are 3 steps to the process. Generate the grid/template (I tried this once with a bsp algorithm not to be confused with the bsp compiling mappers are used to [url]http://www.roguebasin.com/index.php?title=Basic_BSP_Dungeon_generation[/url] though it is technically the same process) You could also use a thing where you place a room, then some coridoor then some more rooms etc Might also want to assign room types here. Generate the rooms - take the above grid/coordinate information and use it to build actual rooms ie place a bunch fo walls floor and ceilings. Optimisation should take place here, place hints on corners etc decorate room - for each room add other stuff like func detail pillars, pipes and lights. or crates and decals! Thinking about it, its kind of similar to ordinary mapping. Make a plan, block it out, decorate it. Might have a go in a week or so when I have free time. I tried editing vmf through code a few years ago but at the time I couldn't easily work with the format, this seems slightly easier than what I was trying, no promises though, I'm horribly flakey.
Like 03C0 suggested I would take a look at how TileGen works. I messed around with it a little but came to the conclusion that it doesn't look great unless you stick to themes that make sense for some repetition like Alien Swarms. Tips/thoughts from when I messed with it: * I liked TileGens approach of having a set of defined rooms that the program would then piece together because it meant I could detail a room and have it look good on it's own without having to worry about programming a way to decorate * TileGens approach also meant you could setup various themes and tell the program "I would like to use the theme dungeon" and it would then just use vmfs from the dungeon set. * Instances make life a lot easier * I found it easier to have a text file that stored how big a room was and where the entrances/exits were then to try and have the program figure that out on it's own * You need a LOT of variations on rooms for it to not look repetitive * Something like a depth first algorithm is probably the way to go and then expand off of the basic idea of that to make more complex layouts if your goal is to make something maze like
Well, I am gonna try my luck with really coarse BSP and then func_details for the finer details. In fact, I was amazed to see that if you put 2 func_detail boxes adjacent to each other, their faces will actually be merged during the compile process. o_O That was quite neat. In any event, it does make sense to start with the rough stuff and then generate the details in, based on the space generated. The way TileGen works is basically the way that's also described in the STRAFE dev blog. It is one approach of many. deceiver: Do go ahead and give it a try too! Certainly we can share ideas and try out different approaches. The players can only benefit from it. At the moment, I don't intend to load whole premade rooms, but just generate brushes from scratch in the program. Instances would make life easier indeed, but I'm not exploring that for now. Graphing algorithms in general are a good idea for this. Here's one other ingredient I have: Suppose you want to place a room with an odd shape, e.g. an L shape or maybe even a swastika, if the interior design demands it. :P You could keep track of which area of your floor is already blocked off by other rooms and randomly try putting your oddly shaped room in there... or what you also could do is: - when blocking off areas in your floor when placing rooms, also block off a little margin around them to make sure you could always place corridors - Instead of randomly trying to position an odd shape, figure out all possible placement positions for that shape and then pick one of those. It's a lot more computation work, but yields better results and makes the processor feel warm and loved.
Rooms with odd shapes will need special attention due to the nature of the PVS. Visibility optimization would have to be done by hand
[QUOTE=SimplePlanz69;47883993]Rooms with odd shapes will need special attention due to the nature of the PVS. Visibility optimization would have to be done by hand[/QUOTE] Don't see why tbh. Just make it add column brushes to func detail and add hints on the corners.
Just output corridor floors with my program. Created a function that has these inputs: origin of the piece in the world, wall present north or not, and the same for the other principal directions. [img]http://shrinker.beyond-veils.de/temp15f/2015-06-07%20gen%20floorfunc.jpg[/img] Next I gotta work on the walls. It's quite some effort to do it this way, but at the moment it's bearable. I've represented things in the coordinate system I'm accustomed to in my program. Here's a snippet for one corner of the trimmings: [code]--trim+fringe corner NW ( if not wallW && not wallN then [ Brush{ bPlanes = [ {-T-} Plane{pP0 = (x0, y0+16, z0 ), pU = (16, 0, 0), pV = (0, 0, -16), pVisuals = Visuals{vMaterial = texCreteTrim, vUAxis = (axisUT, 0.25, 0), vVAxis = (axisVT, 0.25, 0)}}, {-B-} Plane{pP0 = (x0, y0 , z0 ), pU = (16, 0, 0), pV = (0, 0, 16), pVisuals = Visuals{vMaterial = texNodraw , vUAxis = (axisUB, 0.25, 0), vVAxis = (axisVB, 0.25, 0)}}, {-W-} Plane{pP0 = (x0, y0 , z0 ), pU = ( 0, 0, 16), pV = (0, 16, 0), pVisuals = Visuals{vMaterial = texNodraw , vUAxis = (axisUW, 0.25, 0), vVAxis = (axisVW, 0.25, 0)}}, {-E-} Plane{pP0 = (x0, y0 , z0 ), pU = (16, 0, 16), pV = (0, -16, 0), pVisuals = Visuals{vMaterial = texNodraw , vUAxis = (axisUE, 0.25, 0), vVAxis = (axisVE, 0.25, 0)}}, {-N-} Plane{pP0 = (x0, y0 , z0+2*16), pU = (16, 0, 0), pV = (0, -16, 0), pVisuals = Visuals{vMaterial = texNodraw , vUAxis = (axisUN, 0.25, 0), vVAxis = (axisVN, 0.25, 0)}}, {-S-} Plane{pP0 = (x0, y0 , z0+3*16), pU = (16, 0, 0), pV = (0, 16, 0), pVisuals = Visuals{vMaterial = texNodraw , vUAxis = (axisUS, 0.25, 0), vVAxis = (axisVS, 0.25, 0)}}], bEditor = Nothing} , Brush{ bPlanes = [ {-T-} Plane{pP0 = (x0 , y0+16, z0), pU = (16, 0, 0), pV = (0, 0, -16), pVisuals = Visuals{vMaterial = texCreteTrim, vUAxis = (axisUT90, 0.25, 0), vVAxis = (axisVT90, 0.25, 0)}}, {-B-} Plane{pP0 = (x0 , y0 , z0), pU = (16, 0, 0), pV = (0, 0, 16), pVisuals = Visuals{vMaterial = texNodraw , vUAxis = (axisUB , 0.25, 0), vVAxis = (axisVB , 0.25, 0)}}, {-W-} Plane{pP0 = (x0+2*16, y0 , z0), pU = ( 0, 0, 16), pV = (0, 16, 0), pVisuals = Visuals{vMaterial = texNodraw , vUAxis = (axisUW , 0.25, 0), vVAxis = (axisVW , 0.25, 0)}}, {-E-} Plane{pP0 = (x0+3*16, y0 , z0), pU = ( 0, 0, 16), pV = (0, -16, 0), pVisuals = Visuals{vMaterial = texNodraw , vUAxis = (axisUE , 0.25, 0), vVAxis = (axisVE , 0.25, 0)}}, {-N-} Plane{pP0 = (x0 , y0 , z0), pU = (16, 0, 0), pV = (0, -16, 0), pVisuals = Visuals{vMaterial = texNodraw , vUAxis = (axisUN , 0.25, 0), vVAxis = (axisVN , 0.25, 0)}}, {-S-} Plane{pP0 = (x0 , y0 , z0), pU = (16, 0, 16), pV = (0, 16, 0), pVisuals = Visuals{vMaterial = texNodraw , vUAxis = (axisUS , 0.25, 0), vVAxis = (axisVS , 0.25, 0)}}], bEditor = Nothing} , Brush{ bPlanes = [ {-T-} Plane{pP0 = (x0 , y0+16, z0 ), pU = (16, 0, 0), pV = (0, 0, -16), pVisuals = Visuals{vMaterial = texNodraw, vUAxis = (axisUT, 0.25, 0), vVAxis = (axisVT, 0.25, 0)}}, {-B-} Plane{pP0 = (x0 , y0 , z0 ), pU = (16, 0, 0), pV = (0, 0, 16), pVisuals = Visuals{vMaterial = texNodraw, vUAxis = (axisUB, 0.25, 0), vVAxis = (axisVB, 0.25, 0)}}, {-W-} Plane{pP0 = (x0 , y0 , z0 ), pU = ( 0, 0, 16), pV = (0, 16, 0), pVisuals = Visuals{vMaterial = texNodraw, vUAxis = (axisUW, 0.25, 0), vVAxis = (axisVW, 0.25, 0)}}, {-E-} Plane{pP0 = (x0+2*16, y0 , z0 ), pU = ( 0, 0, 16), pV = (0, -16, 0), pVisuals = Visuals{vMaterial = texNodraw, vUAxis = (axisUE, 0.25, 0), vVAxis = (axisVE, 0.25, 0)}}, {-N-} Plane{pP0 = (x0 , y0 , z0 ), pU = (16, 0, 0), pV = (0, -16, 0), pVisuals = Visuals{vMaterial = texNodraw, vUAxis = (axisUN, 0.25, 0), vVAxis = (axisVN, 0.25, 0)}}, {-S-} Plane{pP0 = (x0 , y0 , z0+2*16), pU = (16, 0, 0), pV = (0, 16, 0), pVisuals = Visuals{vMaterial = texNodraw, vUAxis = (axisUS, 0.25, 0), vVAxis = (axisVS, 0.25, 0)}}], bEditor = Nothing}] else [])++[/code] I already cooked up an interface for outputting point and solid entities and editor sections too, the latter I want to use for grouping things according to their cells later. One weird thing I noticed is the texture rotation: I could set a rotation and Hammer would ignore it, and only rotate it as I intended when I set the rotation to 0 in Hammer again. It seems that when the map was loaded, Hammer changed the projection vectors on that particular face to somehow represent the rotation. I have a theory that Hammer links the rotation value properly if and only if the projection vectors are rotated in exactly the same manner Hammer expects with its own reference projections. So in short, I can't use the texture rotation setting properly but instead just rotate the projection vectors by hand. I actually like the flexibility Valve has introduced with those projection vectors a lot, just the interface in Hammer for manipulating those doesn't allow for exploiting their full potential.
I wonder, with a LOT of work, would it be possible to make a generator that created a full, whole, believable city...? Not in Source, of course, hahahahaha, but in maybe Unreal or Unity, or perhaps Source 2. Similar to if an AI played Simcity. Now there's a challenge...
Of course. Worked on walls (still need to finish the small corners, but I must go sleep now :(): [img]http://shrinker.beyond-veils.de/temp15f/2015-06-08%20gen%20corridor%20walls.jpg[/img] This is 100% procedurally generated stuff.
[QUOTE=ArcticWinter;47899989]I wonder, with a LOT of work, would it be possible to make a generator that created a full, whole, believable city...? Not in Source, of course, hahahahaha, but in maybe Unreal or Unity, or perhaps Source 2. Similar to if an AI played Simcity. Now there's a challenge...[/QUOTE] Sure people have been doing it since the early 2000's Couple of examples [video=youtube;FR9xI0GgrBY]https://www.youtube.com/watch?v=FR9xI0GgrBY[/video] [video=youtube;sZxf5XPIy30]https://www.youtube.com/watch?v=sZxf5XPIy30[/video] @Shrinker is this aimed at a specific gamemode or game? Or is it just universal? I think if you aimed at a specific game you would have an easier time refining it.
I am designing a specific level style for singleplayer. Can't do a wide range of things all at once in this starting experiment. :)
[QUOTE=wazanator;47909686]Sure people have been doing it since the early 2000's [video=youtube;sZxf5XPIy30]https://www.youtube.com/watch?v=sZxf5XPIy30[/video] @Shrinker is this aimed at a specific gamemode or game? Or is it just universal? I think if you aimed at a specific game you would have an easier time refining it.[/QUOTE] Just out of curiosity, could you use scene city generator to generate something for use in 3d skyboxes?
This is actually something I started experimenting a wile ago, I'm no codder but I managed to mod the Portal 2 Puzzle Maker to make maps for other games, it's impractical, very limited but easy, I did it mainly so my friends that don't know how to use hammer could come up with maps when we do LAN parties and then tweak and do an artpass to the good ones. Here is the almost final one I made for HL2DM: [t]https://dl.dropboxusercontent.com/u/18080053/images/2013-11-29_00001_2.jpg[/t] I'm left CSGO and [url=https://dl.dropboxusercontent.com/u/18080053/images/tf2_koth_mirror.jpg]TF2.[/url] But then I learn about tilegen and started doing some room instances using hl2 prefabs, I will get back to it someday, my idea was autogenerate airboat paths with other gameplay stuff.
That's pretty awesome, mister.
[QUOTE=wazanator;47909686]Sure people have been doing it since the early 2000's Couple of examples [video=youtube;FR9xI0GgrBY]https://www.youtube.com/watch?v=FR9xI0GgrBY[/video] [video=youtube;sZxf5XPIy30]https://www.youtube.com/watch?v=sZxf5XPIy30[/video] @Shrinker is this aimed at a specific gamemode or game? Or is it just universal? I think if you aimed at a specific game you would have an easier time refining it.[/QUOTE] Stuff like that might be useful for stuff on Source 2, where the lighting is all model-based.
[QUOTE=0bama;47939363]Stuff like that might be useful for stuff on Source 2, where the lighting is all model-based.[/QUOTE] Yeah, I agree. I've been practicing with Source 2, but with valve moving away from DirectX, and working on their own physics system I have zero reference for how detailed I can make things. There is no way to tell how it will perform, but hopefully, since their developing it for their engine, they will work in perfect harmony.
[QUOTE=GaleTheHusky;47939392]Yeah, I agree. I've been practicing with Source 2, but with valve moving away from DirectX, and working on their own physics system I have zero reference for how detailed I can make things. There is no way to tell how it will perform, but hopefully, since their developing it for their engine, they will work in perfect harmony.[/QUOTE] But if you wanted to do something like that in Hammer, there is a sketchup city generator and this: [url]https://developer.valvesoftware.com/wiki/SketchUp_to_Hammer_Export_plugin[/url]
Okay, this next step turned out to be quite difficult to program in a sufficiently elegant manner: [img]http://shrinker.beyond-veils.de/temp15f/2015-06-20%20gen%20maze.jpg[/img] [code]w = 20 :: Int h = 15 :: Int positions = DV.fromList [(x, z) | z <- [0 .. h-1], x <- [0 .. w-1]] marked0 = DV.map (\(x, z) -> ( x+z*w , x == 6 && z == 4 , zipWith (\a (b, c) -> (a, b, c)) [0 ..] ( (if x /= 0 then [(x+ z *w-1, False)] else [])++ (if x+1 /= w then [(x+ z *w+1, False)] else [])++ (if z /= 0 then [(x+(z-1)*w , False)] else [])++ (if z+1 /= h then [(x+(z+1)*w , False)] else [])))) positions marked1 = fst . MOD_T2.maze marked0 . System.Random.randoms . System.Random.mkStdGen $ 10[/code] *edit: And this barely loaded in Hammer. Was fun to try though. :D [img]http://shrinker.beyond-veils.de/temp15f/2015-06-20%20gen%20maze%202.jpg[/img]
But what about brush limits ? How many brushes does it takes for the large one ? I think you should rethink the concept from equivalent sized building blocks to building structures like resizeable walls, floors and etc. I think it shouldn't be that hard to extend any construction in specified way by specified faces or rotate it by any angle.
I did not intend to put something like the large version in the game. I mean just look at it, nobody right in their mind would attempt to make a singleplayer map like that. :P Even the "small" version already has a lot more floor space than most other levels. What you are saying though is to mind optimization techniques... and I shall ponder about then more - once I can output a proper level in the first place. At this stage, it would be too much for me to handle. Also note that after compiling, the brush faces are joined and split according to the BSP visleaves, so the ingame wireframe display doesn't show those original surplus splits, which is pretty neat. Hmm... if I were to build that kind of maze by hand, I would probably make it up of such modules too and not join brushes wherever possible. It doesn't only make it easier to program, it also makes it easier to handle by hand...
[QUOTE=DJ Iñaki;47927739]This is actually something I started experimenting a wile ago, I'm no codder but I managed to mod the Portal 2 Puzzle Maker to make maps for other games, it's impractical, very limited but easy, I did it mainly so my friends that don't know how to use hammer could come up with maps when we do LAN parties and then tweak and do an artpass to the good ones. Here is the almost final one I made for HL2DM: [t]https://dl.dropboxusercontent.com/u/18080053/images/2013-11-29_00001_2.jpg[/t] I'm left CSGO and [url=https://dl.dropboxusercontent.com/u/18080053/images/tf2_koth_mirror.jpg]TF2.[/url] But then I learn about tilegen and started doing some room instances using hl2 prefabs, I will get back to it someday, my idea was autogenerate airboat paths with other gameplay stuff.[/QUOTE] This looks so awesome!
The corridor pieces worked nice and fine, but they've yielded too much code in my program. So I'm just working on externalizing most of the geometry information into its own data format that's just loaded at runtime. A file would consist of named sequences, where each sequence is parametrized with boolean flags. My program would refer to such a sequence and set the flags and stamp one instance of it. A floor thingy like I've shown at first would be represented as one such sequence, with bool flags representing north, east, south, and west. Depending on which combination of flags is set, a brush that's needed for multiple situations would be generated, or not. This developing stuff is not compatible or easy to convert to from VMF yet, but now my program won't be overwhelmed by unnecessarily hardcoding such mass data anymore.
Sorry, you need to Log In to post a reply to this thread.