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

Vanilla-Compatible Design Tips?

Recommended Posts

I'm starting to get the hang of doom map design (I think), and hoped the more experienced mappers might be willing to share their two cents on the subject of accessibility: namely, ensuring a map is compatible with as many versions of Doom as possible (vanilla, chocolate, zdoom, legacy, etc). My current design philosophy is "work on the damn thing 'til you're satisfied with it, regardless of how big it ends up." Which I guess is fairly normal, except I don't have much of a sense of moderation at the moment, and I'd like to try condensing projects a bit more, to make them more accessible.

Or should I not even worry about it, and just keep doing like I've been doing?

Share this post


Link to post
Guest Unregistered account

Oh, trust me, there are loads of ways to create seemingly impossible tricks and structures in Vanilla/Chocolate Doom, and loads more ways to fail at it and essentially break the game. :)


I came up with this reflecting(ish) floor trick.

It involves another trick, known as an Invisible floor, which uses ANOTHER trick, which is a Self-referencing sector.


Results of self-referencing sectors can be messy, so take precaution.



Heh, sorry. I somehow misread the title as "Vanilla-Compatible design Tricks". Whoops. XD

Share this post


Link to post

Size doesn't matter. Vanilla can handle quite large maps. It's the complexity you've got to watch out for. Though, I've always found the static limits to be quite generous, really: if you go over the limits, you're probably not using your resources as efficiently as you could be.

As far as accessibility goes, I've found the opposite to be the case. When you get comfortable with vanilla mapping, you end up building things that don't actually work in modern ports (and you won't fix them - as far as I'm concerned, it's a bug in the port).

Share this post


Link to post
Guest Unregistered account

The funny thing is, ORIGIWAD, the first ever was made, by a hex editor consists of only three sectors.
It works fine in Vanilla Doom but causes random HOM effects in some source ports. XD

Share this post


Link to post

First off:

http://svn.drdteam.org/doombuilder2/

That plugin for Doom Builder includes the Visplane Explorer, which is extremely useful for ensuring vanilla compatibility: just make sure you have your map saved before you use it. Personally when it comes to vanilla mapping I find drawsegs give me more trouble than visplanes: they may not be fatal, but it's difficult to whittle them down and keep the amount of detail you want.

Secondly, size does matter: many large maps in vanilla have what is known as the Savegame buffer overflow, which prevents you from saving your game in vanilla. If you want true vanilla compatibility, keep the amount of Things in your map to a minimum.

Third: let textures do the work for you. You'll notice in Plutonia that there are a few textures made out of the Doom II patches, which made it easier for the Casali brothers to make interesting looking maps with minimal linedefs. Bear in mind though that having a middle texture made up of more than one patch causes vanilla to crash: I've fallen for that one a fair bit. //_-

Hope that helps.

Share this post


Link to post

One thing to keep in mind about Visplane Explorer: it won't show overflows caused by sector height changes during play (eg, doors and lifts), nor by the player's view height being at a strange altitude (even the "bobbing" from running can cause an overflow in extreme edge cases). It's no substitute for rigorous playtesting.

Obsidian said:

Bear in mind though that having a middle texture made up of more than one patch causes vanilla to crash: I've fallen for that one a fair bit. //_-

Only on two-sided lines, of course. And it's more than one patch per vertical column of pixels: if the patches are all side-by-side horizontally, there's no problem.

Share this post


Link to post

Overall, in 2014 vanilla mapping is a rather silly way to add unnecessary complications to the level design process. Why would you want to worry about the sizes of textures you apply to steps, the amount of patches in them, the number of scroller actions in your map and all that crap? You can just map in vanilla format but test your maps in e.g. prboom-plus with the -complevel 2 parameter, and that will be enough to ensure that they will work in all popular ports, which are used by probably at least 95% of people who play pwads. So unless you really want to satisfy the few dinosaurs that still only acknowledge doom2.exe and nothing else, just don't worry about vanilla compatibility. It just isn't worth the effort nowadays in my opinion.

Share this post


Link to post

There is a lot of credit to be given for a person who designs their level for vanilla. There are a lot of limits to be considered. Most notably, visplane overflows which can reduce your freedom as a mapper. In some cases you will be putting doors were you don't want them, deleting windows, reducing details, cutting a large outdoor area into select parts or breaking a large room into smaller rooms just so you can truthfully say your map works on doom2.exe in the text file.

It's not horribly restricting, however the challenge in making a good vanilla map, often lies in using tricks to design a level that doesn't appear to look like it should work in vanilla. Not necessarily broad appeal. In fact the amount of people today who complain about visplane overflows are about the same number of people who drink diet coke and reach their goal weight. There are modern tools that you can use that will simplify the process of staying within limits such as chocorenderlimits or visplane explorer, which is essential if you want to get a vanilla level to look like gothic death matches or btsx.

I don't want to sway you one way or the other, but since accessibility is your concern, you might want to consider designing your maps for limit removing (vanilla minus the restrictive limit crashes) or boom compatible, as these are widely accepted baselines across many ports, and will save you the headaches that come with reverse engineering a vanilla-broken map.

To narrow your scope, if you're designing a map to look like doom or doom 2s maps, or like your favorite map from 1995, then you should be able to make a vanilla compatible map without much knowledge about limitations or with guesswork alone, but if you're making giant rooms with cathedral ceilings, light gradients, and huge windows overlooking expansive mountain ranges, then forget about it.

Share this post


Link to post
40oz said:

I don't want to sway you one way or the other, but since accessibility is your concern, you might want to consider designing your maps for limit removing (vanilla minus the restrictive limit crashes) or boom compatible, as these are widely accepted baselines across many ports, and will save you the headaches that come with reverse engineering a vanilla-broken map.

This sounds like the best bet to me. I don't suppose there's a list somewhere that would help me stay within Boom guidelines?

Thanks for all the responses, fellas. You've all been super helpful.

Share this post


Link to post
Impie said:

This sounds like the best bet to me. I don't suppose there's a list somewhere that would help me stay within Boom guidelines?

The map has to run correctly on Boom.exe. That's really all there is to it.

Share this post


Link to post
Memfis said:

You can just map in vanilla format but test your maps in e.g. prboom-plus with the -complevel 2 parameter, and that will be enough to ensure that they will work in all popular ports, which are used by probably at least 95% of people who play pwads.

This isn't true. Merely running pr+ cl2 doesn't set up vanilla limit overflows, their emulation is disconnected from complevels. I'd also say that chocolate-doom belongs on the list of "all popular ports", yet it will bomb out on the overflows.

All the bizarre accidental engine bugs and mapping errors aside, accounting for visplane overflows is what separates vanilla mapping from, well, limit removing mapping you were talking about. VPOs present a fairly definite upper cap on structural complexity you can achieve in vanilla and they're the first hard limit you're likely to run into. You simply can't have this much detail, that much scenery, or allow those two complex areas to be visible at once. It's simply appealing for some people to have, say, a limited set of tools and a limited canvas.

If that makes your head hurt and you think it's pointless, just call your wad limit removing and go nuts with your architectural urges. Erik Alm had no qualms with it (pun unintended) and his wads are revered universally. Calling your map vanilla compatible in 2014 AD, however, should mean it IS vanilla compatible. It's good manners and we have the advanced tools of modern science for it. And nope, pr+ with overflow emulation enabled is not a good tool for VPO hunting. That Visplane Explorer plugin for DB is a good start and roaming around your monsterless map in chocorenderlimits is a good finish.

Share this post


Link to post
Impie said:

This sounds like the best bet to me. I don't suppose there's a list somewhere that would help me stay within Boom guidelines?

1. Use the "Boom" map format in your map editor.
2. Don't use custom textures higher than 255 units (not even 256) to ensure compatibility with the actual Boom.exe engine. But PrBoom+, the today's very popular Boom-compatible port, can handle taller textures.
3. You can use "Sky Transfer" linedef action, but again, the original Boom.exe won't be affected. The action was added by MBF and today's ports like PrBoom+ are MBF-compatible. In my opinion, you don't have to worry about it and you can use the action freely.
4. Don't use a tag 0 on any lifts or doors (except doors which have a D1/DR action directly on them), because Boom treats tag 0 as a standard tag, and the action would affect all sectors with tag 0.
5. Don't use any linedefs with an action right in front of a wallpress-activated linedefs. Not even walkover-activated actions, scrolling effect actions etc. Unlike ZDoom, Boom doesn't allow the player to press "use" through multiple linedefs with an action (even if they're just walkover!), unless you use the "pass through" linedef flag.

And I think it's pretty much all, but feel free to correct me.

*The last two points applies to vanilla too, of course. I only mentioned them because they're common "ZDoomisms", which are design choices that work in ZDoom but not elsewhere. I thought it would be worth to notify you.

Share this post


Link to post
Memfis said:

Overall, in 2014 vanilla mapping is a rather silly way to add unnecessary complications to the level design process. Why would you want to worry about the sizes of textures you apply to steps, the amount of patches in them, the number of scroller actions in your map and all that crap? You can just map in vanilla format but test your maps in e.g. prboom-plus with the -complevel 2 parameter, and that will be enough to ensure that they will work in all popular ports, which are used by probably at least 95% of people who play pwads. So unless you really want to satisfy the few dinosaurs that still only acknowledge doom2.exe and nothing else, just don't worry about vanilla compatibility. It just isn't worth the effort nowadays in my opinion.


It's true that vanilla mapping probably isn't the best outlet for someone new starting out. There are enough frustrations to get a handle on in just regular Doom mapping, and learning how to work within vanilla limits is far easier if you're already comfortable with the mapping process itself.

Personally I like vanilla mapping for a few reasons that more than justify it for me.
It keeps me reined in a bit, without feeling excessively restrictive. I've built advanced, super-detailed source port maps, and I can certainly appreciate maps like that, but those maps end up taking me 50 years to build and often have performance problems, because I end up wanting to push the ports' capabilities to their limits, too.

Much like learning to compose in MIDI has accelerated my growth as a composer by stripping the feature set down to the bare minimum to keep my focus away from the precise details of synth/effect programming and mixing, the inherent needs of vanilla-oriented projects have helped keep me focused while broadening my horizons as a mapper.

I like technical challenges. Vanilla's featureset and capabilities are fixed and unchangeable, and there's a certain sense of accomplishment that comes from having built something that feels entirely modern and limitless while remaining completely compatible with vanilla. I look at vanilla as just another platform with its own set of limits and idiosyncrasies to abuse. I've mapped for Boom and tried to squeeze as much as I could out of its feature set, when I could have done (most of) the same things using ZDoom instead.

Vanilla mapping doesn't take any more time than any other kind of mapping, I don't think, if you have a feel for the basics and have the tools that help the job. What I'm doing in vanilla nowadays certainly isn't any more effort or complication than what I was doing in other ports a few years ago.

Share this post


Link to post

Then maybe I shouldn't worry too much about it after all, and just keep at it like I have been. After all, it's not like I'm doing Eternal Doom 4 maps...

Might be fun to do a vanilla episode someday though.

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
×