Grimrock

While the LotNR modelers and scripters are putting in 10 hour days to build all of these tools for us to play with, the (less talented) designers can become bored. Well, idle hands are the devil's plaything, and sometimes a fight can break out.

Note: This is really just me playing around bored. These characters/locations are not from the LotNR mod, we're just testing visual potential/possibilities.

Ha! that looks like a great scene

And when I want to be rendered speechless, I just have to come here and peek at this thread.

What you are doing is awesome!

And to clarify Diarmuid's breakthrough that me and Arkos let "slip" above. . .When you are on floor Three, floors One and Five do not exist visually.
. . .Or do they?!
This is the product of an incredible combination of master modeling, and scripting abilities trapped inside the same brain. Really awesome work by Diarmuid and Skuggs.

msyblade wrote:And to clarify Diarmuid's breakthrough, that me and Arkos let "slip" above. . .When you are on floor two, floor one and three do not exist.
. . .Or do they?!

I dunno.. I think processing is slowed on any level that the party isn't on. I know that timers are affected; if you make a time keeping script and watch it as your party falls through pits in several floors at once, you'll notice that the timing can be waaaay off. But I think it still active... monsters still move; I've had the party drop through a pit and have a Crowern fly under them as they fell [and it was then frag/gibbed].

Time in other levels is still active.

IIRC petri said that:

• The current level is processed every frame
• The level above and below are processed every other frame (alternating, I guess)
• All other levels are processed round-robin

This would mean every frame 3 levels are processed: the current, either the one above or below and one of the others in sequence.

(Incidentally if this is to be intepreted literally would mean that in a 4 level dungeon, if you are at level #2 the level #4 would be oddly processed at full speed).

Of course this is "if I remember correctly" petri's post.

I think im meaning to say, if u simply remove the floors and ceilings, you should not see the level above/ below.

Yes, sorry if there was a misunderstanding on the technique:

What it actually is, is that you build floors as separate levels in the dungeon editor, and they are compiled together at runtime so that you can see architecture and props (like torches for example, look above the stairs) on upper and lower levels while on the current level. If you take those stairs in the picture, you would end to the level above and be able to turn back and look at the spot where you were below.

How are you doing it - with offset models, lights, etc? Do you have monsters with offset models and animations? I have made some small sections like this, but it's labor intensive

Of course, donig everything manually on that scale is impossible. That's why it's automatically done to save you the work. There is a script at startup which scans all levels for objects and recreates them on all other levels. So all levels contain all levels, on level 1 you have the objects from level 1-5, on level 2 the objects from level 1-5, etc.

You don't have to do anything, you just build your levels like usual in the editor (with a few little restrictions here and there) and the "dungeonCompiler" script takes care of everything. At the beginning I was using multiple models (eg wall_2ndstore, wall_3rdstore...) but then, thanks to pferguso's R&D work on projectiles who showed the way, I'm now rebuilding the entire above/below levels with projectiles, so I need only 1 "normal" object and 1 "above/below" object that I can place precisely at will. I call it "Projectile Architecture".

In the shot below (in daylight, we can switch at will between day and night with 1 line of code) for example, all walls, pillars, archways, windows, railing, the torch on the wall above the railing... they are all floating projectiles (!).



It's amazing too, because if you go up and down levels they stay there, and they are even save-game proof. It's also marginally slowing down the renderer, it gets bad only if you put tons of torches.