In-Engine Doom Map Editor

In-engine editors for a lot of game developers are seen as nothing less than essential. Being able to iterate and test levels with just a click of a button and negligible wait times because you are already running the game make designing many times faster.

While nodebuilding nowadays has become very fast, the act of loading up the engine you want to test in can still add a second or two (or more, for complex wads/pk3s) onto your testing time every time you load it up. When you are just iterating on and editing say, a small section of a map, this seems completely unnecessary.

Cue trumpets, horns, choirs etc... what about an in-engine doom map editor!!

What does this mean!
+ Edit your map in Full 2.5D!
+ Never have to leave the engine to test!
+ Everything works so much quicker!
+ Only the map needs to be reloaded to test, all the other resources in your wad are like, already in memory!
+ Your preview is 100% accurate! No more ogl/software inconsistency!

Of course, there would be some disadvantages too:
+ Drawing new sectors while in 2.5D would no doubt be more cumbersome/slower than top-down 2D.
+ Nodebuilding/reloading the map would still need to happen (without some rad dynamic BSP or async loading mechanism), but this can be compensated/designed for.
+ Probably some other stuff too?

I wrote up some more technical thought-dump process on how the editor might work, to hopefully narrow down possible engines it could be based off, and work out the viability.

http://pastebin.com/SXnM8MN5

After speaking with Jon, Quasar and some other people, this idea sounds more and more viable.

Thoughts! Ideas! Tell me I'm an idiot!

Sounds awesome! I'll have to look more into this when I get home!

Calamity, being a library, is aiming to be of assistance to provide editors an accurate Doom renderer without needing to write a renderer yourself. Not quite the same as an in-engine editor. Depends on what you're aiming for really. If testing without opening another executable is your goal, I'd almost suggest an in-editor game (think Unreal Engine/Unity). If it's just rendering accuracy, the software renderer will certainly give you that but restrict the ability to do something like Doom Builder's 3D mode effectively.

The goal is literally just as described: to be able to edit levels in game. Calamity is very exciting and will for sure mean that 3d view accuracy is greatly improved, and in-engine games can have other benefits. There are many advantages and disadvantages for in-engine editors, including less immediate/obvious benefits such as editor features making their way into game/map features.

Essentially, all three would be great to happen. Calamity for rendering accuracy and an in-engine editor for other benefits can still be used in tandem. My imagined workflow would likely start a layout in doombuilder, working out the meta-map etc, then move in-engine for gameplay features, on-the-fly detailing, and iterative changes such as seeing how the map flows.

How about using the automap for 2D editing? And add a mouse cursor or panning to make it fast.

jmickle66666666 said:

I wrote up some more technical thought-dump process on how the editor might work, to hopefully narrow down possible engines it could be based off, and work out the viability.

The choice of the engine is also constrained by the features you want to have, and inversely the features that can be had are determined by the choice of engine.

E.g. if you want a full-fledged editor that supports all Doom engine games you will basically need to use ZDoom as a base. If you use PrBoom+ as a base you'll be limited to Doom maps in Doom format, though with Boom/MBF extensions.

This question is independent of the other important question of "which codebase is it easier to work with".

Doesn't Risen3D already have an in-game editor?

jmickle66666666 said:

In-engine editors for a lot of game developers are seen as nothing less than essential. Being able to iterate and test levels with just a click of a button and negligible wait times because you are already running the game make designing many times faster.

While nodebuilding nowadays has become very fast, the act of loading up the engine you want to test in can still add a second or two (or more, for complex wads/pk3s) onto your testing time every time you load it up. When you are just iterating on and editing say, a small section of a map, this seems completely unnecessary.

Cue trumpets, horns, choirs etc... what about an in-engine doom map editor!!

What does this mean!
+ Edit your map in Full 2.5D!
+ Never have to leave the engine to test!
+ Everything works so much quicker!
+ Only the map needs to be reloaded to test, all the other resources in your wad are like, already in memory!
+ Your preview is 100% accurate! No more ogl/software inconsistency!

Of course, there would be some disadvantages too:
+ Drawing new sectors while in 2.5D would no doubt be more cumbersome/slower than top-down 2D.
+ Nodebuilding/reloading the map would still need to happen (without some rad dynamic BSP or async loading mechanism), but this can be compensated/designed for.
+ Probably some other stuff too?

I wrote up some more technical thought-dump process on how the editor might work, to hopefully narrow down possible engines it could be based off, and work out the viability.

http://pastebin.com/SXnM8MN5

After speaking with Jon, Quasar and some other people, this idea sounds more and more viable.

Thoughts! Ideas! Tell me I'm an idiot!

My home port lets you do everything that does not require a node build, from a remote computer. Basically, you use a map editor, and non-node-changing edits show up in game on the other computer. It's pretty primitive.

But, yeah - partial node patching should be doable, especially if you modify the node walking code to ignore deletes, and other like situations.

OR, render the level without the BSP, as you edit :) Cool idea, indeed!

A friend actually brought me here, because we were discussing the exact same thing a few days ago. I've started work on a shite one, but I'm currently at a standstill.

As the developer of a Doom map editor, my personal thought on in-game editor is that the concept can work ok (Build, Cube, Sauerbraten as examples), but when you have fully functional external editors already then the reasons for a in-game editor are not very compelling.

For example, Doom Builder 1 and 2 already has a 3D mode for editing, and Eureka has a good 2.5D preview (I dunno about Slade).

The big challenge for an in-game editor is having a good set of GUI controls / widgets. Doom3 used MFC (by Microsoft) which was not cross-platform (it only worked on Windows OS). But you absolutely *need* all those boring things like menus, scrollable lists, dialog boxes, text input boxes, etc etc.... Even something like a file load/save dialog is a major thing when you cannot rely on Windows functionality.

BTW Eureka does not require a BSP tree for it's 2.5D preview.

jmickle66666666 said:

In-engine editor

andrewj said:

I dunno about Slade

The old slade 2 map editor has a full blown 3D preview mode... i know because i still prefer its simplicity and speed over doombuilder, the only thing it might do is crash once in a while.

andrewj said:

As the developer of a Doom map editor, my personal thought on in-game editor is that the concept can work ok (Build, Cube, Sauerbraten as examples), but when you have fully functional external editors already then the reasons for a in-game editor are not very compelling.

For example, Doom Builder 1 and 2 already has a 3D mode for editing, and Eureka has a good 2.5D preview (I dunno about Slade).

The difference between an editor with a 3D-mode/preview and an in-game editor, is that an in-game editor can jump between the game and the editor immediately and seamlessly. The engine and the editor are one and the same (very much like how it's done in Unity and Unreal). I'm assuming that's the proposal here, it'd be a very cool thing to see in a Doom-engine editor.

Somewhat related and worth mentioning, Fraggle recently (re)added a function in Chocolate Doom where you can refresh an open wad without having to quit and reload the entire game. Great for testing maps for Vanilla Doom, but I don't know if other ports have this refresh functionality.

You'd be hard pressed to create a more efficient mapping environment than GZDoomBuilder's.

Also, I think there are plans for Doomsday to have an ingame editor. Then again, there are many plans for Doomsday. :-D

You know what'd be a really cool concept to use from this? Being able to draw sectors in real time. Imagine if a player could build their own walls or take chunks out of the environment as they're playing. Maybe even have some destructible environment to a certain extent, though it would be completely vertical since Doom handles sector drawing on a 2D plane. Or you could have the ability to create your own world akin to Minecraft or Subnautica.

Iirc, Sonic Robo Blast 2 actually has a limited version of this. You can't alter map geometry in any way, but there are commands to place things around the map and another that overwrites the map's things file with the current on-map things, excluding the player.

MetroidJunkie said:

You know what'd be a really cool concept to use from this? Being able to draw sectors in real time. Imagine if a player could build their own walls or take chunks out of the environment as they're playing.

It would be cool if the player could pause a running game and alter the map's geometry + add/remove things + change existing thing positions in any way he wanted. Then upon unpausing the game, new nodes would be built. Previously existing things like active monsters and sectors in the middle of movement would continue their logic as if nothing special happened during the pause, but the map would actually be different.

scifista42 said:

It would be cool if the player could pause a running game and alter the map's geometry + add/remove things + change existing thing positions in any way he wanted. Then upon unpausing the game, new nodes would be built. Previously existing things like active monsters and sectors in the middle of movement would continue their logic as if nothing special happened during the pause, but the map would actually be different.

That's exactly how an in-engine editor should work, it's a godsend for testing specific areas. Unreal goes so far as to allow the user to edit C++ code while the game is running, and the game updates with those changes immediately — It'd be great to be able to do that with ACS (or Doomscript, when it happens).

scifista42 said:

It would be cool if the player could pause a running game and alter the map's geometry + add/remove things + change existing thing positions in any way he wanted. Then upon unpausing the game, new nodes would be built. Previously existing things like active monsters and sectors in the middle of movement would continue their logic as if nothing special happened during the pause, but the map would actually be different.

Maybe even make it like a type of weapon power where each action drains the weapon's resources to various extents like, say, calculating the area of a wall you're making or carving into and it costs that much to do. You could even make entire puzzles that require the player to manage their resources to get around obstacles. In theory, of course.

That sounds like an idea for an entirely new game, with its own engine that contained a Doom-like engine and a Doom-like editor at the same time, and had full control over them "from the inside".

So such a thing is probably a bit out of the scope of Doom's limitations? I can't imagine your idea of building the nodes while it's paused would take too long on a more modern machine.

No, my point wasn't about speed or limitations, but about control. You mentioned something like a pre-scripted puzzle task for the player, where the game would allow him to both play and edit the map, but still deliberately restrict him with an intention to challenge him. Not give him full control, but just a partial control as a gameplay mechanic, created by the mod's creator who had actual full control. I though that would require rather complex overhead, new scripting languages and new engine.

I mentioned this to jmickle on IRC, but I highly recommend anyone exploring his idea to check out Cube 2: Sauerbraten to see how it can be done, well. It was written by Aardappel who used to be a big figure in the Doom community, too (original author of wadc amongst other things)

I doubt very much of Cube 2 Sauerbraten's method could work with Doom, though, since Cube 2 is fully 3D whereas Doom is 2D based.

MetroidJunkie said:

I doubt very much of Cube 2 Sauerbraten's method could work with Doom, though, since Cube 2 is fully 3D whereas Doom is 2D based.

The ui and various design decisions about how collaborative play and editing work are very relevant IMHO, even if the core tech is wildly different.

jmickle66666666 said:

In-engine editors for a lot of game developers are seen as nothing less than essential. Being able to iterate and test levels with just a click of a button and negligible wait times because you are already running the game make designing many times faster.

While nodebuilding nowadays has become very fast, the act of loading up the engine you want to test in can still add a second or two (or more, for complex wads/pk3s) onto your testing time every time you load it up. When you are just iterating on and editing say, a small section of a map, this seems completely unnecessary.

Cue trumpets, horns, choirs etc... what about an in-engine doom map editor!!

What does this mean!
+ Edit your map in Full 2.5D!
+ Never have to leave the engine to test!
+ Everything works so much quicker!
+ Only the map needs to be reloaded to test, all the other resources in your wad are like, already in memory!
+ Your preview is 100% accurate! No more ogl/software inconsistency!

Of course, there would be some disadvantages too:
+ Drawing new sectors while in 2.5D would no doubt be more cumbersome/slower than top-down 2D.
+ Nodebuilding/reloading the map would still need to happen (without some rad dynamic BSP or async loading mechanism), but this can be compensated/designed for.
+ Probably some other stuff too?

I wrote up some more technical thought-dump process on how the editor might work, to hopefully narrow down possible engines it could be based off, and work out the viability.

http://pastebin.com/SXnM8MN5

After speaking with Jon, Quasar and some other people, this idea sounds more and more viable.

Thoughts! Ideas! Tell me I'm an idiot!

If you want to create the engine yourself , make it to be a mixture of
ZDoom & JDoom...

The Doommer said:

make it to be a mixture of
ZDoom & JDoom...

...and less than 100% compatible with either?

besides zdoom has muddy licensing, that prevents commercial usage, limiting its potential use for game development

raymoohawk said:

besides zdoom has muddy licensing, that prevents commercial usage, limiting its potential use for game development

Hopefully/perhaps GLOOME will resolve that. Although they've gone quiet on that front recently...

GZDoom seems to be a different story, though, since D-Touch was able to use it and have a price tag on it. He simply had to strip out the software renderer, AKA ZDoom.