[Ninety-Six]

This is something that I've been wondering about for like a decade and a half by this point, and I decided I'm tired of question taking up space up in my head.


It's in regards to spawning. Why does Build seem to be the only old-school engine that is capable of genuinely spawning things? What I mean by genuine is, well let's look at Doom by comparison. All enemies are stored on the map. Those that teleport in are kept in a box outside the playable space, that when they wake up they will cross a teleporter line and then appear within the level itself. Even advanced source ports that allow items to be spawned accomplish this with conveyor belts. Build doesn't work like that. The items and enemies that can be spawned actually spawn in in a literal sense. They don't exist on the map prior to the trigger that creates them (I know their spawn points are placed in the map, but). The total kills remaining number even increases when this happens.


And yeah, Doom's an older engine. Which is why I'm so confused that even more technically advanced engines don't work that way. The Quake engine works basically the same way as Doom's engine (in this regard I mean). And even Serious Sam, from 2001, still relies on template objects within the map itself to spawn things. Maybe GldSrc does literal spawning but I'm not sure; I'm less familiar with it. It's kind of moot anyway since it's still in the minority with Build even if it does.


So why is that? And as a followup question, why did "true" spawning seem to be an elusive technical accomplishment in that era?

[Danukem]

Doom does have true spawning though, for example lost souls spawning from pain elementals. I'm not very familiar with doom but that alone is very clearly "true" spawning since the spawned lost soul was not in the map initially. Also the Icon of Sin spawning stuff. And any time a rocket or other projectile is fired, sprites are spawned -- they may not be enemy sprites but that's not a technical limitation distinction.

[Ninety-Six]

Danukem, on 06 October 2024 - 07:48 PM, said:

Doom does have true spawning though, for example lost souls spawning from pain elementals. I'm not very familiar with doom but that alone is very clearly "true" spawning since the spawned lost soul was not in the map initially. Also the Icon of Sin spawning stuff.

I admit I forgot about those. That just reinforces the question all the more, though.

[ck3D]

The RESPAWN sprites around Build maps technically are sprites that just turn into whichever (actor/coded) sprite you set once triggered and so technically speaking, albeit invisible as soon as map launch until that happens, there are sprites pre-loaded in the map, and whenever they're called they just change into the (visible) ones you eventually want. Simplifying a little here so someone can correct me if the wording sounds wrong. Seems to be rather primitive a system anyway since it won't respect angles - RESPAWN-based enemies always will pop into the map facing east for some reason, completely overriding whichever angle the mapper may have given the original RESPAWN sprite (which is kind of lame but in practice makes little to no difference in most cases i.e.. view-aligned sprites).

To successfully work with RESPAWN sometimes additional code has to be run/added so that the sprite the RESPAWN turns into has the correct size otherwise by default it will be given repeats of 1x1 (0x0 being invalid and instantly deleting it, that's when a sprite is completely incompatible with the system), making it almost invisible, for instance some NEWBEAST actor frames do not have such checks. https://infosuite.du...ibility#Respawn

[Danukem]

RESPAWNS definitely do "spawn" a new sprite as far as the game engine is concerned. They aren't literally the same sprite number with a changed picnum. The new sprite goes through the EGS event and at that moment you can even recover information about the RESPAWN it came from as a separate sprite. So there's a moment (not even a whole game tic, but a part of the process) where there are two different sprites, the RESPAWN and the thing it spawned.

None of that matters though because we know for sure that in all of these games, sprites get spawned all the time. When your plasma gun or freezer goes PEW PEW PEW you can literally see the sprites coming into existence and then later deleting. And no there is not some "projectile closet" akin to a monster closet somewhere storing all the possible projectiles. So we know that there was nothing arcane or unusual about sprites spawning into these games. And since a monster is just a sprite, there's no reason in principle why monsters couldn't be spawned.

John Carmack is good at programming and would have had no trouble at all putting spawning monsters into Doom/Doom2 etc. It's possible that these were excluded from Doom 1 due to concerns about performance. If you have all the possible monsters that are gonna be in the map in the map at start, then that foregoes lag caused by spawning more. Or maybe it has something to do with maybe needing to resize some arrays. I don't know, but for sure it wasn't a limit on programming knowledge. If I had to guess I would say the original reason was a performance concern, and then later in Doom2 when we know they had spawning monsters (the lost souls) they just kept using monster closets because their level design techniques were well established and they felt no need to have monster spawners in the maps.

[Aleks]

Maybe it's because Doom wanted to have all the monster count already included at the map start and so this seemed like an easier way of achieving it? I suppose the reason is something very simple and basic like that, i.e. rudimentary engineering "first idea that worked out" kinda thing.

[ck3D]

I stand corrected by Dan's rectification about the sprite swap technically not being a direct swap. I find it interesting to see DooM's 'monster closets' brought up in a discussion about the technical spawning of enemies - I never really considered (and still don't think) the reason for those would be technical at all, or even some kind of pseudo primitive workaround to anything - I always saw them as deliberate and in fact very pioneering level design choices. No one was doing level geo that moved up and down at the time and/or finding interesting practical applications of the mechanic that I know of. So it makes sense DooM would look at all the new gameplay possibilities it would allow for and articulate its level design around the '3D' like that in order to craft a unique experience, similarly to how Duke 3D later took the newly possible stacked spaces and even more dynamic sectors (horizontal doors, rotating structures, trains etc.) it had at its disposal and incorporated those options as its core philosophy.

[Ninety-Six]

 Danukem, on 07 October 2024 - 12:13 PM, said:

None of that matters though because we know for sure that in all of these games, sprites get spawned all the time. When your plasma gun or freezer goes PEW PEW PEW you can literally see the sprites coming into existence and then later deleting. And no there is not some "projectile closet" akin to a monster closet somewhere storing all the possible projectiles. So we know that there was nothing arcane or unusual about sprites spawning into these games. And since a monster is just a sprite, there's no reason in principle why monsters couldn't be spawned.

There is a counterargument to be made in that said projectiles aren't permanent. They will eventually hit a wall and dissipate (especially in the levels crafted by id themselves). Meanwhile the enemies are permanent. Even once they're dead the game is still processing them (except Lost Souls. They might actually be the exception; I'm not sure if the game processes an invisible corpse or just plain deletes them).

 Danukem, on 07 October 2024 - 12:13 PM, said:

John Carmack is good at programming and would have had no trouble at all putting spawning monsters into Doom/Doom2 etc. It's possible that these were excluded from Doom 1 due to concerns about performance. If you have all the possible monsters that are gonna be in the map in the map at start, then that foregoes lag caused by spawning more. Or maybe it has something to do with maybe needing to resize some arrays. I don't know, but for sure it wasn't a limit on programming knowledge. If I had to guess I would say the original reason was a performance concern, and then later in Doom2 when we know they had spawning monsters (the lost souls) they just kept using monster closets because their level design techniques were well established and they felt no need to have monster spawners in the maps.

That still leaves the question of why they kept doing it that way in Quake (when that has demonstrably led to instances where the levels can break because of the rube-goldberg approach of monster spawning. Grisly Grotto has this bad for instance).

 ck3D, on 08 October 2024 - 03:56 AM, said:

I stand corrected by Dan's rectification about the sprite swap technically not being a direct swap. I find it interesting to see DooM's 'monster closets' brought up in a discussion about the technical spawning of enemies - I never really considered (and still don't think) the reason for those would be technical at all, or even some kind of pseudo primitive workaround to anything - I always saw them as deliberate and in fact very pioneering level design choices. No one was doing level geo that moved up and down at the time and/or finding interesting practical applications of the mechanic that I know of. So it makes sense DooM would look at all the new gameplay possibilities it would allow for and articulate its level design around the '3D' like that in order to craft a unique experience, similarly to how Duke 3D later took the newly possible stacked spaces and even more dynamic sectors (horizontal doors, rotating structures, trains etc.) it had at its disposal and incorporated those options as its core philosophy.

To be specific, I was referring to the monster boxes that exist outside the playable space. Proper "monster closets" are still part of the normal level; they're just closed off at the start. I'm talking about the boxes that have but a tiny connecting passage that only exists to transfer sound.

Had id taken the direct spawn method, those teleporter ambushes could have been much more meticulously designed, and again without the threat of monsters getting stuck (which happens even in Doom 1. The optional arena at the end of Unholy Cathedral often ends up with a few imps or pinkies lingering in limbo for a while before they cross the teleporter linedef again).

[Reaper_Man]

I doubt there is a single answer to this and it probably depends more on the specific engine.

I would guess the reason Doom uses the teleport trick instead of spawning in monsters directly is for performance reasons, like basically everything else in the engine's design. It is faster to load the monster in memory and have it exist on the map, than to spawn it at runtime, in a time where every frame mattered.

Quake may not have had "true" spawning for reasons related to the game's general development, and there was more important stuff to do. At very least, Half-Life on Goldsrc has monstermakers which function like a RESPAWN does and uses them all over the place.

Original Unreal had "creature factories" which kinda-sorta acted the way Build's RESPAWN works.

Doom 3 had monsters spawn in, again kinda-sorta like RESPAWN. In that game the monster literally already exists in the map and is just invisible, and when triggered, does the teleport in animation.

Unity allows you to Instantiate game objects (such as monsters), but it's heavily suggested NOT to do it because it is heavy on the engine. So it's better to recycle certain game objects - reset them to some kind of zero state and move them to a new monster's location - rather than spawn them over and over. We use this method in AWOL for similar reasons, it winds up being invisible to the player and there's no overhead for the various on-spawn Game Events.

Of all of these, Doom is the more interesting example because their system allows an essentially unlimited amount and variety of monsters all to spawn from a single point. All of the other examples are either one-time use (like RESPAWN) or are limited to a single enemy type (like Goldsrc's monstermaker). Doom's method also lets the rate the monsters teleport in be organic and essentially random. Their method also means all of the "programming" is done map-side, without having to make explicit cases for how certain spawners work. For example, I can immediately think of how to make a RESPAWN+ which can be triggered multiple times, or spawns in multiple enemies, or a varied enemy type, or a random spawn rate, or all of these things combined. Making it easy for the map maker to place this and "program" it with hitags, lotags, .extra values, and so on is where it gets hard and you'd need some kind of reference guide to understand how to use it... Or, you just place 10 enemies in a room, add a teleporter and a destination, and it's done.

[Ninety-Six]

Reaper_Man, on 10 October 2024 - 05:46 PM, said:

It is faster to load the monster in memory and have it exist on the map, than to spawn it at runtime, in a time where every frame mattered.

Computers are strange. Intuitively you would think the opposite, that creating more monsters when there are less living ones to process idle/active code for would be easier than loading them all at the start. Yet it's almost always the opposite of what seems intuitive.

[High Treason]

You're stood at the edge of a massive rabbit hole there because this sort of thing depends quite heavily on the architecture of the computer. This is why ports of games sometimes run poorly without being hand optimized for the platform they were ported to. I guess maybe compare a SNES to a Mega Drive or something, PS1 to Saturn maybe, dig up the technical documents and consider how you'd write an equivalent engine for each machine. They'll all have some particular aspect that you'd write your code to lean on more than with the other system.

At a very basic level, lets assume there are two different systems, one has a massive CPU but a crappy memory bus hanging off it. The other has a crappy CPU but uses lightning fast SRAM on a really wide bus with everything else being DMA capable.

On the first system, loading the monster in at map start would make sense, because the CPU isn't going to care and the monster is now already in RAM, so won't slow the level down later. However, if we have to load the monster in while the level is already playing, the CPU will have to wait for the monster's tiles and code to be loaded into RAM and can't really do anything in this time, despite how powerful it might be. For an example, on early Intel 386 systems the CPU might have to wait at least five cycles for every memory access, plus a few more for the operation to actually complete, which stacks up quickly if your program accesses it a lot - You have a powerful CPU that's no use when it's sat doing nothing, but a CPU-bound program would run well on this machine.

On the second system, the CPU is a pile of crap, so having a monster constantly pulling on it isn't going to help the game run all that nicely. On the other hand, loading the monster later on will barely have an impact because (assuming the storage we're loading it from isn't dog slow) RAM access is really fast, to where the CPU might hardly have to be involved at all if the machine was designed around this capability. As an example, late Intel 286 systems sometimes had almost no wait at all when accessing memory and so despite using a comparatively older and often slower CPU, they could outrun the flashy new 386 machines in programs that hammered the RAM constantly - The CPU might not technically be as quick and will slog if loaded down with processing, but it doesn't have to wait for the rest of the system anywhere near as often, meaning a memory heavy program would run well on this machine.

The correct way isn't always obvious and you could well have to break the apparent convention for certain applications. Still, curiously, the system architecture did change quite a lot on PCs between the time Doom went into development and when Duke 3D released, so this might well have influenced decisions somewhere along the way. Duke seems to suffer most with disk access and less than optimal texture caching. However, Duke runs a more complex engine where doing things like sight checks can be quite expensive computationally with certain types of level geometry.

[oasiz]

I always felt like doom was just something that the map designers worked out and it also worked well enough in a pinch and the tight deadlines, probably explored quite a bit later in dev and it was just slapped all around.
Aspect of "Monsters teleporting in" happening quite literally and allowing some degree of natural pacing/throttling so that all don't get to the player in one go for gameplay and performance reasons (rendering & sounds)..
It's kind of a natural extension for monster closets through a hack without much code being required.

[NNC]

I think this opening monster closet and then teleport trick had been played in Going Postal and Area 51, but it's pretty clumsy, especially with the fat commander in Area 51, which shoots rockets from it's hidden place before making his teleport. I think the problem is that Build didn't implement the alert system properly, that's much better in Doom.

However, I never understood that despite the gorillion updates, Mapster still can't show the R monster/item (at least with transparency) straight after the R sprite is getting the hi-tag. Also they should be part of the kill count, that can be implemented properly in future EDuke32 versions. And then, errors like not having set palette (in the case of assault captain respawns at least) and in some cases the sprites themselves (eggs, reconcars) are still there, and it has never truly been fixed, only in DaNukem's DukePlus. I would also implement default sizes for active items even at Mapster mapload (I reckon it was there at early Build versions as all item sprites except for the atomic health and pistol seem default at 32:32, but it's gone now).

[oasiz]

These are something that m32 scripts can help with. I implemented these for sw/fury. Loads of similar things can be done.

[ck3D]

NNC, on 14 October 2024 - 10:57 PM, said:

However, I never understood that despite the gorillion updates, Mapster still can't show the R monster/item (at least with transparency) straight after the R sprite is getting the hi-tag. Also they should be part of the kill count, that can be implemented properly in future EDuke32 versions. And then, errors like not having set palette (in the case of assault captain respawns at least) and in some cases the sprites themselves (eggs, reconcars) are still there, and it has never truly been fixed, only in DaNukem's DukePlus. I would also implement default sizes for active items even at Mapster mapload (I reckon it was there at early Build versions as all item sprites except for the atomic health and pistol seem default at 32:32, but it's gone now).

To be fair, a lot of that is because Duke 3D on the game side was coded with the feet (maybe a better way to put it would be it's the sum of so much situational improvised hackwork just to get one specific thing to do one thing at one moment in the game it's not that optimized to be modded as a whole). For instance in order to bleed acid and not blood, NEWBEAST will turn pal 6, spawn pal 6 blood, then immediately revert back to pal 0 before the visual change can be perceptible but it still happens in the running code, when (in theory) cleaner practice would have been to go back on the old blood pool code and give it pal 6 when it's detected to be a NEWBEAST that spawns it. Assault Troopers are weird too because when pal 0 are consistently assigned pal 11 inside of the maps by the game when not turned into Assault Captains with pal 21 (or placed with a non 0 pal in general); Nukebuttons will detect all blocked/hittable objects contained within their parent sector before they agree to activate (that means a blocked Nukebutton will negate its own self) just because the player wasn't supposed to be able to press the E1L1 one through the intact glass. It's a bunch of small one-time quirks due to the game having been written in a linear fashion that add up, and are especially noticeable when people try to get the game to do alternative things. In that sense it's not optimized, also because it only ever was meant to be so much as the base corpus would function and agree to do all the things it needed to in a specific context. EDuke makes it more practical than raw Build to go back and address those old quirks because it exposes access to a larger picture of what the game manipulates than just the old .cons. Danukem does seem to tend to clean all of that stuff up - Alien Armageddon is really well optimized in that sense with a lot of the original oddities still functional but properly rearranged - on the mapper's end that alleviates so much.

[NNC]

ck3D, on 15 October 2024 - 08:15 AM, said:

To be fair, a lot of that is because Duke 3D on the game side was coded with the feet (maybe a better way to put it would be it's the sum of so much situational improvised hackwork just to get one specific thing to do one thing at one moment in the game it's not that optimized to be modded as a whole). For instance in order to bleed acid and not blood, NEWBEAST will turn pal 6, spawn pal 6 blood, then immediately revert back to pal 0 before the visual change can be perceptible but it still happens in the running code, when (in theory) cleaner practice would have been to go back on the old blood pool code and give it pal 6 when it's detected to be a NEWBEAST that spawns it. Assault Troopers are weird too because when pal 0 are consistently assigned pal 11 inside of the maps by the game when not turned into Assault Captains with pal 21 (or placed with a non 0 pal in general); Nukebuttons will detect all blocked/hittable objects contained within their parent sector before they agree to activate (that means a blocked Nukebutton will negate its own self) just because the player wasn't supposed to be able to press the E1L1 one through the intact glass. It's a bunch of small one-time quirks due to the game having been written in a linear fashion that add up, and are especially noticeable when people try to get the game to do alternative things. In that sense it's not optimized, also because it only ever was meant to be so much as the base corpus would function and agree to do all the things it needed to in a specific context. EDuke makes it more practical than raw Build to go back and address those old quirks because it exposes access to a larger picture of what the game manipulates than just the old .cons. Danukem does seem to tend to clean all of that stuff up - Alien Armageddon is really well optimized in that sense with a lot of the original oddities still functional but properly rearranged - on the mapper's end that alleviates so much.

Yep, Duke was a mess of a game, which wasn't notable in the 1990s, when the game's great level design and edgy nature were huge, but it became obvious when it lost the modding race to other contemporary FPS games.

I think some of these things should be fixed for EDuke32, and not for special mods like Duke Plus or Alien Armageddon.

[Mark]

oasiz, on 15 October 2024 - 07:04 AM, said:

These are something that m32 scripts can help with. I implemented these for sw/fury. Loads of similar things can be done.

A script I would find handy is to add a default value for RGB of an SE 49 or 50 polymer light instead of them being zero at time of placement and then having
to hit F8 to add them manually one at a time.