Split from "Detecting automap?"

[Trance]

I feel that there is a bigger issue here that I've brought up a couple of times in other venues than this forum, for which I've gotten no satisfactory answer. Why should player convenience be given precedence over modder freedom when discussing potential features? Shouldn't the focus be on expanding the range of control a modder has over his or her custom content?

I mean, as a user playing a custom WAD made by someone else, if you hit something they've put in that you consider bad design, you can toss your copy of that WAD in the bin, and maybe even bring up something about it to the modders themselves. But why is it considered a valid argument here to reject a potential feature because "some people might turn it into something lame"? It seems to me that people who put forward this rationale are attempting to exert creative control over someone else's content (albeit content that doesn't yet exist). What's up with that? Am I missing some more reasonable case here?

[Gez]

Why should player convenience be given precedence over modder freedom when discussing potential features?

Because it's a sound policy that is less likely to result in massive screwups.

Shouldn't the focus be on expanding the range of control a modder has over his or her custom content?

You can switch to Chocolate Doom if you think ZDoom doesn't offer enough modding features.

But why is it considered a valid argument here to reject a potential feature because "some people might turn it into something lame"?

It's not "some people might turn it into something lame", it's "some people can use it to completely fuck things up". Go play some Terrywads and imagine how much worse they could be if they could, say, disable the menu system entirely ("waaah why can't I change the main menu or replace essential menus with non-functional clones?") or change settings ("waaaah why can't I have the Skulltag ConsoleCommand ACS function"), etc.

The Doom community is already full of judgmental pricks who think everybody should be playing Doom in the way that they, themselves, are playing and everything else is invalid. It's also full of people who obsess about their ideal ~~gameplay experience~~ in which the automap, savegames, brightness/gamma adjustment, fullscreen HUD, pause, quit menu, console, etc. etc. etc. are disabled because it's conflict with their ~~grand vision~~ for their mod.

You want to do that, you build your own executable, because that game ain't Doom anymore at all. ZDoom is a Doom engine game port first and foremost.

[Trance]

Because it's a sound policy that is less likely to result in massive screwups.

It's not "some people might turn it into something lame", it's "some people can use it to completely cake things up". Go play some Terrywads and imagine how much worse they could be if they could, say, disable the menu system entirely ("waaah why can't I change the main menu or replace essential menus with non-functional clones?") or change settings ("waaaah why can't I have the Skulltag ConsoleCommand ACS function"), etc.

So is anyone forcing you to play those Terrywads? Why is there this automatic assumption that the presence of such features will find their way into every WAD you want to play, in the worst way possible? What if someone has a brilliant idea for the use of a feature, but due to this "sound policy" they'll never get to put it into action because other people have decided in advance that nothing good can ever come of it?

The Doom community is already full of judgmental pricks who think everybody should be playing Doom in the way that they, themselves, are playing and everything else is invalid.

This statement can very easily be applied to both sides of the fence.

It's also full of people who obsess about their ideal ~~gameplay experience~~ in which the automap, savegames, brightness/gamma adjustment, fullscreen HUD, pause, quit menu, console, etc. etc. etc. are disabled because it's conflict with their ~~grand vision~~ for their mod.

Like I said, if the modder comes out with design features that you disagree with, you are well within your rights to toss your downloaded copy of their WAD in the trash and maybe submit a few choice words besides. But how is it a "sound policy" to disallow modders the chance to implement a feature in a decent, enjoyable way?

You want to do that, you build your own executable, because that game ain't Doom anymore at all. ZDoom is a Doom engine game port first and foremost.

Sorry, but I consider this argument utterly absurd. What, then, is the point of adding any features AT ALL if they're not features the Doom engine had in the first place?

[Hellser]

I'm sorry, Gez, with that attitude of yours.. It is like you're saying, "This is DooM, turn off that mouse look, extra features that we've added in. Infact, just go play the original doom/doom2.exe."

We modders want freedom to create our mods as we see fit. What if someone don't want to make a mod similar to DooM? What if someone wants to make a rogue-like game without a map for players to play? What if the player doesn't have a map -- having to get an automap item -- yet we have a TAB key which we can press at any time to look at the map.. against the modders' wishes?

There's a ton of possibilities. Most beneficial, some can be used destructive. Then again, any mod can be destructive, a

Code: Select all

Spawn:
TNT1 A 0
TNT1 A 1 A_SpawnItem("ItemHere") 
loop 

could be destructive. Why would a script detecting -- and disabling -- the automap would be abusive?

[FDARI]

@Trance: What you're bringing up there is probably not the main objection in this case. My main objection to making the automap state readable is that this information must then either be synchronized across the network, or accepted as a new means of desyncing multiplayer (and possibly demos; I don't know if they keep up with automap or not). If we add possible sources of desync, we add disclaimer requirements for zdoom features, and potential sources of error that must be investigated whenever anybody has a potentially related problem.

I would hate to have that in zdoom proper. There are some features of this kind already, and I cannot recommend their use -at least not in any other way than as explicitly described on their wiki page. While they could be used in any odd way, using them with any freedom at all increases the risk of inadvertently performing a change that breaks the networking model.

Ok, I have persisted enough on that. In this case it is probably possible to add features that can only be used in the intended way with no risk of desync. So I'd much prefer that.

---

- New feature should allow something that was previously impossible or simplify a valuable but ugly solution (using attacks with damagetype to trigger nearby actor pain-states as a "signal" is hacky, complex and inflexible; a_radiusgive can take its place in some scenarios, and is a huge improvement)

- The feature should be relevant for future use (not just some exceedingly odd project)

- The feature should ideally be easy to use correctly. Sometimes a complex feature needs redesign, other times it might just need good documentation/examples.

- The feature should not introduce a new way to break the game (cause an error that causes zdoom.exe to crash or hang).
--- Example: Dereference null-pointer. Any possibility of null-pointer crash is probably an engine bug, even if it is caused by mod-bugs; null pointers be detected and handled nicely. The feature itself is usually not to blame, since the engine bug can be corrected. Features that cannot be guaranteed to keep good references are not good features.
--- Example: Infinite loop (hang). When caused by loops in mod-code (decorate states with jump actions and state chains that loop without delay) it is just one of the things mod-code is able to do to break things. Can also be engine bug. Should not be able to occur during processing of a single action/feature. (That would be either a fixable bug, or a bad feature)
--- Example: Desync. If caused by fixable bug, ok. If caused by simulating over local information, it is probably not worth sharing the relevant information over the network, but the possibility is there.

- Some features should be very focused on the problem at hand. (Automap hiding for hudmessage.)
- Some features should be very adaptable. (A_Look, A_CustomMissile, A_Warp.)


To me, zdoom can be whatever we want it to be, but its roots in Doom are significant. If there's no Doom left... Why use it? Well.

The doom aspects that seem most... indispensable - the stuff I use zdoom for - what is that? Hm. I like the map editing. I'm not good, but I think the doom solution is excellent for just about any task that it is fit to accomplish at all. And I'd never bother to help anybody make it anything but a first-person-something. The chasecam and various camera actors let you do it if you must, but zdoom excels as FPS. Most other things could better be done elsewhere. I also feel that it has a good combat base.

I would never bother to let a modder disable some feature for purposes of style. Disabling automatic behaviours because they mess with a particular style of gameplay might be worthwhile (restart from most recent save upon death, whenever that occured, has proven unfortunate in some circumstances). Preventing cheats with zdoom is pointless. You never really get to the point where your intentions cannot be ignored.

This is a very open picture of zdoom, with room for a wild array of features. Most are along the lines of (A) More flexible / explicit ways to manipulate actors (where they spawn, how, what they collide with, where they move, what boundaries hold them back), or (B) More powerful ways to identify/access/manipulate specific actors, or manage information. Aside from that, better ingame menus/dialogues, better ways to present information/details that aren't necessarily integral to the FPS experience... Many such features can be approximated with extensive ACS. Not ideal.

Perhaps a flag for hudmessage not to render it if the automap is up? That way, the modder code never has to know whether or not the automap is there.

Already suggested... it would have rendered this thread/issue nonexistant if such a thing were possible...

Maybe I can manage.

[Trance]

@Trance: What you're bringing up there is probably not the main objection in this case. My main objection to making the automap state readable is that this information must then either be synchronized across the network, or accepted as a new means of desyncing multiplayer (and possibly demos; I don't know if they keep up with automap or not). If we add possible sources of desync, we add disclaimer requirements for zdoom features, and potential sources of error that must be investigated whenever anybody has a potentially related problem.

I would hate to have that in zdoom proper. There are some features of this kind already, and I cannot recommend their use -at least not in any other way than as explicitly described on their wiki page. While they could be used in any odd way, using them with any freedom at all increases the risk of inadvertently performing a change that breaks the networking model.

Again, though, that's something that would be up to the modder to use in a responsible way. You say yourself that there are already features capable of desyncing multiplayer in the same potential way; how often are these features abused in a way that breaks the game versus the way they've been used in a safe and even clever way? It should just be a simple matter of warning modders of the potentially harmful effects of using the feature in the wrong way. If a modder chooses to implement it badly in their WAD, well, it will be panned by the playerbase as crap.

[edward850]

The issue is that you are suggesting that there should be more features that could collect information that is outside of zdoom's gamestate. What next? Get_SystemTime()? You just can't keep adding these sorts of things.

[Trance]

Automap information is not the same as system time; that's a pretty weak argument to make. It's information that exists entirely inside the game. We've already got features that deal with information outside the gamestate, and I've not seen those features turning the WAD landscape into a sea of feces. Why can't modders be trusted to use these features responsibly?

[edward850]

It's information that exists entirely inside the game.

Engine, not game.
Record a game, and during so, open the automap. Watch as when you play back the demo, the automap doesn't open.

[Trance]

Yeah, the posts discussing the second track should be moved into their own thread. I apologize for moving the thread off-track, but it WAS a topic that got me thinking about a bigger point of contention.

Engine, not game.
Record a game, and during so, open the automap. Watch as when you play back the demo, the automap doesn't open.

Okay, engine. That doesn't alter my argument.

[FDARI]

For the automap-specific discussion, let us hope that one of us code-savvy people get around to the hudmessage-feature-suggestion; it is a decent solution if it can be made.

Again, though, that's something that would be up to the modder to use in a responsible way. You say yourself that there are already features capable of desyncing multiplayer in the same potential way; how often are these features abused in a way that breaks the game versus the way they've been used in a safe and even clever way? It should just be a simple matter of warning modders of the potentially harmful effects of using the feature in the wrong way. If a modder chooses to implement it badly in their WAD, well, it will be panned by the playerbase as crap.

I disagree. You say we might as well have another. I say it is bad enough that we have one. You don't build your engine with features that break. Come to think of it, one of my favourite things about zdoom is that it is so brilliantly robust. Every game session is self-contained, every save-game is complete, every tick is deterministic (given particular input). Other engines break a little here and a little there, fail to clean up on loads and new games, act differently because it's not the same time of day... They don't have it. Anything I have tried so far loses to zdoom in this respect.

[Trance]

I disagree. You say we might as well have another. I say it is bad enough that we have one. You don't build your engine with features that break. Come to think of it, one of my favourite things about zdoom is that it is so brilliantly robust. Every game session is self-contained, every save-game is complete, every tick is deterministic (given particular input). Other engines break a little here and a little there, fail to clean up on loads and new games, act differently because it's not the same time of day... They don't have it. Anything I have tried so far loses to zdoom in this respect.

I don't really see this viewpoint as being that different from "people are just going to use this feature in a [censored word] way that makes it unfun". If a modder is properly educated on the safe use of a feature, shouldn't they be allowed to use it? My guess is that those other potentially game-breaking features were added in because of their creative potential to modders. Shouldn't that potential count for something when considering new features?

[FDARI]

Invariants. Reliable truths. Anything design principle that is 100% true provides a useful invariant that makes the engine easier to develop and debug. If there were no simulation (shared between players) features that depended on local conditions (unique to each player) at all, then you could say with certainity that desync errors are not "by design" (since the possibility of desync is not part of the design). We have already lost that one, but in a way that will hopefully not be widely applied. The more deviations there are, the more variants we have to look for. I investigate many errors in my work, and believe me, you'd call it a crime to abandon good design principles. If you break your invariants, you need to track your minutiae. A strong design can allow all pertinent details for a problem to be delivered in a few lines. If you have inconsistencies, you need to know each and every one of them, and everything they might possibly tie into. It is unfortunate that zdoom is not at 100% in this regard. I will not support the notion that we should throw it away. Fork it, outdo "Tower of Babel" (liberal implementation policy, but about as reliable as zdoom) and have your very own "Unbridled Doom" (anything goes, everything comes down to the modder). I wouldn't want to work on it (or mod for it), but there are people here who might.

[Gez]

I'm sorry, Gez, with that attitude of yours.. It is like you're saying, "This is DooM, turn off that mouse look, extra features that we've added in. Infact, just go play the original doom/doom2.exe."

That is exactly what I don't want mods to do.

We modders want freedom to create our mods as we see fit.

And developers want freedom to design their port as they see fit.

My freedom to swing my fist around is limited by your freedom to keep your face unpunched. Likewise, the freedom of modders is restricted when it comes to removing player freedoms. Maybe that could change the day there are more modders than players; since that'd be the day not even the mod authors would play their own mods anyway.

What if someone don't want to make a mod similar to DooM?

Then support for that mod is a low priority as far as a Doom-and-co port is concerned.

Seriously, it's nice and cool that completely different games can be made with ZDoom; stuff like Action Doom 2 or Rat Solitaire. But they aren't the point of the port. They're a bonus. ZDoom wasn't created so that one day it'd be possible to play Klondike with giant cards; the aim was to make a cool Doom port which would also allow to play Heretic, Hexen, and even Strife, and add some cool new features for players and modders. Eventually, enough features got added that completely undoomlike gameplay became possible; but that's a side effect and not a design goal.

What if the player doesn't have a map -- having to get an automap item -- yet we have a TAB key which we can press at any time to look at the map.. against the modders' wishes?

Then maybe the modder ought to know a bit more about the engine before coming up with ideas. It's easy: Doom. Press tab for automap. Been like this since 1993. The modder has had twenty years to learn that factoid.


The problem isn't so much the ability to obscure the automap or not. The problem is mostly that there are always some people to shout "help, help, I'm being oppressed" whenever a feature suggestion is denied. Even if arguments beyond just respecting the players are used (e.g., automap-ACS leading to netgame desyncs).

[Trance]

Here's the discrepancy, though. Unlike general application design, where there are two tiers of people involved (developers and end-users), in a game engine like ZDoom there are three distinct tiers: developers, end-users, and the tier in-between: content creators. The developers create and bugfix the engine features available to the content creators, and the content creators make use of those features to create enjoyable experiences for the end-users. From my perspective, it is not the purview of the developer to ignore the content creation tier and make content-related design decisions for the end-users. It should be the modder's job to utilize the tools available to them in a safe and effective way to make the game experience they want to make. If it turns out to be an unplayable mess, that's the fault of the modder, and results in a mod's rejection by the end-users.

I don't like the idea that developers should be paying attention to the end-user's comfort level with custom mods, and rejecting features to protect them from bad mods. It's just unnecessary restriction of creative potential.