by 3saster » Thu Feb 20, 2020 2:53 pm
The line about the non-Doom iwads is not quite true, in particular with regards to Heretic, Hexen, and Strife. The only major ports that support those 3 are GZDoom, Zandronum, and Chocolate Doom. Because of that though, people are far more liberal with making mods/maps for them that use GZDoom/Zandro features, because 99% of people are gonna be playing it on those 2 ports anyway.
The PrBoom section is VERY outdated. No one uses PrBoom these days, they use its far more modern version
PrBoom+. PrBoom+ is the most advanced vanilla-compatible, supporting Doom, Limit-removing, Boom, and MBF. The differences between GZDoom and PrBoom+ are greater than you suggest (the physics in particular), but it won't matter to most non-purist people. The spider mastermind is killable in 1 shot in vanilla, but it is rare and doesn't happen often. As far as modding goes, PrBoom+ basically only has DEHACKED, which really doesn't cut it for advanced gameplay mods. Its main purpose is for demo-recording and vanilla compatibility and behaviour. Compared to the other options you mentioned, it is primarily a port for relatively vanilla maps, and is not well-suited at all for advanced gameplay mods.
You may want to mention LZDoom near GZDoom, just as an aside. It is a fork of GZDoom whose ZScript capabilities are fairly close to what GZDoom has. The main difference is a renderer that will run on much older hardware, the aside is that for that reason, it will not be able to do some of the most advanced rendering based stuff. In the same boat, there is ONE reason to use GZDoom Builder Bugfix; Ultimate Doom Builder needs OpenGL 3.3, so if you are using very old hardware that can't run it (the same kind that would use LZDoom), you would use GZDB-BF.
Your comment that Doom format "will run on anything starting with MS-DOS" is not quite true. True vanilla doom (chocolate) has some very strict limitations that can easily be broken (visplane error for instance). Basically every modern port other than Chocolate Doom is limit-removing though, so that isn't a huge deal in the context of this document.
Your comment on the Boom map format is not quite right. This is not a PrBoom specific format, this is a mapping format that is supported by a large chunk of ports. It does offer some MAJOR additions over Doom format (in particular, voodoo doll scripting is the big one). The main reason to use this is it's the most advanced format that's supported by most ports. It's also good for the same reason you suggest Doom format; it largely functions as an extension of Doom format (same thing with line specials, etc.), so once you understand how Doom format works, you can upgrade to Boom with little difficulty. By comparison, UDMF has lots of new stuff that is fundamentally different.
One thing worth mentioning earlier is that PK3 is actually just a ZIP file. As in, you can pack a folder by just zipping it using 7-zip or whatever and renaming the extension to .pk3. Also, when using a folder, if you don't like the command line, you can actually just drag-and-drop the folder over gzdoom.exe.
In the scripting component, it's worth mentioning that one of the main reasons to use DEHACKED is for relatively minor gameplay additions to non-UDMF maps (some basic additional monsters is a very common use case). However, indeed, as you mentioned, for gameplay mods, or if you want to create something that isn't reusing Doom's actions, there is very little reason to use DEHACKED. The main use case of DEHACKED is the same reason as Boom map format; it's the most advanced scripting component that is supported by most ports. If someone really is interested in DEHACKED, Doomworld would be a much better place to point them to.
As a trivia section for ZScript, it may be worth mentioning that is modelled after UnrealScript, from the original Unreal Engines (one of them anyway). That is the reason for some of the weirder differences, like the default blocks. Randi really like UnrealScript
One thing worth mentioning is what ACS is. In the context of GZDoom, this is meant for map-scripting. As such, one would learn more about that in a mapping tutorial than a scripting tutorial. You probably don't need to go into too much detail for that reason, but I think it's important that users know what it is. In Zandronum however, this is used to do the advanced stuff DECORATE can't, and adds a lot to the spaghetti mess when doing anything advanced.
The line "DECORATE results in overly long and hard to read code, while ZScript is much cleaner" is not always true, but will get true very quickly if you try to do anything more than just defining basic, Doom-style monsters.
The line "Your code will also likely run faster than DECORATE" is misleading. I don't believe ZScript is inherently faster than DECORATE; however, related to the last point, you don't have to fiddle around with hacks (like giving actors inventory items to do conditionals), and that would be what causes the speed increase.
All-in-all though, a decent starting document. It's rather obvious that this is written by someone who is biased against the vanilla source ports, and vanilla mapping/modding. Thankfully, this doesn't change the document too much in the important areas, because for gameplay mods, the non-ZDoom ports are very poorly suited for that. If this was a mapping starter instead of a mod starter, I would have gotten on your ass far more
The line about the non-Doom iwads is not quite true, in particular with regards to Heretic, Hexen, and Strife. The only major ports that support those 3 are GZDoom, Zandronum, and Chocolate Doom. Because of that though, people are far more liberal with making mods/maps for them that use GZDoom/Zandro features, because 99% of people are gonna be playing it on those 2 ports anyway.
The PrBoom section is VERY outdated. No one uses PrBoom these days, they use its far more modern version [url=https://doomwiki.org/wiki/PrBoom%2B]PrBoom+[/url]. PrBoom+ is the most advanced vanilla-compatible, supporting Doom, Limit-removing, Boom, and MBF. The differences between GZDoom and PrBoom+ are greater than you suggest (the physics in particular), but it won't matter to most non-purist people. The spider mastermind is killable in 1 shot in vanilla, but it is rare and doesn't happen often. As far as modding goes, PrBoom+ basically only has DEHACKED, which really doesn't cut it for advanced gameplay mods. Its main purpose is for demo-recording and vanilla compatibility and behaviour. Compared to the other options you mentioned, it is primarily a port for relatively vanilla maps, and is not well-suited at all for advanced gameplay mods.
You may want to mention LZDoom near GZDoom, just as an aside. It is a fork of GZDoom whose ZScript capabilities are fairly close to what GZDoom has. The main difference is a renderer that will run on much older hardware, the aside is that for that reason, it will not be able to do some of the most advanced rendering based stuff. In the same boat, there is ONE reason to use GZDoom Builder Bugfix; Ultimate Doom Builder needs OpenGL 3.3, so if you are using very old hardware that can't run it (the same kind that would use LZDoom), you would use GZDB-BF.
Your comment that Doom format "will run on anything starting with MS-DOS" is not quite true. True vanilla doom (chocolate) has some very strict limitations that can easily be broken (visplane error for instance). Basically every modern port other than Chocolate Doom is limit-removing though, so that isn't a huge deal in the context of this document.
Your comment on the Boom map format is not quite right. This is not a PrBoom specific format, this is a mapping format that is supported by a large chunk of ports. It does offer some MAJOR additions over Doom format (in particular, voodoo doll scripting is the big one). The main reason to use this is it's the most advanced format that's supported by most ports. It's also good for the same reason you suggest Doom format; it largely functions as an extension of Doom format (same thing with line specials, etc.), so once you understand how Doom format works, you can upgrade to Boom with little difficulty. By comparison, UDMF has lots of new stuff that is fundamentally different.
One thing worth mentioning earlier is that PK3 is actually just a ZIP file. As in, you can pack a folder by just zipping it using 7-zip or whatever and renaming the extension to .pk3. Also, when using a folder, if you don't like the command line, you can actually just drag-and-drop the folder over gzdoom.exe.
In the scripting component, it's worth mentioning that one of the main reasons to use DEHACKED is for relatively minor gameplay additions to non-UDMF maps (some basic additional monsters is a very common use case). However, indeed, as you mentioned, for gameplay mods, or if you want to create something that isn't reusing Doom's actions, there is very little reason to use DEHACKED. The main use case of DEHACKED is the same reason as Boom map format; it's the most advanced scripting component that is supported by most ports. If someone really is interested in DEHACKED, Doomworld would be a much better place to point them to.
As a trivia section for ZScript, it may be worth mentioning that is modelled after UnrealScript, from the original Unreal Engines (one of them anyway). That is the reason for some of the weirder differences, like the default blocks. Randi really like UnrealScript :P
One thing worth mentioning is what ACS is. In the context of GZDoom, this is meant for map-scripting. As such, one would learn more about that in a mapping tutorial than a scripting tutorial. You probably don't need to go into too much detail for that reason, but I think it's important that users know what it is. In Zandronum however, this is used to do the advanced stuff DECORATE can't, and adds a lot to the spaghetti mess when doing anything advanced.
The line "DECORATE results in overly long and hard to read code, while ZScript is much cleaner" is not always true, but will get true very quickly if you try to do anything more than just defining basic, Doom-style monsters.
The line "Your code will also likely run faster than DECORATE" is misleading. I don't believe ZScript is inherently faster than DECORATE; however, related to the last point, you don't have to fiddle around with hacks (like giving actors inventory items to do conditionals), and that would be what causes the speed increase.
All-in-all though, a decent starting document. It's rather obvious that this is written by someone who is biased against the vanilla source ports, and vanilla mapping/modding. Thankfully, this doesn't change the document too much in the important areas, because for gameplay mods, the non-ZDoom ports are very poorly suited for that. If this was a mapping starter instead of a mod starter, I would have gotten on your ass far more :P