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

Why do people still map in Boom format?

Recommended Posts

2 minutes ago, Da Werecat said:

So ZDoom is the obstacle to progress, because its source code isn't immediately compatible with conservative source ports?

 

Like Doomsday's code is not compatible with most other ports - or 3DGE's code is not compatible with other ports - or hell - even Eternity C++'ified parts of its code and made some sweeping changes to get its features to work. Good luck taking code from those ports.

 

But yeah, that's classic kb1: The world is larger than the small bubble you seem to live in.

 

Share this post


Link to post
27 minutes ago, NinjaLiquidator said:

No speedrunners will max your maps when mapping in Zdoom. You will lose a lot of players in general since a lot of people has Boom.

 

This is flat out wrong. I think this has been said before, but what makes you people even THINK that PrBoom and other low end ports are the engine of choice for most players?

 

This is what I wrote last year about the same thing and I believe everything I said back then still applies to the situation:

 

In clear English: All you'd lose is the hard core of Doomworld, but very little beyond that. Last year PrBoom's and all other 'classic' engines' downloads were dwarfed by GZDoom's downloads, I cannot say what the state of things is now, because the counters are no longer available, but I don't think it has changed much since then.

Share this post


Link to post
6 minutes ago, Hell Theatre said:

Last year PrBoom's and all other 'classic' engines' downloads were dwarfed by GZDoom's downloads, I cannot say what the state of things is now, because the counters are no longer available, but I don't think it has changed much since then.

I think I know what's gonna happen next.

Share this post


Link to post

Presenting misinformation as fact needs to be clearly pointed out as such!

If you want to let that stand, present the numbers that prove that PrBoom is so important that a mapper "would lose a lot of players" if it was not supported!

 

A mapper saying he maps for vanilla Doom or Boom because he prefers the style of maps that allows to make is perfectly legitimate.

But mapping for those engines to maximize audience is bollocks. To maximize audience you need an uncompromised product, and in this case that includes choosing the proper engine for what you want to make! Say what you want, but maps based on hacks and exploits do not feel like a polished product, they feel like the things they used: hackish!

Share this post


Link to post

Compromises can be big, and they also can be small. If we're talking about small compromises and ways to improve compatibility without spoiling your vision, the audience will grow.

Share this post


Link to post
1 hour ago, Hell Theatre said:

In clear English: All you'd lose is the hard core of Doomworld, but very little beyond that.

Do you realize how hostile, repugnant and preachy you sound? Have you ever paused for a second to consider that everyone's definition of "audience" might not equate to the raw number of download clicks? That perhaps this puny, annoying "hard core" dwarfs the mapping output of your glorious Zdoom empire, because they seek pleasure from a beloved hobby and validation from their peers instead of... raising their Doom stock market value?

Share this post


Link to post

This seems like a reasonable thread to articulate what I've been feeling on this issue...

 

For the longest time I've avoided ZDoom (and thus alternative approaches to mapping/scripting than Boom features) because of license issues which are largely addressed in the meantime. This was a personal thing for me which probably seems/seemed stupid to everyone else all along but *shrug*.

 

Thus I looked at Boom, and the "physicality" of voodoo conveyors was compelling only in a totally absurd way: because it's so Rube Goldberg. I think the idea of building elaborate scripted situations in them by hand is totally ludicrous; but doing so via a higher-level description is not quite as insane, so I've spent a long time building libraries and tooling in WadC to do exactly that. But, fundamentally, given better approaches exist (ACS, which is not even that good!) I've kind of decided that I'm wasting my time.

 

Also if I can formulate some kind of rule (call it Dowland's law if you must): even if I spend X effort to build boom-script-generators, theoretically saving Y time if it gets deployed/used by people (and it wouldn't); someone else with more time/talent will spend Z (where Z > Y > X) doing something at massive scale and by hand. Take a look at "The Last Sanctuary" for example: the guy built a day/night cycle in a huge outdoor canyon region, with changing light levels and a sky texture rotation across multiple sectors, entirely by hand. What's the point in making obscure generators when the most interesting insane things are done by people with too much time/talent on their hands, the hard way? (I'm reminded of this by some recent stuff I saw on twitter, Sierpinski Triangle in Quake, of course, by hand, not generated https://twitter.com/ShrimpScampie/status/854011569864400896)

I put less time into Doom stuff now anyway, but I am interested in working on a completely different approach to scripting in new/experimental ports; I've seen some interesting proofs-of-concepts that I might one day contribute to.

 

On 4/16/2017 at 1:52 AM, Gez said:

Examples of things that could easily join a "Boom+" format without requiring any new rendering features nor changes in the movement code.

 

I love the idea of a Boom+ (or MBF+). I'd also add: more empty frame table entries that most ports have added anyway; some more scrollers that are more flexible than the simple static scrollers but don't overload the xoff/yoff for textures requiring you to calculate linedef normals; erm, actually that's all I can think of right now. Oh, alternative approaches to coloured lighting that work on a per-sector basis (like zdoom's colours) and are declared in a way other than naming an alternative COLORMAP lump to make it easier for GL/advanced graphics ports to support.

Share this post


Link to post
3 minutes ago, Jon said:

Take a look at "The Last Sanctuary" for example: the guy built a day/night cycle in a huge outdoor canyon region, with changing light levels and a sky texture rotation across multiple sectors, entirely by hand.

I thought he used WadC? I'm not sure.

Share this post


Link to post
52 minutes ago, Da Werecat said:

Compromises can be big, and they also can be small.

Correct - but sometimes even small compromises can become a problem.

 

Just a small example. Recently I did some reworking on one of Freedoom's maps. One problem in that map was that a switch to open a room with one of the keys was half a map away with no indication what the switch does.

Normally, with advanced resources at my disposal the solution would have been a fourth key and a clearly marked door in that fourth key's color.

Too bad that the aim is vanilla compatibility, so we only have 3 keys and are stuck with a situation that just doesn't have a decent solution - the player has to somehow guess what the switch does.

 

Ultimately this is something every mapper has to decide for themselves: Do they want to attract the speedrunning crowd or do they want to make the map they set out to without any compromises.

On another note, I really miss those early light-scripted ZDoom maps like Dark 7, because this argument may convince their makers to  restrict themselves to Boom features. These days, ZDoom maps rarely come without massive use of advanced features.

 

8 minutes ago, Jon said:

For the longest time I've avoided ZDoom (and thus alternative approaches to mapping/scripting than Boom features) because of license issues which are largely addressed in the meantime. This was a personal thing for me which probably seems/seemed stupid to everyone else all along but *shrug*.

 

Well, that time has passed as of yesterday, when finally I managed to remove the last anti-GPL code that was still present.

 

9 minutes ago, Jon said:

Thus I looked at Boom, and the "physicality" of voodoo conveyors was compelling only in a totally absurd way: because it's so Rube Goldberg. I think the idea of building elaborate scripted situations in them by hand is totally ludicrous;

That's actually the best description of conveyor scripting so far... :D

 

Share this post


Link to post

I think a good enough Doom wad can find a wide audience regardless of port compatibility.

 

With that said, though, I'm more interested in the active community who leave comments on wads and communicate with their authors, than I am in a big download-count number of random people who I'll never hear from and might have not even actually played it.

Share this post


Link to post
1 hour ago, Da Werecat said:

I thought he used WadC? I'm not sure.


He did use it to help with the heavy lifting, that's true, I forgot that. Even weirder, rather than learn to write the generator entirely in WadC, he wrote a C++ program to generate an intermediate WadC program.

Share this post


Link to post
1 hour ago, Graf Zahl said:

These days, ZDoom maps rarely come without massive use of advanced features.

I think this is true.  The feeling that if you're stumping for UDMF (or equivalent) you have to justify its use by implementing lots of features only ZDoom supports.

 

You can imagine the response on Doomworld if someone released a map that was in UDMF only because it made good use of just one ZDoom feature. I'm sure someone somewhere would pipe up with "but if you removed just that one feature, you could make it limit-removing compatible!" as if broad compatibility was more important than the artistic integrity of the map.

Share this post


Link to post
1 hour ago, Graf Zahl said:

Just a small example. Recently I did some reworking on one of Freedoom's maps. One problem in that map was that a switch to open a room with one of the keys was half a map away with no indication what the switch does.

Normally, with advanced resources at my disposal the solution would have been a fourth key and a clearly marked door in that fourth key's color.

Too bad that the aim is vanilla compatibility, so we only have 3 keys and are stuck with a situation that just doesn't have a decent solution - the player has to somehow guess what the switch does.

 

I'm curious how you solved this issue. For me one solution seems like it would be to use an artifact like a small tower in both locations that lowers into the ground, like a piston that releases the door mechanism, so the player has a visual association between the locations. You'd have to make the distant door a lowered wall though instead.

Share this post


Link to post
4 minutes ago, NecrumWarrior said:

I'm curious how you solved this issue. For me one solution seems like it would be to use an artifact like a small tower in both locations that lowers into the ground, like a piston that releases the door mechanism, so the player has a visual association between the locations. You'd have to make the distant door a lowered wall though instead.

I didn't solve it. I just helped out streamlining the map but when it came to solving this issue there were several different opinions so I left it to the guy in charge to decide what to do with it.

Share this post


Link to post
19 minutes ago, Bauul said:

I'm sure someone somewhere would pipe up with "but if you removed just that one feature, you could make it limit-removing compatible!" as if broad compatibility was more important than the artistic integrity of the map.

It really depends on the feature.

Share this post


Link to post
2 hours ago, Graf Zahl said:

Just a small example. Recently I did some reworking on one of Freedoom's maps. One problem in that map was that a switch to open a room with one of the keys was half a map away with no indication what the switch does.

Normally, with advanced resources at my disposal the solution would have been a fourth key and a clearly marked door in that fourth key's color.

Too bad that the aim is vanilla compatibility, so we only have 3 keys and are stuck with a situation that just doesn't have a decent solution - the player has to somehow guess what the switch does.

When I've revised maps that had unintuitive switch or key progression, I've considered things like whether the obstacle needs to exist in the first place, and whether it ought to remain in the same location. Sometimes it's as simple as moving the key or switch to a nearby area from which the player can more easily see where it leads, other times it entails moving some walls and windows around to open a more obvious path, or other times you can lure the player in the desired direction by releasing some monsters over there. If all else fails, there's no(t much) shame in a convenience teleporter.

 

Assuming that you're not creating a 12-hour-long behemoth of a map, needing more than a few keys is probably a sign that the layout flow has become more convoluted than it needs to be.

Share this post


Link to post

Also, Doom does have six distinct keys with six distinct door markers. Many mappers have made use of this to create 4-, 5-, or 6-key maps in Boom format (most of the maps in Counterattack, off the top of my head). If you want, there's no reason you can't use recolored keycards to replace skull keys and recolored textures to replace skull key markers in Boom levels. That said, implementing new keys is going to be just one more reason why I think Decorate is the answer to Heretic's woes, and I'm grateful for it.

 

I know some people don't want to jump through Boom's hoops, and they don't have to. You can create an incredibly elegant level in Boom format, or an incredibly elegant level in ZDoom formats. ZDoom does have a lot of unnecessary stigma, but that stigma was brought about by a lot of poorly considered feature cramming. I've found that a Boom mapping philosophy in a ZDoom format is really comfortable, provides a good classic feel for the levels, and still gives a bit of extra flexibility. But people are going to map in whatever format they like best, and if they like conveyors better than ACS, that doesn't make them wrong.

Share this post


Link to post

I think you missed the part where Graf was talking about downgrading from Boom to vanilla, therefore having six distinct door markers ... for three distinct keys and three keys completely identical to one of those other keys sans appearance.

Share this post


Link to post
1 hour ago, esselfortium said:

Assuming that you're not creating a 12-hour-long behemoth of a map, needing more than a few keys is probably a sign that the layout flow has become more convoluted than it needs to be.

Normally I'd agree, but this was about a map that had some serious issues with progression, it was made by someone with an apparently deep love for inane switch hunts. So it was mostly about making it flow better. The problem with that particular switch was that the key was in a special room, and the only reason to visit the switch was to make it open the door.

Share this post


Link to post
8 minutes ago, Graf Zahl said:

Normally I'd agree, but this was about a map that had some serious issues with progression, it was made by someone with an apparently deep love for inane switch hunts. So it was mostly about making it flow better. The problem with that particular switch was that the key was in a special room, and the only reason to visit the switch was to make it open the door.

In other words, bad planification of progress for the map...

Share this post


Link to post
8 hours ago, Graf Zahl said:

Too bad that the aim is vanilla compatibility, so we only have 3 keys and are stuck with a situation that just doesn't have a decent solution - the player has to somehow guess what the switch does.

Have you considered simply adding a (sector) number in front of both the switch and a door? John Romero did that in e1m4b.

Share this post


Link to post
18 hours ago, kb1 said:

 

3. Because Boom format is extremely stable: A map made 10 years ago will play fine 20 years from now.

 

I think this was a really important point that might be missed.  Playing ZDoom maps from 10 years ago is a real chore.  Sometimes everything just works, but there's no guarantee of that.  When I play a Boom map from the early 2000s I don't need to download a version of Boom that was in use at the time, I just use PRBoom+. It just works. A stable format is important.

 

I don't really map, but from a player's perspective, I can tell you I'm more likely to load up an old Boom map than an old ZDoom map that I'm not sure will work as intended.

Share this post


Link to post
18 minutes ago, 7hm said:

I think this was a really important point that might be missed.  Playing ZDoom maps from 10 years ago is a real chore.

 

What map from 10 years ago does not work anymore?

People, if you are having issues with old maps and do not bother to report them, the issues cannot be fixed. Keep in mind: The only reason that you find old stuff stop working and nothing being done about it is because I cannot constantly play old maps and check for regressions. I wouldn't have time for anything else. Someone needs to tell me.

 

Also kb1 missed the point by a mile: It's not Boom format that's extremely stable, but the ports not advancing. Of couse stuff does not break if the code used to play it is vitually the same as it was 18 years ago. Boom format is just as prone to breaking as any other mapping format if some change in the engine makes it unintentionally behave differently.

 

Share this post


Link to post
39 minutes ago, 7hm said:

I think this was a really important point that might be missed.  Playing ZDoom maps from 10 years ago is a real chore.  Sometimes everything just works, but there's no guarantee of that.  When I play a Boom map from the early 2000s I don't need to download a version of Boom that was in use at the time, I just use PRBoom+. It just works. A stable format is important.

 

I don't really map, but from a player's perspective, I can tell you I'm more likely to load up an old Boom map than an old ZDoom map that I'm not sure will work as intended.

Yeah, I have first hand experience with this issue. Ten years ago when I dabbled in Doom for the first time I made a map in ZDoom. I later lost my most updated version but when i went in recently to try and recreate what I had using an older version, all the ZDoom based stuff, particularly the water, didn't work right whenever I tried to test it. The whole thing felt like so much of a hassle that I decided to just leave it alone.

 

EDIT: I will admit that there may have just been something wrong with that particular map that I hadn't implemented properly back then, but now all my new maps I'm working on are either Doom or Boom format.

Share this post


Link to post
16 minutes ago, NecrumWarrior said:

EDIT: I will admit that there may have just been something wrong with that particular map that I hadn't implemented properly back then, but now all my new maps I'm working on are either Doom or Boom format.

Not much has changed about how water works in all that time, so it's really most likely that the map was broken to begin with. Do you still have it?

For me any old map that apparently broke is important to check the engine.

Share this post


Link to post
50 minutes ago, Graf Zahl said:

What map from 10 years ago does not work anymore?

Claustrophobia comes to mind (the "gut-spewing" room slows to a crawl in modern software ZDoom, the "spectre'd fireballs" attack that the final boss has is obscenely hard to see in GL).

Share this post


Link to post
23 minutes ago, Graf Zahl said:

Not much has changed about how water works in all that time, so it's really most likely that the map was broken to begin with. Do you still have it?

For me any old map that apparently broke is important to check the engine.

I'll do some research to see how water should be implemented properly and then see if what I have matches up. If it doesn't still then I'll give it over to you. I probably just did it wrong tbh, I recall it being something that I had a hard time figuring out back then.

Share this post


Link to post
20 minutes ago, Cynical said:

Claustrophobia comes to mind (the "gut-spewing" room slows to a crawl in modern software ZDoom, the "spectre'd fireballs" attack that the final boss has is obscenely hard to see in GL).

Neither of those seems like outright breaking - the latter of which just seems like an issue that comes naturally when playing something designed for a primitive renderer in a newer one ( see: fake reflective surfaces via sprites and textures that go "under" the floor that just get clipped in a renderer that uses more general-use 3D rendering ), while the former ... kinda stumps me. Just software, or does it affect hardware too?

Share this post


Link to post
2 hours ago, Graf Zahl said:

What map from 10 years ago does not work anymore?

People, if you are having issues with old maps and do not bother to report them, the issues cannot be fixed. Keep in mind: The only reason that you find old stuff stop working and nothing being done about it is because I cannot constantly play old maps and check for regressions. I wouldn't have time for anything else. Someone needs to tell me.

 

Also kb1 missed the point by a mile: It's not Boom format that's extremely stable, but the ports not advancing. Of couse stuff does not break if the code used to play it is vitually the same as it was 18 years ago. Boom format is just as prone to breaking as any other mapping format if some change in the engine makes it unintentionally behave differently.

 

Apparently, I didn't miss the point...cause you just reiterated it: People map for Boom because it's stable. That was the point - duh. You kinda breezed around all of my other points, though, especially about the point that it's not Boom/PrBoom/PrBoom-Plus's fault that advanced features are somewhat inhibited. It is because devs stopped caring about inter-port compatibility. So, what solution do you offer? "Port devs: Stop what you're doing and just use ZDoom!" There is no source-related upgrade path towards ZDoom features, short of replacing your entire source port's code with ZDoom code. Not much, anyway. That's great for ZDoom, but I want my new features to be done in a vanilla/Boom way: Using existing structures, using original formats, etc.

 

Of course, some advanced features require breaking the mold, and advancing existing setups, and ZDoom has provided one way of accomplishing those.

 

Now, without naming them, (it's kinda obvious and boring) there's some people on the forum that hear anything about ZDoom, and get unreasonably defensive, and argumentative, some of which have predictably shown their childish nature in this thread. Because of this, I have to repeatedly claim that it's ok that ZDoom has gone this route, as have other ports which might be labelled 'Advanced'. At the time advanced features were being conceived, there were no alternatives, so new lump types, new structures, new scripting techniques, etc., were built to support these new features. And, yes, many of them could have been done in a manner more compatible with the original source, and, more importantly, more compatible with other ports. Boom proves this.

 

Because Boom support can be easily added to most any source port, mapping for it guarantees compatibility. Because people are going to use different ports - there's no way around it - compatibility is important, as every programmer worth their salt should know.

 

So, to evolve, there must be collaboration, and synchronicity between port devs. You can't just add a feature, and expect all ports to follow. I believe the next standard would involve the following technologies/formats:

  • UDMF - This is the best vehicle for adding map-related features, by its nature of allowing custom properties.
  • "DECORATE-lite" as a thing definition language. DECORATE is easy to understand, and quite compact.
  • A new standard set of usable frames, thing slots, and sound slots, for DeHackers. Something like 40 frames and 5 sounds per thing, or so.
  • A small set of new generic codepointers.
  • An agreed-upon standard allotment of free/common enhanced linedef numbers, doomednum numbers, etc. For example, doomednum 5001 is commonly used for Player 5 - this should be discoverable by looking at an online wiki page, or something.
  • A standardized save format, and a standardized demo format, built with extensibility in mind.

If these advances could happen, we could up our standard set of features that would be available across all ports. To me, these types of features are really the features to devote most energy towards. I find it ridiculous that there are maps that ports cannot begin to try to load, because they cannot parse all of the custom lumps provided.

 

But, until that happens, people will continue to map in the most advanced format guaranteed to load virtually everywhere: Boom/MBF format.

 

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
×