Why Are Secret Exits Hard Coded to Maps 15 and 31?

[Six]

Is there any technical reason behind it?

If there is some specific reasoning behind it, how come we aren't able to utilize it in any other map slot, Couldn't the secret exit just be a stand alone function?

I know very little to none of Doom's code, hence why this may be a no-brainer to the majority.

[esselfortium]

When you're hurrying to get something done on a deadline, it's much faster to hardcode it.

It would've been much nicer if the secret exit line action used the tag field for the map number it would exit to, though.

[DuckReconMajor]

It's nice to know which map to look for the secret exit in, but mappers should still have had the ability to choose.

[Alfonzo]

DuckReconMajor said:

It's nice to know which map to look for the secret exit in, but mappers should still have had the ability to choose.

I think when you're looking at a smaller set of maps such as the episodes of Doom, then the value of granting the designer the ability to select where the secret exit will appear is increased. I'd find it very fun trying to discover which one of the 8 maps in the episode feature that elusive switch, but increase the number of maps past 20 or so and the process would start to become laborious, despite the better payoff.

[Six]

esselfortium said:

It would've been much nicer if the secret exit line action used the tag field for the map number it would exit to, though.

Precisely this.

A secret exit isn't very secret if you're already aware of which map it's situated before you've even played a megawad, this is one of my pet peeves. I could understand that things needed to be cut to reach deadlines, but as trivial as secret exit location is, it couldn't of been that difficult to code in its own line action for both map 31 and 32.

Surely?

[Phobus]

Ahh, but what if some numbnuts writes in "33" for the map to be exited to? You'd then need the game to handle that in some way. There's more to programming these things than you think.

This sort of thing is why I love MAPINFO and think it would have been brilliant in the original doom.

[Graf Zahl]

Commercial software development is a completely different business. If you don't need something you don't do it. End of story.

That's why secret exits, automap names, intermission texts and their locations are hardcoded. It's a lot quicker for the developers than to cook up a good definition format.

Also, considering the overall sloppiness of Doom's code it's quite clear that no time was spent on elaborate definition management. It had to serve the released game, nothing more.

The big question, though, is, why did the early ports like Boom, not address these configurability issues? They still persist to this day in PrBoom+. Only the more advanced ports eventually addressed them.

[Maes]

Graf Zahl said:

The big question, though, is, why did the early ports like Boom, not address these configurability issues? They still persist to this day in PrBoom+. Only the more advanced ports eventually addressed them.

For reasons entirely similar to the ones you mentioned for business software development: don't do something if you don't need to or if tackling it will open up more problems than you can be assed to solve (elegantly).

Suppose you reimplement feature X or fix bug Y....why not go the extra mile and add some features of your own? OK, but in which direction? The "advanced source ports" you speak of all extended this (and similar) functionality in their own direction, creating at least 2-3 incompatible standards (e.g. ZDoom and EDGE scripting).

In such cases, you usually stick to a lowest common denominator, feature-wise, and don't stray too much from "the path". A good example of this would be BEX vs DEH: it's essentially an extension of the DEHACKED format using pretty much the same philosophy, but doesn't go the extra mile and add full-fledged scripting.

The end result? Both because it was a de-facto extension for Boom (which in turn was the de-facto standard for newer source ports), and because it was not too hard to implement on top of an existing DEHACKED subsystem, it caught on. Ports that added scripting did it each in a different direction, and none of them is simple enough to "transplant" into different ports (e.g. it would be needlessly complex to copy ZDoom's scripting into a totally different port NOT based on ZDoom itself).

[printz]

Graf Zahl said:

Commercial software development is a completely different business. If you don't need something you don't do it. End of story.

I guess the -file and the PWAD type were added in there in order to help them compile the maps, and they simply decided not to remove them from the final release?

[Maes]

printz said:

I guess the -file and the PWAD type were added in there in order to help them compile the maps, and they simply decided not to remove them from the final release?

That will always be id's little secret ;-) Yes, they left it there. No, they didn't release a single spec or tool to spark modding (stuff released 10 years later doesn't count).

Maybe it was all a big social experiment, leaving it there and see how much the crowd can figure out by themselves. We'll probably never know for sure.

[Quasar]

They all - Carmack and Romero both included - still claim they wanted to make modding easier in Doom than it had been in Wolf. While I don't doubt the intent was there, they certainly could have done more. It took the community a couple months to figure out the BSP tree, for example, time Carmack could have saved them with a single email explaining it :P

[Maes]

Quasar said:

They all - Carmack and Romero both included - still claim they wanted to make modding easier in Doom than it had been in Wolf.

Indeed, it was a cleaner system than Wolf 3D, but what they meant by "modding" might be a tad different than the "everything is Open (TM) and Free (TM)!" mentality that's pervasive today. Did it come with "make your own levels!" tools? No, it didn't. Was an official tech spec doc ever released? No, it wasn't (the SC release in 1997 doesn't count). Did they even confirm that the -file parameter was there in any official manuals? Nope, not even that.

Maybe what they really meant was "making modding easier for licensed third parties, who will be provided with the necessary technical specs and development tools", and "easier for ourselves, who will be able to sell mission packs [sic] made playable just with some extra files and a batch script".

Fact is, they never released "privileged info" or tools even to those few publishers that sold Doom mods commercially (and if they ever did no one remembers): even the Lost Episode, Perdition Gate, Master Levels all the way up to Final Doom were made using third-party editors, and not with exclusively provided id tools AFAIK. And as we all know, id themselves never used PWADs to e.g. turn Doom I into Doom II or Doom I into Ultimate Doom.

[Graf Zahl]

Maes said:

For reasons entirely similar to the ones you mentioned for business software development: don't do something if you don't need to or if tackling it will open up more problems than you can be assed to solve (elegantly).

That makes no sense for a project like Boom that had more editing friendliness as one of its main goals.

[Scypek2]

When I had Dmapedit, I remember it had separate "exit to map 31" and "exit to map 32" actions. Weird.

[Graf Zahl]

Probably because one was a switch and the other a walkover.
Add a semi-stupid developer to the picture and you got...

[Maes]

Graf Zahl said:

That makes no sense for a project like Boom that had more editing friendliness as one of its main goals.

The creator of Boom found himself in the quite enviable position of becoming the "booty daddy" for generations to come, for what regarded engine and map format extensions. His ideas would become the standard for all source ports to come, something that very few Doom source port authors can claim.

But at the same time, he was not likely to develop something as complex as ZDoom as the first advanced source port ever. So (without diminishing Killough's work in any way), what he did was arbitrarily add a bunch of new linedefs he could come up with, remove all easily fixable engine limitations and sent it on its merry way. The rest, as they say, is legend.

As "easily fixable limitations" which also include "editing friendliness" I mean stuff like removing limited visplanes and sprites in PWADs, but NOT something so complex like adding proper 3D floors. Extra linedefs are also "forward compatible" even with old editors, as you can always enter the linedef type manually. Something like e.g. Hexen map format for ZDoom OTOH, is not.

Sure, there were some hacks like BEH and extra wall animation definitions which were extended but which couldn't be really called a "clean" system. Other than that, Killough and the Boom team really managed to strike a "golden balance": their enhancements sit "atop" the standard Doom engine, extending it in just all the right places, with everything feeling like "Vanilla Doom, but squared and cubed, and with some subtle tweaks". "Doom the way it was supposed to be" is not just a catchphrase. The Boom code is also not so divergent from vanilla code, and it's easy to use it as a base to incrementally add features to vanilla-based ports.

Something like ZDoom OTOH has diverged so much from vanilla that it's bordering on being a totally different engine which also has a Doom compatibility mode. It's unlikely a different source port will ever try to be "fully ZDoom compatible" without being based on ZDoom itself, exactly because it's so complex and divergent from vanilla.

[Siggi]

The fact that Boom lacks a line that provides this feature is surprising. The fact it's not addressed in DEH or BEX is also surprising. It really seems like something Boom would have.

I guess that's just easy to say in hindsight.

[Siggi]

Maes said:

But at the same time, he was not likely to develop something as complex as ZDoom as the first advanced source port ever.

Considering Boom already adds custom line types, how would adding another line type to handle the secret levels take it in a similar direction ZDoom has gone?

I understand what you're saying about ZDoom being a different engine with a Doom compatibility option, but I just don't see how that's relevant here.

Phobus said:

Ahh, but what if some numbnuts writes in "33" for the map to be exited to?

But there are already WADs with 33 levels, look at Plutonia 2. :P
You can get there perfectly fine with -warp using a vanilla exe.

[Maes]

As I already hinted, there probably was a minor brainstorming process involved. Killough (or others on the Boom/TNT team) came up with features they'd like to have, and this was apparently enough to make them think about scrolling/friction floors, voodoo doll mechanics and health-replenishing switches, but not selectable-level exit-switches. I wonder if this "brainstorming" phase was even open to public debate as in "suggest your desired next-gen Doom features".

[Siggi]

Fair enough. Obviously during their theoretical brainstorming session, no one suggested it. But had someone suggested it, I highly doubt Team TNT members would have shot it down saying "We shall have none of that, tis not Doom!".

[Graf Zahl]

The far more likely reason why Boom didn't get further is that they never finished their work.

Overall the port looks like a half-baked affair with major parts that would have needed changes to make it editing friendly left out. There was talk about a Boom 'Phase 2' that never came to be.

[Maes]

It could even just be that they coded-in features as they went, just for the heck of it "Hmm...wouldn't it be awesome if Doom had...SCROLLING FLOORS? Quick, quick, code this in and see how it looks!"

"Next...hmmm....how about a switch that HEALS YOU? Quick, quick, code it in! Press it....huh, huh huh, it heals you, heh dude, this is fun, let's think of something else...CONVEYOR BELTS! Quick, quick code this in! Hmm...it's missing something...I know, let's put a bunch of voodo dolls on it!..."

And at some point they simply didn't have time to keep trying stuff, as Graf Suggested ;-)

[Gez]

http://forums.somethingawful.com/showthread.php?threadid=3420790&goto=lastpost

Quasar said:

They all - Carmack and Romero both included - still claim they wanted to make modding easier in Doom than it had been in Wolf. While I don't doubt the intent was there, they certainly could have done more. It took the community a couple months to figure out the BSP tree, for example, time Carmack could have saved them with a single email explaining it :P

Well, the WAD format is the extent of their effort in this direction; and honestly compared to VGAGRAPH+VGADICT+VGAHEAD, AUDIOT+AUDIOHED, GAMEMAPS+MAPHEAD, and VSWAP (yeah, four different ways to archive resources, scattered across eight different files), it is a lot better.

For example, sounds, sprites, and wall textures are all identified by number alone, so you have to replace the entire archive to replace just one of them. Also, you can't have more than 64 different walls.

It really explains why every halfway-ambitious Wolfenstein mod out there comes with its own custom exe. (Which usually does not have its source code available, so good luck if you don't want to play that mod in DOSBox.)

[printz]

Siggi said:

The fact that Boom lacks a line that provides this feature is surprising.

I believe it wasn't added, because the system is more complex than that. You not only have to set which levels go to which levels; you also have to set which levels are boss maps, and how, and maybe other effects too. That's rather something to be set in a map info data, which wasn't even started.

[shadow1013]

Why didn't iD just use a variable to store the last "normal" map visited when a secret exit was reached, and then when the game is ready to return back to normal maps, it would go to that map. easily implemented with maybe five lines of code

[Maes]

shadow1013 said:

Why didn't iD just use a variable to store the last "normal" map visited when a secret exit was reached, and then when the game is ready to return back to normal maps, it would go to that map. easily implemented with maybe five lines of code

The problem is that when "cheating" and warping to said secret level, finishing it would result in no such variable being set, with possibly very bad side effects.

The only way around that would be to have a default, hardcoded destination value depending on the IWAD and episode...and lo and behold, that's exactly what they chose to do.

And since it would be needlessly complex keeping two parallel level exit systems (a more flexible one for "regular" play, and a hardcoded one for "playing it safe in all cases"), they just chose the easy way (the easiest that got the job done) and hardcoded the entire thing.

As someone else said, a completely flexible way of handling this would require some sort of mapinfo lump instead of hardcodings, and not even Boom tackled that.

[Gez]

shadow1013 said:

Why didn't iD just use a variable to store the last "normal" map visited when a secret exit was reached, and then when the game is ready to return back to normal maps, it would go to that map. easily implemented with maybe five lines of code

Because it was not needed for their purposes.

Plus, if they did it that way, they would have forgotten to take into account things like savegames.

[Maes]

Gez said:

Plus, if they did it that way, they would have forgotten to take into account things like savegames.

Heh, I can almost imagine how a "resuming savegames inside a secret level leads to crashes after finishing it" bug would be. In general, "one off" status variables weren't treated very well by the savegame system (e.g. in the Spawn spots not preserved in saved games bug).

[tempun]

Maes said:

and health-replenishing switches

[citation needed]

[Maes]

I recall there was a demo map which showcased ALL Boom features in one map, and there were quite a lot of them. So many, in fact, that no single mapper is likely to master them all, and some are quite obscure too. To the best of my recollection, I recall that there were instant-healing as well as instant-death switches in there.