Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
smeghammer

Vertically stacked 3D doors

Recommended Posts

Posted (edited)

This may be of use to someone else, so I thought I'd share my thoughts...

 

I'm building a multi-level building for my latest WAD and I came across an interesting problem - I needed multiple doors at different levels, all sharing the same sector (so the building floorplan worked). I wanted then to operate as doors and be (relatively - see below) independent of each other. The player needs to be able to operate the door she is in front of, but NOT also trigger the doors directly above/below. 

 

Essentially what this means is the same linedef trigger needs to be able to operate several 3D sectors, but additionally decide which one, based on where the player is vertically (i.e. your z-position).  I came up with the following script:
 

Spoiler

 


#include "zcommon.acs"
int switchHeightMap[2][3] = {
    //    controlsectortag,    triggerHeight,    soundThingId
    {    3,                     0,                1},
    {    2,                     128 ,            2},
};

/*
test of stacked doors with independent switches:
*/
script 1 (int index){
    FloorAndCeiling_RaiseByValue (index, 12, 64);
     //see https://github.com/rheit/zdoom/blob/master/wadsrc/static/filter/game-doomchex/sndinfo.txt
     PlaySound(index,"doors/dr1_open");
    Delay(144);
    FloorAndCeiling_LowerByValue (index, 12, 64);
    PlaySound(index,"doors/dr1_clos");
    TagWait(index);
}


/*
test of stacked doors switched by vertically stacked switches. This is to simulate multi-3Dfloor sectors
behaving as doors - i.e. they should trigger themselves but NOT the dorrs directly above or below.
*/
script 2(void){
    /*
    These refer to the indicies of the vertically stacked 3D floors (that are doors) defined 
    in the lookup data array 'switchHeightMap[]':
    */
    int controlSectorLookup[2] = {0, 1};
    
    /*
    because we are on a single map line, we cannot differentiate between the door lines ('cos they are the 
    SAME line...) so when we activate it, we need to determine the correct code path to take by determining
    the player height first and then activating the correct eD door object.
    */
    for(int x=0; x<2; x++){
        //test if the player is correct height for current door (i.e. is player same height as control sector):
         if(checkPlayerDoorProximity(controlSectorLookup[x] )){
            
            log(s:"opening door at ",i:switchHeightMap[controlSectorLookup[x]][0]);
            log(s:"via control sector ",i:switchHeightMap[controlSectorLookup[x]][0]);
            
            //now move the relevant control sector:
             FloorAndCeiling_RaiseByValue (switchHeightMap[controlSectorLookup[x]][0], 12, 64);
             //see https://github.com/rheit/zdoom/blob/master/wadsrc/static/filter/game-doomchex/sndinfo.txt
             PlaySound(switchHeightMap[controlSectorLookup[x]][2],"doors/dr1_open");
             Delay(144);
             FloorAndCeiling_LowerByValue (switchHeightMap[controlSectorLookup[x]][0], 12, 64);
             PlaySound(switchHeightMap[controlSectorLookup[x]][2],"doors/dr1_clos");
             TagWait(switchHeightMap[controlSectorLookup[x]][0]);
            //break out of loop
            break;
         }
     }
}

/*
Check the player z-index against the height of the current switch. When we use >1 3D floor in the same
location, we get stacked floors, doors etc. We need to ensure that the player is in fact at or nearly at
the height of the supplied 3D floor, as defined in the lookup array.

Return true or false:
*/
function bool checkPlayerDoorProximity(int switchHeightMapLookupIndex ){
    int switchHeight = switchHeightMap[switchHeightMapLookupIndex][1];
    log(s:"in check height func - switch: ", i:switchHeight);
    bool trigger = false;
    int zpos = (GetActorFloorZ(0))/65536; //see https://zdoom.org/wiki/Definitions#Fixed_point_numbers
    log(s:"in check height func - player: ", i:zpos);
    if(switchHeight >= zpos-24 && switchHeight <= zpos+24){
        trigger = true;
    }
    return(trigger);
} 


 

 

 

 

 

Basically, the script tests the height of the player and operates the corresponding 3D floor to simulate a door cycle. I could not abstract the script triggered by the line action any more than above, so the map script for a level with many such doors will require a handler script like script 2 above for each set of vertically stacked doors, but differing in the controlSectorLookup array indicies (I am using Eureka primarily, so Hexen format rather than UDMF, so I am limited to 8 bit argument numbers). The linedef cannot be triggered more than once concurrently, so if I try to operate more than one vertical switch in rapid succession, it will not work. That is no problem though.

 

My test map can be found here.

 

And a screenshot of the test map:

 

Screenshot%20from%202020-07-17%2009-03-4

 

The two switches on the left share the same linedef and are faces of two stacked 3D sectors. The bottom one will operate the blue door and he upper will operate the red door. The green mapspot things emit the sound for the switch that has been triggered.

Edited by smeghammer

Share this post


Link to post

Clever use of check player height to ensure proper switch/door combination is used.

 

Also, nice use of comments to explain what the functions do. Thanks.

Share this post


Link to post

@ReX, thanks for the comments. Heh - I am building a - pretty experimental so far - building with three floors and multiple 3D doors. As I noted in the code, I cannot abstract the actual door cycle code (FloorAndCeiling/PlaySound/Delay) to a separate function, so the handler code is many repeated blocks (one for each vertical stack of doors) unfortunately.

 

Building a complex (ish) 3D structure is HARD! I can see why it can take many months to do a decent map. Here's a few screen grabs:

 

Main gate:

Screenshot%20from%202020-07-24%2020-41-0

 

In the slime!

Screenshot%20from%202020-07-24%2020-40-4

 

Corner office anyone?

Screenshot%20from%202020-07-24%2020-38-0

 

 

Share this post


Link to post

@smeghammer Those are excellent screenpics. They show a high degree of geometric complexity, while being visually appealing, and also looking very realistic.

 

Is the player under-water (or in some sort of liquid pool) in the second screen-shot? If so, you should consider adding an appropriate color to the under-liquid sector. [It appears to be a nukage pool. In which case, the under-liquid color ought to be a suitable shade of green.]

 

If you're interested in using a multi-level elevator, take a look at this tutorial.

 

 

Share this post


Link to post

@ReX, thanks again for the comments - it is a WiP, and yes player is in a nukage trench. I will certainly revisit the under-slime colour (I did look at translucent water and various RGB combos a while back, but got distracted by the walkways...). I currently have three flights of stairs connecting the floors - I'll certainly look at the lift idea for another map though.

 

You may notice, I have done this with purely 3D sectors and while the ground floor and first floor are OK to build, it is getting quite fiddly to add unique decoration to the second floor. Another thread suggested looking at portals as an alternate way of doing the multi-level thing. That methodology looks  - different... I'll need to twist my brain around to think that way. 3D floors kill my little NUC as well when playing it.

 

I actually find it really hard to make an abstract, non-realistic map and I'm fully aware that doing something realistic is probably aiming a bit high - this is only my 3rd WAD and was supposed to be a smaller one...

 

If you are interested,  my other four maps completed so far are for Hellbreach, and the small arena style Belial's Ruin. The first has my first ever maps from a few months ago (just after COVID started, and they get pretty huge, with 3D caves in one) and the second is a very small one made while waiting for inspiration for map 4 of Hellbreach.

 

 

Share this post


Link to post
18 hours ago, smeghammer said:

... yes player is in a nukage trench. I will certainly revisit the under-slime colour (I did look at translucent water and various RGB combos a while back...)

The method for adding under-liquid color is straightforward. Assign a tag ID to the 3D control sector [say, 16]. Then, in ACS create an OPEN script and insert the following:     Sector_SetFade(16, R, G, B);

where R, G, B take values for red, green, and blue between 0 and 255. 0 represents no color, 255 represents maximum color saturation. Your script would look like this:

 

script 1 OPEN 

{

    Sector_SetFade(16, 0, 192, 64);
}

 

This will create a somewhat bright under-liquid green color, with a tinge of blue. You can fiddle with the G & B values to get the desired color.

 

18 hours ago, smeghammer said:

You may notice, I have done this with purely 3D sectors and while the ground floor and first floor are OK to build, it is getting quite fiddly to add unique decoration to the second floor.

One alternative to using sectors to create unique decorations, is to use models. For example, if you're making an office building, you can use models for desks, chairs, filing cabinets, floor lamps, computers, boardroom tables, etc. If you're creating a computer server building you can use models for the various types of equipment.

 

I have made some 4 storey office buildings that try to create a distinct look from one floor to the next. In one version, the bottom floor is a basement used for storage. The first floor has office cubicles, the second has actual offices (shared by 2 employees each), and the third floor has the executive offices. I used different textures for the walls, carpets, and ceilings for an additional way to distinguish which floor you're on.

 

Here is a picture of the exterior of one of the office buildings I created. Unfortunately, I can't find a screenshot of the interior of any of these buildings. But here is a picture of a toilet in that office building. You'll see that the partition between the stalls is made of sectors, but the sink, soap dispenser, urinals, toilet bowls, etc. are all models. The floors below and above have similarly shaped toilets, but the placement of the sinks, soap dispensers, and hand dryers is different, as are the walls, tile floors, and walls. This gives the sense of being on a different floor.

 

I'll grant that, if you're using stock DooM textures, the use of realistic models might clash with your theme. Still, it might be worth considering.

 

18 hours ago, smeghammer said:

Another thread suggested looking at portals as an alternate way of doing the multi-level thing. That methodology looks  - different... I'll need to twist my brain around to think that way. 3D floors kill my little NUC as well when playing it.

Yes, portals take a bit of thinking to wrap one's head around. But, as people have pointed out, they provide a great deal of flexibility to create multi-level areas that don't look the same.

 

19 hours ago, smeghammer said:

I actually find it really hard to make an abstract, non-realistic map and I'm fully aware that doing something realistic is probably aiming a bit high - this is only my 3rd WAD and was supposed to be a smaller one...

Actually, you'll be surprised at how (relatively) easy it is to make realistic-looking levels, especially if you have suitable textures. The big "problem" with making realistic levels is that they will often inhibit the other aspects of gameplay that make DooM so appealing - flow and speed. For example, it is very difficult to make interesting gameplay in the tight quarters of an office building.

 

19 hours ago, smeghammer said:

If you are interested,  my other four maps completed so far ....

I've downloaded them and will give them a whirl. Thanks.

Share this post


Link to post

@ReX, thanks for the time you took to provide detailed comments on my post - very useful. I actually used the Sector_SetFade() method in the open script a while back - I had the trench as water and used a blue-ish RGB setting. I think the current slime is too translucent, and I will certainly resurrect the above method to set the under-slime colour.

 

At the moment I am using Doom2 stock textures, flats and things - I have yet to delve into using custom textures etc. - that will likely be in another project now, as will the use of portals I think. 

 

Those pics of your office look very Half-Life Anomalous Materials - love it.

 

44 minutes ago, ReX said:

The big "problem" with making realistic levels is that they will often inhibit the other aspects of gameplay that make DooM so appealing - flow and speed. For example,

 

That is definitely true. A couple of people have played and fed back on some of the Hellbreach maps - one common point is the lack of monsters and big open spaces - I tried to make them 'realistic' as well in the sense that they would make sense as a real space, so arbitrary large groups of monsters placed to fight the player may not always make sense (to me at least). I've been playing basically since the shareware release, but only started making maps since COVID-19 started (aside from a few crappy bits back in the day), so there is much to learn (and unlearn) about what is involved in creating a good playable map. It is therefore very much appreciated when the community takes the time to provide meaningful feedback as you have.

 

Have fun with the other maps :-) 

 

Share this post


Link to post
22 minutes ago, smeghammer said:

hose pics of your office look very Half-Life Anomalous Materials - love it.

 

Hah! Just noticed the barnacle on the ceiling...

Share this post


Link to post
14 minutes ago, smeghammer said:

Hah! Just noticed the barnacle on the ceiling...

Yes, the building is part of a Half-Life themed DooM mod known as Paranoiac (and its precursor Paranoid) on which I worked as part of The Persecution Complex team.

 

41 minutes ago, smeghammer said:

That is definitely true. A couple of people have played and fed back on some of the Hellbreach maps - one common point is the lack of monsters and big open spaces - I tried to make them 'realistic' as well in the sense that they would make sense as a real space, so arbitrary large groups of monsters placed to fight the player may not always make sense (to me at least).

One thing I have come to accept is that the type of maps you (and I) favor developing fits into the definition of "niche" mods. For my part, I will occasionally sacrifice some of the favorite gameplay elements of DooM in exchange for the ability to realize my particular vision. I enjoy working with geometry in creative ways, and this doesn't always have universal appeal. But I am absolutely fine with that.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×