Procedural dungeon (crawler) generation (swift mazes)

[nbohr1more]

Keep up the good work.

 

I can't wait to try your next demo!

 

[Tels]

It is very interesting to see the modules starting to go full 3D on that perspective shot! Not only that but the prototype also shows a cool attempt of creating a "place" (the small steps, the altar and the light coming from above), which is beyond the proof of concept and goes directly to a practical use example. I can see the maze getting "vertical" now, with the player moving down or up as he advances. I guess the next step would be to have floor over floor, like you suggested before?

 

Well, actually, it already is "floor over floor" - that works since basically from release v0.01 It was even used in the demo level, the "pit" is actually one floor below the main level.

 

Also, I am working on the code, so the prefabs do get not really much attention, but I do have a lot of ideas for this

 

Reskinning seems like a huge time saver, but I wonder if the stress of creating the system you described and using it (without being a programmer I mean) would be heavy? Would it be possible to load the prefab in an interface (like how we have now in DR), apply changes to the surface textures, and then save it in your modules set for use in the map? Of course, changing the whole module at once (or just the floor, or walls) can be done remotely by code and save you a lot of effort, but being able to load the prefab and change it by hand (aligning tough textures, changing their scale, all that manual work), and then save it and instantly use it in the map as a personalised set is also a reasonable way of doing it, I would think.

 

Since all prefabs are done with DR, they can also be changed with DR. The "reskinning" is just so that if you want to have two "sets" of dungeons in one level, like "old sewer" and "dry temple cellar", then you don't need to have to keep two sets of prefabs, if the prefabs only (or mostly) differ by texture.

 

Because otherwise if you find a problem in one prefab-set, you'd need to redo both of them. Instead right now you:

 

* keep one "master prefab" set

* selectively overwrite this with some prefabs in the other set (like making the walls look different) AND then just reskine all the base prefabs for the second set.

 

Like so:

 

* first set base prefab (texture A, floor, ceiling, no wall), PLUS wall prefab (texture A, south, north, east, west variant)

* second set: a skin for the base prefab (texture , PLUS a special south wall prefab (texture

 

Basically, it just cuts down on the amount of copy-cat prefabs you need to make your level appear different.

 

PS: I was taking a look at the page, I was wondering if it would be possible to translate your fog mechanics to any map, or is it done with particular code? I would be really interested in giving it a try, whenever it is available!

 

Technically, it would be possible, I guess, but I have not tried to make it standalone yet.

[jaxa]

A simple map editor. WIP.

 

swift.html

Edited October 12, 2012 by jaxa

[Tels]

That's really cool!

 

Do you plan on expanding it (by maybe having it generate the config etc?) Or would you mind if I expand it?

[jaxa]

I will try and expand it. I'm just information-limited at this point.

 

1. In the [charset], you have %20 to represent space. Is there a compatible equivalent for UTF-8? Like \u25A1 instead of the □?

 

2. Are you limited to having a maximum of 9 "connects"? Or are you able to define any symbols as connects and were just using 1-9 for convenience (that seems more likely). Better yet, name and explain each column:

 

[Connects]
2		  air				   1 on Location 0								 Back

 

Looks like '2' is the symbol, "air" is the prefab that is inserted wherever a '2' is, "1 on Location 0" is the place to connect to, and '1', '2' are unique identifiers in this case, and "Back" is an optional(?) description.

 

[Charset]
;Char As Base			 As Wall  As Corner  On Wall  Description
.·	-				   -		-		  -		Solid space (inaccessible)
%20   empty			   -		-		  -		Empty Hallway
S	 empty, pstart_east  -		-		  -		Start, facing east
X	 empty, exit		 -		-		  -		Exit area
□	 pit				 -		-		  -		Hole down
▣	 plate			   -		-		  -		Pressure plate
■	 pit_bottom		  -		-		  -		Hole in the ceiling
┌┐┘└  -				   wall	 -		  -		Solid wall, ignored otherwise
												   (_north, _south, _west, _east)
─│	-				   wall	 -		  -		Solid wall
												   (_north, _south, _west, _east)

 

3. You seem to be saving time by putting multiple characters on one line. Would it be fine to have each on its own line?

4. What does each column mean? Looks like the middle columns control extra prefabs that are placed around. What's the difference between "-" and "empty" under "As base"? Wouldn't both render a floor? I see that the periods are actually the void (or solid/impassable). What does "As Corner" do?

5. The offsets, eg. "offset=0 0 36". Are the units something specific to Dark Radiant? Also I assume "offset=-15 50 -25" is a valid use of negative offsets.

6. Let's say I make multiple locations on a single level with connects, and maybe offsets. Can I make some catastrophic mistakes that Swift Mazes would choke on? For example:

 

┌───┐
│ ┌─┘
│ 4··
│ └─┐
└───┘

 

I try to connect this room to a much larger room with the tiny space/entrance. Wouldn't the larger room overlap the top and bottom bits?

 

What about offsets? Could they be used to accidentally smash rooms together?

Edited October 12, 2012 by jaxa

[Tels]

I will try and expand it. I'm just information-limited at this point.

 

Sorry about that, I'm still experimenting with some features and sometimes they change syntax rather quick before settling down

 

1. In the [charset], you have %20 to represent space. Is there a compatible equivalent for UTF-8? Like \u25A1 instead of the □?

 

The only characters that "work" with the %XX syntax as %20 and %5b and %5d because " ", "[" and "]" confuse the parser otherwise. I can add full unicode support if that is nec.

 

2. Are you limited to having a maximum of 9 "connects"? Or are you able to define any symbols as connects and were just using 1-9 for convenience (that seems more likely). Better yet, name and explain each column:

 

[Connects]
2		  air				   1 on Location 0								 Back

 

Looks like '2' is the symbol, "air" is the prefab that is inserted wherever a '2' is, "1 on Location 0" is the place to connect to, and '1', '2' are unique identifiers in this case, and "Back" is an optional(?) description.

 

Sorry, I did cut the description from that section. Connects are using symbols, so they can use anything you want, 1..9 are just examples. Here is the description:

 

;Symbol
;	   Prefab (double occurances will be removed) list
;							   Leads to
;													   Comment
1	   separator_stairs_east   2 on Location 1				 Leads up

 

[Charset]
;Char As Base			 As Wall  As Corner  On Wall  Description
.·	-				   -		-		  -		Solid space (inaccessible)
%20   empty			   -		-		  -		Empty Hallway
S	 empty, pstart_east  -		-		  -		Start, facing east
X	 empty, exit		 -		-		  -		Exit area
□	 pit				 -		-		  -		Hole down
▣	 plate			   -		-		  -		Pressure plate
■	 pit_bottom		  -		-		  -		Hole in the ceiling
┌┐┘└  -				   wall	 -		  -		Solid wall, ignored otherwise
												   (_north, _south, _west, _east)
─│	-				   wall	 -		  -		Solid wall
												   (_north, _south, _west, _east)

 

3. You seem to be saving time by putting multiple characters on one line. Would it be fine to have each on its own line?

 

Yes, that works automatically. Only each symbol needs to be unique.

 

4. What does each column mean? Looks like the middle columns control extra prefabs that are placed around. What's the difference between "-" and "empty" under "As base"? Wouldn't both render a floor? I see that the periods are actually the void (or solid/impassable). What does "As Corner" do?

 

All right, it seems I really need to start documenting this all clearly. Please give me some time to do it on the web, in the meantime:

 

Note: A block is considered to be non-empty and generated, when there is a map symbol at its base place. If you want to treat a block non-empty but not include any prefabs on it (in this location/level), then you can use "air" as a special prefab name that causes this block to be non-empty, but does not include anything directly. Otherwise, at least all prefabs mentioned in the "as base column" will be included in this block.

 

"as base" affects the block where the symbol is placed directly.

 

"as wall" are the blocks north, south, east and west of the block. Note that this can affect multiple blocks! If the prefab name contains a direction identifier at the end like "_north", it will ONLY be used if placed north of a block, and then it will be used exactly in this way. Otherwise, "_north", "_south" etc. are appended automatically and these prefabs are added to all non-empty blocks next to the wall pieces.

 

"on the corner" is the blocks north-east, north-west, south-west and south-east of a block adnd work otherwise like "as wall". The offsets or these positions in grid space here are -1,-1, 1,-1, -1,1 and 1,1.

 

Edit: Forgot this:

 

"on the wall" is "two blocks north, south etc. (basically if you have a block next to its "wall" on the west side, the "on the wall" block is one field further west. Here again if the prefab name says "_north", it will only be applied to the block IF the symbol "on the wall" is actually north of the block (e.g. offset in gridspace "0, -2"). otherwise, the prefab will be applied to all blocks that are not empty (the midot ones are empty). This is used mostly if the base of a block is already taken by a symbol and you want to include additional stuff like an extra torch there.

 

5. The offsets, eg. "offset=0 0 36". Are the units something specific to Dark Radiant? Also I assume "offset=-15 50 -25" is a valid use of negative offsets.

 

Yes, units always mean "DR units". The config values are checked and enforced strictly on the code, but so far this does not lead to documentation (it should be automatically generated). And yes, negative offsets are fine.

 

6. Let's say I make multiple locations on a single level with connects, and maybe offsets. Can I make some catastrophic mistakes that Swift Mazes would choke on? For example:

 

┌───┐
│ ┌─┘
│ 4··
│ └─┐
└───┘

 

I try to connect this room to a much larger room with the tiny space/entrance. Wouldn't the larger room overlap the top and bottom bits?

 

The only things that Swift Mazes checks and "chokes" on is when the locations for the connects do not "line up" in block space. If you only have one connect, it will always line up, obviously. If you have something like this:

 

┌───┐
│   2
│ ┌─┘
│ │··
│ └─┐
│   1
└───┘

 

and other location has:

 

┌──┐
3  │
│  │
4  │
└──┘

 

there is no way both 2 and 1 can ever match to places for 3 and 4 so the map will not be build. (Because 1 and 2 are 5 blocks apart, and 3 and 4 are 3 blocks apart)

 

But I get your question is if Swift Mazes detects the "smash". No, it does not, this is perfectly legal (and I have even ideas how to use it for features). The only thing it cares is that after final assemble, the map will not leak.

 

So you can place bigger prefabs into smaller ones or vice versa, and as long as afterwards all connects are matched up and the map does not leak, it works.

 

What about offsets? Could they be used to accidentally smash rooms together?

 

Yes, or by design

 

I can send you more example configs if that helps. Also some doc will go live on the website after the weekend. Sorry about the delays, but RL interfered a lot

[i30817]

Could you attempt some modifier symbols to control elevation? This kind of roguelike map was probably never used for 3d enviroments, so i suspect you're doing original work (at least in games). Since rogue-likes are only 2d, they don't need it, but i think that a 2d version of the 'floor' and maybe the 'ceiling' can probably express extrusions for the walls. Even ladders?

 

The possibility to override the 'pieces' default mapping in the map definition file would probably also be nice, if you don't already have it. Pit traps with slanting walls and spears at the bottom, pit traps with lava, pit traps with crushing ceilings, etc.

Edited October 19, 2012 by i30817

[i30817]

The ability to place darkmod objects on one of the horizontal axis parallel at the location with default offsets (so a mantlepiece touches any wall for instance) would be nice too at least for prototypes. Obviously not for detailed stuff, just 'i want a bed here and a mantlepiece there'.

 

Problem is, i think collisions would be rather easy unless the object X-Y size was 'converted' to 'swift maze units' (not to mention the 'default offsets' for things that must be near or in walls like windows, paintings doors and such)

Edited October 19, 2012 by i30817

[nbohr1more]

Fog questions:

 

 

I'm trying to help Biker with a little fog scenario and I remembered that you had worked out a solution in this framework.

 

After reviewing your blog, I see that you used a blendlight which fades based on location which looks like the solution

BloodRayne used over at Doom3world for Hexen EOC.

 

That probably means it's the best way anyway but I fumbled around and found that the fog density can be specified by

script but there is no pre-built fade.

 

So, this is what I worked out:

 

void fog_fade_out ()

 

{

 

float count;

 

count = 8000;

while (count < 20000)

{

$nbohr1more_fog.setLightParm( 3, count );

count = count + 100 ;

sys.print("\n");

sys.print("\n");

sys.print("\n");

sys.print ("Fog parm values adjusted +100,\n");

sys.print ("Count now equals: " + count + "\n");

sys.wait(0.1);

}

 

}

 

(where nbohr1more_fog is the name of a fog light entity)

 

Does that look like it will work?

 

Did you already try this method?

[Baddcog]

just skimmed the thread. Surprised you haven't heard of Torchlight Tels.

 

Anyway, their basica design is simple as far as dungeon pieces goes.

 

1st: dungeon type..

 

You enter a mine

or

cave

or...

 

Then there are tile sets for each type. each type is really nothing more than artwork (mine, cave, dungeon)

 

The tile sets are:

 

4 way, 2 way (north/south), 2 way, (west/east), dead end... etc.. Then, dead end empty, dead end with chest...

 

This can be divided into more variation of course. Say each tile is a 9x9 grid, if you exit one to the north in the east corner, middle or west corner...

---

I know you probably understand that , just trying to throw in any ideas you can use.

 

=========

Anyway cool project. Maybe cities could be done too to an extent. Would be tough to have good roof crawling, etc.. sight lines and whatnot.

 

But it might not be that hard to set up a good set of tiles that could still make fairly interesting cities. Still, with dungeons it's easy to make tiles of rock tunnels that fit together and randomly attached will still feel fairly random.

With a city you have to mix up bricks, etc.. or everything will tend to look the same.

 

If you have canals you need to have a 'dead end' at either end no matter what that looks like it keeps going even if the player can't. (in a cave it could be underground water flow, etc..)

[Tels]

Fog questions:

 

 

I'm trying to help Biker with a little fog scenario and I remembered that you had worked out a solution in this framework.

 

After reviewing your blog, I see that you used a blendlight which fades based on location which looks like the solution

BloodRayne used over at Doom3world for Hexen EOC.

 

That probably means it's the best way anyway but I fumbled around and found that the fog density can be specified by

script but there is no pre-built fade.

 

So, this is what I worked out:

 

void fog_fade_out ()

 

{

 

float count;

 

count = 8000;

while (count < 20000)

{

$nbohr1more_fog.setLightParm( 3, count );

count = count + 100 ;

sys.print("\n");

sys.print("\n");

sys.print("\n");

sys.print ("Fog parm values adjusted +100,\n");

sys.print ("Count now equals: " + count + "\n");

sys.wait(0.1);

}

 

}

 

(where nbohr1more_fog is the name of a fog light entity)

 

Does that look like it will work?

 

Did you already try this method?

 

Did you read this entry: http://swift-mazes.com/diary.html#fog

 

In it I explain it a bit.

 

I'm using a blend light (fog light does not work, as you cannot "fade it away", no matter how thin you make the fog, it is still visible and if you switch of the fog light, this is a noticable "pop"). and then fade radius and strength. When it is "thin" enough, I switch if off. (Switching off fog lights does not work, either).

 

Looking at my code, it sets shaderParm6 to 0 (to note that the light is off, because I couldn't determine this with a script event, need to add this), and otherwise shaderParm6 ot a positive value - however, I'm not sure that is actually right - shaderParm6 isn't used by blendlights (according to the wiki), so this might simply be a remnant of my old tries with fog lights. (The comment in the code still talked about shaderparm3). I'll have to debug this, maybe it explains some strange fadings in my map.

 

So to recap:

 

* yes, you can modify the strenght of a fog light via shaderParm3 - but you cannot really thin it out enough to fade between fog and non-fog

* fog and blend lights cannot be switched off, they will still be rendered (D3 bug), so you need to find a way to hide them. I'm shrinking it to radius 1,1,1. Teleporting it away might also work.

* modifying the color and radius helps to blend between areas.

 

Swift Mazes contains code to fade between fog in areas, you'll see it when the demo gets released (hopefuly soon).

[nbohr1more]

Thanks for the clarifications. I guess we'll see how much my kludge version compares to your version soon...

 

looking forward to that demo

[Tels]

It's been a long time, and I'm truly sorry for the delay. After the break I've now resumed development again.

 

Lost the server, and the very latest version of the prefabs, but the code and a copy of the website survived.

 

Progress report:

• The first step was adding more documentation, because after such a long time I found out the hard way which things I forgot to document
  
• Also the scripting code was cleaned up and made much more object oriented and generic.
  
• The last version had an aweful lot of code dedicated to run under TDM v1.08 - since now everybody will have at least 2.00, this was all thrown out and the code is not shorter and much more clear
  
• It is now possible to set a different ambient light cap and dynamic for each location (formerly only the base ambient light color could be set).
  
• The secret locations now also can modify the objectives, which is quite nice.
  

As for features, I got teleporters to work, albeit they still miss a particle and I couldn't get any sound to play for whatever reasons (it works with other things). And I finally got the pressure plates work in a reliable way, this thread details the adventures on getting it to work.

 

So what's next?

1. First step would be to change the way prefabs work. Right quite a lot prefab contains copies of other prefabs, like the floor or ceiling, or corner columns or walls. This makes it hard to change one part, because you need then to change many prefabs. So a sort of "include" and "inhibit" (if prefab X is included, it inhibits prefab Y from getting included, like "wall_niche" inhibts "wall" because it replaces it) will be necessary.
   
2. As a second step I want to make level generation easier for machines. Such a level map
   

 

[Level 1]
··▾·▿··▾···▾··
·┌──────────┐·
·│S▣□  O □  │·
·└┐ ┌─┐?┌─┐X│·
·◆│B│·└─┘·└·┘·
··············

 

is hard to create and read for humans, but almost impossible for a computer. I have an idea how to change this, so a GUI could create the nec. config much more easily.

 

And last but not least I have some ideas for connectivity maps and auto-visportaling stemming from that. Stay tuned

[Tels]

Good news everyone!

 

The webpage has been restored at http://www.swift-mazes.com and it now contains a manual section, as well as an (experimental) RSS feed for new releases. Further updates to the webpage will be along shortly - like new Diary Entries

 

As for the prefabs, I have teached the code now to honor "includes" and "inhibits" for prefabs, in a recursive way. This means this actually works:

 

[Prefab ceiling_hole]
offset=0 0 0
; this prefab is a bit bigger than a block
extends=-96 -96 -96 96 96 996
; it includes these, unless they are already defined or prohibited
includes=corner_ne corner_nw corner_se corner_sw floor
; if this prefab is used, the "ceiling" prefab will be inhibited (ceiling_hole replaces it)
inhibits=ceiling

 

So instead of "baking" the corners and floor into the "ceiling_hole" prefab, it just includes them. That will make updating prefabs much easier. It also "inhibits" the ceiling prefab, so if you use f.i. the "empty" prefab together with the ceiling_hole, you will end up with only one copy of the floor and corners, and the no "ceiling".

 

Next step are now the connect-maps, and a small refactoring of the event system to tie it into the objectives and locations.

Edited August 30, 2014 by Tels

[SeriousToni]

This is nice to watch

[Tels]

A small status update.

 

Took a break to start working on fixing idTrigger_Touch. First half is done, more on that later.

 

The manual has been greatly enhanced and updated. Formerly it contained mostly auto-generated sections, now it includes a great deal more info and descriptins. And I added a preliminary section (autogenerated) with the entity system. The scriptobjects will come later, too. The API is not stable yet, so please see this as a first draft.

 

Code-wise I got the inheritance of prefabs to work properly and reliable and fixed a few smaller bugs. Also worked on the prefabs a bit more. We are now almost where we where before the break - the demo levels are mostly working again. Mostly missing are good sound effects and the prefabs still have some mis-aligned textures and missing details.

 

Also worked on a few minor enhancements, too. The script object for binary movers now can set acceleration and deceleration times for open and close independently, and the time when targets are triggered can be set "on begin of open", "on end of open" or "not on open at all". Likewise for close. So you get complex behaviours in one go.

 

For instance, when the player frobs the pullchain, the following will happen:

 

* the pullchain will first accelerate a bit downwards, then speed down, then come to an abrupt halt

* it will then trigger the target(s)

* wait 0.4s

* then accelerate upwards and come to an abrupt stop when it is up again

 

Creates for a rathe nice and fluid motion that makes you believe you really pulled a chain triggering something.

 

I've also create a custom model that models the pullchain and the ring at the bottom as one model. That saves an entity and the complicated frob-peer and bind-system to glue them together.

 

Hopefully soon I can show a working prototype. Stay tuned

[Tels]

While working on the connectivity map, I've stumbled over one big problem in the current code (it does not merge blocks) and one bug (did not properly handle all connection-layouts between locations). The code has now been rewritten and fixed, but this drew me back about a week.

 

The details inlcuding diagrams can be found in latest diary entry.

 

Now I can finally continue with the auto-visportaling

Edited September 21, 2014 by Tels

[Tels]

I've finished the base work for the connectivity map and fixed a few more places where the code looped over all locations - instead if must first loop over all worlds, and then per-world on the locations.

 

With that now done properly, the auto-visportaling problem was talcked. And it turned out to be easier than thought, only a few dozend lines of code

 

There is a new diary entry up with screenshots, showing before and after and a few optimizations that can be done later: http://swift-mazes.com/diary.html#auto

 

I've also added more info to the manual, including an auto-generated section with all the script objects and their functions. The documentation (comments) isn't parsed and included yet, but one can get a nice overview and see the inheritance already: http://swift-mazes.com/manual_scripts.html

 

Please tell me what you think of these things.

Edited September 23, 2014 by Tels

[Tels]

Good news everyone!

 

I've spent a lot more time with the connectivity map and the auto-visportaling feature. As a first step I've teached the map generator to also output a .darkradiant file. This makes it much easier to inspect the result in DR. All supportive entities (player start, ambient light, objecives and so on) are added to the Default layer, while the various locations are all put in their own layer. Unfortuntaley, it is not possible to have sub-layers, or I would have added the entities and brushwork to different sub-layes. But its a lot easier already:

 

 

Click on the image to see the animation.

Edited October 3, 2014 by Tels

[Tels]

And last but not least I've finished the auto-visportaling algorithm. The first step added way too many visportals, because it did not pay attention to certain features. For instance, it added portals across open rooms, as well as for single-block hallways. In a configuration like this:

 

# B - $block, L - $left, R - $right, F - $front, … - new visportal, E - frontleft, T - frontright, G - double forward block
# ┌─┬─┬─┐
# │·│G│·│
# ├─┼─┼─┤
# │E│F│T│
# ├─┼…┼─┤
# │L│B│R│
# └─┴─┴─┘

 

The first revision always added the visportal between B and F if B and F where connected, there wasn't a visportal there yet, and either L or R existed.

 

However, we should not add a portal if either E or T exist and are connected to L or R, respectively. And we only should add the portal if G is present and connected to F (otherwise F is a single-block).

 

With that revised, the code generated a lot less portals, but still to many. So I implemented the auto-visportaling as a multi-pass algorithm. The first pass just flags potential visportals (as outlined above), and the second and third pass remove these again. The second pass removes visportals in configurations like this:

 

 # ┌─┬─┬─┐
 # │B¦F¦N│
 # └─┴─┴─┘
 # Case 1 (Both F and N are also sealed completely => remove 3 auto-visportals)
 # ┌─┬─┬─┬─┐
 # │B¦F¦N¦O│
 # └─┴─┴─┴─┘
 # Case 2 (Both F and N are sealed but not between them => remove 2 auto-visportals)
 # ┌─┬─┬─┬─┐
 # │B¦F N¦O│
 # └─┴─┴─┴─┘

 

e.g. when we can remove 2 visportals. The third pass takes care of situations like this:

 

 # B - $block, F - $front, ¦ auto-visportal
 # ┌─┬─┐
 # │B¦F│
 # └─┴─┘

 

The reason for two steps is that we want to minimize the number of visportals, and removing a single visportal might block later the removal of two of them.

 

The algorithm is not perfect, but a lot better and comes very close to the optimium. For the testmap (specially build to test a lot of configurations) with 70 blocks, the following statistics can be observed:

1. No auto-portals: 4 portals (2 from gates, 2 from location separators) and 4 areas. (wrong sound propagation and bad performance)
   
2. Auto-portals, naive: 36 additional portals (=40), 50 areas are created (way too many visportals)
   
3. Auto-Portals with two-pass optimization: 21 additional portals (=25), 24 areas (close to optimal)
   

In case you wonder, the entire process of adding and optimizing the portals takes 0.014 seconds. No, that is not a typo Compare that to the about 8 seconds of dmap

 

The bigger map I'm building with 210 blocks gets 67 additional portals in 0.04 seconds. Dmap here takes well over 25 seconds (with or without the additional portals).

 

Here is a link to an animation (warning: 1 Mbyte!) that shows the various revisions and steps the algorithm takes, with colorized areas. The first frame shows the map w/o autovisportals. Then comes a comparisation with the faulty algorithm. Then the various optimization stages of the new algorithm, followed by a colorized view of the result.

 

http://swift-mazes.c..._2014-10-03.gif

 

TODO: optimize the visportals due to the separator prefabs. These should be generated by the code and combined with the auto-generated portals, to avoid the overly small areas around location connector points.

[Tels]

Incidentily, I'm looking for a few alpha testers to see if I'm on the right track. Please only post if you can spare some time, can follow instructions and are willing to give me feedback afterwards, oh, and don't mind seeing something that is very crude and unfinished

[161803398874989]

I would be interested in thinking about and optimizing this visportal algorithm of yours, might be fun. However, I'm not sure what you mean by the letters B, G, F, etc. in your description of the Visportalling algorithm. I also wasn't able to find it with a cursory search on swift-mazes.com Can you explain?

 

Also, clicking on http://swift-mazes.com/media/auto_visportaling_2014-10-03.gif gives a 403 forbidden error.

[Tels]

I would be interested in thinking about and optimizing this visportal algorithm of yours, might be fun. However, I'm not sure what you mean by the letters B, G, F, etc. in your description of the Visportalling algorithm. I also wasn't able to find it with a cursory search on swift-mazes.com Can you explain?

 

The letters are just arbitrary names of the blocks, as explained in the comments. The algorithm gets a block position and directions (like NORTH) and then works on the blocks in that direction from the block B. L and R are just the blocks west and east, in this case.

 

The function is then called four times, with NORTH, EAST, WEST and SOUTH and places the portals in the appropriate direcitons.

 

The current implementation only works in the horizontal plane, as the current missions are usually quite flat, and portals between the different floor levels are rare, and are manually placed as part of the prefabs. But there is nothing that prevents the algorithmn to work in 3D.

 

Also, clicking on http://swift-mazes.c..._2014-10-03.gif gives a 403 forbidden error.

 

Oops, you need to first click on this directory: http://swift-mazes.com/media/ then click on the image in the directory (server disallows direct linking)

[RPGista]

Work continues on this platform, thats really great. There was another dungeon crawler Doom3 mod, but the name elludes me. You can probably find it on Moddb, it could give you more inspiration. I see the new stuff is all about technical achievements, the infrastructure. Its fascinating, but hard to comment for mappers and modelers (like me). So I was thinking about dungeon crawlers and how they could be mixed with live-action, free moving FPSs like TDM. The game has sensitive, organic AI. They are getting more and more sophisticated. You also have a cooly animated FPS character. Also, a pretty great combat system, that people here are often overlooking/undervaluating. Having those 3 aspects in your game would put it right up there as far as action RPGs go. So then you have a world building tool. Many will agree that randomness in world building is not a design choice, only meant for populating vast areas with material. Mappers want the freedom to create uniqueness. Im interested in what those modules could be, once you figure out how to work with them in your vision. Im thinking about old crawler games I used to play. What interests you in them is the search for something, how the world offers you different paths, some harder, some ideal, some dead ends. I could see your mapping tool offering more than a way of connecting geometry. Like your trap test. Modules that are puzzles, or templates of puzzles, that people could modify to fit their story. Or a scripted sequence module, where a cutscene or some action would play, and people had to add the story, add the moves and sounds/subtitles. Gameplay stuff. Many possibilites, of course. But I suspect a world building tool full of modular gameplay triggers would be pretty interesting for mappers or would be mappers out there.

[Tels]

Stumbled over this:

 

https://www.youtube.com/watch?v=UuPnUYUj2JM

 

I'll definitely look more closely at this as a source of inspiration for the artwork - the dungeon looks great!