A return to DooM mapping - Which version to map for?
Moderator: GZDoom Developers
Forum rules
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. If you still don't understand how to use a feature, then ask here.
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. If you still don't understand how to use a feature, then ask here.
A return to DooM mapping - Which version to map for?
Hi!
So, after some two decades or more, I'm making a return to DooM mapping. I've never been
a 'professional level' mapper back in the days, it was a hobby for me. Managed to put together
a whole episode for DooM1 back in the old days, and also took part in the 10Sector contest,
but after recently trying to find my old files, it turned out that they must have gotten lost
during a harddrive cleanup or something. Sad, but what's gone is gone. However, nostalgia
struck hard, and now I'm back to mapping. I'm using DoomBuilder 2, and I got questions!
1> For some reason most people seem to suggest mapping for DooM2 rather than the
old DooM1. Other than there being more resources in the iwad, and a bit more functionality
when it comes to triggers, is there any reason for that? I mean, I own both games, but
in a 'return to the roots' kind of fashion I'm feeling much more drawn towards the good
old DooM1, perhaps even just what's in the shareware version of it.
2> Any of the tutorials I've looked at do suggest that when you set up your editor, to select
zDooM/gzDooM wad file format. Again, other than much increased functionality thanks to
all the work that's been put into zDooM over the decades, is there any reason for this? Or
is Classic DooM still a viable alternative especially if cross-sourceport compatibility is wanted?
3> So, the main difference between the iwads of DooM1 and DooM2 obviously is the resources.
Different texture names, a few more weapon models and monsters, different names and tags
for most of the resources. Does any tool exist that makes it possible to convert a DooM1 map
to DooM2 or vice versa, something that goes through the pwad, smartly translates resource
names and replaces things that do not exist in either version with matching replacements?
Thanks in advance,
-Clyde
So, after some two decades or more, I'm making a return to DooM mapping. I've never been
a 'professional level' mapper back in the days, it was a hobby for me. Managed to put together
a whole episode for DooM1 back in the old days, and also took part in the 10Sector contest,
but after recently trying to find my old files, it turned out that they must have gotten lost
during a harddrive cleanup or something. Sad, but what's gone is gone. However, nostalgia
struck hard, and now I'm back to mapping. I'm using DoomBuilder 2, and I got questions!
1> For some reason most people seem to suggest mapping for DooM2 rather than the
old DooM1. Other than there being more resources in the iwad, and a bit more functionality
when it comes to triggers, is there any reason for that? I mean, I own both games, but
in a 'return to the roots' kind of fashion I'm feeling much more drawn towards the good
old DooM1, perhaps even just what's in the shareware version of it.
2> Any of the tutorials I've looked at do suggest that when you set up your editor, to select
zDooM/gzDooM wad file format. Again, other than much increased functionality thanks to
all the work that's been put into zDooM over the decades, is there any reason for this? Or
is Classic DooM still a viable alternative especially if cross-sourceport compatibility is wanted?
3> So, the main difference between the iwads of DooM1 and DooM2 obviously is the resources.
Different texture names, a few more weapon models and monsters, different names and tags
for most of the resources. Does any tool exist that makes it possible to convert a DooM1 map
to DooM2 or vice versa, something that goes through the pwad, smartly translates resource
names and replaces things that do not exist in either version with matching replacements?
Thanks in advance,
-Clyde
- MFG38
- Posts: 414
- Joined: Sun Apr 14, 2019 8:26 am
- Graphics Processor: nVidia (Modern GZDoom)
- Location: Finland
- Contact:
Re: A return to DooM mapping - Which version to map for?
It's all down to preference. If you want to make a vanilla map for Doom 1, make a vanilla map for Doom 1. There are no strict rules governing which game you can/should map for and in which format.
- Kappes Buur
-
- Posts: 4120
- Joined: Thu Jul 17, 2003 12:19 am
- Graphics Processor: nVidia (Legacy GZDoom)
- Location: British Columbia, Canada
- Contact:
Re: A return to DooM mapping - Which version to map for?
I could not say it any better.MFG38 wrote:It's all down to preference.
The main reason to map for either DOOM or DOOM2 I would surmise is that most people own a copy of the DOOM2 IWAD.
Indeed, in the last few years things have progressed quite dramatically. If you allow me to make a comparison
Mapping for Doom or DOOM2 in vanilla format is like driving an old Volkswagen Beetle.
The feature set is rather limited by today's standards, but some decent maps can be made.
Mapping for DOOM or DOOM2 in UDMF or DOOM in HEXEN format is like driving a Cadillac.
The feature set is rich in options, a greatly expanded list of action specials, scripting, monster development, 3D actors, etc.
The tools to use are GZDoom Builder - Bugfix for map construction and Slade3 for lump editing.
https://www.doomworld.com/forum/topic/7 ... nt-1992417
However, the only way for you to find the right path to mapping is by trying them all.
And read the WIKIs
https://doomwiki.org/wiki/Entryway
https://zdoom.org/wiki/Main_Page
The forum is always open to answers questions.
But, most important of all, have fun mapping.
Re: A return to DooM mapping - Which version to map for?
To be fair, I have a personal tip. Always start with the basic format, in this case, vanilla Doom. Once you grasp the mapping fairly good, try advanced formats like Boom format and UDMF format. I already saw people failing at mapping, trying to grasp the overwhelming amount of features that those formats have, especially UDMF.
Yes, it's down to preference but, the basics are essential to learn first.
Yes, it's down to preference but, the basics are essential to learn first.
Re: A return to DooM mapping - Which version to map for?
I agree that getting the basics of what makes a good map sorted out is absolutely essential but I most certainly do not agree that mapping in vanilla first necessarily assists in making that goal any more easy. In fact, if you intend moving on to UDMF, I think learning vanilla conventions, shortcuts and hacks could actually be detrimental.
Vanilla mapping is not necessarily simpler. It has a bunch of illogical conventions and restrictions that exist because the format is what was needed in 1993 to make the maps that the mappers at id were making at that time. It is a more primitive and restricted format but not necessarily a more simple one to work with or one that inherently leads an inexperienced mapper to the finer points of creating good gameplay.
But I've ranted about that quite recently, so I'll just link to it rather than repeat myself.
viewtopic.php?f=123&t=64444&p=1101212#p1101212
Vanilla mapping is not necessarily simpler. It has a bunch of illogical conventions and restrictions that exist because the format is what was needed in 1993 to make the maps that the mappers at id were making at that time. It is a more primitive and restricted format but not necessarily a more simple one to work with or one that inherently leads an inexperienced mapper to the finer points of creating good gameplay.
But I've ranted about that quite recently, so I'll just link to it rather than repeat myself.
viewtopic.php?f=123&t=64444&p=1101212#p1101212
- Darkcrafter
- Posts: 564
- Joined: Sat Sep 23, 2017 8:42 am
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
Re: A return to DooM mapping - Which version to map for?
Yeah I sometimes say stupid things (I mean that I suggested to start with vanilla thing)
Go with GZDoom Builder BugFix; GZDoom UDMF and Doom2.wad because it's a "industry standard".
Go with GZDoom Builder BugFix; GZDoom UDMF and Doom2.wad because it's a "industry standard".
- Matt
- Posts: 9696
- Joined: Sun Jan 04, 2004 5:37 pm
- Preferred Pronouns: They/Them
- Operating System Version (Optional): Debian Bullseye
- Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
- Contact:
Re: A return to DooM mapping - Which version to map for?
Seconding Enjay about not necessarily starting in vanilla, having seen 3 new names in the scripting forum ask about things that are best done in ZScript and the person with the least prior ACS/Decorate experience having the easiest time with my suggestions. Best to learn the basics with the most up to date and advanced tools, then branch out from there, than to have to unlearn a career's worth of arbitrary limitations and workarounds.
Reasons I can think of for mapping for Doom rather than Doom 2 in 2019 using GZDoom:
- guarantee no ssg, archviles or chaingunners (obsolete - anyone can just include some sprites now so there's no assurance on the user's part)
- spider/cyber kill end (obsolete, unless you *really* hate working with ACS)
- sweet mountains
- you're doing something D1-specific and want the symbolism
- you never bought D2 (obsolete, it's $6 on Steam, you can do with one less venti soy caramel decaf macchiato with extra sprinkles and double shot of espresso)
Reasons I can think of for mapping for Doom rather than Doom 2 in 2019 using GZDoom:
- guarantee no ssg, archviles or chaingunners (obsolete - anyone can just include some sprites now so there's no assurance on the user's part)
- spider/cyber kill end (obsolete, unless you *really* hate working with ACS)
- sweet mountains
- you're doing something D1-specific and want the symbolism
- you never bought D2 (obsolete, it's $6 on Steam, you can do with one less venti soy caramel decaf macchiato with extra sprinkles and double shot of espresso)
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49068
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: A return to DooM mapping - Which version to map for?
leodoom85 wrote:To be fair, I have a personal tip. Always start with the basic format, in this case, vanilla Doom. Once you grasp the mapping fairly good, try advanced formats like Boom format and UDMF format. I already saw people failing at mapping, trying to grasp the overwhelming amount of features that those formats have, especially UDMF.
Yes, it's down to preference but, the basics are essential to learn first.
That stuff is being said often but it's still dead wrong and the only reason it is so prevalent in the Doom community because that's where things started.
Vanilla has a more limited feature set, but it also comes with some inane ways to express that feature set. That even more applies to Boom and the omnipresent voodoo doll scripting that gets used in Boom maps.
In order to learn, the best thing would be to use a feature set that allows to more freely express one's ideas but ensuring up front to limit oneself to a subset of features.
If you start to learn the more specialized things first it will only get harder to transition to a more generic definition style later - the other way around should work better where you first learn the basics but aren't restricted by the limitations. Once you understand the basics it is far easier to work in the limitations into your working style.
Re: A return to DooM mapping - Which version to map for?
Just to clarify my position: I’m not saying that mapping for vanilla (or Boom or whatever) is necessarily bad. If you have a reason to mod for them, that’s your choice and that’s fine. There are, of course, good reasons for mapping for vanilla (e.g. your map should be playable in any source port).
All I take issue with is the often repeated advice that in order to learn mapping you should start with vanilla and then move to more advanced mapping formats.
Some people contend that doing so allows you to get the basics sorted out before moving on to bells and whistles like coloured lighting, scripting, ambient sounds or whatever. I simply don’t believe that because the basics are the same in any format (indeed, they are pretty much the same in any game). The important stuff about making a fun map (good progression, interesting layout, challenging but fun fights etc etc) are basically the same in any format and in many different games. e.g. if you were making a Duke Nukem map, or a Quake map or something for a more modern game, many of the basic considerations will be the same. Do you need to map for vanilla Doom to get it right for those games? Of course not. Having mapped for Doom and Duke (plus many other games (and let’s not forget the other Doom engine games)) I see the progression from vanilla Doom to UDMF as being around about as different as mapping for Doom and then moving to Duke3D. i.e the basic core skills of making a fun map are much the same but the specifics of how to put that map together don’t have that much progression from one to the other (in either direction).
So, if the basic core skills are the same, where is the difference between the formats? The difference is in the detail of exactly how you implement your map – i.e. the actual mechanics of how you tie line actions to sectors, the range of options that you have and so on. As I said, I believe that these are different enough between vanilla and more modern formats that there really isn’t much difference in progression regardless of which direction you are going. i.e. learn vanilla and then move to UDMF or learn UDMF an go to vanilla. What I do feel could be the case, however, is that vanilla can teach bad habits. For example, there are ways of achieving certain goals in vanilla that can be done, but involve bizarre hacks – transparent doors, deep pools of water and many other visual tricks – rely on fooling the renderer and, actually, often give a sub-standard result. Why even bother learning that if there is a native way of doing such things that will give a better result in UDMF? You would have to learn the twisted arcane way of doing it only to unlearn it and do it properly later. How does that help progression? And to a lesser extent, the same thing exists with line activation types (to a new mapper, it surely makes no sense that line activation types and whether the action is repeatable or not (and by whom) are tied to what the line type makes a sector do in Doom) and a whole host of other vanilla features/limitations that are only there because they satisfied what was needed when Doom was being made and not the needs of an extensive and long-lived modding community.
But won’t learning UDMF teach bad habits too? Possibly, but less so inherently IMO. It might mean adding “unnecessary” bells and whistles to your map (the most common complaint – “he spent all his time on coloured lighting but forgot to make the map fun”), but at least you will be doing it via a properly coded feature. You want to make some deep water just because you can in UDMF? Well, you can (albeit that it doesn’t necessarily mean a good (or bad) map). You then move to vanilla and you still want to make deep water for no better reason than UDMF allowed you to. Well, you still can, but now you have to learn a rendering hack to make it happen.
Remember, people can (and always have) made crap and good maps in all formats.
So, TL:DR - map in whatever mode you like, but IMO, the essential, basic skills of putting together a fun map are the same in any mapping format (and many games) and there simply isn’t a logical progression from the specifics of vanilla mapping to the advanced formats. So, if you plan on making maps where it is easier to do what you want from right out of the gate, why not go for the map format that is more likely to let you do that with properly coded built-in features? i.e. the format that was designed for modders and not the format designed to the specific requirements of people making the first ever maps in 1993.
All I take issue with is the often repeated advice that in order to learn mapping you should start with vanilla and then move to more advanced mapping formats.
Some people contend that doing so allows you to get the basics sorted out before moving on to bells and whistles like coloured lighting, scripting, ambient sounds or whatever. I simply don’t believe that because the basics are the same in any format (indeed, they are pretty much the same in any game). The important stuff about making a fun map (good progression, interesting layout, challenging but fun fights etc etc) are basically the same in any format and in many different games. e.g. if you were making a Duke Nukem map, or a Quake map or something for a more modern game, many of the basic considerations will be the same. Do you need to map for vanilla Doom to get it right for those games? Of course not. Having mapped for Doom and Duke (plus many other games (and let’s not forget the other Doom engine games)) I see the progression from vanilla Doom to UDMF as being around about as different as mapping for Doom and then moving to Duke3D. i.e the basic core skills of making a fun map are much the same but the specifics of how to put that map together don’t have that much progression from one to the other (in either direction).
So, if the basic core skills are the same, where is the difference between the formats? The difference is in the detail of exactly how you implement your map – i.e. the actual mechanics of how you tie line actions to sectors, the range of options that you have and so on. As I said, I believe that these are different enough between vanilla and more modern formats that there really isn’t much difference in progression regardless of which direction you are going. i.e. learn vanilla and then move to UDMF or learn UDMF an go to vanilla. What I do feel could be the case, however, is that vanilla can teach bad habits. For example, there are ways of achieving certain goals in vanilla that can be done, but involve bizarre hacks – transparent doors, deep pools of water and many other visual tricks – rely on fooling the renderer and, actually, often give a sub-standard result. Why even bother learning that if there is a native way of doing such things that will give a better result in UDMF? You would have to learn the twisted arcane way of doing it only to unlearn it and do it properly later. How does that help progression? And to a lesser extent, the same thing exists with line activation types (to a new mapper, it surely makes no sense that line activation types and whether the action is repeatable or not (and by whom) are tied to what the line type makes a sector do in Doom) and a whole host of other vanilla features/limitations that are only there because they satisfied what was needed when Doom was being made and not the needs of an extensive and long-lived modding community.
But won’t learning UDMF teach bad habits too? Possibly, but less so inherently IMO. It might mean adding “unnecessary” bells and whistles to your map (the most common complaint – “he spent all his time on coloured lighting but forgot to make the map fun”), but at least you will be doing it via a properly coded feature. You want to make some deep water just because you can in UDMF? Well, you can (albeit that it doesn’t necessarily mean a good (or bad) map). You then move to vanilla and you still want to make deep water for no better reason than UDMF allowed you to. Well, you still can, but now you have to learn a rendering hack to make it happen.
Remember, people can (and always have) made crap and good maps in all formats.
So, TL:DR - map in whatever mode you like, but IMO, the essential, basic skills of putting together a fun map are the same in any mapping format (and many games) and there simply isn’t a logical progression from the specifics of vanilla mapping to the advanced formats. So, if you plan on making maps where it is easier to do what you want from right out of the gate, why not go for the map format that is more likely to let you do that with properly coded built-in features? i.e. the format that was designed for modders and not the format designed to the specific requirements of people making the first ever maps in 1993.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49068
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: A return to DooM mapping - Which version to map for?
IMO anyone who thinks that these are essential to their map making before even making a map should seriously reconsider their attitude towards mapping.Enjay wrote:For example, there are ways of achieving certain goals in vanilla that can be done, but involve bizarre hacks – transparent doors, deep pools of water and many other visual tricks – rely on fooling the renderer and, actually, often give a sub-standard result. Why even bother learning that if there is a native way of doing such things that will give a better result in UDMF?
The first goal should be to make a well-playing map without hacks - or advanced features if targeting something more modern. TBH, I don't know many maps using any of these vanilla renderer exploits that truly benefit from it.
For some strange reasons "mapping for vanilla" often means making semi-broken maps - because there's no 'legal' way to get around the restrictions, mappers tend to resort to hacks instead of targeting a more capable engine. In that regard I find the current discussion over at Doomworld about 'vanilla conveyors' a bit disturbing. I wonder how many maps using this unstable hack will be produced as a result...
Re: A return to DooM mapping - Which version to map for?
Very much agreed.Graf Zahl wrote:The first goal should be to make a well-playing map without hacks - or advanced features if targeting something more modern.
Also agreed and therein lies the bit that makes no sense to me. Clearly they want maps that do those things - i.e. they want those features - but they would rather use often really quite awful and unstable hacks with sub-standard results to achieve what would be easily possible with a properly coded and well defined feature. I do sort of get the "I''m climbing the mountain because it's there" attitude to trying to make the vanilla engine do things it was never meant to do* but, in the long run, it still doesn't make sense to me over all.Graf Zahl wrote:For some strange reasons "mapping for vanilla" often means making semi-broken maps - because there's no 'legal' way to get around the restrictions, mappers tend to resort to hacks instead of targeting a more capable engine.
*ironic that many people who claim that vanilla is the way Doom is meant to be spend so much time forcing the engine to do things that it was clearly never intended to do.
and that there (to me at least) is an excellent summing up of a good attitude and approach towards starting mapping/modding.Graf Zahl wrote:In order to learn, the best thing would be to use a feature set that allows to more freely express one's ideas but ensuring up front to limit oneself to a subset of features.
If you start to learn the more specialized things first it will only get harder to transition to a more generic definition style later - the other way around should work better where you first learn the basics but aren't restricted by the limitations. Once you understand the basics it is far easier to work in the limitations into your working style.
Re: A return to DooM mapping - Which version to map for?
Hello again!
So, it's been what, a week, two? Time flies. And while I haven't actually replied to all the answers I've gotten
for my questions so far, I've definitely been reading, and the amount of not only any feedback, but actually
POSITIVE feedback and HELPFUL answers really has left me pretty surprised. You guys rock!
That one little map I originally started worked on? It's growing. Via a few conversions it first started as a
DooM1 map, then moved to DooM2 format, then to DooM2 UDMF. With the change come a lot of new things
to learn. ACS scripting is awesome, makes things possible that only were really difficult or not possible at
all to pull off in the 'old days'.
Still, I'm trying to somehow stick to the old spirit of DooM mapping. No polyobjects (yet?), no slanted
surfaces, let's keep things simple, as a tribute to how things were in good old Original Doom, all the
while I'm develloping my own style, and picking up things left and right. And the map is growing. Pushing
limits. Definitely won't run in vanilla doom and needs gzDoom at this point, and it's prolly long enough
to qualify as an episode on its own. At 17MB size -without custom textures or other size-bloating assets-
it's both huge and getting as detailled as I can get away with. The base geometry is finished, game flow
of the map is pegged down, right now I'm adding details. Greebles and nurbs. 40k vertices, 70k sidedefs,
and I'm only about 70% done with the detailling work. After that, it's light placement, then monsters
and a few scripts here and there. Then game-testing. This has grown into a major project, even if it'll
likely be an one-off and not the start of a whole series of maps. But it's fun.
-Clyde
So, it's been what, a week, two? Time flies. And while I haven't actually replied to all the answers I've gotten
for my questions so far, I've definitely been reading, and the amount of not only any feedback, but actually
POSITIVE feedback and HELPFUL answers really has left me pretty surprised. You guys rock!
That one little map I originally started worked on? It's growing. Via a few conversions it first started as a
DooM1 map, then moved to DooM2 format, then to DooM2 UDMF. With the change come a lot of new things
to learn. ACS scripting is awesome, makes things possible that only were really difficult or not possible at
all to pull off in the 'old days'.
Still, I'm trying to somehow stick to the old spirit of DooM mapping. No polyobjects (yet?), no slanted
surfaces, let's keep things simple, as a tribute to how things were in good old Original Doom, all the
while I'm develloping my own style, and picking up things left and right. And the map is growing. Pushing
limits. Definitely won't run in vanilla doom and needs gzDoom at this point, and it's prolly long enough
to qualify as an episode on its own. At 17MB size -without custom textures or other size-bloating assets-
it's both huge and getting as detailled as I can get away with. The base geometry is finished, game flow
of the map is pegged down, right now I'm adding details. Greebles and nurbs. 40k vertices, 70k sidedefs,
and I'm only about 70% done with the detailling work. After that, it's light placement, then monsters
and a few scripts here and there. Then game-testing. This has grown into a major project, even if it'll
likely be an one-off and not the start of a whole series of maps. But it's fun.
-Clyde