Procedural'ity in DR

[motorsep]

Interesting article https://medium.com/@gellenor/i-dont-want-to-design-levels-any-more-cb217b9073d5 that got me thinking if there is a possibility of adding such thing via Python add-ons.

[nbohr1more]

Have you played with:

 

http://forums.thedarkmod.com/topic/14119-procedural-dungeon-crawler-generation-swift-mazes/

[motorsep]

That isn't the same thing. For once, it needs to be inside DR or Blender (if Blender will ever be capable exporting textured brushes). It also not just random - it needs to be parametric, meaning building/adjusting layout as you move brushes/models around.

 

DR would need groups to begin with, where you can group entities and room together, and then moving a room (group's "root") would move everything with it, while adjusting "children" would have no effect on the "root".

[Sotha]

It was an interesting read.

 

I'm overcoming the craft-by-hand issue with the modular approach, where everything I build I build with re-use in mind.

 

It just feels utopistic how the procedural generation systems could know what the mapper wants and how to fill in the gaps. The same for patrol nodes and stuff.

 

Monsterclipping, I think, could be automatized.

[motorsep]

Well, CADs can do it, so any level editor can add such functionality. It's not not feasible without a group of skilled programmers

[SteveL]

I suspect that FMs are too small and too individual to profit from this approach. It becomes worthwhile when you have vast play areas to generate, Skyrim-style. FMs tend to composed of small, individually crafted areas, that wouldn't have parameters in common.

 

Tech-wise, DR's python interface doesn't support brush placement as far as I can see. That's probably why Tels is using an external script to generate the map file for his Swift Mazes. If you want to try it, I reckon you look at that. It doesn't matter whether he's using random or procedural generation (surely the two can't be separated anyway?), he must have written a lot of the base code that'll be needed for your idea.

[motorsep]

That's not what I am after. I am after moving floors, and staircase adjusting between them. Moving rooms and entities belonging to that room moving with it. Moving room and the hallway between rooms expanding automatically.

[Tels]

That's not what I am after. I am after moving floors, and staircase adjusting between them. Moving rooms and entities belonging to that room moving with it. Moving room and the hallway between rooms expanding automatically.

 

You want to do this just during the construction phase, right?

 

I do agree that "grouping" is a feature that is very useful in an editor. You simply group a room together (with possible sub-groups like "the table with all the stuff on it"). It then becomes MUCH easier to make the room more wide or move the table to the corner.

 

Right now in DR, you always have to select stuff entities manually, which can become a problem in huge maps. Likewise, things hidden from view (like visportals) will not be selected, so if you move a hallway, the visportal tends to stay behind, introducing all sort of errors and problems during mapping.

 

At least DR now has layers, but still, grouping is a feature missing for larger maps, that can simplify certain operations a lot.

 

Swift Mazes really solves a completely different problem in a different way and is probaby not very useful for the typical TDM mission. At least not until there is a GUI for it, and probably not even then.

[Sotha]

That's not what I am after. I am after moving floors, and staircase adjusting between them. Moving rooms and entities belonging to that room moving with it. Moving room and the hallway between rooms expanding automatically.

 

This is stuff that novice mappers must learn to avoid. Once you build something it is laid in concrete. You do not move stuff after it is in place. This is exactly because of the nature of mapping: so many stuff will break if you move stuff. As the mapper gains experience, they will build in a fashion that they never move stuff anymore. Good planning is essential before you get the hang of things.

 

What would be perhaps more interesting than systems facilitating moving, would be Floorplan Based Automatic Building (FBAB).

 

Let's say the mapper could define the overall appearance of some elements. Like what walls look like. What the ceilings are like. How tall the rooms are. What windows and doorways look like. Then the mapper draws a floorplan with the areas of interest marked accordingly. Then an automatic generation system converts the rough floorplan into real geometry with the elements added. Everything would be ready out-of-the-box: everything would be sealed, all the doorways would contain doors, visportals and handles. The mapper could possibly even add markers for furniture and they would be there, all surrounded with monsterclip!

 

A rough mockup:

Left, the simple floorplan. Doors are marked with pink (caulk), windows marked with red (m_c). (Yes, in the mockup the window brushes do not always hit the mark, but you get the idea: where there is a window brush, would be a window element in the product map.) The mockup is missing floors and ceilings, but the auto-generator would of course add those.

 

In this way, the mapper could make the whole layout of their mission. Then simply convert it into real geometry and immediately jump into the decoration phase.

[Tels]

This is stuff that novice mappers must learn to avoid. Once you build something it is laid in concrete. You do not move stuff after it is in place. This is exactly because of the nature of mapping: so many stuff will break if you move stuff. As the mapper gains experience, they will build in a fashion that they never move stuff anymore.

 

And I think that is the whole wrong approach to take. The editor should not only make it possible to move stuff, but make it easy.

 

Imagine that text editors didn't let you move paragraphs around, or that vector drawing programs didn't let you move parts of the diagram around etc etc. That would be just silly.

 

Having the ability to do some more automated building would also be nice. But simple "grouping" is a first step.

 

One can look for other 3D editors which have procedurality build-in, and also real-time scaling and so on. Just watch the Overgrowth videos and what their editor can do in real-time, and you will see that the workflow in DR compared to that is very cumbersome and backwards.

[motorsep]

I looking into Sketchup with some modules that allow this kind of workflow

 

I think the only (that I've seen/heard of) software that does this kind of procedurality/parametric modeling is Solid Works. So I am not really sure if game dev will ever go for such procedurality as the tools will cost a a lot. But it would be a massive time saver.

 

Another example would be real-time CSG. You'd place subtraction brush in the doorway or window and if you don't like it, simply adjust position of it and when map is saved, CSG would apply. In the CAM view you wouldn't see subtraction brush, you'd see the result of CSG. Non-destructive mapping, if you will.

 

In the mean time layers and grouping would be the thing for DR. I don't know if real-time CSG is achievable, but it definitely sounds less complex than parametric modeling / mapping.