@@NesiAwesomeness The pattern is 3 non interlaced frames, then there's 2 interlaced frames. If you go frame by frame in the video (in places with movement) you'll see frames where two other frames have been combined into one with alternating lines.
1:21 - Knee-jerk reaction is to give a weak pointer to allow for this interaction. I do not know about your codebase at this point so I am assuming a C-like language that should have the ability to do this interaction. This weak pointer can be changed based on the last interacted aircraft of the player rather than hardcoded to the one you have on the screen now. 2:15 - Although I agree that keeping information private is ideal and probably the best solution, you can prevent tampering with information given by sending const data rather than a pointer to the object. Although you may be creating a copy of that variable or class when you request it, the optimizer may remove that and use a reference under the hood; so that may not be a concern. 2:46 - To shortcut this, you could give a weak reference to the player. This would allow you to send information of state change in the Aircraft State Machine (ASM for brevity) to the Player. The player then can have the responsibility to read those events or ignore them as desired. In your example, the last known state change of the ASM will determine the business logic of the Player in changing his State Machine. The difference from this and my knee-jerk reaction would be that the ASM can either post updates or the Player can poll updates. I like this suggestion better. 4:20 - Not sure if this is the best approach. Basically, it just adds the data from the State into the base class. Yes, you will not need to add additional code to each class, but it still requires functions to reach into another class to get the data it needs for evaluation. One way this problem can present itself is if you are referencing the object multiple times in the same function and during evaluation the object becomes null. Now this may not happen as often so may be difficult to reproduce and would be very tricky to even figure out why the program crashed in the first place depending on your language. Final assessment: Although I think you found a clever idea to deal with this issue, you may be able to reduce future complications in your code if you lock the aircraft state before evaluating it. My suggestion would be to move into more of an event driven paradigm where you send (publish) the state of the aircraft when it changes, and anyone can read (subscribe/observe) the changes if they want to know the latest change. This would create a more complicated situation, but would allow multiple NPCs/players to interact with the aircraft in the future (2-seater aircraft, etc.) Also allow and NPC and player to monitor the same aircraft for whatever reason. Note: I do think that your solution was very innovative and want to also say that these are just opinions/suggestions and there may be much better ways than what I presented. I am not writing the code and so cannot and should not have a perspective on what you should do. These are just considerations to make if they seem helpful.
I agree with the use of godots signals (observer pattern), but I don't believe godot has any sort of pointers you can use (from my understanding it's more similar to python) although if something like that does exist then let me know cuz that would be useful :O
I mostly send signals, but also if I have a bunch of stuff referencing something, I use custom resources. Like a resource that's PlaneData that the plane updates and has things like it's state, but the resource can be attached to anything that needs to references it, like the player. If you accidently change the variable that stores the plane state in the resource from the player, it doesn't affect the plane itself, just some variable in a resource that only references the plane.
My approach would be to not allow the player to access the plane's state machine or manipulate the plane directly. The player shouldn't fly the plane; instead, the plane itself should handle the inputs. This way, when the plane explodes, all the player needs to know is that the plane no longer exists and can exit out of the pilot state. As for ejection, the player is in the plane and has its own sub state machine component to keep track of whether it is Landed or Flying. The player can switch to the Ejection State or any other to state. Ideally, if you've implemented this correctly, you can reuse the code from the plane's state management for the player's sub state while InPilot. This way both keep track of their own internal state and are loosely coupled. I don't know your code, hopefully this helps. Edit: I thought on this a bit more, if you want npcs to use the same code, given this approach, you probably have to tack on separate component that just interfaces with the npcs.
@@legocloneguy1 that's actually really neat, like super idea. That's mostly how my code functions, the player's script controls the plane and handles inputs just doesn't keep the plane's state in its own "Flight" substate.
Without knowing your code it's impossible to say what the best solution is, but using meta data seems like a cheap way to avoid designing the system with the correct interfaces and dependencies. You say "circular reference" when referring to the player and plane having a reference to each other, but in reality this is just a coupling. Yes we like to decouple, but in this situation does it not make sense for the plane to have a reference to its pilot, and vice versa? You can abstract the player to an even more minimal pilot interface that other classes like NPCs could use if that's a concern. The pilot interface requires an Eject function be implemented, and then you implement the pilot interface on the player.
@@HappyGhetto I do have a piloting interface, I just didn't include that into the video because I felt it was beyond the scope of what I was trying to get across but the "Piloting" script is seperate from the player and can be use just like the state machine. If it's best practice to decouple why not just do that. I figured it might be easier but I just prefer to be on the safe side and find another way.
@@NesiAwesomeness If you want to avoid coupling you could create an interface like IStateMachineOwner that has a GetCurrentState method. Yes this is boilerplate, and I understand you wanted to avoid adding code to every object that has the state machine, but it's more robust than using meta data imo. You can add other things you might need to the interface too. Anyway, I think it's great you're making these kind of videos and are trying to strive for good design, keep it up!
I haven't gone though this problem yet, so I'm not even sure if my propositions work, but I'll throw my hat in as a comment for the sake of the algorithm. I think I would have gone with option 2 with some modifications: Either define my signals in my event bus, or make a new event bus just for my state machine to decouple the signal from the emitter. So (I'm guessing) even if the code that emits the signal is destroyed, you won't have the null problem in your player script. If I wanted to avoid an event bus, I might play around with a clean up function before calling queue_free() on the plane that calls get_connections() on all my signal, and manually disconnecting them before freeing the node. (but again I haven't tried this and I'm not even sure if this works the way I think it does lol). Thanks for the videos, man. This is the first time I learned about set_meta. Hope to see and learn more!
Thanks for the tip, I actually did that first as well. But I didn't want to have just one plane connected to the Message Bus as they were going to be multiple plane in the game and multiple NPCs also entering planes and I didn't want a case where the camera would follow a plane an NPC entered because the signal from that plane was connected to the message bus even though it isn't the player that entered it. So I decided to just keep all code that references the message bus to the player script.
I'm not currently making the game I plan to make, instead I'm currently making backend and frontend software. But when I do it's in my plans to try to only use low level code for rendering, scene data manipulation/construction, and handling inputs. though ideally unreal engine would handle that all for me well enough that I barely have to touch it. And then I just use a higher level language on top since everything else that makes up a game doesn't use very many resources. Higher level languages mean you don't have to manage memory, you can utilize dynamic programming for faster development, utilize insane language features super smart people have made like virtual threads, and if it's a lisp you can create you're own DSL as easily as writing normal code(just don't create an abomination, especially if you're sharing the codebase with others). The higher level languages that are in my considerations are janet lang, and clojure(I may want to compile it to native using graalvm rather than using a JVM). There aren't a ton of lisp lanuages that exist, this is for many reasons, but janet lang and clojure should be able to cover everything, espectialy if Java's JNI successor or the jank lang dialect of clojure is done by the time I start, since interop with lower level code will be a lot simpler meaning I have to get annoyed by it even less. If I had to write low-level code for rendering, scene data manipulation/construction, or input handling due to the game engine not having what I need Id probably try to use roc or nim. Nim tries really hard to help you reduce state like clojure does, as well as help you make a DSL as easily as possible considering it isn't a lisp and so it's inherently a lot harder. Roc tries really hard to use smart compilation techniques leveraging modern memory constructions to find ways to retain many abstractions that are typically considered higher level, but without incurring a performance cost. But I haven't looked into how well those languages would interop with the existing game engines, though most stuff interops with C relatively well. A big consideration here is that my game doesn't need some super novel game engine, rendering technique, shader aesthetic, or anything else like that. Though it's worth mentioning that almost all games people make also fulfill this constraint. But lots of game developers seem to really like working on that "game engine" style stuff... at least the game developers I see on UA-cam, even though the games are making don't need that.
@@faytruefireside I use Godot, GDScript is a pretty high level language. Some systems do require a lot of thought just to make sure you're follow like "best practices". I actually knew you'd say unreal maybe I'll try that out too someday but Godot is just super convenient
@@NesiAwesomeness Yah unreal just has some insane rendering performance capabilities and rendering quality of life stuff. And we all know that our games get low on FPS way too quickly while developing them. Plus unreal costs like nothing to use. You have to make 1 million before you pay anything and even after that its 5%. For the vast majority of games its cheaper then unity.
in an OO language you could only have a public get_state method and protected set_state, perhaps this is possible in c#? i've never gone that route or if that is one of the benefits to it. secondly, im not sure having circular signals is an issue. its a pub/sub system so there isn't really a broken reference or maybe i'm missing something. thirdly, if what you got works, goodjob :) i wouldn't worry too much about re-factoring now unless it becomes a problem, and explore other options on the next game
@@Xanhast thanks so much, I'm probably just not educated enough to understand how variables can be protected. Someone mentioned using "constants" somehow
@@NesiAwesomeness yeah im not sure in gdscript either, and why i suggested c# might be a better choice for these relatively abstract components that are implementing more OO ideas, where as gdscript is designed to be great for gameplay elements that you can iterate on quickly without worrying about strict typing and protected members etc
Why's the video interlaced?
I have no idea what that is. I just used the UA-cam preset on DaVinci Resolve.
@@NesiAwesomeness The pattern is 3 non interlaced frames, then there's 2 interlaced frames.
If you go frame by frame in the video (in places with movement) you'll see frames where two other frames have been combined into one with alternating lines.
@@sinus4784 yh I googled it, thanks so much I hope it didn't take too much away from the video?
@@NesiAwesomeness It doesn't :)
I just wanted to mention it as it does look a little odd
1:21 - Knee-jerk reaction is to give a weak pointer to allow for this interaction. I do not know about your codebase at this point so I am assuming a C-like language that should have the ability to do this interaction. This weak pointer can be changed based on the last interacted aircraft of the player rather than hardcoded to the one you have on the screen now.
2:15 - Although I agree that keeping information private is ideal and probably the best solution, you can prevent tampering with information given by sending const data rather than a pointer to the object. Although you may be creating a copy of that variable or class when you request it, the optimizer may remove that and use a reference under the hood; so that may not be a concern.
2:46 - To shortcut this, you could give a weak reference to the player. This would allow you to send information of state change in the Aircraft State Machine (ASM for brevity) to the Player. The player then can have the responsibility to read those events or ignore them as desired. In your example, the last known state change of the ASM will determine the business logic of the Player in changing his State Machine. The difference from this and my knee-jerk reaction would be that the ASM can either post updates or the Player can poll updates. I like this suggestion better.
4:20 - Not sure if this is the best approach. Basically, it just adds the data from the State into the base class. Yes, you will not need to add additional code to each class, but it still requires functions to reach into another class to get the data it needs for evaluation. One way this problem can present itself is if you are referencing the object multiple times in the same function and during evaluation the object becomes null. Now this may not happen as often so may be difficult to reproduce and would be very tricky to even figure out why the program crashed in the first place depending on your language.
Final assessment: Although I think you found a clever idea to deal with this issue, you may be able to reduce future complications in your code if you lock the aircraft state before evaluating it. My suggestion would be to move into more of an event driven paradigm where you send (publish) the state of the aircraft when it changes, and anyone can read (subscribe/observe) the changes if they want to know the latest change. This would create a more complicated situation, but would allow multiple NPCs/players to interact with the aircraft in the future (2-seater aircraft, etc.) Also allow and NPC and player to monitor the same aircraft for whatever reason.
Note: I do think that your solution was very innovative and want to also say that these are just opinions/suggestions and there may be much better ways than what I presented. I am not writing the code and so cannot and should not have a perspective on what you should do. These are just considerations to make if they seem helpful.
@@danielmiller8223 thanks so much, I'll see what I can do to try this.
I'll have to read up on "weak pointers" and all that jazz. Thanks again.
I agree with the use of godots signals (observer pattern), but I don't believe godot has any sort of pointers you can use (from my understanding it's more similar to python) although if something like that does exist then let me know cuz that would be useful :O
I mostly send signals, but also if I have a bunch of stuff referencing something, I use custom resources. Like a resource that's PlaneData that the plane updates and has things like it's state, but the resource can be attached to anything that needs to references it, like the player. If you accidently change the variable that stores the plane state in the resource from the player, it doesn't affect the plane itself, just some variable in a resource that only references the plane.
My approach would be to not allow the player to access the plane's state machine or manipulate the plane directly. The player shouldn't fly the plane; instead, the plane itself should handle the inputs. This way, when the plane explodes, all the player needs to know is that the plane no longer exists and can exit out of the pilot state. As for ejection, the player is in the plane and has its own sub state machine component to keep track of whether it is Landed or Flying. The player can switch to the Ejection State or any other to state. Ideally, if you've implemented this correctly, you can reuse the code from the plane's state management for the player's sub state while InPilot. This way both keep track of their own internal state and are loosely coupled. I don't know your code, hopefully this helps. Edit: I thought on this a bit more, if you want npcs to use the same code, given this approach, you probably have to tack on separate component that just interfaces with the npcs.
@@legocloneguy1 that's actually really neat, like super idea.
That's mostly how my code functions, the player's script controls the plane and handles inputs just doesn't keep the plane's state in its own "Flight" substate.
Without knowing your code it's impossible to say what the best solution is, but using meta data seems like a cheap way to avoid designing the system with the correct interfaces and dependencies. You say "circular reference" when referring to the player and plane having a reference to each other, but in reality this is just a coupling. Yes we like to decouple, but in this situation does it not make sense for the plane to have a reference to its pilot, and vice versa? You can abstract the player to an even more minimal pilot interface that other classes like NPCs could use if that's a concern. The pilot interface requires an Eject function be implemented, and then you implement the pilot interface on the player.
@@HappyGhetto I do have a piloting interface, I just didn't include that into the video because I felt it was beyond the scope of what I was trying to get across but the "Piloting" script is seperate from the player and can be use just like the state machine.
If it's best practice to decouple why not just do that. I figured it might be easier but I just prefer to be on the safe side and find another way.
@@NesiAwesomeness If you want to avoid coupling you could create an interface like IStateMachineOwner that has a GetCurrentState method. Yes this is boilerplate, and I understand you wanted to avoid adding code to every object that has the state machine, but it's more robust than using meta data imo. You can add other things you might need to the interface too. Anyway, I think it's great you're making these kind of videos and are trying to strive for good design, keep it up!
@@HappyGhetto omg oop coders are the worst
@@feivmoon How would you solve his problem? I'm not familar with GDScript, I come from unreal so yes I'm more familiar with OOP.
Great vid. Nice editing. I must look into metadata soon.
You should
I haven't gone though this problem yet, so I'm not even sure if my propositions work, but I'll throw my hat in as a comment for the sake of the algorithm. I think I would have gone with option 2 with some modifications:
Either define my signals in my event bus, or make a new event bus just for my state machine to decouple the signal from the emitter. So (I'm guessing) even if the code that emits the signal is destroyed, you won't have the null problem in your player script.
If I wanted to avoid an event bus, I might play around with a clean up function before calling queue_free() on the plane that calls get_connections() on all my signal, and manually disconnecting them before freeing the node. (but again I haven't tried this and I'm not even sure if this works the way I think it does lol).
Thanks for the videos, man. This is the first time I learned about set_meta. Hope to see and learn more!
Thanks for the tip, I actually did that first as well. But I didn't want to have just one plane connected to the Message Bus as they were going to be multiple plane in the game and multiple NPCs also entering planes and I didn't want a case where the camera would follow a plane an NPC entered because the signal from that plane was connected to the message bus even though it isn't the player that entered it.
So I decided to just keep all code that references the message bus to the player script.
I do not envy the added difficulty making games due to stuff needing* everything* to be in a low level language and be based on inheritance.
I'm not currently making the game I plan to make, instead I'm currently making backend and frontend software. But when I do it's in my plans to try to only use low level code for rendering, scene data manipulation/construction, and handling inputs. though ideally unreal engine would handle that all for me well enough that I barely have to touch it.
And then I just use a higher level language on top since everything else that makes up a game doesn't use very many resources.
Higher level languages mean you don't have to manage memory, you can utilize dynamic programming for faster development, utilize insane language features super smart people have made like virtual threads, and if it's a lisp you can create you're own DSL as easily as writing normal code(just don't create an abomination, especially if you're sharing the codebase with others).
The higher level languages that are in my considerations are janet lang, and clojure(I may want to compile it to native using graalvm rather than using a JVM). There aren't a ton of lisp lanuages that exist, this is for many reasons, but janet lang and clojure should be able to cover everything, espectialy if Java's JNI successor or the jank lang dialect of clojure is done by the time I start, since interop with lower level code will be a lot simpler meaning I have to get annoyed by it even less.
If I had to write low-level code for rendering, scene data manipulation/construction, or input handling due to the game engine not having what I need Id probably try to use roc or nim.
Nim tries really hard to help you reduce state like clojure does, as well as help you make a DSL as easily as possible considering it isn't a lisp and so it's inherently a lot harder.
Roc tries really hard to use smart compilation techniques leveraging modern memory constructions to find ways to retain many abstractions that are typically considered higher level, but without incurring a performance cost.
But I haven't looked into how well those languages would interop with the existing game engines, though most stuff interops with C relatively well.
A big consideration here is that my game doesn't need some super novel game engine, rendering technique, shader aesthetic, or anything else like that. Though it's worth mentioning that almost all games people make also fulfill this constraint.
But lots of game developers seem to really like working on that "game engine" style stuff... at least the game developers I see on UA-cam, even though the games are making don't need that.
@@faytruefireside I use Godot, GDScript is a pretty high level language.
Some systems do require a lot of thought just to make sure you're follow like "best practices".
I actually knew you'd say unreal maybe I'll try that out too someday but Godot is just super convenient
@@NesiAwesomeness Yah unreal just has some insane rendering performance capabilities and rendering quality of life stuff. And we all know that our games get low on FPS way too quickly while developing them.
Plus unreal costs like nothing to use. You have to make 1 million before you pay anything and even after that its 5%. For the vast majority of games its cheaper then unity.
@@faytruefireside unreal is such a great choice, I just don't have the hardware for it, Godot is just super light weight
@@NesiAwesomeness I hope you arnt stuck with poor hardward forever,
thats pretty cool i didnt know that
@@Húhú202ehhe thank you
Kinda crazy that the algrithim hasbt bosted this video more
@@CopperCrownDummyWhoMakesGames it should I need more people's takes
in an OO language you could only have a public get_state method and protected set_state, perhaps this is possible in c#? i've never gone that route or if that is one of the benefits to it.
secondly, im not sure having circular signals is an issue. its a pub/sub system so there isn't really a broken reference or maybe i'm missing something.
thirdly, if what you got works, goodjob :) i wouldn't worry too much about re-factoring now unless it becomes a problem, and explore other options on the next game
@@Xanhast thanks so much, I'm probably just not educated enough to understand how variables can be protected.
Someone mentioned using "constants" somehow
@@NesiAwesomeness yeah im not sure in gdscript either, and why i suggested c# might be a better choice for these relatively abstract components that are implementing more OO ideas, where as gdscript is designed to be great for gameplay elements that you can iterate on quickly without worrying about strict typing and protected members etc
hopefully someone with more godot experience can confirm tho, i've not tried c# in godot but have wider programming experience
First comment