Thanks for the lesson as always! do whatever you enjoy as content, that´s the most important. If there´s burnout, disconnect, health is first. When you decide to come back after refreshing your mind and soul, I´d like to throw a topic for you: data-oriented programming. Would be interesting to know your take on it and how you would apply it in a little example in Godot and if it would make sense at all.
Sorry, youtube ate notification and I discovered your comment randomly when checking dashboard(. So, DOD imo, is a nice tool if the task is right for it. Godot-wise I don't think it is suitable, because of the whole nodes thing. There is sort of "balance" between how abstraction-oriented or how data-oriented is your expressive mechanism provided by the engine/language is. And Godot's nodes are big in "describing reality", they are really good at helping you design your games with objects. DOD frameworks in general have a common feat - they sell programmer's comfort for being the fastest boy in the village. They often have structs instead of objects, they have a lot of static data tables, they gravitate to aspect-oriented ways where you "construct" descriptions for your concepts from a number of enumerations. And to be that fast they are relatively low level. Here the problem with Godot comes, I can invent some DOD-ish approaches and designs, but they will be exactly "data oriented designs" built on top of not so data oriented framework. And essentially what I'll achieve is I will lose all my perks as a human individual in describing my reality with objects. While simultaneously I won't get that x100 calculation prowess that dod frameworks usually provide. There is a small chance that I'll do a lil bevy engine as a treat, but no more than one or two vids and only because certain individuals I respect asking me to do this, I'm not an engine hopper and I won't be switching to something completely different fully.
@@PointDown thanks for the answer, yes it seems the use of structs, or Struct of Arrays to align data with memory to reduce memory usage and use the cache is key for this fast performance. I like the idea of having specific arrays that define a state, for example, if you are only interested in enemies very low in health, just add the to a separate array to avoid traversing all the enemies array, etc... but trying to visualize forward how I would apply DOD, I agree with use that I would naturally end up with a OOD and a few parts of DOD, and it´s actually very hard for me to imagine how a only-DOD codebase for a game would even look like... I guess I won´t wrap my head around until I delve deep in the procedural ways of assembly code. About the Beby engine feel free ofc it´s your channel! for me it´s about godot but I think it´s good knowing about other engines! Thanks again!
A parkour series would be neat indeed! Always wondered how that worked, but it seems to me that with godot's undercooked IK system it might be a bit of a nightmare. Don't beat yourself up about this one though, even just your "examples" i think are very valuable and far more interesting than most of the"tutorials" you mention. Extending your existing framework isn't as difficult as coming up with it in the first place, and you've more than shown its potential even with fairly basic behaviors.
Thanks for support ^^. Nah, parkour is fine, it doesn't use that much IK. Parkour animations do use "procedural crotches", but not IK ones, more like a whole root translation. For example we have an animation of jumping a lil bit and pulling ourselves up to a high edge. In this case to adapt to the height of any concrete edge what we do is we play all the same animation of bones, we just also do a lil parallel translation of a root bone in first several frames to adjust initial jump height. You'll need an eagle eye and probably an information about such thing being in place to recognize that "that jump's original height is 20 cm but we used it to jump 37 cm at firs 16 frames". I can't see much place to IK usage in parkour rn, mostly root rotations/translations. Obviously, the animations themselves were created with IK technology usage in 3d software, said self-pulling-up certainly had IK rig for hands on animation production stage, but when baked, they "forget" their past, it's just the bones movement, so that's a 3d artist problem, not Godot's :D.
hey, great videos! this subject interests me a lot and I wanted to ask you, how would you tackle simulating enemy behaviors offscreen? in like unloaded chunks. imagine a behavior for animals to roam the world, following paths (or navigating closest points). I imagine this would have to tracked somehow and updated not so often.
Whoooa, what a question! So, I don't know if I would even process anything in a completely unloaded chunk (speaking in minecraft terms I suppose). In a partially loaded or unseen world areas like "far end of location" or "behind city's walls" - idk, it depends on the game I suppose. Right now my mind drifts to two possible solutions: one is a standalone "makeshift behaviour", probably similar to wandering, but much more plain. Another idea is, see, an enemy is probably gets the information of "you are unloaded/behind 3 walls and put on slacking mode" from outside. It's hard to imagine an entity actively checking on how far a player is from it, I think it's a task for a different, bigger entity like location director or smth, that loads or unloads packs of entities. So, if we get that call, "you are put on minimal activity lifesupport mode", I find we can use a bunch of meta-information as well. For example, what prohibits us from activating all .disabled checkboxes aside from idle in that moment? Keep in mind that we also probably have other effects like hiding our hi-res model and showing a lowpoly one.
Hey! The struggles you’ve described are understandable and i think it’s a reasonable decision to stop/pause this series. You have already presented a bunch of interesting ideas that people can take and run with. And like, your vids are definitely not for beginners, so i suspect most people are already doing that rather than following step-by-step. But also, i suspect there’s another difficulty, not strictly systems-related: communication. No matter how awesome a system is under the hood, if it’s not communicating to the player what it’s doing, they’ll feel like it’s either cheating or random. Think of Half-Life: the soldiers are not super-complex, and somewhat predictable, but they seem reasonable and talk through what they’re doing out loud. Still a cool enemy after all these years! But apparently, some of the enemies have a sense of smell and can even track the player using it. Really cool, but not obvious in the game at all. Establishing this communication is a design/art challenge in itself, but without it, even an extremely complex enemy might appear less interesting than a more straightforward but expressive one.
let's gooooooooooo fair flight dropped
Thanks for the lesson as always! do whatever you enjoy as content, that´s the most important. If there´s burnout, disconnect, health is first. When you decide to come back after refreshing your mind and soul, I´d like to throw a topic for you: data-oriented programming. Would be interesting to know your take on it and how you would apply it in a little example in Godot and if it would make sense at all.
Sorry, youtube ate notification and I discovered your comment randomly when checking dashboard(.
So, DOD imo, is a nice tool if the task is right for it. Godot-wise I don't think it is suitable, because of the whole nodes thing. There is sort of "balance" between how abstraction-oriented or how data-oriented is your expressive mechanism provided by the engine/language is. And Godot's nodes are big in "describing reality", they are really good at helping you design your games with objects. DOD frameworks in general have a common feat - they sell programmer's comfort for being the fastest boy in the village. They often have structs instead of objects, they have a lot of static data tables, they gravitate to aspect-oriented ways where you "construct" descriptions for your concepts from a number of enumerations. And to be that fast they are relatively low level. Here the problem with Godot comes, I can invent some DOD-ish approaches and designs, but they will be exactly "data oriented designs" built on top of not so data oriented framework. And essentially what I'll achieve is I will lose all my perks as a human individual in describing my reality with objects. While simultaneously I won't get that x100 calculation prowess that dod frameworks usually provide.
There is a small chance that I'll do a lil bevy engine as a treat, but no more than one or two vids and only because certain individuals I respect asking me to do this, I'm not an engine hopper and I won't be switching to something completely different fully.
@@PointDown thanks for the answer, yes it seems the use of structs, or Struct of Arrays to align data with memory to reduce memory usage and use the cache is key for this fast performance. I like the idea of having specific arrays that define a state, for example, if you are only interested in enemies very low in health, just add the to a separate array to avoid traversing all the enemies array, etc... but trying to visualize forward how I would apply DOD, I agree with use that I would naturally end up with a OOD and a few parts of DOD, and it´s actually very hard for me to imagine how a only-DOD codebase for a game would even look like... I guess I won´t wrap my head around until I delve deep in the procedural ways of assembly code. About the Beby engine feel free ofc it´s your channel! for me it´s about godot but I think it´s good knowing about other engines! Thanks again!
A parkour series would be neat indeed! Always wondered how that worked, but it seems to me that with godot's undercooked IK system it might be a bit of a nightmare.
Don't beat yourself up about this one though, even just your "examples" i think are very valuable and far more interesting than most of the"tutorials" you mention.
Extending your existing framework isn't as difficult as coming up with it in the first place, and you've more than shown its potential even with fairly basic behaviors.
Thanks for support ^^.
Nah, parkour is fine, it doesn't use that much IK. Parkour animations do use "procedural crotches", but not IK ones, more like a whole root translation. For example we have an animation of jumping a lil bit and pulling ourselves up to a high edge. In this case to adapt to the height of any concrete edge what we do is we play all the same animation of bones, we just also do a lil parallel translation of a root bone in first several frames to adjust initial jump height. You'll need an eagle eye and probably an information about such thing being in place to recognize that "that jump's original height is 20 cm but we used it to jump 37 cm at firs 16 frames". I can't see much place to IK usage in parkour rn, mostly root rotations/translations. Obviously, the animations themselves were created with IK technology usage in 3d software, said self-pulling-up certainly had IK rig for hands on animation production stage, but when baked, they "forget" their past, it's just the bones movement, so that's a 3d artist problem, not Godot's :D.
hey, great videos! this subject interests me a lot and I wanted to ask you, how would you tackle simulating enemy behaviors offscreen? in like unloaded chunks. imagine a behavior for animals to roam the world, following paths (or navigating closest points). I imagine this would have to tracked somehow and updated not so often.
Whoooa, what a question! So, I don't know if I would even process anything in a completely unloaded chunk (speaking in minecraft terms I suppose). In a partially loaded or unseen world areas like "far end of location" or "behind city's walls" - idk, it depends on the game I suppose. Right now my mind drifts to two possible solutions: one is a standalone "makeshift behaviour", probably similar to wandering, but much more plain. Another idea is, see, an enemy is probably gets the information of "you are unloaded/behind 3 walls and put on slacking mode" from outside. It's hard to imagine an entity actively checking on how far a player is from it, I think it's a task for a different, bigger entity like location director or smth, that loads or unloads packs of entities. So, if we get that call, "you are put on minimal activity lifesupport mode", I find we can use a bunch of meta-information as well. For example, what prohibits us from activating all .disabled checkboxes aside from idle in that moment? Keep in mind that we also probably have other effects like hiding our hi-res model and showing a lowpoly one.
Noice!
Hey! The struggles you’ve described are understandable and i think it’s a reasonable decision to stop/pause this series. You have already presented a bunch of interesting ideas that people can take and run with. And like, your vids are definitely not for beginners, so i suspect most people are already doing that rather than following step-by-step.
But also, i suspect there’s another difficulty, not strictly systems-related: communication. No matter how awesome a system is under the hood, if it’s not communicating to the player what it’s doing, they’ll feel like it’s either cheating or random. Think of Half-Life: the soldiers are not super-complex, and somewhat predictable, but they seem reasonable and talk through what they’re doing out loud. Still a cool enemy after all these years!
But apparently, some of the enemies have a sense of smell and can even track the player using it. Really cool, but not obvious in the game at all.
Establishing this communication is a design/art challenge in itself, but without it, even an extremely complex enemy might appear less interesting than a more straightforward but expressive one.