Freedoom 0.7 discussion

[chungy]

It's probably best to hear from any potential mappers to get an idea of what to target. How many people are willing to contribute to Freedoom, and how many of those would be deterred from vanilla limitations? If it is a significant number, how many of those feel that targeting limit-removing ports is a good compromise, or wish to keep the Boom target?

Any other discussion is really just thinking hypothetically...

[myk]

Esselfortium, your post screams "me, me!". I mean it because of the over-empahsis ("this is a really bad idea" "tons of good mappers would not join") and by the way you end it. You also add irrelevant arguments about vanilla quirks that don't work in some OpenGL engines. Doomsday actually aims to support those, but in any case, who said the tricks were necessary?

You're not addressing the fact that Feedoom's core levels wouldn't work with vanilla engines, and just because some people wouldn't map for it, it doesn't mean the community wouldn't output 60 quality vanilla levels even before the resources were done. There are also mappers who would stay away from it if it weren't vanilla compatible, anyway.

In fact, if you want to guarantee attracting a consistent amount of good mappers that tend to stay strictly away from vanilla, you'd have to make it for something more advanced than Boom, probably ZDoom or GZDoom. Your own arguments are hinting this. Or Eternity, perhaps, although that would be rather experimantal, as it's unclear how popular it will become at this point.

MikeRS said:
That's rather pessimistic, I'd think it's not quite as true as you think... and even if it were true, it'd just strengthen the case for Chocolate Doom (the article is about UI simplicity, of all things). Either that, or you can name a port where the advanced options are hidden away in a console, and keep the basics available in the UI.

Good points. Besides, I get the impression the issue with documentation is also related to the fact that it often just sucks. Programmers write source code. There's no guarantee that they're going to write useful documentation as well. When the documentation is absent or lame, it's no wonder people stay away from it (even more). It's often necessarily eventually anyway. Explanations always are, or there would be little use for "customer support", which is a big part of providing a software product or a service.

[chungy]

NiGHTMARE said:

Actually, there are several vanilla editing tricks that don't work properly in Doomsday (3D bridges for example), due to it's hardware renderer nature. And it's not a bug, it's a feature :P.

It's my opinion, my current argument, that Freedoom should try to be as port-agnostic as possible, thus the vanilla target. If ports (like Doomsday) are intentionally incompatible with vanilla, that's their own fault, the Freedoom project doesn't need to go out of its way to cater to port-induced limitations. The OpenGL rendering doesn't really need to stop them, PrBoom handles many of the rendering tricks just fine in its GL mode, for example. I'm not even talking about going out of the way to use vanilla tricks to their fullest; just whatever it takes for mappers to make their best effort.

It's *POSSIBLE*, sure, but how much effort will it be, and how long will it take to achieve? Clearly it was difficult enough to attract people who were willing and capable of making good quality maps in the first place... so imagine how hard it's going to be when you reduce the number of mappers willing to participate to the project by half (or more). And that's not even counting the number of maps you're going to have to reject on the basis of quality level.

fraggle informed me that the contributions to Freedoom dropped severely after the move to SourceForge, when he could no longer make daily builds, and the contributors could no longer see the fruit of their labor in the same day as submission. I can't guarantee anything, but hopefully new daily builds would subdue this discouragement; Jon's already setup a cron job for uploading daily builds now (although there's no real changes, yet).

Seriously, the number of skilled mappers who still work within vanilla limitations is almost certainly in the single digits.

I think the only realistic way to get 32/36 top quality vanilla-compatible levels -- without having a tiny handful of people spend years upon years upon years working on them -- is to mine the archives for the best vanilla-compatible levels which grant permission to be re-used and modified (and which don't use modified propietary resources, or at least none that can be replaced).

Given the fact that the number of contributors to Freedoom hasn't gone over 2 in the last few months/years, the number of potential mappers isn't really discouraging me. This isn't like your typical megawad either that's all done in the shadows, all the current work is always going to be public :)

As for mining the archives, this is an interesting idea, certainly worth thinking about, though I would personally prefer new work rather than recycled work.

So you're even going to dump those Freedom levels which are high quality (such as MAP07)? Now that really is unncessary extra effort :(.

Well, there's no idea currently... I believe Cato is actually doing some work in downgrading the current levels, but I'm not sure what he's done so far.

[esselfortium]

myk said:

Esselfortium, your post screams "me, me!". I mean it because of the over-empahsis ("this is a really bad idea" "tons of good mappers would not join") and by the way you end it. You also add irrelevant arguments about vanilla quirks that don't work in some OpenGL engines. Doomsday actually aims to support those, but in any case, who said the tricks were necessary?

I stated my case strongly because I strongly feel that it's a bad idea.

Organizing 32in24s with Shaikoten, we've discovered time and time again that the more limits we place on mappers, the fewer people are interested in contributing to it. Interestingly, even doing a ZDoom project as an experiment (rather than our usual aim for Boom compat) didn't see nearly as much participation as usual.

I don't think I said anything about OpenGL or vanilla quirks, though. o_O I think you might be mixing up my post with part of NiGHTMARE's.

You're not addressing the fact that Feedoom's core levels wouldn't work with vanilla engines, and just because some people wouldn't map for it, it doesn't mean the community wouldn't output 60 quality vanilla levels even before the resources were done. There are also mappers who would stay away from it if it weren't vanilla compatible, anyway.

In fact, if you want to guarantee attracting a consistent amount of good mappers that tend to stay strictly away from vanilla, you'd have to make it for something more advanced than Boom, probably ZDoom or GZDoom. Your own arguments are hinting this. Or Eternity, perhaps, although that would be rather experimantal, as it's unclear how popular it will become at this point.

I don't see how mapping for what's essentially the definitive standard and is supported by nearly every port that's used today is remotely comparable to limiting it to any other port. The Community Chest series has been successful in Boom format, as have the 32in24 series and many other megawad projects.

It's an admirable goal to aim for a full set of maps with compatibility with every existing Doom engine, but achieving that full set of maps becomes much more difficult as you tighten the limits.

Boom mapping is nice because it's scalable, so to speak: it's possible to make a Boom-compatible map that could also potentially run in vanilla (with the mapper not needing to learn anything new, even), while at the same time being possible to create much more than that.

Is it more limited than, say, ZDoom? Sure it is, but when you get to that point you could also say other ports are more limited than Quake, and so on from there. Boom, or even limit-removing, is a good compromise that's been proven to work with successful projects from the time of Boom's creation to today. It's powerful enough to allow for a lot of originality and ease of use, while still being similar enough to limit-removing or vanilla mapping that it can be easily picked up by someone who hasn't worked with it before.

[Creaphis]

With my earlier comment, "Freedoom could be packaged differently for different people," I wasn't really thinking that there should a whole line of releases (eg. Freedom for Noobs, Freedoom Elite, Freedoom Home Premium). My meaning was this: while Freedoom could be packaged with mature, technically-inclined gamers and current Doomers in mind, it makes more sense to package it in such a way that can be appreciated by people outside of our tiny sphere. If you package Freedoom with Chocolate Doom, members of the general game-playing public will see massive pixels and will turn the game off. They won't go looking for "something better" because they've already found it, and it's called Gears of War 2 or Dead Space or whatever is popular at the moment. You have one chance to impress somebody, and someone who doesn't immediately like what they see won't go out of their way to see if they like Freedoom on another engine - and that's the people who will understand the concept of "source port."

I don't mean this as any offense to fraggle's work - I love Chocolate Doom, but that's because I'm already a Doomer.


Also, with all the community projects that Essel has administrated, I think his statements on the preferences of mappers hold some weight.

[andrewj]

I suggest shipping FreeDoom with a minimal fork of ChocoDoom which removes the worst limits, especially visplane overflow and openings limit. That will keep mappers happy.

I volunteer to maintain such a minimal fork.

Regarding tricks (fake bridges etc), I think they should be avoided, there's not much novelty in them anymore.

EDIT: wanted to reply to Creaphis's post. No doubt some people would be turned off by the low resolution. However FreeDoom is not about matching contemporary games. All the resources (Textures etc) are going to be much lower resolution compared to modern games, and nobody is suggesting it should be otherwise -- that would be an entirely different project I think.

[LexiMax]

esselfortium said:

I stated my case strongly because I strongly feel that it's a bad idea.

Organizing 32in24s with Shaikoten, we've discovered time and time again that the more limits we place on mappers, the fewer people are interested in contributing to it. Interestingly, even doing a ZDoom project as an experiment (rather than our usual aim for Boom compat) didn't see nearly as much participation as usual.

The maps only have to be made once, and in return we get an IWAD that works on any number of potentially ridiculously incompatible source ports now or in the future. Again, it's an IWAD replacement a totally new base game, not just a "total conversion", you can't make the same kinds of assumptions of how it'll be played (or in freedoom's case, used.).

And why are the limits any issue. If a mapper is constantly running into them, perhaps they're thinking too large-scale. ID somehow managed to make all of Doom and Doom 2 within those limitations, and I doubt Freedoom is supposed to be the second coming of Eternal Doom in complexity, so why not simply tone down your architectural complexity? Do you really need those extra drop shadows? Does the fourth level really need to utilize all three keys? Does the fourteenth? I'd personally be happy with maps with scythe-like scale, honestly.

[Nuxius]

I would suggest talking to entryway and seeing if he can make a special version of Doom+ and Doom2+ that adds high resolution support. Many of the limits have already been extended for those ports, but the options are the same as vanilla Doom's.

[esselfortium]

Nuxius said:

I would suggest talking to entryway and seeing if he can make a special version of Doom+ and Doom2+ that adds high resolution support. Many of the limits have already been extended for those ports, but the options are the same as vanilla Doom's.

Considering that Doom+/Doom2+ are actually made from hacking the compiled EXEs, making the game run at a different resolution would probably be...rather difficult, to say the least. Even if you're not taking into consideration stuff like scaling the menu/hud graphics to fit the increased screen size, instead of all showing up somewhere in the upper left or having a lot of odd space between them. A fork of chocodoom would work better with much less work. :p

[chungy]

Creaphis said:

If you package Freedoom with Chocolate Doom, members of the general game-playing public will see massive pixels and will turn the game off. They won't go looking for "something better" because they've already found it, and it's called Gears of War 2 or Dead Space or whatever is popular at the moment.

These people wouldn't be running Freedoom no matter what port it is anyway. At best, you can do Doomsday with Quake 3-era graphics, but it's just not enough to cater to the "graphics are everything" crowd.

AlexMax said:

And why are the limits any issue. If a mapper is constantly running into them, perhaps they're thinking too large-scale. ID somehow managed to make all of Doom and Doom 2 within those limitations, and I doubt Freedoom is supposed to be the second coming of Eternal Doom in complexity, so why not simply tone down your architectural complexity?

This is probably the best argument for vanilla I've seen. You don't need tons of fancy features just to make a good game.

Nuxius said:

I would suggest talking to entryway and seeing if he can make a special version of Doom+ and Doom2+ that adds high resolution support. Many of the limits have already been extended for those ports, but the options are the same as vanilla Doom's.

Not an option. Only free engines can even be considered, not even mentioning that it'd be good to use something that doesn't require DOSBox and a beefy computer.

[myk]

esselfortium said:
Organizing 32in24s with Shaikoten, we've discovered time and time again that the more limits we place on mappers, the fewer people are interested in contributing to it. Interestingly, even doing a ZDoom project as an experiment (rather than our usual aim for Boom compat) didn't see nearly as much participation as usual.

How many mappers you'll attract is hardly the only thing to consider. The point was made that the community has a lot of mapping power, compared to resource making power. You'll be able to make dozens of Boom compatible 32in24 add-ons geared towards Freedoom anyway, but we're talking about the base files of the project.

I don't think I said anything about OpenGL or vanilla quirks, though. o_O I think you might be mixing up my post with part of NiGHTMARE's.

Yeah, sorry about that one :p

The Community Chest series has been successful in Boom format, as have the 32in24 series and many other megawad projects.

Various vanilla projects have also been very successful. Practically anyone plays a good vanilla WAD. My point above is that the ones that don't probably won't play a plain Boom WAD either. But what about all the vanilla fans? (They exist because of engine idiosyncrasies.)

Boom mapping is nice because it's scalable, so to speak: it's possible to make a Boom-compatible map that could also potentially run in vanilla (with the mapper not needing to learn anything new, even), while at the same time being possible to create much more than that.

That argument is totally bent towards the act of making a level. Playing is different; there are people that enjoy the simplicity of Doom and the basic engines that run it. If half the levels have Boom stuff that is gone. And if half are Boom levels and the other half are vanilla they'll contrast, making the WAD less consistent.

[esselfortium]

myk said:

That argument is totally bent towards the act of making a level. Playing is different; there are people that enjoy the simplicity of Doom and the basic engines that run it. If half the levels have Boom stuff that is gone. And if half are Boom levels and the other half are vanilla they'll contrast, making the WAD less consistent.

Ehh, I'm not sure if that'd be as noticeable as you say it is. IIRC some of the FreeDoom maps are already in a more classic-ish style than others, and a mapper who's mostly experienced with vanilla submitting something to a Boom project would probably be unlikely to make something drastically different than their vanilla maps, even if they're technically made for Boom.

In a community-made project, even one for vanilla, some maps are more detailed-looking than others, so the main difference if vanilla mappers submit something to a Boom project is that certain maps would be missing such things as turbo or slow doors, basic voodoo-scripted events, etc. that not all Boom (or other sourceports, for that matter) maps make use of anyway. IMO it's unlikely that the maps made specifically for Boom would turn out as Phobos: Anomaly Reborn: Redux, so the contrast would probably not be bad, if it was noticeable at all :)

[myk]

You're only answering to the last sentence there, not the whole point. But it does have an effect when you're trying to pull off a project with consistent feel and play. In projects like the CC WADs or even 32in24 it might not matter because the point is mainly showcasing different authors or producing quick and fun sets. If you want a stronger creative design you need to set some standards to follow based on some central ideas.

[Creaphis]

MikeRS said:

These people wouldn't be running Freedoom no matter what port it is anyway. At best, you can do Doomsday with Quake 3-era graphics, but it's just not enough to cater to the "graphics are everything" crowd.

You're polarizing the population at large into the two groups of "people who will like Freedoom" and "people who could not possibly like Freedoom no matter what" and I really don't think it's that simple. There ARE people who would enjoy playing Freedoom in a simple high-res port, appreciating its visual simplicity, who would find the blockiness of Chocolate Doom simply too painful on the eyes.

[boris]

NiGHTMARE said:

So you're even going to dump those Freedom levels which are high quality (such as MAP07)? Now that really is unncessary extra effort :(.

Heh, I just tried MAP07 in Chocolate Doom and it VPO's. I'd never have thought that, it's not even big and overly detailed.

[Catoptromancy]

boris said:

Heh, I just tried MAP07 in Chocolate Doom and it VPO's. I'd never have thought that, it's not even big and overly detailed.

I liked map7 enough I managed to make a vanilla version. Sadly much detail is missing without touching gameplay.

Many maps actually play fine on choco, there just may be a boom linedef or 2 that keeps map from being beaten. Vanilla compat might just mean a door moves slower or something similar.
Some maps crash choco like map01, removed the green fog and made it nearly vanilla compat with just one edit.

I guess boom support would be ok. To keep it more distant from the original id iwad. But av and hr2 have proved that boom is not needed for great maps.

[Csonicgo]

can there be two versions of these maps? one for boom (as an add-on PWAD), and one for vanilla? I don't want the good Boom maps lost. :(

[Catoptromancy]

None of the maps will disappear.

[Catoptromancy]

What about a freedoom-lite? Something with medium to small vanilla maps just like the original id maps, in case someone feels like porting a port to their calculator or something. Would be fully vanilla compat.
The standard freedoom will keep boom.

Someone mentioned voodoo doll scripting. I think maps should be fully coop playable, voodoo doll scripting breaks every multiplayer port. Other than that I think more boom features should be used.

[chungy]

The people seem to have spoken in the other poll: Boom compatibility will remain the current target for the foreseeable future. Of course anyone can maintain a fork, but you're better off just making a new megawad.

Now that issue's settled, maybe we can discuss other areas. :-)