Random musings

[Murdoch]

This topic is gonna be about various things, suggestions, ramblings, ideas and what not. Most of it probably rubbish but I think worth discussing regardless. Everyone feel free to add their own thoughts to it.

1. First of all James, I have the Visual C++ Toolkit I d/led from Microsoft's site. Do you know if it is possible to somehow leverage this to compile Eternity? In the bin directory it has link.exe, cl.exe and various dlls.

2. Water and other liquids. Not sure what you could do in the context of Doom, but it would be nice to see more done with these to try and make more believable worlds but still making it Doom. Fraggle was on the right track with that swirly liquid code.

Two things in particular come to mind - making the water move up and down slightly to simulate the wavy motion of water. Probably too hard with Doom's renderer. What might be more doable is being able to somehow make a liquid sector that can interact with another texture. Say you could have a sector of water next to a sector of say sand, and a square or rectangular "buffer" sector with this special type. It takes the two flats and then creates an interaction between the two. Using this technique it should be possible to easily create the illusion of lapping water, such as what you'd get along the edge of a beach. Manipulation of flats by a formula of some kind is possible, otherwise fraggle's swirl code wouldn't exist. Let's be creative :)

3. Monster AI. I love Doom dearly still, but it has become frighteningly predictable. I realised this about six months ago when I realised I was doging imp fireballs without even looking. I saw them launch and new exactly how much time I had till they hit me.

Some quite simple optional mods could make a big difference. I think we've spit-balled on this before James. Things like randomising enemy hit points, speeds and projectile speeds. I realise it will break some WADs, but those who haven't been design by guys too anal about ammo balance should be fine.

4. Crouching and jumping. These have become part of my FPS skills well and truely. When I come to Doom I miss them. It makes for a better experience, I think - lets you interact with the world in a more believable way. Maybe these could be added to Eternity to be used at the player's discretion, and with the option for a level designer to enable or disable them via the mapinfo lump?

5. EDF for weapons. What is the status on this? Both Millennium and Caverns of Darkness need this. If I could compile the code I'd love dearly to try and help.

6. Ambient sounds. I seem to remember some mention of ambient sounds in previous reference to Eternity, but I could not find anything in the docs. For my needs, there needs to be two kinds. Looping or randomised playing ones you can assign to a thing, visible or invisible. Second it would be neat to be able to have a sound sourced from a sector, to make it easy to do things like creating a water sector with sea sounds.

7. How scriptable are particle fountains? Basically I want to be able to simulate waves breaking again a rock. Obviously can't make the wave itself, but a puff of particles accompanied by a suitable sound could create something close. So the particle fountain would need to be able to be turned off and on, and playing a sound in the event of the latter.

8. Rain effects. You mentioned these in the Millennium forum. How do you plan on implementing these, and what exactly will they be capable of? Will they be able to be used in a massive outdoor area without choking the engine?

9. Slopes. I know, I know :P But the bottom line these are a tremendously useful design capability. Are there plans to implement these in Eternity?

Basically I want to be able to make Doom more fun and unpredictable, with more believable worlds to explore while still making it Doom.

[Joe]

1. This is possible and i'll give it a try, but the problem is you'll need sdl to compile it, and it's bad enough getting sdl stuff to compile with vc++, never mind the free toolkit edition. Oh, and Eternity compiles with VC6, not VC.net so that could be a problem.

2. Sounds cool, especially the wave idea.

3. Thats what happens when you play doom for a good few years :p. I'm also pretty sure you can randomize the stats and attacks (definitely attacks, mainly because quasar told me to write a tutorial on it), but i'll have to have a play around to be honest.

stdinclude(root.edf)

framedelta 
{ 
   name = S_TROO_ATK3 ; 
   action = SetCounter ;
   args = {0, 2, 11}; 
   nextframe = S_TROO_ATK4;
}

frame S_TROO_ATK4 
{    
   cmp = "TROO|6|*|1|CounterSwitch|S_TROO_ATK5"
   args = { 0, 10006, 2 }
}

frame S_TROO_ATK5 
{
   cmp = "TROO|6|*|6|TroopAttack|S_TROO_RUN1";  
   dehackednum = 10006
}

frame S_TROO_ATK6 
{ 
   cmp = "TROO|6|*|6|BruisAttack|S_TROO_RUN1";
}

This edf snippet with make it so that the imp will fire either a baron fireball or an imp fireball, and the choice is (OMFG) random! Expect tutorial soon ;).

4. Jumping would be cool, it's always fun to jump around your level when testing it, i find. Crouching on the other hand seems a bit useless, though i suppose it could be used for the old air vents and stuff.

5. EDF for weapons is another thing i was gonna try out. Adding a couple random attacks or something, heh. Probably wont work though.

6. Support for ambient sounds is already in eternity (cue edf with ideas shamelessly stolen from CQIII :D) :

stdinclude(root.edf)

sound WaveSnd 
{ 
   lump = "wavesnd"; 
   prefix = false; 
   dehackednum = [insert number here] 
}

thingtype WAVESND
{
   spawnstate = S_WAVESND1
   flags = NOSECTOR|NOBLOCKMAP   
   //We dont wanna collide with our sound now do we?
   doomednum = [insert number here]
}

// for some reason if you start the 
// sound playing on the first frame it
// doesn't work (Quasar: things don't 
// call the codepointer in their first 
// spawnstate)

frame S_WAVESND1 
{ 
   cmp = "troo|*|*|1|*|@next"
} 

frame S_WAVESND2 
{ 
   cmp = "troo|*|*|120|PlaySound|@this"
   misc1 = sound:WaveSnd 
}  
// just use the imp sprite thingies
// here, you wont be able to see it
// anyway and it should work fine

7. I believe the particle stuff is all hard coded at the minute, but that could change. If you give him a couple years, heh.

8. With regards to rain effects, I have no idea.

9. Slopes wouldn't be bad they'd take a while, and using zdoom/build code would screw overt the current license, something quasar is probably unwilling to do. But we can dr buteam :D.

* Edited for extreme line length -Quasar

[Quasar]

JoelMurdoch said:

1. First of all James, I have the Visual C++ Toolkit I d/led from Microsoft's site. Do you know if it is possible to somehow leverage this to compile Eternity? In the bin directory it has link.exe, cl.exe and various dlls.

I would need to export a makefile for you to use. I can do this easily using Visual Studio; I've just never had any need to do it so far. Consider it done for the next version. You do not have to compile SDL for VC++, that is already done for you by the SDL guys, who use an elaborate cross-compiler setup to build it for Windows using the linux version of GCC. You will, however, have to change paths in the generated makefile to point to where you have setup the SDL and SDL_mixer libraries. I hope you will be able to handle that.

JoelMurdoch said:

2. Water and other liquids. Not sure what you could do in the context of Doom, but it would be nice to see more done with these to try and make more believable worlds but still making it Doom. Fraggle was on the right track with that swirly liquid code.

Two things in particular come to mind - making the water move up and down slightly to simulate the wavy motion of water. Probably too hard with Doom's renderer. What might be more doable is being able to somehow make a liquid sector that can interact with another texture. Say you could have a sector of water next to a sector of say sand, and a square or rectangular "buffer" sector with this special type. It takes the two flats and then creates an interaction between the two. Using this technique it should be possible to easily create the illusion of lapping water, such as what you'd get along the edge of a beach. Manipulation of flats by a formula of some kind is possible, otherwise fraggle's swirl code wouldn't exist. Let's be creative :)

The swirling flat code is simple because it only has to distort a single flat, which it can hold in a flat memory buffer. Trying to dynamically apply effects between two flats situationally depending on their location is not possible with the current way floors work, AFAIK. A good idea, but not technologically feasible.

JoelMurdoch said:

3. Monster AI. I love Doom dearly still, but it has become frighteningly predictable. I realised this about six months ago when I realised I was doging imp fireballs without even looking. I saw them launch and new exactly how much time I had till they hit me.

Some quite simple optional mods could make a big difference. I think we've spit-balled on this before James. Things like randomising enemy hit points, speeds and projectile speeds. I realise it will break some WADs, but those who haven't been design by guys too anal about ammo balance should be fine.

As joe demonstrated, there are some ways this kind of thing can be done through EDF, though not to the degree you are speaking of. The primary problem with your idea of randomizing some fields is that they are only stored in mobjinfo_t and therefore can only have one value per species. Moving all fields into mobj_t would make Eternity use too much ram, and otherwise it won't work in save games, since mobjinfo_t is created once at startup by EDF and not saved.

JoelMurdoch said:

4. Crouching and jumping. These have become part of my FPS skills well and truely. When I come to Doom I miss them. It makes for a better experience, I think - lets you interact with the world in a more believable way. Maybe these could be added to Eternity to be used at the player's discretion, and with the option for a level designer to enable or disable them via the mapinfo lump?

Jumping will be added as soon as netgame/demo input problems are resolved in an extensible manner. Crouching you can forget about unless somebody is prepared to provide me with suitable crouching frames for all the DOOM, Heretic, Hexen, and Strife player classes. I'm not prepared to allow a 56-tall sprite to appear to walk through a 24-tall hole in the bottom of a wall :P

JoelMurdoch said:

5. EDF for weapons. What is the status on this? Both Millennium and Caverns of Darkness need this. If I could compile the code I'd love dearly to try and help.

Status is that it is in the high design and conceptual stage. No work has been done on it, partially because of the same netgame/demo input issue. Weapon changes are packed into a narrow set of bits in the ticcmd_t structure, and thus changes can only be recorded for the first 16 weapons. This is a low limit and I'm not sure it would be well received for EDF to have a 16-weapon-per-player-class limit, however reasonable I personally think that limit is.

JoelMurdoch said:

6. Ambient sounds. I seem to remember some mention of ambient sounds in previous reference to Eternity, but I could not find anything in the docs. For my needs, there needs to be two kinds. Looping or randomised playing ones you can assign to a thing, visible or invisible. Second it would be neat to be able to have a sound sourced from a sector, to make it easy to do things like creating a water sector with sea sounds.

Eternity TC defined some hardcoded ambient sound objects but those were removed from the code a long time ago. As joe demonstrates, it's fairly simple to make an object that sits around playing localized ambience. Well-managed global ambience effects as seen in Heretic are not currently available, but obviously they are going to be implemented for Heretic support sooner or later, and will at that point be usable in DOOM as well.

JoelMurdoch said:

7. How scriptable are particle fountains? Basically I want to be able to simulate waves breaking again a rock. Obviously can't make the wave itself, but a puff of particles accompanied by a suitable sound could create something close. So the particle fountain would need to be able to be turned off and on, and playing a sound in the event of the latter.

Particle scripting is in its infancy, so you basically can't do anything with it yet. Particles can be turned on and off by setting/removing the DORMANT flag on the object, but support for changing flags in scripting isn't quite complete yet either.

JoelMurdoch said:

8. Rain effects. You mentioned these in the Millennium forum. How do you plan on implementing these, and what exactly will they be capable of? Will they be able to be used in a massive outdoor area without choking the engine?

Particles are low-cost and you can have thousands of them active without choking the engine. I imagine I will create a control spot object which spawns particle rain within a given radius of itself with parameterized effects such as wind speed (direction determined by the control point's angle).

JoelMurdoch said:

9. Slopes. I know, I know :P But the bottom line these are a tremendously useful design capability. Are there plans to implement these in Eternity?

Basically I want to be able to make Doom more fun and unpredictable, with more believable worlds to explore while still making it Doom.

Let's put it this way. You can hold your breath waiting for slopes if you want to turn blue and die in a slow, painful fashion :) I recognize their usefulness, but they are not a natural extension of the DOOM engine and require massive rewrites to anything that deals with floors in even a passing manner, far surpassing the amount of work that was needed for object z clipping, 3DMidTex, and even portals.

[Graf Zahl]

Quasar said:
Moving all fields into mobj_t would make Eternity use too much ram.

Don't tell me that a few kilobytes are really that dramatic. Let's just assume you have 4000 objects in a map and 10 new 4 byte properties. That would be just 160000 bytes - and that's for an extreme case!

Crouching you can forget about unless somebody is prepared to provide me with suitable crouching frames for all the DOOM, Heretic, Hexen, and Strife player classes. I'm not prepared to allow a 56-tall sprite to appear to walk through a 24-tall hole in the bottom of a wall :P

Trust someone who was talked into adding it: The sprites are the smallest issue. The side effects in the game are much worse. This is a minefield better to be left alone. Far too large parts of the engine are not capable of handling it properly.

[Murdoch]

Quasar said:

I would need to export a makefile for you to use. I can do this easily using Visual Studio; I've just never had any need to do it so far. Consider it done for the next version.

Cool. I hate being one of those "Can I have this please?" types. I'd love to be able to make small changes here and there, and test them, before presenting them for your consideration.

Trying to dynamically apply effects between two flats situationally depending on their location is not possible with the current way floors work, AFAIK. A good idea, but not technologically feasible.

Damn. Oh well I suppose it could be loosely simulated with animated flats. Better than nothing anyway. You can have as many frames as you want in a particular set of animated flats, right?

Moving all fields into mobj_t would make Eternity use too much ram, and otherwise it won't work in save games, since mobjinfo_t is created once at startup by EDF and not saved.

Ah, of course. But what about randomising projectile speeds before each one is launched? If memory serves, each projectile is launched by applying stats to a new mobj. If you added a few lines in that function, you could have completely random projectile speeds. Not just one particular speed per instance of a monster - different every time he shoots. That would not need to be recorded in save games. Just something, ANYTHING to stop it being so damned predictable. When I play now it feels more like a dance to me. Yes Joe, I've been playing for many many years. Since the beginning of 1994 to be exact.

Hang on a minute... aren't all mobjs spawned the same way? The table used as a reference to create a new mobj. Putting code in their could randomise hit points. Are their individual details not remembered by save games and just rebuilt with info from the table?

Jumping will be added as soon as netgame/demo input problems are resolved in an extensible manner.

Cool.

Crouching you can forget about unless somebody is prepared to provide me with suitable crouching frames for all the DOOM, Heretic, Hexen, and Strife player classes. I'm not prepared to allow a 56-tall sprite to appear to walk through a 24-tall hole in the bottom of a wall :P

Fair enough. Maybe block it outright in multiplayer? And then there's the "Is multiplayer truely worth fixing?" but... :P

I'm not sure it would be well received for EDF to have a 16-weapon-per-player-class limit, however reasonable I personally think that limit is.

I personally would agree with you, and I'm sure most would. 16 weapons is plenty. Anymore than that would be silly and more than likely redundant with a designer just doing pointless variants of the same thing.

As joe demonstrates, it's fairly simple to make an object that sits around playing localized ambience.

Cool cool, and thanks Joe.

Particles are low-cost and you can have thousands of them active without choking the engine. I imagine I will create a control spot object which spawns particle rain within a given radius of itself with parameterized effects such as wind speed (direction determined by the control point's angle).

Sweeeeeeeeeeet. I can barely keep the drool in my mouth. Seriously, I love rain and have dreamed of seeing it in Doom. I'm disappointed how so few games use it as it can help create such great atmosphere. This level idea I have in my head, I want dark, spooky, atmospheric with outbursts of outright chaos and weirdness (the W1 seamless teleport I requested is part of this concept).

Too bad about the slopes. ZDoom's implementation has always felt kinda hackish to me so I thought it might not be too much of a stretch.

I've seen what Steve's been doing with portals in Millennium. Neat stuff. I'm trying to get him to post shots, as I think Eternity would get more attention if people could see more of what it can do. Right now it's largely theoretical.

The level I want to make, if I ever get around to it, will make use of portals too to create a big detailed seaside level in the middle of a severe storm. Big emphasis on the if :)

[Quasar]

JoelMurdoch said:

Damn. Oh well I suppose it could be loosely simulated with animated flats. Better than nothing anyway. You can have as many frames as you want in a particular set of animated flats, right?

I'm sure there's SOME kind of limit, but you'll never run into it.

JoelMurdoch said:

Ah, of course. But what about randomising projectile speeds before each one is launched? If memory serves, each projectile is launched by applying stats to a new mobj. If you added a few lines in that function, you could have completely random projectile speeds. Not just one particular speed per instance of a monster - different every time he shoots. That would not need to be recorded in save games. Just something, ANYTHING to stop it being so damned predictable. When I play now it feels more like a dance to me. Yes Joe, I've been playing for many many years. Since the beginning of 1994 to be exact.

Hang on a minute... aren't all mobjs spawned the same way? The table used as a reference to create a new mobj. Putting code in their could randomise hit points. Are their individual details not remembered by save games and just rebuilt with info from the table?

Well, Graf Zahl made a good point about the ability to make more fields dynamic and not really use that much RAM, so we'll see. The issue isn't how the objects are spawned. Take max HP, for example. It is only stored in the mobjinfo_t entry, and is copied into the mobj at spawn time. However, if a feature assumes mo->info->spawnhealth is constant, it won't work for something that was spawned with randomized spawnhealth and may thus not act correctly.

JoelMurdoch said:

Fair enough. Maybe block it outright in multiplayer? And then there's the "Is multiplayer truely worth fixing?" but... :P

Chasecam?

JoelMurdoch said:

I personally would agree with you, and I'm sure most would. 16 weapons is plenty. Anymore than that would be silly and more than likely redundant with a designer just doing pointless variants of the same thing.

Especially 16 weapons *per player class*, as I intend to tie weapons to players via their EDF-defined class. Expect dynamic player classes relatively soon, as they are needed to get the Heretic player working properly.

JoelMurdoch said:

Too bad about the slopes. ZDoom's implementation has always felt kinda hackish to me so I thought it might not be too much of a stretch.

Actually, and this is a complement I rarely give out to anything, zdoom's slopes seem very well-implemented and fundamentally sound to me. They're based on plane math like all floors should be in a proper 3D engine. Any oddities probably come from trying to get DOOM's beast of a clipping engine to handle things interacting with them, and that simply cannot be helped without a fundamental paradigm shift.

That fact still wouldn't make it any less of a challenge for me to add in slopes, though.

JoelMurdoch said:

I've seen what Steve's been doing with portals in Millennium. Neat stuff. I'm trying to get him to post shots, as I think Eternity would get more attention if people could see more of what it can do. Right now it's largely theoretical.

Some publicity would be nice, IMO ;)

[Entropy]

Just want to comment on Joelmurdochs monster AI.
Yes...it is too easy to dodge monster projectiles, but if you make them faster they become very inaccurate.
Can this be changed in Eternity?

[Quasar]

Eternity doesn't support blazing projectiles yet, but it'll have to do so at some point if I really intend to support Hexen :P

[andrewj]

Quasar said:

Weapon changes are packed into a narrow set of bits in the ticcmd_t structure, and thus changes can only be recorded for the first 16 weapons.

The weapon bits should store the key number the user pressed (0-9), instead of an absolute weapon ID.

[Quasar]

Ajapted said:

The weapon bits should store the key number the user pressed (0-9), instead of an absolute weapon ID.

I believe this would cause a large number of issues, actually, not the least of which is the fact that players all have their own weapon key bindings.

[andrewj]

Quasar said:

I believe this would cause a large number of issues, actually, not the least of which is the fact that players all have their own weapon key bindings.

That is what the original Doom source does, so you might have bigger issues (demo compatibility) if you don't do it the same way.

[Quasar]

BOOM already has code that makes it work differently when playing old demos, so that's of zero concern :)

[Mordeth]

I replied earlier, but the forum software buggered and ate my post :/ Anyway, here a few of my comments from a designer's point of view.

More realistic liquids: yeah! Doom's 64x64 jerky flat animation really looks outdated. Swirling looks better. Plus, we have Hexen-style 64-x128 flats to look forward to, since James is working on Hexen support anyway. Right? :)

Weather effects: another feature I'm really looking forward to! Rain, snow, both able to be affected by wind. Maybe even duststorms, like the effect seen in Morrowwind..?

It would also be nice if we could have FOGMAP effects that are seen outside the affected sector, and vice versa. Very nice to combine with those weather effects, and plenty of other uses too!

And after several years I'm finally willing to admit that jumping / crouching may have added value for Doom :) But developers should be able to (un)lock that feature permanently for their WADs. Slopes can be very nice, but are not very Doom-y... especially great for use in outdoor sceneries. Both these things are not on my wishlist anyway :)

But a "NO" to randomising stats of existing monsters. This due to balance and control. Plus, you can already randomise pretty much every aspect of a new monster... New / faster attacks are easily defined in EDF, and with RandomJump you can switch randomly between those different attacks. Stats like health or appearance can also be randomised by making a 'Spawner' thing that will RandomJump to different kind of Spawns, each spawning a different variation of your monster (Imp-1, Imp-2, etc, or even different types of monsters). You can make a EDF patch for the original game that way, but keep in mind that items are a different beast altogether.

Big problem with randomising stuff in a game that has fast save/load times, is that players are going to abuse it by reloading a couple of times until they get the outcome they want. One big reason why a Diablo-clone for Doom won't work ;) So, randomising stuff should happen at a point that the player is not aware off, and well before he sees the effect of the randomising.

[EDIT:]

Something I forgot to mention earlier. Eternity has some new monster behaviour (mostly inherited from MBF, I think) such as fleeing when low on health, avoiding environmental hazards (like crushing ceilings) and rushing to the aid of dying friends. But, this behaviour is controlled by a menu option. I'd like this behaviour to be an EDF option as well, overriding the menu.... this way I have control over which (new) monster(s) exhibit this kind of behaviour without being relient on player menu choices. Even nicer would be to create (or be able to define) new monster behaviour codepointers, eg create a monster that always tries to keep its distance from you, or patrolling guards.

Also looking forward to alter monster behaviour with scripting, so I can have interaction between monsters and their environment (or rather, make it seem that there is interaction).

Joel mentioned that Doom monsters have become very predictable... so true. But they all have the same basic behaviour patterns... 'sleep', 'wake up', 'try to get in range', 'ranged attack' or 'melee attack'. Oh, and yes: 'in pain' and 'die' :) Defining new behaviours like those listed above will surely help to bring the excitement back. Makes me remember of playing against Cacodemons, way back in the day. When you shot one of those, they always seemed to recline a bit away from you... when doing this with the chaingun they would actually seem to 'flee'. I loved that. Of course, it was just that they have a low mass, and the impact of the bullets pushed them back. But still, they seemed 'smart' for doing that :)

[Lüt]

Oooh, duststorms could look great in some of the earlier Millennium maps. On the subject of fogmaps, I remember an old program called InkWorks which would allow the editing of the fade-to color for diminshed lighting (black could be replaced by grey for fog, brown for duststorm, etc). Being able to apply that on a sectoral (or even full map) basis would be cool enough, but I also remember having some special lump created by that program which only effected certain colors. I was never able to recreate it or edit the original, but there was a way for different colors to fade to different colors in vanilla doom. An example WAD was given where brown textures were used outside (brick, sludge, rock) and other colored textures were used inside (base, mostly). The brown colors would fade to brown, which all others would fade to black, giving the impression of a duststorm outside and regular environment inside. If something like this were more easily configurable and could be implemented on a more specific level than "the entire WAD", I could find some good places to use it.

[Quasar]

Umm, guys...

BulletAttack
Type: Monster attack, parameterized

Parameter Information:

* Args1 = DeHackEd number of sound to play (default of 0 = no sound)
* Args2 = Select accuracy (default of 0 = 1)
o 1 = Always accurate
o 2 = Never accurate
(moderate horizontal spread with no vertical error)
o 3 = Super Shotgun accuracy
(wide horizontal spread with moderate vertical error)
o 4 = Monster accuracy (very wide horizontal spread)
* Args3 = Number of bullet tracers to fire (default of 0 = 0)
* Args4 = Damage factor (Damage formula is: dmgfactor * ((rnd%dmgmod) + 1))
* Args5 = Damage modulus
(Forced into range of 1 to 256)

It's all right there in codeptrs.html.

[myk]

Mordeth said:
But, this behaviour is controlled by a menu option. I'd like this behaviour to be an EDF option as well, overriding the menu.... this way I have control over which (new) monster(s) exhibit this kind of behaviour without being relient on player menu choices.

Well, at least you can already force such options in a wad by using an OPTIONS lump (this is a feature from MBF.)