Sourceport idea - Trick-less Doom

This is just an idea, and I'm not going to actually implement it by any means, I've just wanted to bring it up and discuss.

Imagine a Doom port which would fix all Doom-engine specific glitches and quirks which are unrealistic / illogical / balance-breaking. Not only the obvious bugs like wallrunning or infinitely tall actors or ghost monsters or stupid vanilla limits, but also things like this:

• Grabbing items through walls.
  
• Balancing on a few pixels wide ledge. <-- Specially this!
  
• Gliding.
  
• SR50.
  
• Dead player exiting the map.
  
• Archvile jump. (?)
  
• Corpse physics.
  
• Fast fireballs clipping through walls.
  
• Pain Elementals being harmless at close range.
  
• Monsters opening doors from the other side than where they stand.
  
• Other things like that which I don't remember right now, feel free to add ideas.

In addition, the port would:

• Remove all HOMs.
  
• Increase the speed of slow types of moving floors, for the sake of less grindful playability.
  
• Monsters on a ledge would slightly hang over it to shoot a player under the ledge. <-- I think this is clever.
  
• (Just maybe) Allow enemies to crouch, jump and strafe, as well as the player.
  
• Make decorations at least partially destroyable.
  
• Somehow change the effect of Blur Sphere to be more advantageous for the player.
  
• Change the effect of Invulnerability to be more balanced. (only partial damage reduction, slow down player's movement etc.)
  
• Make Light Goggles switchable on and off.

The port shouldn't affect player's ammo capacity, even though it's ridiculously unrealistic, for the sake of keeping Doom gameplay enjoyable. I feel it should be kept, at least.

The port wouldn't feature any inter-sourceport demo compatibility, of course, but it would spice up playability by being less cheekily illogical. Would anyone be interested in such a port? I personally would.

DoomLegacy

I already have some plans that are somewhat along the same lines.
Maybe not exactly the same ideas.
I may have to add another options page for enabling this stuff and selecting among the alternatives.

I am not sure what some of those things are.

DoomLegacy 1.45 has:

Solid Corpse - I played with these on over Thanksgiving. The player has to jump over the corpse. They are a real pain when the corpse blocks a door. In a few cases had to resort to shotgunning the corpse to get rid of it.

Mancubus fast fireballs - The inherited code did not adequately check fireballs. I gave DoomLegacy improved checking. Most fireballs are now stopped at the surface of a wall instead of halfway inside it.

Monsters: Have momentum and obey the same floor friction rules as the player. The player is faster in most cases, but there are some mud situations where the monsters are faster.

Plans:
Power-ups: Try to provide alternatives for the power-ups to get them away from colormap changes.

The googles should be more controllable. They could be IR googles, or star-light googles. The vanilla style googles had an interesting idea, of making it possible to see in the dark. But the colormap implementation does not implement any recognizable tech.

scifista42 said:

The port wouldn't feature any inter-sourceport demo compatibility, of course, but it would spice up playability by being less cheekily illogical. Would anyone be interested in such a port? I personally would.

Considering that 'realism' is the most harmful feature of modern games, I have my doubts that this will work.

I have no problems with fixing obvious bugs (like the item grabbing) but changing well established gameplay fundamentals would make this not particularly attractive.

I experimented with crippled speed running, where the Doom guy could only run in the area of a unit circle. The result is that it felt nothing like Doom. It would be like if you took double spaceships out of Galaga.

scifista42 said:

• Balancing on a few pixels wide ledge. <-- Specially this!

This is by far the hardest problem on the list to solve. The standard solution is to push the player off if his centre isn't directly above the highest floor, which works until you try to climb a staircase and find you can't do it without a running start, or at all depending on the staircase geometry.

scifista42 said:

• Change the effect of Invulnerability to be more balanced. (only partial damage reduction, slow down player's movement etc.)

In Quake, invulnerability does not protect armor. Another idea is to prevent non-artifact health items from being picked up while invulnerable, since realistically, being invulnerable would drastically limit your options for medical treatment.

scifista42 said:

Balancing on a few pixels wide ledge.

How would this work with The Chasm?

Xaser said:

How would this work with The Chasm?

He would be likely to fall down, but not if he stayed exactly in the middle of the thin ledge. I was more talking about super-thin ledges by a wall, where the player unrealistically balances with his legs stretched to the side or whatever.

These would all be nifty and entertaining as optional DMflags, honestly. I don't think I'd play a source port where they were always enabled, though.

Graf Zahl said:

Considering that 'realism' is the most harmful feature of modern games,

I share this opinion on many particular characteristics of Doom's vs. modern shooter's gameplay, but not all of them. Getting rid of glitch-like behaviour is always a right move that game developers do, IMO. I thought it would be enough of a reason to justify "changing well established gameplay fundamentals", of course only some of them, as I've described.

And as Doomkid said, making the behaviour toggle-able would be cool, too. But the new behaviour should be the default value in this fictional sourceport.

Most of these don't even affect normal players.

VGA said:

Most of these don't even affect normal players.

But any normal player can decide to try the tricks anytime he wants, and take advantage of them how many times he wants. That doesn't change the fact that they're basically undesired side-effect quirks of the engine. Let's get rid of them, if we can! No?

Foxpup said:

This is by far the hardest problem on the list to solve. The standard solution is to push the player off if his centre isn't directly above the highest floor, which works until you try to climb a staircase and find you can't do it without a running start, or at all depending on the staircase geometry.

Do what Marathon does. Push the player off only if it's higher than can be stepped back up onto relative to the player's feet. Think of it like a popsickle shape, the stick is the 24 units that Doomguy can step (or fall in this case), but he will be pushed if the rest of his collision box hits the ledge.

I don't entirely agree with all the items in the list of proposed feature changes, though given the direction you're going with it I might suggest some:

1. Make the actor collision cylindrical like in Unreal. The SNES version was like this, probably one of the very few things good about that port. Box collision actually means it's wider than the defined number of units when facing it from 45 degree increments (NW, SW, SE, NE). Cylinders would make it uniform to the lowest possible size.

2. Make the world be seen with square pixels instead of 5:6, as Romero says this is how the world was intended to be seen but they didn't bother with aspect ratio correction.

3. And to compensate for #2 leaving the sprites too wide (at least the monster sprites were seemingly intended to be seen at 5:6), it's worth taking a page from the PSX version's book and scaling the sprites down horizontally so that they remain 5:6 while the world around them is wider. It would also go well with item #1 above given the scale issues with it.

scifista42 said:

He would be likely to fall down, but not if he stayed exactly in the middle of the thin ledge. I was more talking about super-thin ledges by a wall, where the player unrealistically balances with his legs stretched to the side or whatever.

This sounds like MBF's torque simulation, also applied to living players, as well as corpses.

Remove all HOMs.

HOMs are essentially places where there should be a texture but the renderer doesn't know what to draw. That means you can't really remove them - there's nothing to remove. Like trying to remove a vacuum :) I assume you mean "replace HOM with a special missing texture pattern", which is already possible in many ports (Boom-based ports' and Odamex's flashing HOM option, ZDoom's chequered pattern for a missing texture, etc.)

Increase the speed of slow types of moving floors, for the sake of less grindful playability.

That would be good. It's far too late to change this now obviously but I often think "down-wait-up-stay" lifts worked the wrong way round. They should wait at the bottom, rise when triggered, pause, and lower to their lowest level again. If you want to descend a lift you can just hurl yourself down the empty shaft - I didn't notice "add falling damage" on your list ;)

Make decorations at least partially destroyable.

I think this would require lots of new sprites derived from the IWAD, in which case it would be unworkable for GPL-licensed engines.

Monsters on a ledge would slightly hang over it to shoot a player under the ledge.

I suppose that would require the projectile to be spawned in front of the monster instead of inside it, and adjustments to the way missile->momz is calculated (Doom's way becomes terribly inaccurate as the difference between source and target height increases)

RjY said:

I assume you mean "replace HOM with a special missing texture pattern"

I suppose that would require the projectile to be spawned in front of the monster instead of inside it, and adjustments to the way missile->momz is calculated (Doom's way becomes terribly inaccurate as the difference between source and target height increases)

Yeah, I've meant to do something like that. That's why I'm presenting this whole idea as a sourceport and not just a mod, I've imagined what if the code worked differently. ;)

Sodaholic said:

1. Make the actor collision cylindrical like in Unreal. Box collision actually means it's wider than the defined number of units when facing it from 45 degree increments (NW, SW, SE, NE). Cylinders would make it uniform to the lowest possible size.

Yes, this sounds great too.

Sodaholic said:

3. And to compensate for #2 leaving the sprites too wide (at least the monster sprites were seemingly intended to be seen at 5:6), it's worth taking a page from the PSX version's book and scaling the sprites down horizontally so that they remain 5:6 while the world around them is wider. It would also go well with item #1 above given the scale issues with it.

u wot m8. Where the hell did you get this from? Unless this happens engine-side (and I really don't think it does), then you've been dreaming about aspect ratios again. The monster and item sprites themselves are near-identical to their PC counterparts save for some weird vertical shifting in places, and only the HUD weapon stuff is actually downscaled:


Just let the aspect ratio thing go, man. Doom was made by a bunch of dudes who didn't really give two shits about that sort of stuff, they just made everything 'look right' through design.

@Baron

In NTSC (what the game was very likely designed for), you get a 32 line status bar and 192 lines of vertical resolution without aspect ratio correction on the world, making it appear 8:7 instead of 5:6 like the PC version with only 168 lines. The sprites were drawn at a lower horizontal scale engine-side (75% is as close as I can estimate at the time being), making them appear to be 6:7 which is closer to 5:6 than 8:7 is.

And no, I cannot let go of the aspect ratio thing. :P

I have one.

A mix of Zandronum and ZDoom. Well, It will read the actor flags and state parameters. of those ports and you don't need the Skulltag stuff to run its wads.

That would be one of the features for me.

Doom was always the Mario of first person shooters, with modern ones being more like Tomb Raider in comparison.

So being able to hang off of thin ledges isn't at all a problem in my book.

You'd have to fix SR40 as well, because it's unrealistic and illogical. As Ghostly says, you'd get a terrible abomination, not Doom.

I also don't see why "fixing" avjumps or glides is benefitial to your cause. They're entirely logical from the engine's perspective and you'd actually need gross hacks to "fix" them. The logical solution is to simply edit such exploits out of the maps.

Last point I have a big issue with is giving monsters extra behavioral options. Everyone who ever tried to decipher Doom's immortality formula always brings up simplicity of the monster AI. The monsters are stupid, but that means they're wonderfully versatile. Jumping will only lead to one thing: they'll all jump into an abyss. Without a doubt. And I'm not even mentioning how un-Doom it would feel to fight some leaping and crouching and dodging chaingunners. Go play half-life, heh.

scifista42 said:

The port shouldn't affect player's ammo capacity, even though it's ridiculously unrealistic, for the sake of keeping Doom gameplay enjoyable. I feel it should be kept, at least.

Use this mentality, but also for everything else on the list, not just ammo capacity. Great job, well done! Good source port.

This has been done already. It's called "Doom 3".

There's also the issue of breaking compatibility with a lot of maps. Quite a few wads take advantage of dead player exiting and item "grabbing", among other things.

Taking away a lot of these 'tricks' would make the port idiosyncratic, for the lack of a better word.

^ I think it goes without saying that when alterations and "corrections" are made to the gameplay, demo compatibility goes out of the window.

Not just demo compatibility, map compatibility too. Scythe 2 map25 would be impossible to exit entirely and depending on scifista's approach so would possibly be all the maps that kill you by telefragging Romero and some barrels. Same goes for ksutra map24, speaking of which... you exit it by setting off a barrel explosion chain that eventually pushes a voodoo doll over the exit. And since voodoo dolls are a gross bug, we can safely assume they'd get fixed too - breaking compatibility with the majority of notable Boom wads in existence. Goodbye, voodoo scripting.

I don't know why PE being harmless at close range is consider a "bug". But you may add this: lost souls stopping when items on the way...

On top of what dew was saying, Map30 of TNT uses the voodoo trick, so that's throwing an IWAD out, too.

I'm pretty sure that isn't the only trick that's used in Final Doom either, but I could be mistaken.

In the end, such a "Trickless Doom" would be so different that it would be simpler just remaking Doom in another engine -maybe not so distanced as Doom 3 was, but SNES Doom or GBA Doom 2 would be a good example.

They would be options. We have had this conversation before about which maps need which options enabled (or disabled) on which ports.
This huge database thing was planned out. Automatic Internet access to it by ports was suggested.

Any demo playback would set compatibility to normal for such options.
They would not affect any exiting demo because demo playback code would switch them off, just like for any other option.

Maps where the player inches around a thin ledge to get some prize, would fail if that was prevented. Being that people can actually do this (on their heels or toes) means that it is not that illogical. Opinions differ on what is logical or too illogical, but it is a separate issue from just wanting a simple game at the expense of logical play.

If it looks like the player ought to be able to do something, and it can be accomplished without mangling existing simple play, then I would take a shot at trying to make it happen.

If it looks like the player should not be able to do something, like grabbing an item through a wall, then the engine should be fixed to block this. Much less discussion is needed. If the implementation of this changes normal play then something is wrong with that implementation, not with the idea of fixing this grab problem. Putting in a new "grab the item" control would be the wrong was to go
in fixing this, but is not a good argument for not fixing it.

I do not advocate the kind of realism that appears in other games.
They concentrate on appearance instead of logical play. Attempts to allows players to walk on anything drawn, have led to games where the player can walk on "ANYTHING", a new form of illogical game behavior.

I favor improvements like DoomLegacy has done. 3d floors because having only one floor did not make sense. The idea that one floor was illogical or was not realistic enough is like arguing philosophy.
The inability to jump over a monster (infinite tall monster problem) was removed. The same arguments could be argued, ... infinite ho-hum.

If SR40 and SR50 are to be hindered in the engine, it should be such that any normal play is mostly unaffected.

Monsters with additional behaviors would actually feel more natural.
The problem is in settling for half done, simplistic implementations of such behaviors.
There is a reason that it was not done before, it takes considerable interaction checks, and a large number of special case handlers. It may involve an interaction check against every other kind of object in the game. Look at the internal code of nethack to understand how complicated this gets, and what needs to be done.

Methinks aiming for verisimilitude in Doom betrays the game's greatest stregths. Very few games harbor as dedicated a community of content creators as Doom, and I think the game's abstract nature is responsible.

Take another game, Team Fortress 2, for example. It was created with an unrealistic visual style to justify the abstractions in mechanics and level design that made the game more fun to play. As a result, you have not only a fun game, but a game with a thriving community of map makers and weapon designers, something that would not be possible otherwise.

This isn't to say there is anything inherently wrong with realism in games, or that a realistic interpretation of Doom is invalid, just that I don't think it belongs in a port.