Hope you all enjoy this special 66(6)th episode on the AI of DEWM. But one thing I wanted to mention, specifically for all you programmers out there... There's one part of this video that maybe sounded wrong when you heard it the first time. The pain chance variable can apparently be set to any value between 0 and 256. That doesn't sound right - and believe me, every time I listened to this video, I kept thinking it was a mistake. For anyone who is not a programmer, this doesn't sound right because it provides 257 unique values. It would make more sense to have 256 possible values, ranging from 0 to 255. That's because a number stored in an 8-bit integer can only have a value between 0 and 255. So it would make sense to use 256 values, so you can store the data in an 8-bit integer. So what's going on here? The pain chance is absolutely capped at 256 and not 255. But when the probability test is executed to trigger the pain state, it checks if a randomly generated number (x) is less than pain chance (y). So it simply says if(x
FYI. The word is "Gib" with a soft G (pronounced like "jib") and is short for "Giblets". This was verified during a conversation I had with Bran Hook back around '97.
Funnily enough this is an "issue" in the original Star Craft. Your troops have a chance to hit their target. This mainly comes into play when when a character is shooting at someone that has a higher elevation, given it a 1/3 (IIRC) chance to hit. But they _did_ use a 0-255 value, so even when both shooter and shooted-at are on the same elevation and you'd expect 100% hit chance, there is still a 1/255 chance of missing the shot.
@@JeffBoen This is another "gif" vs "jif" again, isn't it? I've rarely heard anyone refer to it as "jibbed" or "jiblets", and it doesn't sound right compared to the colloquially accepted version of it ("gif"/"gib").
@@nebuchadnezzer2436 Look up Brian Hook if you don't know who that is. I would think that the guys who wrote the actual code and coined the term would know, which is why I asked him when I got the chance 20+ years ago when Quake was released, but hey, think whatever you want.
Monster infighting is such a fantastic game mechanic, sadly very little modern game utilizes it, even Doom Eternal has it only scripte here and there and monsters dont hurt each other :(
There is unscripted in fighting. If you start a fight and move far enough away they will start in fighting. It bugs me that it doesn't do damage at all.
We love this mechanic, too. Which is why we design opportunities to set it up in our Doom II mod. There's just something very satisfying about getting the bad guys to turn on each other and make your life easier. Oh, it's Dragon Sector (The Remake) if yanyone wants to check it out.
It's not scripted, I once played horde mode and I saw on the other side of arena 2 arachnatrons were fighting with mancubus. But yeah, they do not deal any damage to each other.
Two corrections: - The frame rate _is_ capped at 35 FPS in the original DOS release. The released Linux Doom source code doesn't have the cap implemented, and source ports implement proper capping/uncapping alongside things like interpolation of monster positions. - In the state graph, the XDie state should be connected to the Raise state as well, since even gibbed enemies can be resurrected by an Archvile. The state and therefore the animation isn't changed, so it plays in reverse a regular death animation, but otherwise there are no issues with it. Now, resurrecting _crushed_ enemies gets you some issues, but that's a different topic. By the way: User-made maps often use a slightly different approach to the teleporter encounters. Instead of using physically connected "pipe" sectors connecting the dummy and target areas, which can be annoying to do in cramped and complex maps, the dummy and target sectors are instead joined together into one. They're then two distinct shapes on the map, but they share the same properties like tags, textures, and heights. In terms of sound propagation, they also act as one, so making noise in the target sector alerts monsters in a completely disconnected area many map units away. Very handy, though vanilla maps don't use it afaik because it wasn't discovered yet.
@@rompevuevitos222 Yes, but he says the frame rate is uncapped as the renderer is not tied to the game logic. I don't know how much of the latter is true, but the former is not - in the original release, the frame rate _is_ capped at 35 FPS.
I played one of the new wads on ps4 earlier and i forget the name if it, but the map was huge and had lots of archviles. Eventually i had to admit i was impressed there were no closing doors in the whole map. if there were doors, the amount of ghost enemies would be insane
Nicely done! One minor thing, the statement at 16:13 is a little misleading. Floor heights matter when calculating line of sight to the player. One example: From the starting room of map 8 of Doom II, go through the north door, and without using a weapon, carefully hug the west/left wall as you proceed north, and you'll only be seen by the Cacos to the east. Or, hug the east/right-hand wall and you'll only be seen by the Cacos to the west. Anyway, great video as usual. Cheers.
"Technically the barrels have a pain chance of zero. Which, y'know, makes sense because they're barrels." Now that just makes me want a barrel pain state and animation implemented.
As someone who ultimately wants to get into programming for games, and is leaning towards learning C++ first, I really appreciate that you actually showed the text file so that we can get an idea of how things can be structured
(*puts on college professor hat*) Even if you're just starting out, it's always interesting to see how other people write code. Even when you're not at their level of proficiency yet. We all see problems differently, and learning how to decompose complex problems and coding solutions for them is something we all do slightly differently from one another (this is a known thing about humans learning, our 'mental models' are all unique). So sometimes seeing someone else do the same things you want to do can be very useful in learning good practice or just alternative ways to do something. I've learned a lot over the years in my career just by sitting next to other programmers. It's a very useful practice to get into.
25:00 regarding the AMBUSH flag, it's interesting to note that when you make a sound to wake monster up, they wait for visual contact. But it ignores the monster's line of sight. That means that even if the monster is facing away and you move so _you can see it,_ it'll turn around and start attacking without actually having to see you.
It's definitely one of those things that's greater than the sum of its parts. In this case, MUCH greater. Very simple systems, but stitched together in imaginative and complex ways.
The "pathfinding" in Doom is amazingly brilliant. It doesn't just walk directly toward you or bounce off walls, but it will actually follow walls using an amazingly simple process, which allows monsters to navigate through corridors and go around obstacles to find their way to the player. I tried to replicate this pattern in my own game, but I never got it to work right.
I love when you go into this level of depth. Many of the shorter vids that just discuss how a particular algorithm or tactic is used in a game can be interesting, but as someone who has studied these topics a bit I’m already familiar with the methods. But having never made a real video game, I find it far more fascinating to learn about how it all comes together in application.
It's interesting to see the differences between how Doom and Quake work, as someone who has had some experience with Quake modding. Most of these differences come from Quake having a scripting language ("QuakeC"). The biggest is that, instead of the basic FSM flowchart that all monsters use, all entities (not just monsters) use a system where they will set a time in the future where they will execute a function (almost everything sets this to "0.1 seconds from now", meaning effectively logic runs at 10 fps), as well as which function will be executed. This "think" system allows for for some very intricate behaviour to be defined, although most monsters follow the same basic structure as Doom's monster FSM (and some common functions that most monsters go through). "Spawn" became two states ("Stand" for standing still, "Walk" for walking along mapper-defined patrol paths), the "See" state is called "Run", there's no "Raise" state, and only one "Die" state that ends in a dead-end loop. Other smaller changes are that model animation frames are defined with each function, and there are chains of functions for each state that specify a model frame every 0.1 seconds, as well as the things to do on each of those functions (usually but not always this was the common AI function, but for attacks you would specify the attack function to use). Pain is handled differently; weaker monsters would always go into a pain state, but tougher monsters would use a chance based on the amount of damage that was done (more damage = more likely to pain); but there is now a pain cooldown that can be specified (usually 1 or 2 seconds depending on animation length; overridden to 5 seconds on Nightmare, even if the monster failed to actually do pain). And the gib check now has a target value that can be defined per monster, which makes it more possible to gib the toughest enemies with Quad Damage (and sometimes even without).
Yeah as a fellow Quake modder/coder I can attest to that. A funny quirk: if you look at how the movetogoal() function works, it's basically the same way as Doom does its bumping around, even down to the code level - almost as if they took it straight out of Doom and just made some adaptations. Given the amazingly rushed development of Quake it's understandable they'd try to reuse stuff from it. It still basically works in 2D, and you can clearly see the 3D element was an afterthought - it even brought up an inconsistency in height tracking for flying monsters, where for horizontal movement they track their .goalentity, while for flying height they follow their .enemy entity. Usually you don't notice that because in the id1 code, when a monster gets aggroed both fields get set to the same entity, but the inconsistency is there. In Arcane Dimensions there's an enemytarget system that decouples that to allow for flying monsters to always hover a set height above the player instead of being always at the same level - they track a dummy entity that's always hovering above their target. I also used it in Alkaline to create a "path_angry" system that decouples .enemy from .goalentity so they can track path points for movement while still aiming and directing their attacks at you
@@AIandGames something worth noting is that, unlike Doom, *everything* in Quake is an entity - the closest you'll get to an object type in QuakeC. They all share the same set of coder-defined properties, or "entity fields". So, in the game, a monster is an entity, the player is an entity, a door or a button is an entity, flying weapon projectiles are entities (with a limited lifetime), even the map itself is one, albeit a special one, the "world" or "worldspawn" as we call it. Among these properties, you can also have a few function callbacks that will fire when certain events happen upon the entity, that can be defined on a classname or even individual entity basis. So, what happens when it'll get hurt, when it gets killed, when it touches something, when it gets "used" (when another map entity targets it, like pressing a button to open a door), and so on. It means that anything can have a health and effectively be killed for example. In fact that's what happens when you shoot a button or a secret door, they have a health value set, are marked as shootable, and have their own .th_die function callback set that will tell them what to do when that happens - fire its targets, move a certain way, etc. That's also why they "bleed" when you shot them - it's the exact same codepath that handles monster damage. In monsters, each classes' th_die callback will do the health check if their negative health is enough gib or not, and call their respective death animations otherwise.
Your ability to synthesize technical information into an educational and entertaining video is surpassed only by your wonderful voice. Great Scot, keep up the great work!
It's amazing how much they improve from Wolfenstein to Doom within less than a year of work. Then again, it is made by AI god in human form, John Carmack
It sounds like you were less able to suppress the Scottish-ness in this episode's narration! Also, for anyone at all interested in the nuts and bolts of DEWM, you owe it to yourself to check decino's channel! He's done A.I videos like this one, but also stuff like the sources for the game's audio and interesting tidbits about the sprites!
Great video, thanks. I remember downloading the shareware version back in the early 90s using my dial up modem and then playing doom all night on my 386DX40 PC. The following weekend we dragged our PCs to a friends house to play together all weekend, good times.
The Doom AI has some quirks skipped over here too. Like how you can get 2 barons of hell to infight. If one baron explodes a barrel and the splash damage hits a 2nd one, they will infight. There's also a thing where pain state makes it so that the next action is (almost) guaranteed to be an attack.
I'd love to see more videos exploring the source code of existing games! 🤩 Sometimes understanding their architecture is as interesting as knowing which techniques they use!
A Scotsman saying ‘Rrrrip your face out’ sounds terrifying. Your dialect sounds awesome and terrific. Don’t even feel the need to deal it down. Also: nice things for you.
Over the summer I keep thinking 'I wanna write something like the original Doom!' but I know I'll get distracted after a while and give up. It breaks my brain when I remember that the team behind this made it in their basement. King shit honestly. Those were the days! Great job as always. I'm so glad I found your channel lol, it's made me think a lot more critically about the games I play since I'm learning possible approaches to my own games!
Nobody says nice things about you? Time to change that! Love your videos, content, and enthusiasm! You do a great job of breaking down technical information into digestible bits! Love to see DOOM content, and always look forward to this series.
38 seconds in and this video should have more views, nice cuts and edits. Then that voice, Just right for the narration of such a video. 50 seconds in and I'm liking this.
Love these videos. I'm tinkering with basic AI in simple python games and it's really interesting to see how solutions were found in older games. Oddly enough, I settled on a 'zones' idea for a procedural map generator I created - fun to find out that Doom incorporated something similar! Keep up the good work!
Doom is my first video game I played at the ripe age of 2! Had nightmares every night, but I played it unconditionally. My dad thought the graphics was so poor, so blood etc. didn’t really have an impact.
Minor correction: gib(s) is pronounced "jib(s)" (like giblets). The term itself actually originated from the word giblets, and was coined by Adrian Carmack!
Its funny that I saw this video today. Over the past 24 hours or so Ive been implementing an FSM for a javascript remake of double dragon (using the original graphics - itll never be released, Im simply doing it for fun and possibly to add to my CV). Anywho... up until yesterday Id never implemented an FSM. Id heard of them with regards to dealing with animation, movement, actions etc so it seemed like a good time to implement one. The funny part is that the basic building blocks in doom are pretty much exactly what Ive now added to the game. Its just nice to know that Im at least kinda doing it right :) As Im always on the lookout for new puzzles to get my teeth into, Im now considering creating a simple fps in three js (for the mapping) and phaser (for sprite manipulation). Of course thatll be after double dragon is finished and the other 3 games im working on XD
Hi. Thanks for this great overview video of DOOM's AI. I'd love to see something like this reviewing aspects of Duke 3D's source code, which has also been made public.
Came to say nice things. And there’s a lot to say. I stumbled across this rather than anyone else’s video. And just as with caterpillar styled cakes I agree you’re free to make your own. I enjoyed the content a lot. I guess being an original DOOM /DOOM II fan and a techy it was right up my sector. I’m still talking state machines in my daily work so I think I will now smile at the thought that some of them should probably xdie. It’s a while since I played with wad files but it no doubt helped me on my techy journey through life so I’m glad I did. Thanks for adding a new dimension to my love of doom. I’m currently replaying it on PS4.
Doom on the Snes limited sprite sets to just the front facing set. This meant the enemies were always facing you, and always saw you. It was very tough compared to the pc version.
Hey, i think there is a mistake in gibbing section. Only few monsters have xdeath state and therefore a gibbing animation (with according xdeath state) could be ran. Cyberdemon, as mentioned in the video, doesn't have one and can not be gibbed even when damaged for 8000+ dmg. I suppose, if you edit the code by adding Xdeath state and corresponding animation sprites, it could work for cyberdemon. Anyway, thank you for the video, it's always nice to see some tech details
I'm 2/3 of the way through this video, and while I've learned a lot, I think the most entertaining thing I've learned is that Doom (and I have no idea the order of anything to do with Doom, so please excuse me) at some point... Had enemies... With Roomba logic.
Hearing you talk about Doom makes me want to hear you talk about a predecessor to the game. Not Wolfenstein 3d. But, a game that in a way, inspired Wolfenstein 3d. That would be Ultima: Underworld. It could be argued that Ultima: Underworld used a relative of a Goal-Oriented Action Planner.
Dewds. I have watched many DOOM vids over the years but for whatever reason this one actually gave me the nostalgia tickles bringing me back to my kidship marveling at the game's awesomeness and technical magic.
I've noticed those sound pipes before but never thought they were a design trick to portal in monsters. Pretty awesome. Same for mf_ambush. Great video, even for a non dev.
I'm learning to use the doom builder and this helped me to understand a little more how the ai works. I find the sound pipes idea interesting. I may use it.
I think it'd be interesting to make a video on a game with a focus on Friendly AI or with teams on it, to see how the AI reacts to the player. Like In Republic Commando and your squadmates, or the original Battlefront games and show how the AI soldiers would prioritize what targets, or how they'd determine which command post to go to etc I feel like that'd be really interesting.
Barrels having a pain chance makes me wonder if ID experimented with them needing to be weakened before they exploded or more shots would be required to destroy them in an earlier iteration.
Whoa how does that sound tunnel work? That means that there is both a wall and a gap in that particular bit of the wall. I thought that wasn't possible due to the 2Dness of the game's map.
Well the sound doesn't really travel in 3D space, it simply checks to see if there is any area connected to the current room that isn't blocked and then states the sound is also audible in that area. So by creating a tiny sound corridor, the sound still 'travels' successfully.
Of course it's a finite state machine. Literally anything digital is a finite state machine. And anything analog, may have have an infinite number of states, but you can subdivide it into a finite number of states which have any substantial difference to each other, like it doesn't matter what the 10th digit after a decimal point is.
Yeah, technically. Technically you could never make a pushdown automaton because it'd need infinite memory, but that doesn't mean it's not a useful concept.
Wonder what Carmack would say about this code today. Too me it seems odd grouping AI behaviour together with rendering behaviour for example the logic for which sprite to show depending on angle to player
Hope you all enjoy this special 66(6)th episode on the AI of DEWM. But one thing I wanted to mention, specifically for all you programmers out there...
There's one part of this video that maybe sounded wrong when you heard it the first time. The pain chance variable can apparently be set to any value between 0 and 256. That doesn't sound right - and believe me, every time I listened to this video, I kept thinking it was a mistake. For anyone who is not a programmer, this doesn't sound right because it provides 257 unique values. It would make more sense to have 256 possible values, ranging from 0 to 255. That's because a number stored in an 8-bit integer can only have a value between 0 and 255. So it would make sense to use 256 values, so you can store the data in an 8-bit integer. So what's going on here?
The pain chance is absolutely capped at 256 and not 255. But when the probability test is executed to trigger the pain state, it checks if a randomly generated number (x) is less than pain chance (y). So it simply says if(x
The fact that the < operation is a tiny bit faster on a slower 386 CPU of the era than a
FYI. The word is "Gib" with a soft G (pronounced like "jib") and is short for "Giblets". This was verified during a conversation I had with Bran Hook back around '97.
Funnily enough this is an "issue" in the original Star Craft. Your troops have a chance to hit their target. This mainly comes into play when when a character is shooting at someone that has a higher elevation, given it a 1/3 (IIRC) chance to hit. But they _did_ use a 0-255 value, so even when both shooter and shooted-at are on the same elevation and you'd expect 100% hit chance, there is still a 1/255 chance of missing the shot.
@@JeffBoen This is another "gif" vs "jif" again, isn't it? I've rarely heard anyone refer to it as "jibbed" or "jiblets", and it doesn't sound right compared to the colloquially accepted version of it ("gif"/"gib").
@@nebuchadnezzer2436 Look up Brian Hook if you don't know who that is. I would think that the guys who wrote the actual code and coined the term would know, which is why I asked him when I got the chance 20+ years ago when Quake was released, but hey, think whatever you want.
Monster infighting is such a fantastic game mechanic, sadly very little modern game utilizes it, even Doom Eternal has it only scripte here and there and monsters dont hurt each other :(
True but the amount of monsters in Eternal would just make the game easier.
There is unscripted in fighting. If you start a fight and move far enough away they will start in fighting. It bugs me that it doesn't do damage at all.
We love this mechanic, too. Which is why we design opportunities to set it up in our Doom II mod. There's just something very satisfying about getting the bad guys to turn on each other and make your life easier.
Oh, it's Dragon Sector (The Remake) if yanyone wants to check it out.
It's not scripted, I once played horde mode and I saw on the other side of arena 2 arachnatrons were fighting with mancubus.
But yeah, they do not deal any damage to each other.
I remember playing with iddqd and going through levels trying to set all the monsters up to kill each other, lol
Two corrections:
- The frame rate _is_ capped at 35 FPS in the original DOS release. The released Linux Doom source code doesn't have the cap implemented, and source ports implement proper capping/uncapping alongside things like interpolation of monster positions.
- In the state graph, the XDie state should be connected to the Raise state as well, since even gibbed enemies can be resurrected by an Archvile. The state and therefore the animation isn't changed, so it plays in reverse a regular death animation, but otherwise there are no issues with it. Now, resurrecting _crushed_ enemies gets you some issues, but that's a different topic.
By the way: User-made maps often use a slightly different approach to the teleporter encounters. Instead of using physically connected "pipe" sectors connecting the dummy and target areas, which can be annoying to do in cramped and complex maps, the dummy and target sectors are instead joined together into one. They're then two distinct shapes on the map, but they share the same properties like tags, textures, and heights. In terms of sound propagation, they also act as one, so making noise in the target sector alerts monsters in a completely disconnected area many map units away. Very handy, though vanilla maps don't use it afaik because it wasn't discovered yet.
ofc that he's referring to the original game
@@rompevuevitos222 Yes, but he says the frame rate is uncapped as the renderer is not tied to the game logic. I don't know how much of the latter is true, but the former is not - in the original release, the frame rate _is_ capped at 35 FPS.
I played one of the new wads on ps4 earlier and i forget the name if it, but the map was huge and had lots of archviles. Eventually i had to admit i was impressed there were no closing doors in the whole map. if there were doors, the amount of ghost enemies would be insane
Hey there! I’m a big fan of your DOOM covers
Nicely done! One minor thing, the statement at 16:13 is a little misleading. Floor heights matter when calculating line of sight to the player. One example: From the starting room of map 8 of Doom II, go through the north door, and without using a weapon, carefully hug the west/left wall as you proceed north, and you'll only be seen by the Cacos to the east. Or, hug the east/right-hand wall and you'll only be seen by the Cacos to the west. Anyway, great video as usual. Cheers.
Here's a demonstration of the Doom II scenario described above: th-cam.com/video/3FmB_vIsBPw/w-d-xo.html
"Technically the barrels have a pain chance of zero. Which, y'know, makes sense because they're barrels."
Now that just makes me want a barrel pain state and animation implemented.
Barrel Pain State is a good name for a punk band.
A stubbed-toe hop would be awesome.
@@JJKoester Let's make that band...
Would be easy.
Here i am chuckling over thinking about a metal barrel full of acid screaming when shot.
Oh my God, the way they handled the sound propagation and 'sound-sight' is fascinating game design for the time.
Dat Intro
As someone who ultimately wants to get into programming for games, and is leaning towards learning C++ first, I really appreciate that you actually showed the text file so that we can get an idea of how things can be structured
(*puts on college professor hat*)
Even if you're just starting out, it's always interesting to see how other people write code. Even when you're not at their level of proficiency yet. We all see problems differently, and learning how to decompose complex problems and coding solutions for them is something we all do slightly differently from one another (this is a known thing about humans learning, our 'mental models' are all unique). So sometimes seeing someone else do the same things you want to do can be very useful in learning good practice or just alternative ways to do something. I've learned a lot over the years in my career just by sitting next to other programmers. It's a very useful practice to get into.
@@AIandGames My thoughts exactly, well said!
25:00 regarding the AMBUSH flag, it's interesting to note that when you make a sound to wake monster up, they wait for visual contact. But it ignores the monster's line of sight. That means that even if the monster is facing away and you move so _you can see it,_ it'll turn around and start attacking without actually having to see you.
Doom will never cease to fascinate me.
Whilst the thing is, basically, a very crude world built with sellotape and carboard, it is in essence, magic.
It's definitely one of those things that's greater than the sum of its parts. In this case, MUCH greater. Very simple systems, but stitched together in imaginative and complex ways.
Editing images to the metal beat is AMAZING
The "pathfinding" in Doom is amazingly brilliant. It doesn't just walk directly toward you or bounce off walls, but it will actually follow walls using an amazingly simple process, which allows monsters to navigate through corridors and go around obstacles to find their way to the player.
I tried to replicate this pattern in my own game, but I never got it to work right.
Gem of a channel to learn about ai in games
I love when you go into this level of depth. Many of the shorter vids that just discuss how a particular algorithm or tactic is used in a game can be interesting, but as someone who has studied these topics a bit I’m already familiar with the methods. But having never made a real video game, I find it far more fascinating to learn about how it all comes together in application.
It's interesting to see the differences between how Doom and Quake work, as someone who has had some experience with Quake modding. Most of these differences come from Quake having a scripting language ("QuakeC").
The biggest is that, instead of the basic FSM flowchart that all monsters use, all entities (not just monsters) use a system where they will set a time in the future where they will execute a function (almost everything sets this to "0.1 seconds from now", meaning effectively logic runs at 10 fps), as well as which function will be executed. This "think" system allows for for some very intricate behaviour to be defined, although most monsters follow the same basic structure as Doom's monster FSM (and some common functions that most monsters go through). "Spawn" became two states ("Stand" for standing still, "Walk" for walking along mapper-defined patrol paths), the "See" state is called "Run", there's no "Raise" state, and only one "Die" state that ends in a dead-end loop.
Other smaller changes are that model animation frames are defined with each function, and there are chains of functions for each state that specify a model frame every 0.1 seconds, as well as the things to do on each of those functions (usually but not always this was the common AI function, but for attacks you would specify the attack function to use). Pain is handled differently; weaker monsters would always go into a pain state, but tougher monsters would use a chance based on the amount of damage that was done (more damage = more likely to pain); but there is now a pain cooldown that can be specified (usually 1 or 2 seconds depending on animation length; overridden to 5 seconds on Nightmare, even if the monster failed to actually do pain). And the gib check now has a target value that can be defined per monster, which makes it more possible to gib the toughest enemies with Quad Damage (and sometimes even without).
Yeah I think I'll need to do an episode on Quake eventually. Especially looking at how it evolves from DOOM. 🙂
Yeah as a fellow Quake modder/coder I can attest to that.
A funny quirk: if you look at how the movetogoal() function works, it's basically the same way as Doom does its bumping around, even down to the code level - almost as if they took it straight out of Doom and just made some adaptations. Given the amazingly rushed development of Quake it's understandable they'd try to reuse stuff from it.
It still basically works in 2D, and you can clearly see the 3D element was an afterthought - it even brought up an inconsistency in height tracking for flying monsters, where for horizontal movement they track their .goalentity, while for flying height they follow their .enemy entity. Usually you don't notice that because in the id1 code, when a monster gets aggroed both fields get set to the same entity, but the inconsistency is there. In Arcane Dimensions there's an enemytarget system that decouples that to allow for flying monsters to always hover a set height above the player instead of being always at the same level - they track a dummy entity that's always hovering above their target. I also used it in Alkaline to create a "path_angry" system that decouples .enemy from .goalentity so they can track path points for movement while still aiming and directing their attacks at you
@@AIandGames something worth noting is that, unlike Doom, *everything* in Quake is an entity - the closest you'll get to an object type in QuakeC. They all share the same set of coder-defined properties, or "entity fields". So, in the game, a monster is an entity, the player is an entity, a door or a button is an entity, flying weapon projectiles are entities (with a limited lifetime), even the map itself is one, albeit a special one, the "world" or "worldspawn" as we call it. Among these properties, you can also have a few function callbacks that will fire when certain events happen upon the entity, that can be defined on a classname or even individual entity basis. So, what happens when it'll get hurt, when it gets killed, when it touches something, when it gets "used" (when another map entity targets it, like pressing a button to open a door), and so on.
It means that anything can have a health and effectively be killed for example. In fact that's what happens when you shoot a button or a secret door, they have a health value set, are marked as shootable, and have their own .th_die function callback set that will tell them what to do when that happens - fire its targets, move a certain way, etc. That's also why they "bleed" when you shot them - it's the exact same codepath that handles monster damage.
In monsters, each classes' th_die callback will do the health check if their negative health is enough gib or not, and call their respective death animations otherwise.
Your ability to synthesize technical information into an educational and entertaining video is surpassed only by your wonderful voice.
Great Scot, keep up the great work!
The fact that you're talking the about code for a game that's 30 years old, it says a lot. Love Doom
It's amazing how much they improve from Wolfenstein to Doom within less than a year of work. Then again, it is made by AI god in human form, John Carmack
It sounds like you were less able to suppress the Scottish-ness in this episode's narration! Also, for anyone at all interested in the nuts and bolts of DEWM, you owe it to yourself to check decino's channel! He's done A.I videos like this one, but also stuff like the sources for the game's audio and interesting tidbits about the sprites!
dunnae supress that lad
Seconding Decino, the dude's amazing
That was some expert regurgitation! Loved the video. Didn't understand 90% of it.
I enjoyed this technical regurgitation. You're a nice person. Job done!
As a fellow Scot, I like how your accent got stronger as the video continued. Especially the rolling of the Rs.
Aye, I won't lie I did kinda ham it up a bit. 😉
Great video, thanks. I remember downloading the shareware version back in the early 90s using my dial up modem and then playing doom all night on my 386DX40 PC. The following weekend we dragged our PCs to a friends house to play together all weekend, good times.
The Doom AI has some quirks skipped over here too. Like how you can get 2 barons of hell to infight. If one baron explodes a barrel and the splash damage hits a 2nd one, they will infight. There's also a thing where pain state makes it so that the next action is (almost) guaranteed to be an attack.
10:59 - It makes me happy that someone else remembered that. I was thinking about it the whole time during pain chance discussion.
I'd love to see more videos exploring the source code of existing games! 🤩
Sometimes understanding their architecture is as interesting as knowing which techniques they use!
Watched the AI of Doom 93, crushed mi AI, trying to understand bits and pieces, concluded that in '93 those people that made doom were incredible.
"ouch that hurt!" said no barrel ever.
I really enjoyed you regurgitating technical facts on the internet.
A Scotsman saying ‘Rrrrip your face out’ sounds terrifying. Your dialect sounds awesome and terrific. Don’t even feel the need to deal it down. Also: nice things for you.
ooh, that's interesting, glad I don't have to worry about those kinds of micro-optimisations 😁
Over the summer I keep thinking 'I wanna write something like the original Doom!' but I know I'll get distracted after a while and give up. It breaks my brain when I remember that the team behind this made it in their basement. King shit honestly. Those were the days!
Great job as always. I'm so glad I found your channel lol, it's made me think a lot more critically about the games I play since I'm learning possible approaches to my own games!
Nobody says nice things about you? Time to change that!
Love your videos, content, and enthusiasm! You do a great job of breaking down technical information into digestible bits! Love to see DOOM content, and always look forward to this series.
Fantastic breakdown man
Really giving me ideas for enemy AI structures.
Great video/info, but I wanted to give a special shout-out to the editing at the beginning synching to the music.
38 seconds in and this video should have more views, nice cuts and edits. Then that voice, Just right for the narration of such a video. 50 seconds in and I'm liking this.
Love these videos. I'm tinkering with basic AI in simple python games and it's really interesting to see how solutions were found in older games. Oddly enough, I settled on a 'zones' idea for a procedural map generator I created - fun to find out that Doom incorporated something similar! Keep up the good work!
Great video, man. I needed a refresher and this really hit everything.
Doom is my first video game I played at the ripe age of 2! Had nightmares every night, but I played it unconditionally. My dad thought the graphics was so poor, so blood etc. didn’t really have an impact.
The graphics were amazing for the early 90s
10:37 Technically, the rocket counts as 2 hits, since the impact and splash damage are calculated separately.
Great video, I imagine you'll make Decino proud.
I have been playing Doom since I was like 12 years old, and only today I have realized level E1M1 is a plasma rifle
Remember, as Ahoy once said: "It's Gibs like giblets not Gib like goblet"
Holy hand grenades. You can really tell that the Doom devs were D&D players.
Gib as in giblets. Jibbed. Also, DOOM monsters do damage themselves; infighting.
Minor correction: gib(s) is pronounced "jib(s)" (like giblets). The term itself actually originated from the word giblets, and was coined by Adrian Carmack!
that is some crispy footage to go with some really cool information! Wish I'd had the same quality of footage when I reviewed the first two games
Its funny that I saw this video today. Over the past 24 hours or so Ive been implementing an FSM for a javascript remake of double dragon (using the original graphics - itll never be released, Im simply doing it for fun and possibly to add to my CV). Anywho... up until yesterday Id never implemented an FSM. Id heard of them with regards to dealing with animation, movement, actions etc so it seemed like a good time to implement one. The funny part is that the basic building blocks in doom are pretty much exactly what Ive now added to the game. Its just nice to know that Im at least kinda doing it right :)
As Im always on the lookout for new puzzles to get my teeth into, Im now considering creating a simple fps in three js (for the mapping) and phaser (for sprite manipulation).
Of course thatll be after double dragon is finished and the other 3 games im working on XD
21:10 I feel that this was personal :P
Hi. Thanks for this great overview video of DOOM's AI. I'd love to see something like this reviewing aspects of Duke 3D's source code, which has also been made public.
There's a list of projects on my to-do list and Duke 3D is certainly on there.
@@AIandGames Awesome!
Came to say nice things. And there’s a lot to say. I stumbled across this rather than anyone else’s video. And just as with caterpillar styled cakes I agree you’re free to make your own. I enjoyed the content a lot. I guess being an original DOOM /DOOM II fan and a techy it was right up my sector. I’m still talking state machines in my daily work so I think I will now smile at the thought that some of them should probably xdie. It’s a while since I played with wad files but it no doubt helped me on my techy journey through life so I’m glad I did. Thanks for adding a new dimension to my love of doom. I’m currently replaying it on PS4.
Would be funny if other characters could attack arch vile, because then he would kill them, revive them and kill them again
found this video by accident, very interesting and well presented, also for newbs like me who have basically no programming experience at all.
Doom on the Snes limited sprite sets to just the front facing set. This meant the enemies were always facing you, and always saw you. It was very tough compared to the pc version.
Hey, i think there is a mistake in gibbing section. Only few monsters have xdeath state and therefore a gibbing animation (with according xdeath state) could be ran. Cyberdemon, as mentioned in the video, doesn't have one and can not be gibbed even when damaged for 8000+ dmg. I suppose, if you edit the code by adding Xdeath state and corresponding animation sprites, it could work for cyberdemon. Anyway, thank you for the video, it's always nice to see some tech details
I'm 2/3 of the way through this video, and while I've learned a lot, I think the most entertaining thing I've learned is that Doom (and I have no idea the order of anything to do with Doom, so please excuse me) at some point... Had enemies... With Roomba logic.
Hearing you talk about Doom makes me want to hear you talk about a predecessor to the game. Not Wolfenstein 3d. But, a game that in a way, inspired Wolfenstein 3d. That would be Ultima: Underworld. It could be argued that Ultima: Underworld used a relative of a Goal-Oriented Action Planner.
I feel like AI and sky net will be our DOOM.
(rimshot)
Thanks so much for this deep dive. It's great to see how something like this was put together :)
I enjoyed the AI of DOOM 2016.
It is funny that the ENTRYway is not properly protected...
Absolutely amazing! Well done.
Dewds. I have watched many DOOM vids over the years but for whatever reason this one actually gave me the nostalgia tickles bringing me back to my kidship marveling at the game's awesomeness and technical magic.
Yes...Doom, my first FPS! Great video and amazing intro!
I've noticed those sound pipes before but never thought they were a design trick to portal in monsters. Pretty awesome. Same for mf_ambush. Great video, even for a non dev.
John Carmack was a goddamn mega genius!
Gib is short for giblets. It's pronounced with a J sound.
Well, you are nice. Thanks for the amazing video on the OG DOOM!
The original DOOM is such a fucking good game. Also, awesome video!
I'm learning to use the doom builder and this helped me to understand a little more how the ai works. I find the sound pipes idea interesting. I may use it.
What I liked about Doom and Doom 2 is when the bad guys accidentally shoot each other and they only start fighting.
20:48 that was so satisfying
0:00 This is the fucking INTERMISSION music from the game.
Just in case there is anyone out there that doesn't get what Doom is about.
I think it'd be interesting to make a video on a game with a focus on Friendly AI or with teams on it, to see how the AI reacts to the player.
Like In Republic Commando and your squadmates, or the original Battlefront games and show how the AI soldiers would prioritize what targets, or how they'd determine which command post to go to etc
I feel like that'd be really interesting.
Barrels having a pain chance makes me wonder if ID experimented with them needing to be weakened before they exploded or more shots would be required to destroy them in an earlier iteration.
If someone wants to know more, check out Decino's youtube channel.
I've just randomly come across this vid. Very entertaining and informative. You've got a new sub good sir.
An instant click, let's goo!
Whoa how does that sound tunnel work? That means that there is both a wall and a gap in that particular bit of the wall. I thought that wasn't possible due to the 2Dness of the game's map.
Well the sound doesn't really travel in 3D space, it simply checks to see if there is any area connected to the current room that isn't blocked and then states the sound is also audible in that area. So by creating a tiny sound corridor, the sound still 'travels' successfully.
Nice Things.....honestly fantastic video, thanks.
Yep... Barrels are silent monsters, but is more like an actor itself
I give you small pointless bonus point for correct pronunciation of Wolfenstein ... aaand I take it back for wrong pronunciation of gibbing.
When yer alone and life is getting you lonely, ye can always go ACH! DooMtoon!
Omg that reference. _[Chef's kiss]_
Absolutely fantastic =)
Very interesting.
Thanks!!
Of course it's a finite state machine. Literally anything digital is a finite state machine. And anything analog, may have have an infinite number of states, but you can subdivide it into a finite number of states which have any substantial difference to each other, like it doesn't matter what the 10th digit after a decimal point is.
Yeah, technically.
Technically you could never make a pushdown automaton because it'd need infinite memory, but that doesn't mean it's not a useful concept.
i studied FSM's in university. No wonder Doom is so easy to port to everything.
ONLY the Zombieman, Shotgunner, Chaingunner, and Imp even have gibbing states. You cannot gib a Cacodemon, for example.
So basically Roomba pathfinding
“Hellooo, I’m Scott Manley”
Awesome video. If you are interested, watch Decino's videos, since Doom mechanics are super interesting and he has a whole series about it.
Pretty sure Doom ran even on a 386SX. But to play Duke Nukem 3D I had to annoy my cousin, because his boyfriend had a 486 🙈
Wonder what Carmack would say about this code today. Too me it seems odd grouping AI behaviour together with rendering behaviour for example the logic for which sprite to show depending on angle to player
Funny that you called John Carmack a humble developer and not the eldritch mind-harvester that holds together all layers of the universe.
Neat!
Dope sick intro!
that modern remake of doom music in the intro is golden..but i think decino has beaten you on this topic
Awesome video! Glad I stumbled upon your channel. Liked, subscribed, commenting for the algorithm.
I have left a comment. May this help you with the cruel algorithm gods.
Also, cool vid.