Now I get it 😂 I thought firstly that you are just crazy 😅 Good luck with learning new stuff!!

you didnt actually pin this

I thought it was clear, nobody leaves a game engine for only 3 key reasons! There might be some stand-out reasons, but if the engine doesn't "feel" right then you can't really list all the points...bit like life decisions come to think of it 🤣

@@NightHutStudio what's clear for someone couldn be not clear for another one 😁

@@artsurock yeah I agree, very true :)

Hi, great to see you here! I'm really excited to see what the future of Bevy will look like (especially with the editor on the horizon). It's been a pleasure to develop games with Bevy so far and I hope to contribute one day, when I'm more experienced with rust and Bevy :D

And I doubt Cart is going to start charging for Bevy installs XP

Legend

​@@loganwoodbury4050that's more likely to happen from the Rust foundation, sometimes they do stuff like that

I am interested in machine learning and simulation, and other kinds of visual simulations, no matter if it is a game or something usefull. But normally machine learning has no 2d or 3d (phyiscs engine) and sound.. and U.I. .. all the things that game programming environments DO have usually. I want to get something up quick and running. Godot language is way too slow for having 1000's of objects, and using C++ is.. difficult and not editor integrated anymore. Godot projects also become very nested and cloggy. I think Bevy is the answer

And this comment aged like milk, looks like you Unity is back with a good deal again. :P

@@SnakeEngine keep telling yourself that, they are going to do it again they got away with it and implemented and horrible fee anyways

@@Nylnezz Yeah, and they will face a repeated punishment and backpedal again. So you will be save as a Unity dev, it's not like Unity has a monopoly in the game-engine space. Imagine few years down the line, you are like "shit, the Unity engine is thriving while my freaking Godot project doesn't scale and is full of bugs. Leaving Unity was the stupidest decision I have ever made that robbed me years of time". So just keep going with Unity if you want to get somewhere :)

@@SnakeEngine what the fuck are you talking about?

@@SnakeEngine i really do hope unity gets his management in check, and i agree that godot lacks scalability for now, but its good to have choice when a corporation is only out to get you money more and more dont you think

Might be onto something :)

For us gamedevs, making games & learning new tools is more fun than playing em

Yep, your right. I probably should have mentioned that

@@timberdev Eh, it's an easy mistake to make. The only reason I even made the comment is because I used to think that too. Great video by the way, and I hope development goes well!

Wow, doesn't matter now. I'm so glad I never learned that shit engine. I feel bad for all of you goons that wasted your time but I always hated c# and the engine just felt clunky. NGL, I'm pretty smug, the amount of times i was tempted to use it... glad I never did. Dumb engine.

@@mrmaniac9905 No need to be so harsh about it

​@@bbrainstormer2036yeah you're right I did have an overbearing tone. I apologize

Falling down the same rabbit hole as Randy lol

Did you missed the last third of the video? ;-)

yeah I was kinda confused about that, because the node architecture was designed to support both inheritance and composition.

@@squee-z6442 @pigdev has a video on it also @RedefineGamedev has a good course on AI - Both show both inheritance and composition - I like using resources - there is a video in my dead youtub - good luck

i'd be surprised: everyone i know who's tried both bevy and dots agrees that dots doesn't feel at all good to use in comparison. bevy's ecs is just so nice to use.

@@laundmo they're trying to turn C# into C++ with Burst, no wonder it feels shoehorned.

Singletones are bad. There are more suitable aproaches that are better. Try Dependency Injection (vcontainer as a container).

I agree. Even though the mix of depreciated and experimental features is frustrating, and the time I spend watching Unity compile my scripts really adds up, the range of solutions makes easy and fun to experiment. As for the issues related to my own approach: well as my projects balloon in scope and complexity, the number of references and the confusing mess of coupled components just starts to make my head spin. i know there must be a better way and I’m totally intrigued and enticed by the observer pattern for its modularity. But I have a hard time putting the concept into practice and meaningfully changing my approach to scripting. How did you familiarize yourself with the observer pattern? Tutorials only take you so far yknow I need some experienced insight for nonspecific implementations and your comment really got me thinking about the possibilities

@@robwaters2948 I don't think I'm experienced enough to give advice but I'll give you how I think about it I guess? I try to make my scripts do one thing and one thing only, and I'm completely fine with having tons of scripts even if each script is only a few lines of code; what's more important is separation of concerns, so that when I find a bug related to X, I know exactly where to look, because X is handled fully in this file (or directory if it's a multi-script system kind of deal). Before writing anything I usually ask myself quickly, should this really be here? If I'm grabbing a reference to another script to call something on it, then probably not. I go with a "to whom it may concern, event X has just occurred" approach, and only expose static events. For example, if I have a clipboard script that manages copying, storing, and pasting stuff, and on copy I want to: -Play a sound -Change the color of something in the UI -Potentially more in the future I expose a static public event at Clipboard.onCopy, and invoke it when I copy, "to whom it may concern, a copy event just occurred". And in my SFX manager, UI, or whatever other script, I can subscribe to that and do whatever I want there. In regards to what's an event and what's not, I start with 0 events in all scripts, and when I find I need to know that X happened in some script, instead of grabbing a reference to it, I go add the event on it for now and future use. Over time my system events build up, and I don't have unused events because I only add them when I need them for the first time. I don't know if this kind of pattern is good or bad, but it's personally served me well, I've yet to get bitten by it. Let me know what you think though!

@@robwaters2948 and for you, answer are use DI and containers. Try it first, implement that in your project and try to follow the strict rules of container, and after some time you will start to understand how to make your code better. Observer also a not good patter xD. When I create my code, I imagine every method as empty room with me in it. Then I try to implement logic of said method. If I need something, then I try to recieve that trough window that I have. Said window is a method arguments. Only trrough that window I can recieve all that I need. If I create class - I try recieve only needed things trough constructor arguments. After some time I start to make very good code, that live years without changing in my projects. Best patterns is strategy and dependency inversion.

what we thinking now buddy

I was thinking about that all throughout the unity chapter, it does have it's quirks sometimes (especially if u made the dumbass decision of using the beta versions for a slightly better looking editor xD) but if you know how to properly use unity it is the most powerful 2d engine out there (I'm not going to get into unity/unreal here). Can't blame the dev though, ecs is a challenge to wrap your head (especially if you're already used to GOs and OOP) around at this current stage and it isn't properly implemented in 2D yet. Plus ecs in unity is more of a system for optimisations rather than just making a normal 2d game where maximum performance isn't required.

the reason ECS is many developers preferred choice is that the design patterns you suggested are built into the foundation of the engine. Bevy's `Resource` trait is a singleton, systems themselves are dependency injection and the observer pattern is the `Changed` filter. in Unity and C#, genuine proficiency is required to write elegant, performant code. in Bevy with Rust, you cannot write code that isn't elegant and performant.

All of these patterns are great and all, but they don't scale in terms of performance. OOP as implemented in C# and other languages forces your CPU to do a ton of pointless pointer chasing just to call a function or read a single value from memory. ECS on the other hand can store all of your data in linear memory which is much better for CPU cache utilization. I don't see this mentioned in comments, but this is the main reason why ECS is becoming popular and why Unity has DOTS in the first place.

Tbh, I consider OOP itself an overall anti-pattern for games and high performance systems in general. Java and C# being the worst examples of it. Rust's way of doing functional programming makes all these patterns much more inherent to the way you write code and it doesn't feel like you're wrangling the language to follow idioms.

​@@Sergeeeek ecs makes serialization trivial. That's my favorite part. That, and faster entity query

The slow bloated editor and closed source is not really a code issue.

You can also use composition in godot

​@@ArnoVaiassemblies definition can help you with editor performance if you'll use them correctly. And there are tools such as Odin Inspector to make your editor comfortable and efficient

@@bonsaipropagandaYeah I don’t quite understand why he thinks inheritance is too heavily relied upon Godot. Composition can be easily done with the node system as long as the component is programmed well enough to work in dynamic scenarios. A majority of the inheritance system can be avoided by dynamically adding composite nodes at runtime as needed.

​@@catcactus1234 all nodes in Godot use inheritance. For example you can't just extract some functionality from KinematicBody2D and reuse it in your code, you have to use the whole node which also includes PhysicsBody2D -> Node2D -> Node etc. If the builtin nodes don't do something you want you can either inherit them, or rewrite them from scratch. There is no third option, unfortunately.

Sounds like you have a wise father!

@@hermestrismegistus9142 yes, he's a computer scientist at a national observatory

I'm really determined to Bevy at the moment, so yeah, I will likely stick with it :D

Write your own renderer, physics engine, collision system, write everything yourself.

@@pietrocavicchioli6128 what?

@@pietrocavicchioli6128 the funny thing is that you easily could in bevy. you can replace even very core parts of it with your own implementatio.

I think it's time now ;-)

Good luck :D