A tech demo of 3D moving floors. There's still some things that I want to do to it, but as a start this is pretty neat.

Floor Demo
29.12 KB
WAD Type
Advanced engine needed  : ZDoom 2.6.1 or GZDoom 1.7.0
Primary purpose         : Technical demo of 3D moving floors
Title                   : Floor Demo
Filename                : FLOORDMO.WAD
Release date            : January 21, 2013
Author                  : Ethan Watson aka GooberMan
Email Address           : <email removed>
Other Files By Author   : Doom - The Arcade Game
                          Space Station Omega

Misc. Author Info       : But Goober!? Why are you making Doom maps again? 

Description             : A tech demo of 3D moving floors. There's still some
                          things that I want to do to it, but as a start this
                          is pretty neat. 

Additional Credits to   : The entire internet. You earned it.

* Play Information *

Executable needed       : ZDoom 2.6.1 or GZDoom 1.7.0
IWAD Needed             : DOOM2.WAD
Map #                   : MAP01
Single Player           : Yes
Cooperative 2-4 Player  : Yes
Deathmatch 2-4 Player   : No, but no reason why not with some starts
Other game styles       : No
Difficulty Settings     : No
New Graphics            : No
New Sounds              : No
New Demos               : No
DEH Patch               : No

* Construction *

Base                    : From scratch.
Build Time              : Three hours.

Tool(s) used            : Doom Builder 2.
Known Bugs              : More like known limitations.
Will Not Run With...    : Alan Wake

* General info *

Has it really been 10 years since STARBOX.WAD?

Earlier this morning, I got an idea on how I could implement moving 3D floors.
Except they wouldn't be 3D floors as such. They'd be a use of polyobjects with
walkable mid textures. A bit of experimenting (and finding a Doomworld thread
from last year) soon showed me the futility of my idea - that being that
impassable polyobjects will push you out of the way. However, since I'd also
planned on implemting height variation effectively, I'd also been playing
around with sector heights in my polygon control sector. This gave me an
interesting discovery - if I set my texture offsets to *lower* than the control
sector's floor height, I didn't need walkable mid textures. The polygon would
spawn with that sector's height. Or, in other words, it was entirely possible
to replicate oldschool 3D floors purely with polyobjects.

So, the only line flags I set on my polyobject lines were doublesided, lower
unpegged, and clip middle texture. This made my polyobject completely
unblocking while moving. Combined with the texture offset and a control sector
floor height set higher than the target sector floor height, I had a polyobject
that would push me out of the way if I got in front of it but *not* if I stood
on top of it.

Now, some might call that mission success. But from the start, I was
programming some scripts with friction in mind. Being on a moving floor that
slides away from me isn't good enough. I have to move with the floor. And this
is the tricky part. To know if you're on a floor, generally these days you'd
use an "Actor Hits Floor" thing. But that doesn't work. So you need to refer to
linedefs. The script expects all exterior linedefs of your polyobject to be
facing out. The script that activates on crossing it then checks which side it
was activated from before determining if the player is on or off. Next, you
need to know if the player's Z value matches the floor's Z value. To do this,
I check against a dummy thing inside the control sector. You could use
GetSectorFloorZ in the same manner, but you still need a dummy thing inside
that control sector for reference. If the Z height matches, the player is on
the floor and thus friction should be applied.

Using SetActorPosition was bad. It removed all freedom of moving on a platform.
To implement friction, I needed to alter the player's velocity. Finding the
correct velocity value was trial and error. I'm sure there's some
mathematically correct way to find out the correct velocity to apply based on
referring to the Doom movement code and plugging it in to an equation, but as
it stands dividing the difference of the floor's previous position to it's
current position by 10.7 gets something very close to the correct friction on
the platform.

All that remains is to set up your polyobject's move path. The path I've set
up moves tri-directionally - it moves on X and Y as a polyobject does, and it
moves along Z at the same time thanks to altering the control sector.

Oh, and because I don't like showing off anywhere near enough, it is also
multiplayer compatible.

* You can't walk under the floor.
* Things get screwy if your polyobject goes below the normal floor.
* Rotational friction is not currently supported. There is no GetPolyobjAngle
  to compare against.
* I'm disabling view bob when setting the velocity. I quite simply haven't
  checked if leaving it enabled will bob your view as the platform moves.

* Removing the sector height modification and simply changing the texture
* To account for the now-missing height, anchor some invisible bridge things to
  the poly object.
* See if we can't get a flat rendering over that 3D floor. Transfer_Heights
  trickery? Non-solid 3D floor trickery?

* Copyright / Permissions *

Authors MAY use the contents of this file as a base for modification or reuse
as long as they give credit to me.

You MAY distribute this file, provided you include this text file, with
no modifications.  You may distribute this file in any electronic
format (BBS, Diskette, CD, etc) as long as you include this file 


DM Spawns
Co-op Spawns
Help improve the database by uploading an image
Creative Commons License