Why do people still map in Boom format?

Speaking as someone who started off mapping in Hexen format (like 10 years ago mind you) I can safely say that Boom Format is way easier for new mappers to learn. It's been much easier to work with while I re-aquaint myself with Doombuilder than trying to figure out the new fangled UDMF format. I opened a line def on a UDMF map and thought my head would explode.

I also think that it's a good idea to stick to the simplest format your vision will work with. ZDoom formats are sort of unnecessary if you don't have plans to do slopes or some other function specific to it.

EDIT: Fuck, how do I keep getting myself to the top of pages...

For me? Maximum compatibility.

PrBoom with more advanced features is essentially Eternity. I hope we can make an official release of this port soon enough, as long as all immediate problems are sorted. Don't mind its outdated homepage; I'm considering asking the admins to change the subforum headline link to the wiki instead.

I guess people map for PrBoom+ because they're more comfortable. Another possible reason is that you can have a MBF mod with fairly intensive Dehacked, and you can still easily record demos on a stable never evolving platform (keep in mind that doing this is easier and less time consuming than recording and uploading video). Also it's quite possible people choose PrBoom+, limit-removing and even vanilla Doom because they want to be challenged by the limits. Or try various hacks to do cool stuff despite them. As a player, by now, I'm not sure it's really worth it. I used to be more apologetic, but I realized I saw them all by now. Stuff like the lack of room-over-room or monster AI cannot be solved (in so far) in PrBoom+ mods, making gameplay fairly predictable and unsurprising. Or the worst one: lack of surprise regarding which map leads to the secret level. 

Considering that PrBoom is the "gold standard" for demo compatibility I honestly do not see this change.

What we definitely need to get something a bit more feature loaded off the ground is easy interoperability of the more advanced ports, but as things are, their definition formats are entirely incompatible which poses a major issue for people wanting to go beyond 'just Boom'.

Well, maybe I take the plunge and write an EMAPINFO parser for ZDoom, to get at least that one problem out of the way - and maybe we can eventually convince PrBoom to join the team. I think that alone would give a tremendous boost to making other stuff than the standard issue 32 level megawad with the secret exit in MAP 15 and the super secret exit in MAP31, if there was one format that can be used by all...

3 hours ago, printz said:

PrBoom with more advanced features is essentially Eternity.

I think Eternity goes "too far" to be a less conservative PrB+. Things such as portals, 3D middle textures, and slopes require too many changes to game logic (over/under logic for 3Dmidtex, virtual positions for portals, vertical movement on slopes). That's why I listed a few things that wouldn't require any change to monster AI or player movement code to show that there was still room for growth in the Boom standard.

I think PrBoom+ (or an independent fork) should finish what MBF started. MBF added a bunch of useful codepointers, for example, but it all looks like the idea was abandoned mid-development. We have a custom melee attack for monsters, but not a custom projectile attack? Just a few more lines of code would've made a big difference.

Doom Retro DEHACKED extensions would also do good. Basic MAPINFO support sounds like a useful idea. Maybe it's too late for all that, but I don't know. 

Obviously, all of this should be disabled in older complevels. I recall reading that the main reason to not add new features (well, aside from the Heretic decapitation death, which was important enough, I suppose) was that if you play the wad in older engines, it will break. But, well, shouldn't that be obvious for users?

12 hours ago, bzzrak said:

*cough* DOOM RETRO *cough*

No clear standarts, disabled demo recording (as a result of the former). Would be a pretty weird port to make an exclusive release for. Unless its DEHACKED extensions also work in ZDoom.

Were new dummy sounds implemented, by the way? Because you can add tons of new frames and item slots, but there won't be much use for them if you can't add new sounds.

11 hours ago, Cynical said:

When Valiant came out, it required a dev version of prboom-plus to run, since it was using newly-supported MBF features.  That's not standstill.

MBF is hardly new. Its support should've been there from the beginning.

13 minutes ago, Da Werecat said:

Doom Retro DEHACKED extensions would also do good. Basic MAPINFO support sounds like a useful idea. Maybe it's too late for all that, but I don't know. 

It's never too late for anything. It all depends on the project's maintainers' willingness to do this stuff, so if you have someone open minded to such careful extensions it will work. On the other hand, if you have a maintainer who doesn't want this kinds of improvements you are hopelessly stuck.

Frankly, PrBoom should have continued what Boom started, not trying to conserve Boom/MBF in the state they were abandoned.

Nobody here is talking about turning it into a new feature-centric port, but about shaving off the rough edges and removing some of the more inane restrictions.

If I had to single out the biggest problem in Doom mapping it would be that 'Boom compatible' still does not allow episode progression definition after all these years and that such a basic thing requires using an advanced port.

Over the years I compiled several episodes out of randomly collected maps. Despite most of these maps being Boom or even vanilla compatible, the episiodes are not, because they depend on ZDoom's MAPINFO to be played.

Sorry, but that's just stupid.

I think PrBoom+ should be the port to dictate common features, yes. Depends on entryway's willingness to do this kind of stuff. If it adds new features, I'll add them to Eternity.

1 hour ago, Da Werecat said:

No clear standarts, disabled demo recording (as a result of the former). Would be a pretty weird port to make an exclusive release for. Unless its DEHACKED extensions also work in ZDoom.

Well, if it's a powerful megawad worth playing, there's no harm in limiting it to one port. It's just the port software that needs to be stable and without problems.

3 minutes ago, printz said:

It's just the port software that needs to be stable and without problems.

It should also play nicely with modern hardware.

As a counterexample, Doom Legacy turns me off just for being 4:3 only, I think a port with mainstream appeal needs to a) handle widescreen monitors properly and b) handle high resolutions properly.

A 640x400-limited port is most definitely not going to cut it for any user who's not out for a pure retro experience.

9 hours ago, Decay said:

Why should I screw around with voodoo doll conveyor belts when I can achieve the same thing with a simple line of acs?

Because voodoo doll conveyor belts are physical, ACS isn't. Basically it's the difference between using a GUI and using a command line. Voodoo dolls are perfect because they are allow you to use your mapping skills alone to effectively program scripts.

I think many mappers like to think in physical spaces, so a physical conveyor belt that moves an activator across trigger lines is just much, much easier to get your head around than spending ages on the wiki peering at arcane coding examples trying to work out how to edit them to what you need. I understand conveyor belt speeds, I struggle with knowing my [ from my {s. 

So while I personally don't really use them (I'm either limit-removing or UDMF, I also don't really see the point of a halfway house), I can totally see the appeal.

As an aside, MAPINFO support in PRBoom+ seems like a no-brainer. Zero demo compatibility issues and it just makes life sooooo much easier.

14 minutes ago, Bauul said:

Zero demo compatibility issues

Except maybe where special tags are concerned. Or enemy telefragging a la MAP30. (Both of which can be set via MAPINFO if I recall right)

But then again, it's nothing a new -complevel wouldn't be the cure for, right? ;)

9 minutes ago, Bauul said:

Because voodoo doll conveyor belts are physical, ACS isn't. Basically it's the difference between using a GUI and using a command line. Voodoo dolls are perfect because they are allow you to use your mapping skills alone to effectively program scripts.

This is a terrible answer to a rhetorical question.

Conveyor belts with voodoo dolls aren't even intuitive at all. "Yea I'll just place a bunch of player 1 starts on a scrolling sector with some line actions because it makes sense to have multiple player 1 starts in a map." Heck, last I checked even the most recent GZDB will tell you what went wrong and where with your scripting attempt. "Advanced" formats cater to the lazy, thus they are purposely designed to be easy and flexible. I can't script for shit and even I've pulled some decent full map changes.

Point is though, and you say this, it's more of a matter of what you're used to. If all you've ever done is conveyor belts, it'll be easy, and you can think of ways to implement what you want without much trouble (thus making the format appear "easier").

55 minutes ago, Bauul said:

Because voodoo doll conveyor belts are physical, ACS isn't. Basically it's the difference between using a GUI and using a command line. Voodoo dolls are perfect because they are allow you to use your mapping skills alone to effectively program scripts.

At least this made me laugh. But on the technical side it amounts to saying that Punched cards are a better medium to input some program into a computer than an expressive programming language, because the medium is physical and you can touch it.

On the functionality side this is pretty much what a conveyor script is to a real scripting language: a clumsy workaround for stuff that often can be expressed in a few lines of text.

1) Not everyone has the same approach to mapping - classic Doom's gameplay and feature set is ample to the point where not everyone has to think about coding or scripting

2) most mappers are gonna be more inspired by the large collection of classic & Boom maps people have made over the years than the silver scripted slagheap the ZDoom community offers

3) giggle you know I don't mean it I love all doom stuff

1 hour ago, Bauul said:

much easier to get your head around than spending ages on the wiki peering at arcane coding examples trying to work out how to edit them to what you need.

The issue with this is that if you're just doing what you could do with voodoo doll conveyors, you need to know like two things:

1. to remember to have #include "zcommon.acs" at the top.

2. to know how to define a script ... which can be simple as

script 1 ( void ) {
  // insert script here
}

After that, about the only things you might need to look up on the wiki are Delay() and TagWait(), which are pretty intuitive ( both have a single argument, one waits a specified number of tics, the other waits until all sectors with the specified tag stop moving ). The rest of the stuff is just using the same action specials you'd use on lines, with the arguments in the same order as they are on the linedef definition - there's barely any need to look at the wiki at all for stuff like that.

And, as you'll note, no reason to confused [ and {, since the former never comes up - you'll only need to make the distinction if you start working with arrays, which are completely unnecessary until you start doing some wacky stuff with ACS.

1 hour ago, Bauul said:

Because voodoo doll conveyor belts are physical, ACS isn't.

And somehow that makes Voodoo dolls better than ACS?

And as a programer there is no difference between GUI or CLI if you can achieve similar, if not better, results.

Its like saying typewritters are better than PC because it prints directly to paper.

Just want to chime in re: why people would want to avoid scripting, a form of text-based code, and prefer a more kinesthetic (albeit virtually so) 'voodoo doll' approach to sequential line/sector actions.

Dyslexia's a thing, k? Now, this manifests itself in subtly different ways on a per-individual basis, but some dyslexic people:

1. probably do not know (through non-diagnosis or their own unintentional ignorance) they are dyslexic
2. probably can't fathom the arcane nature of code, which barely resembles the more familiar structuring of prose
3. have workarounds for the above two based on other stimuli

Ergo, a dyslexic mapper may think better in spatial terms (or even visual terms, aided immensely by DB2/GZDB's 3D preview) than wrestling with something like code, which can be incredibly specific as to which order things need to be in to even function. Emphasis on 'order' important; it's pretty much the main 'thread' between the three main subcategories of dyslexia (to wit: dyscalculia being the difficulty processing number; dysgraphia being the same for graphemes or the collections of symbols that make up letters and words; dyspraxia a more general information-processing difficulty).

Personally, the idea of any sort of code makes me feel pre-emptively dizzy -- I used to code in BASIC back in the day and I honestly wouldn't go any more low-level because it wouldn't play well with my own dyspraxia. Hell, even BASIC was difficult.

tl;dr - sure, scripting is better and more controllable. But that doesn't mean it's the de facto better choice for all mappers.

I imagine many mappers just want to map, and scripting is perceived as something foreign. It's like how people would rather pile sectors than make a texture that would represent the desired details in a more elegant way.

While reading this thread, the word "trite" comes to mind.

Either you like the feel (demo compat) of Doom as it was designed, or you like the vast changes the zDoom family has made to give their engine a more modern feel. Mapping habits often follow suit.

This is a rift that will forever exist in our community so long as the zDoom family maintains its goals; nothing wrong with what they want, but the importance of the feeling of the game and flexibility it offers won't ever be offset by a fancy new engine for some folks and therefore we will never see eye-to-eye on this as a community. 

Top that off with the barrage of 'minute details that don't much matter' and we all get caught up in the placement of these lines in the sand on a beach during low tide, if you catch my drift.

Thus we have these trite arguments over details that aren't actually important.

*Applause*

I think you missed the discussion by a very wide margin.

Yes, you are correct that some people like the feel of the original Doom, but the reason they still use the Boom feature set has nothing to do with it being the perfect compromise but it being the only option because the relevant ports chose a long time ago to stop adding new editing features.

I think we can only hope that Eternity has a bit of success to break up this stalemate.

Life is how it is Graf; we can only deal with what we currently have. Unless somebody comes along to put in work for something newer, (and that catches on) then PrBoom+ 2.1.4 is the newest, most feature-rich thing we got as a community in terms of preserving the Doom feel.

We'll see what happens when Eternity catches on, but right now it unfortunately hasn't. Hopefully it will someday.

Different strokes for different folks.

@Decay @Graf Zahl @Arctangent @jazzmaster9

Just to be clear, I'm not saying conveyor belts are better (obviously they aren't) but to someone who thinks in physical spaces they are easier to understand. They require zero additional mapping knowledge to implement, whereas ACS requires, well, learning ACS. 

Also to be clear, I don't personally use them. In my opinion, if you're going to use an advanced source port then go the whole hog.

But I do understand why someone would use them. I think the issue is as soon as you're used to coding it's a no brainier, but many mappers aren't. They'd opt for a more kinesthetic option always over coding.

18 minutes ago, Bauul said:

Just to be clear, I'm not saying conveyor belts are better (obviously they aren't) but to someone who thinks in physical spaces they are easier to understand. They require zero additional mapping knowledge to implement, whereas ACS requires, well, learning ACS.

How does one randomly discover they need to make scrolling sectors outside the map and use multiple player 1 starts? Both formats require at least some minimal investigation from a mapping standpoint.

1 hour ago, Fonze said:

Life is how it is Graf; we can only deal with what we currently have. Unless somebody comes along to put in work for something newer, (and that catches on) then PrBoom+ 2.1.4 is the newest, most feature-rich thing we got as a community in terms of preserving the Doom feel.

One can still lobby for improving the state of affairs.

36 minutes ago, Bauul said:

Just to be clear, I'm not saying conveyor belts are better (obviously they aren't) but to someone who thinks in physical spaces they are easier to understand. They require zero additional mapping knowledge to implement, whereas ACS requires, well, learning ACS. 

 

I think the necessary knowledge to teach the ACS features that are needed to replace conveyor scripts can be conveyed in a few minutes. It's really nothing more than:

Start with:

#include "zcommon.acs"

For each conveyor belt,

start a script with

script {number)(void)

{

Invoke any action like this

Door_Open({tagnum}, {speed});

To create delays between actions, use

delay(tics);

to wait for a specified amount of tics or

tagwait(tag)

to wait for a previously started action to complete.

For the simple one trigger starts one sequence case that's really all there is.

No need to learn more complex stuff. But once someone has a grasp on these basics the following steps are infinitely easier.

Effectively the major difference is that in terms of conveyors, time has to be expressed as a distance, whereas here it has to be expressed as a time value.

One thing I noticed when mapping in Boom format was the fact that I cannot use push-lifts. This completely blew my mind, and I couldn't believe I had to make little switches on the wall to call lifts instead of having simple push-lifts like you have in vanilla Doom.

Other than that, Boom is the "vanilla++" format in the Doom community, for better or worse. When learning how to make maps, I started with vanilla Doom 2 format, then worked my way up to Doom in Hexen format, and then updated to UDMF. I recommend newcomers to do the same, as this will ensure that you will ease your way into the mapping work-flow and learn how to use more advanced features as you start to feel more comfortable with the previous format.

From a mapping stand-point I prefer UDMF just because of how much freedom it gives me, but good looking playing advanced Doom maps on an old system.

1 minute ago, Agentbromsnor said:

One thing I noticed when mapping in Boom format was the fact that I cannot use push-lifts. This completely blew my mind, and I couldn't believe I had to make little switches on the wall to call lifts instead of having simple push-lifts like you have in vanilla Doom.

Let me guess: you came from ZDoom, and then it didn't work in a more conservative engine?

You have to assign a tag. ZDoom doesn't require it, but Boom does, and so does vanilla Doom.

I didn't know that. :o I did search online for an answer to this, but I just figured the feature wasn't there for some reason.

I'm not sure if I tried tagging previously. I would have to take a look at my most current WIP Boom format map.

I rarely map in Boom format. For me it is Vanilla Doom or GZdoom. I always thought that since I allow some features to be introduced and "contaminate" the "purity" of Vanilla, I can allow everykind of special effect.

There is the question of the demons, but today with youtube and streaming I suppose there should be no more need for lmp, IMO.

Happy Easter.