Horizontally moving platforms

[hfc2x]

I cannot do something like this, so if anyone out there is able to, it would be much welcome.
The thing is that 3D floors have made it possible to have 3D platforms which are able to move up and down (like in most modern games), but Doom is seriously lacking the same thing, but for horizontal movement. While it can actually be worked around by making bridges and stuff, actual moving platforms cannot be made whatsoever. An actor moved by camera interpolation points can somewhat emulate this, but it's not perfect and the player has to still "walk" on top of this actor to keep him/herself on top of it.

So here's the deal:
Making an actor similar to fake 3D bridges would be the key for this. Adding it special native properties to keep the player "attached" to it while it moves (like a moving sector), and give it arguments to set its path through path nodes or patrol points. That would make actual horizontal-moving platforms possible. Then, giving it an appearance would depend on the modder (be it sprites made for it or actual 3D models).

Adding something like this will really expand what can actually be done in a map.

[Amuscaria]

AFAIK, a moving sector-based object is impossible with Doom's BSP-based map structure. However, if you're talking about an actor, the problem is that there are no functions to handle friction between 2 objects. The bottom object can move, without the top moving. I guess you can simulate friction by giving any actor touching the bridge thing a net velocity that is equal to the bridge objects movement velocity; relative to the map, you will be moving 'on' the bridge object. I'm not sure if you can apply this to only objects that are on top of the bridge object.

[hfc2x]

Well, Rise of The Triad did it, so Doom can do it too. The problem is that there's possibly no one interested in implementing this.

[edward850]

Well, Rise of The Triad did it, so Doom can do it too.

This is not how it works. Different engines do different things, and this usually includes physics.

[hfc2x]

Different engines do different things

And that's why I said that, since ROTT uses an enhanced version of the Wolf engine, which is of course, far more limited than the Doom engine. So, even if it's not an easy thing to do, it's likely that this can actually be implemented in ZDoom.

[FDARI]

While just about anything *can* be done, it might fit very poorly with existing code. If it does not double the size of the source, memory used or processing power required, if much existing zdoom code can be reused, then it is feasible. Otherwise, it can be done.

Tetris is a very simple game. It is fully possible to have tetris in zdoom, but you'd have to write tetris from scratch and integrate that with the existing engine (which means it is more work than just writing tetris from scratch). It may actually be possible with acs + voxels or hudmessages (a matter of style). With hudmessages you could even obscure most of the doom features and get a near faithful 2d experience.

I'm not saying that your idea is bad. I'm saying that saying something can be done is saying very little indeed.

Perhaps Doomscript can give us the means to handle this on our own. Maybe - just maybe - ACS bumpspecial can do it. Not sure; walking onto/bumping into, and staying on board, might be tricky. (Event handler for actors bumping into platform-actor, check if actor radiuses overlap, if they do, check if bumping actor is higher up, if it is, modify its speed based on platform movement.)

Based on the apparently possible scripting implementation, it seems that a built-in feature ought to be near-feasible, rather than tetris-unfeasible; but perhaps it is not required.

[TheDarkArchon]

Different engines do different things

And that's why I said that, since ROTT uses an enhanced version of the Wolf engine, which is of course, far more limited than the Doom engine.

There's a fundamental difference here, though. The DIP would have been able to dump and rewrite Wolf 3D code without worrying about compatibility with Wolf 3D. ZDoom, for reasons that should be obvious, can't.

[StrikerMan780]

It might not currently be feasible, but, I would really be amazed if Moving sectors could be done Ala. Build. (Trains anyone?) From what I recall, Build uses a BSP-Structure for it's maps, but, I'm unsure what it does differently in order to make moving sectors possible. There was a limit though, moving sectors couldn't go outside their parent sector, otherwise there would be major Slime-trailing or HOM involved.

[edward850]

From what I recall, Build uses a BSP-Structure for it's maps ...

Nope. It doesn't use Ray-casting either, but rather some weird brute-forced wall sorting. What you are also overlooking is ZDoom's physics engine, which only barely has the concept of one object standing on another.

[AFADoomer]

Quick and dirty moving platform:

Code: Select all • Expand view

ACTOR Platform : SwitchableDecoration
{
   Height 8
   Radius 32
   Mass 10000
   +FLOORCLIP
   +SOLID
   +ACTLIKEBRIDGE
   +CANPASS
   +BUMPSPECIAL
   +NOGRAVITY
   Activation THINGSPEC_ThingTargets | THINGSPEC_ThingActs | THINGSPEC_Switch
   States
   {
   Spawn:
      UNKN A 0
   Spawn.Patrol:
      "####" A 1 ThrustThing (angle * 256 / 360, 1, 0, 0)
      "####" A 20
      "####" A 0 A_JumpIf((velx != 0) || (vely != 0), "Spawn.Patrol")
      "####" A 7
      "####" A 1 A_UnSetSolid
      "####" A 1 A_SetAngle(angle + 180)
      "####" A 1 A_SetSolid
      Loop
   Inactive:
   Active:
      "####" A 1 ACS_NamedExecute("W_DoPlatform", 0, 64, 64)
      Goto Spawn.Patrol
   }
}

With this ACS script:

Code: Select all • Expand view

Script "W_DoPlatform" (int PlatWidth, int PlatHeight)
{
   int NotMoving = True;
   int OnPlatform = True;

   int PlatTID = UniqueTID();

   Thing_ChangeTID(0, PlatTID);

   SetActivatorToTarget (PlatTID);

   While (OnPlatform)
   {
      NotMoving = True;

      int PlatX = GetActorX(PlatTID);
      int PlatY = GetActorY(PlatTID);
      int PlatZ = GetActorZ(PlatTID);

      int PlayX = GetActorX(0);
      int PlayY = GetActorY(0);
      int PlayZ = GetActorZ(0);

      int offsetX = PlayX - PlatX;
      int offsetY = PlayY - PlatY;
      int offsetZ = PlayZ - PlatZ;

      While (NotMoving)
      {
         SetActorPosition(0, GetActorX(PlatTID) + offsetX, GetActorY(PlatTID) + offsetY, GetActorZ(PlatTID) + offsetZ, 0);
         If (GetPlayerInput(-1, INPUT_BUTTONS) & (BT_FORWARD + BT_BACK + BT_MOVELEFT + BT_MOVERIGHT + BT_JUMP))
            NotMoving = False;
         delay(1);
      }

      If (((offsetX * 2) > PlatWidth) || ((offsetY * 2) > PlatHeight)) OnPlatform = False;
      delay(1);
   }
}

This makes a moving thing that travels back and forth between two points that you can stand on. Basically it moves the player with the platform object as long as they're standing still on the platform. If you do this in GZDoom, you could probably set up a model for the item to make it look like a real platform.

Obviously this could be expanded upon, but this was a rough proof of concept.

[Gez]

If you do this in GZDoom, you could probably set up a model for the item to make it look like a real platform.

Voxels!

[AFADoomer]

Proof of concept, with voxel platform (that may look familiar...):
http://www.afadoomer.com/files/platform.pk3

Summon 'Platform' for a moving platform, or 'StaticPlatform' for a non-moving platform.

I also changed the code to use SetActorPosition and calculate movement based on the thing's defined speed, instead of using ThrustThing (movement was jerky and speed was hardcoded with ThrustThing).

[Enjay]

Hang on, hang on. Don't you know that what you just did can't be done?

Seriously, that works really well and is very smooth.

[Gez]

It works nicely, but only for the player of course. Engine-side support, if it were implemented somehow, would allow to put imps on these platforms.

[AFADoomer]

It works nicely, but only for the player of course. Engine-side support, if it were implemented somehow, would allow to put imps on these platforms.

I'm working on that... It vaguely works when you add THINGSPEC_MonsterTrigger to the Activation property of the platform, but the code to keep them on the platform is glitchy.