Thoughts on ZDoom/GZDoom derivative not based on Doom?

[Caligari87]

I asked in another thread about the possibility of re-writing ZDoom's physics code since it's apparently kind of a mess, and was understandably met with a [no]. This got me thinking, however. One of the things that draws me to Doom modding is the simple tools and quick prototyping.

- UDMF is extensible and modern
- The line/sector paradigm is a cinch to think in despite not offering "true" 3D
- DECORATE is quick and easy to create various items with
- ACS is simple enough for even a programming novice to learn
- Lump-based editing is also quite simple and intuitive. PK3s/ZIPs are a great format to work in.

Why not take all these things, but divorce them from everything that makes Doom outdated and difficult to work with? Right off the top of my head, there's a ton of drawbacks to the current state of the engine.

- For levels, the old BSP column/flat design is limiting, and even with GZDoom's enhancements, things like floor decals are still not feasible.
- The current sound engine needs to be purged to make the engine GPL-compatible and allow commercial use (which I understand may be in progress).
- Non-square pixels/mapunits are used, making "realistic" mods difficult without some sort of real-world analog.
- AI is tied to archaic enemy behaviors with little extensibility.
- Dialog is based on the Strife format, which I personally still have trouble wrapping my head around.
- Modern features like dynamic point/directional/shadow-casting lights are unrealistic for the rendering engine, which is still stuck half-way in the 90's

Granted, this would be an incredibly complex and time-consuming undertaking. I'm a novice programmer (I'd offer my own skills if I knew C/C++ at all) and the thought makes me shudder. Still, I wonder if there would be any interest in "rebuilding" the mod-friendly features of ZDoom/GZDoom into a more modern, simple, and fun "generic" game engine, without needing to keep compatibility with Doom itself, and get rid of all the archaic detritus that keeps it from moving forward?

[BouncyTEM]

I know I would love to see this. I've felt this should've been done with zdoom/gzdoom [probably gzdoom, opengl opens up more options] eons ago.

[Nash]

The problem is no one is interested in making a Doom engine non-Doom. Anyone who wants to make something non-Doom will have to resort to source mods.

[Blzut3]

I have thought about how useful a modern 2.5D game engine might be. I'm not sure if the premise of supporting all of ZDoom's script types in such an engine would be ideal. DECORATE for example is an easy to use language because it's specifically made to match how things are structured in the Doom engine (Wolf3D uses very similar structures if you want to point at ECWolf). I'm sure there are plenty of things in DECORATE that you wouldn't want to do if you wanted a truly modern engine. For example, I don't think it's normal for action functions to be called by the animation system, especially in regards to state jumps.

Not having much experience with newer engines, I can't say for sure of course, but the point is that the premise of using the same domain specific languages could bring in more Doomisms then you think.

[Graf Zahl]

I'd have to agree with Blzut3. It's not that simple. There's so many things that'd have to be changed that in the end not much would be left of the things you might consider useful.

[JPL]

A better approach would probably be to build a modern 2.5D engine from scratch, using Doom's things/verts/lines/sectors world representation and editing paradigm with UDMF maps, simple text-based data formats a la DECORATE, an embedded scripting langauge (Lua, Python, whatever - ACS is cool but its design has been very accretive only because of compatibility with Doom), and archive-based resource access (PK3s are after all just ZIPs).

XL Engine http://xlengine.com is probably the closest project to this, but progress has been slow, the creator hasn't opened the source up yet, and it's trying to do a LOT by supporting Dark Forces, Daggerfall, and eventually Blood.

[Caligari87]

That's kinda what I'm thinking, actually. With GZDoom already supporting 3D floors, models and lights, even the 2.5D part is only a formality for basic level design constraints. I figure with UDMF for maps, DECORATE for state-based actors, MAP/SND/GAME/ETC -INFO lumps for the rest, and some kind of scripting language that can hook into all the myriad existing action specials, at lot of the heavy feature work is already there. It's just ("you keep using that word...") a matter of pulling it all into a "generic" engine that's not designed around the limitations of a 20-year-old game. Hell, mapping in UDMF could be as simple as creating a new game-config for Doombuilder, no new tools required.

[Graf Zahl]

Trust me, you do not want DECORATE as it is in there! The way it links states with actions is one of Doom's biggest problems, that needs to be resolved differently if you want a stable engine.

[Caligari87]

Fair enough, you're the expert

To satisfy my curiosity, what are some alternatives? Or how would you design a similar system in theory? I'm not sure how other (non-Doom) engines do actors, really.

[NeuralStunner]

Personally? I would vouch for something more like QuakeC. Actors are internally a set of functions that can do basically anything that a usual function can. While the default game uses a somewhat state-like system 9with several mini-functions that set a frame and call AI code), you wouldn't necessarily have to do it that way.

[Caligari87]

So kinda like "Here's the actor's animation states, and here's a script that tells it which to use"? I see how that could definitely be an improvement.

[NeuralStunner]

In a way. More that the code tells entities which model frame to use. (It uses a "frame name" but, as far as I can tell, that's all preprocessor stuff.)

[VGA]

Well, Sonic Robo Blast 2 is a new game based on Doom Legacy's source. It seems to be reasonably popular.

https://www.srb2.org/