Відео

OMG I litearlly was thinkging the same thing and i didn't know what to do ;.; ... ty for conceptualizing it

Honestly, just add 2 constructors to the base titan, an empty one that automatically randomizes the stats, and one that requires you to pass the stats as arguments.. I get the whole inheritance vs. composition debate, but I've honesty never had to use composition because any problem that could be fixed with composition could also be fixed with a smarter inheritance system.

One thing to keep in mind for anyone using composition and overall just trying their best to make good code: PROTOTYPING IS GOOD, DO IT! You do NOT want to be the person that spends a year (learning how to and then) creating a versatile system full of state machines and scripts for every little thing you could ever need only to then find out that Godot's 3D hinges are the most confusing thing ever and therefore you either need to spend god knows how long learning the intricacies of Godot's physics engine to make a version of them that does what you want or just give up the project entirely. BEING ABLE TO JUST MAKE SOME *REALLY* **REALLY** BAD CODE SO YOU CAN FIGURE OUT WHAT TO DO IS REALLY GOOD! also this is a really good video and i will use similar things in my projects now thank you

huh?

I'm going to show my students this video. The way I hate OOP

What's the music starting at 3:35 ?

this vid is so good omg

wait... did i just discovered home??? as in, NIGERIAN GAME DEVS!!!! Abeg, make i join una community na. i've felt alone for so long :(

Hey! I'm a new-dev and this is cool. So I use luau (roblox) and I've been making an ability system and this is exactly what I've been doing but described in a word. I use an OOP approach but basically "abilities" have a bunch of different things that could make them up, maybe it's a projectile, maybe it heals, maybe it follows the cursor etc. etc. and I just specify these different things and build an object with blocks I've pre-made rather than having new things inherit from wtvr. Composition. I didn't know the word to describe what I was trying to do, but it's this exactly.

I will try it in godot 4.4. I have to read the subtitles because i wonder any can understand your bad voice. Open you mouth please ;)

I've been trying to understand the different methods of this kind of implementation because all of my code is horrible and awful and terrible. But I've never been very good at understanding the videos, but this has been probably the best example I've seen. Thanks!!

The biggest bug with my code was... Myself.

I have a question what do you use to create the programming sheme it would be usefull for me to share with my friends when i explain programming archiectuer and stuff like that thanks in advance .

I truly agree, it's gorgeous...

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.

So when actually you want to use them? I do tries compositions sometimes but I find it is harder to work with 15+ script going into it. So I just resort to making new scripts as a “presets”.

Well, I've been using the subscriber pattern found in a lot of AWS services, as well as, web frameworks like RXJS. C# let's you do this with delegates and events. This is so that any time I need to make a change where it's appropriate i.e. FixedUpdate, Update or LateUpdate the classes who care about some physics object subscribe to changes in say the RigidBody. The only coupling that happens is when I need to inject a reference to physics changes. Everything that cares about a change gets invoked in a deterministic way. This pattern is what the new Input Module does. I'm not a long term game dev just been programming other things professionally for years now.

Hard to watch with this shitty background music.

This is an amazing video! Composition, or ECSs are extremely useful and something that people tend to either misunderstand, or ignore. However, I do wish you had a better example than Titans because Titans are actually an amazing example of where Inheritance would shine bright. For the main reason that there are thousands of them. The way you describe composition is such that you can apply components to your entity to make exactly what you need, but no one is going to manually create 1000s of Titans, that is ridiculous. You would manually create the, maybe 10, special Titans, and then have some systems that create Titans with a random set of a group of components based on the genetic needs of each class of Titan. Which would be very easy and efficient to do with composition, but in terms of actually managing the Titans themselves, you would want an inheritance layer that controls how the composition happens. In other words, sometimes it's best to use the 2 patterns together.

i use godot with 2GB ram

Good exercise is to write some game logic in c. And when you try to create Oop in c, slap your wrist. This exercise will help you understand that game is not real life. And that In turn, will give you more freedom to create solutions that make sense for you and for the machine.

most people do not understand that, inheritance is there to inform what an object is (a titan IS a creature, it IS living, it IS tall, it IS a monster). Composition is there to inform what an object has (a titan HAS a shape, it HAS high hp, it HAS high damage). Interfaces (and also member functions) are there to inform what an object can do (a titan CAN crush you, it CAN move, it CAN eat humans). For your example at the very beginning, the randomize has imho no place inside the titan class, as it does not define a titan. it defines how to generate one, which is not the role of a titan (a titan cannot generate a titan can it?). if I complete the example: The Titan Generator can create any kind of titans! it can create basic titans which can run, kill, and eat! it can also generate weird titans, which for some reasons cannot move, but can do everything a basic titan can do. it also generates special titans, which have shielded plates, have higher speed or attack. Those titans can even use a special attack! when basic titans try to use it, they fail miserably... in this example, BasicTitan have four functions (run, kill, eat, attack). they also have a shape, that is passed to the constructor. The WeirdTitans inherits the basicTitan, and overrides the run function to do nothing (as they cannot move) The SpecialTitan inherits the basicTitan, and modifies its base characteristics (hp, strength, speed...). its attack function is overrode to implement a special attack. The TitanGenerator is a factory whose sole job is to create titans, based on what is asked to it. if it creates a basic titan, it is randomly generated. if it is a special titan, it has presets.

"This old code I wouldn't touch with a 10 foot pole. The code smelled like vomit; spaghetti" "So I had this player class, which inherited from a class called Entity, which had code for movement..." Uh oh.

>memedot

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.

And that's why you should be a hardcore coder like me, which prefer inheritance 😂😂 Btw, this is just personal thought: I think inheritance is just composition, but not a full composition If I'm not mistaken, C++ internally compile inheritance into a composition too

Bro 🤣🤣🤣

Kinda crazy that the algrithim hasbt bosted this video more

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

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.

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!

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.

Great vid. Nice editing. I must look into metadata soon.

Why's the video interlaced?

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.

thats pretty cool i didnt know that

First comment

I think you have to learn object-oriented design first in order to critique. 😅

Nice, I actually didn't see it coming to use behaviour trees in the plane and the camera ✌️ I learned something new

ANy way to optimize this ? SO if im trying to draw it in full screen how can i make it smoother ?

Thanks for talking in such a peaceful way, not cutting the silence too much nor speed up talking as my brain uses those time to process. One question, what's the behavior of Camera: Freefall?

As a Haskell truther, you're on the right track. Just wait till you get into the insanity category theory offers. Problem is applying it to the main game engines, unless you're building your own engine it's hard to squeeze efficiency out of monadic composition, you're always gonna be beholden to OOP to some degree. The Scala-esque mixed approach will always be the best you can get away with in most cases.

So why Composition over ECS?

OOP places a high burden on the designer of the system. Any unforeseen situation can lead to costly refactors, and this might repeat several times before one arrives at the correct solution for the problem. Functional programming attempts to solve the issue by allowing the system to evolve more organically. Like a city, you just tack on more streets, more houses, more floors, until your system can't take it no more and people are spending 3h in traffic for 7km trip. I think this debate will never be settled because the functional approach just isn't scalable, while correct OOP is too difficult to be practiced by the masses.

always love to see a 2 years experienced programmer take a s h iat on OOP

Why am I here. I just started as a developer. This is too advance lol

Really cool, are you sharing the sauce code? 🥫🙂