Regarding the feasibility of a project

[Gergin]

Some friends and I are looking into creating a procedurally generated horror game. Before we really dive into it though I was wondering if such a project will even be possible using UDK.

Essentially, we would construct small sub levels that have all necessary components. The end user would select an option to generate a level which would take these sub levels and combine them using a set of rules. My concern primarily deals with the lightmaps but there are other issues.

Can we bake the lightmaps into the sub levels and give the end user these prebaked sub level assets to be combined at runtime?
Can an end user even build a level dynamically given the assets (Can they construct a level and save it?)

We're not full licensees so we only have UDK to work with.

[Lexluthor1]

Some friends and I are looking into creating a procedurally generated horror game. Before we really dive into it though I was wondering if such a project will even be possible using UDK.

Essentially, we would construct small sub levels that have all necessary components. The end user would select an option to generate a level which would take these sub levels and combine them using a set of rules. My concern primarily deals with the lightmaps but there are other issues.

Can we bake the lightmaps into the sub levels and give the end user these prebaked sub level assets to be combined at runtime?
Can an end user even build a level dynamically given the assets (Can they construct a level and save it?)

We're not full licensees so we only have UDK to work with.

I seem to remember a tool someone made on here for procedural map building on the fly but whether it can run dynamically at run time is another question !
Also I can't see how you could bake lightmaps into a level that hasn't been generated, ie. If you're looking at users generating a level at run time, there's nothing to build a light map on until the level is created! The individual static meshes would have their own light maps but then the user would have to build the lighting after generating it before playing the level ...
It all sounds far too complex for me and if you're new to UDK I think this idea is way too over ambitious

[Gergin]

I figured the user wouldn't be able to generate any lighting data, forcing us to use dynamic lights for everything.

Could the user generate a level and save it off in a file if they were given all the assets to do so or is that also beyond the capacity of UDK?

Furthermore, assuming we do use dynamic lighting for all our lights, would this cause an unacceptable performance hit? There wouldn't be a TON of lights in any given area and the user wouldn't have LOS to more than a handful at a time.

[Lexluthor1]

I figured the user wouldn't be able to generate any lighting data, forcing us to use dynamic lights for everything.

Could the user generate a level and save it off in a file if they were given all the assets to do so or is that also beyond the capacity of UDK?

Furthermore, assuming we do use dynamic lighting for all our lights, would this cause an unacceptable performance hit? There wouldn't be a TON of lights in any given area and the user wouldn't have LOS to more than a handful at a time.

As far as I know, no matter how you generate the lighting, dynamically or whatever, it still needs to be built and so there's no way around it..

So lets say for arguments sake that the user generated three rooms from your procedural generation gadget/tool and then pressed play from your hypothetical menu, even if there was some way of having a lighting system for every conceivable generated map, it would still need the final build before it could be played or look authentic..I suppose its possible for your tool to generate a simple light map very fast, but it would still slow down the ability to be able play instantly from once the world was generated...The world would have to be very simple too for the quick light build!
I could be wrong, but I'm almost certain that there's no escaping the final light build!

[Gergin]

Is it even possible for the end user to build for dynamic lights or any lighting?

I know building lighting is a lengthy process but I'm wondering if it can even be done.

[Lexluthor1]

Is it even possible for the end user to build for dynamic lights or any lighting?

I know building lighting is a lengthy process but I'm wondering if it can even be done.

Theoretically, yes!
But who knows how long it would take!
A simple single static mesh in a map with a sky dome and precomputed visibility with baked light maps on the mesh would take around ten to twenty minutes to build the lighting.....Then above and beyond that could be whatever, depending on the complexity of the world...

The Epic citadel takes aprox 24 hours to build the lighting on the map! Even the Jazz mini map takes a few hours to build the full production lighting !

[Gergin]

Well unless anybody has any ideas about how to do this within a reasonable time frame we'll just be building the maps by hand.

Thanks for the responses Lex.

[Lexluthor1]

Well unless anybody has any ideas about how to do this within a reasonable time frame we'll just be building the maps by hand.

Thanks for the responses Lex.

My pleasure......
You may not get many responses in this section because it would have faired better in the Level design section

[Chosker]

The Epic citadel takes aprox 24 hours to build the lighting on the map! Even the Jazz mini map takes a few hours to build the full production lighting !

I think you're misleading the guy. he already said his maps will only use dynamic lights (ie. no lightmass to build!) so if you can get it to build the light at runtime it will only take a few seconds. I know because I only use dynamic lights without lightmass and it takes no time at all.

if you can get around that, the next problem will be the AI pathing. if you use AI paths maybe they can be generated at runtime as well. if you use navmeshes, I have no idea if a pre-saved navmesh data will get along and "connect" with one at an adjacent level that's put there at runtime

[Lexluthor1]

I think you're misleading the guy. he already said his maps will only use dynamic lights (ie. no lightmass to build!) so if you can get it to build the light at runtime it will only take a few seconds. I know because I only use dynamic lights without lightmass and it takes no time at all.

if you can get around that, the next problem will be the AI pathing. if you use AI paths maybe they can be generated at runtime as well. if you use navmeshes, I have no idea if a pre-saved navmesh data will get along and "connect" with one at an adjacent level that's put there at runtime

I'm not misleading him because if you read the comment I said that I'm not sure!
If what you say is correct then he'll have no problem....

[Gergin]

I think you're misleading the guy. he already said his maps will only use dynamic lights (ie. no lightmass to build!) so if you can get it to build the light at runtime it will only take a few seconds. I know because I only use dynamic lights without lightmass and it takes no time at all.

if you can get around that, the next problem will be the AI pathing. if you use AI paths maybe they can be generated at runtime as well. if you use navmeshes, I have no idea if a pre-saved navmesh data will get along and "connect" with one at an adjacent level that's put there at runtime

Ok, here's a question. Do dynamic lights have the same visual quality of lightmaps or are they visually inferior?

Seems to me like they should be worse as they're doing all their work during runtime and compromises have to be made.

As for the AI, that's another issue that we've recognized might be problematic but we're taking things one step at a time.

[Chosker]

dynamic lights are visually inferior and more expensive to render. this is because with static lights you can use lightmass which will do a light-bouncing simulation (hence the long build times mentioned before) and save the results in a lightmap that will automatically be used on those static objects in the level.
then again dynamic lights aren't that bad-looking, specially if you have more than just a sun (and even then it's not bad... check my own game)

[ambershee]

I'd say dynamic lights are superior, because they function on a per-pixel basis, rather than a texel based lightmap. Where you lose out with dynamic lighting is performance cost (they are more intensive, and increasingly so as your shaders get more expensive), and you cannot make use of lightmass 'global illumination' since that's all baked. The lack of GI may not be a problem with a horror game since harsh shadowing and lighting may well fit into the art style nicely (take a look at Doom 3 as a really solid, exagerated example of this).

You can't rebuild lights at run time, but generating maps using dynamic lights is far from unfeasible so long as you are careful about how you go about it.