I have pinned this comment to clarify some things about the video. I've noticed, that there is some confusion about the negative things I pointed out about Unity. While the main three points presented in this video are valid (at least to some degree), I did not make it clear that my motivation to switch away from Unity is only partly because of these points. I wanted to explore other game engines simply for the joy of learning and having some new experiences. Also I did initially plan to use Godot for the project - switching to yet another game engine was not part of that plan. It just so happened that development was slowed down by the mentioned bug of Godot 4. I then randomly tried out Bevy and Rust and found it to be extremely fun to work with. I did not abandon Godot because of the negative things I mentioned. Moving to bevy was simply due to an unlucky situation I found myself in. I still think Godot is great but Godot 4 was sadly not working for me and it looks like it still isn't. Game dev is not my job. It is just something I really enjoy doing in my free time. And I believe it is important to also try other options. Unity is still probably the best engine for professional game development. My goal with this video was to show the journey of me switching game engines and NOT to say that one engine is better than the other. And I pointed out some positive and negative things I encountered along the way.
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 🤣
Hey! Creator and lead developer of Bevy here. Loved the video. Let me know if you encounter any issues / have any ideas. We're still in the process of building out Bevy and feedback from developers is important to us!
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
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
@@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 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
I like what you are doing. You focus on long term goals and putting time into something you enjoy doing and crafting quality work with patience and dedication, not something rushed for views and money. I look up to you for this. Keep going strong bro 💪 ❤
@@timberdev could have just written ECS in the first engine rofl... ECS isn't that complicated concept to grasp .. but if u like to explore, i recommend checking out Defold Engine , cosindering the content of this video, i think u might like it
One of the best advertisement for ECS and rust tbh, I am intrigued 😯😯
Рік тому+2
amazing. it's cool that more and more people notice rust and use it in their projects. i heard about bevy and it's nice to see that you enjoyed using it
I think you just shifted how I think about ECS. You never know when someone will describe a concept in a certain way that sets your brain off on a new track.
Regarding the references in Unity, I usually just use a script that houses all my references for my player and have other scripts just take a reference to the reference "hub". Idk if thats good practice but it works for me
@@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.
Great video, good luck with your game! I think stability is currently Godot's biggest issue (at least for the 4.x versions). It is a bit annoying at times, but personally I'm fine with it because of pretty much everything the engine offers. I feel like the issue with code growing more complex and ugly is possible to be avoided, provided you design your system with avoiding coupling in mind from the get go. Real shame you came across a pretty nasty bug, but I'm glad you're enjoying your time with Bevy! Excited to see more
I've enjoyed this video, I've actually gone a pretty similar, if shorter journey, where I tested out Unity and Godot but ultimately felt like they were restrictive. Then I tried implementing a small CLI game in engine-less rust for a while, but later I found Bevy. The ECS relieved lifetime headaches, but it was configurable enough that I could make the game without being locked into a bunch of functionality I didn't care for. I migrated my game to Bevy and have loved it, plus the community has been really supportive =] Really happy to see an experienced game dev validating that choice!
You can achieve the same principle of Systems -> Components from ECS in Unity by using MonoBehaviours -> ScriptableObjects and a more clean Architecture between each MonoBehaviour. Try to learn about programming design patterns and it will help a lot with OOP (Dependendy Injection, Singletons, Observer Pattern, just to name a few). Regarding the Inheritance over Composition, that's a principle of SOLID - Interface Segregation (look it up, its very useful) and it can also be applied in Unity with C#, just as well as you described it for ECS. I'm sure ECS has its advantages, but Unity isn't the cause of you experiencing these issues - your coding architecture is. Hope to continue seeing more from your journey.
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.
Saw the thumbnail and thought: "Let me guess, fed up with Unity switched to Godot and likes but doesn't feels quite right and ends up with Bevy" ...guess I nailed it.
Neat - been following you for sometime your game looks good. Just one thing about Godot - the event system / Observer pattern is designed to decouple nodes. I am not sure how the C# works in godot but the build in GDScript supports both Composition and inheritance . I am sure you look at the resource class that is used to store data Godot 4 I think need more time in the oven - but that is my view. Really keen to see where you take your project.
@@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
Hope you feel more inspired with a more functional type of programming design pattern! I just recently started playing with phaser, which also follows a ver classical OOP design pattern. Coming from a more functional approach, I prefer OOP for game dev much more though. Happy developing!
2:10 Unity has dozens of ECS frameworks with hundreds or even thousands of stars on github. I believe this is the largest production-ready ECS game engine right now.
To be honest I love Unity's style and the structure it kind of guides you towards. I try to mostly never store references to other scripts, and instead use static events for communication (Observer design pattern), and I love creating singletons with a private instances and public static methods, like Unity's own systems (GameObject, Input). You can come up with extremely clean solutions by following the most suitable design patterns for your situation. As for the editor being slow and cumbersome and bloated, I could not agree more, it's the single most frustrating point about Unity, but I manage to tolerate it just because Unity's scripting solutions are just brilliant in my opinion; literally no matter what it is you're trying to do, you can find a creative way to implement it in a clean way and probably very easily and quickly. I'm definitely trying other engines in the future, but for now, I think Unity is a solid tool if you're experienced with it specifically.
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.
Great video :)! It was pretty interesting seeing you troubleshoot your inconveniences with the game engines. Hope everything goes smoother from now on!
To be honest, most problems you have described in this video are code related, thus on you, you can confidently use composition instead of inheritance with unity. That said, rust is a great choice.
@@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.
I dissagree with your 3rd point. Its fully possible to use unity as a glorified renderer. Also unity doesn't force you to use inheritance? You can easily make modular systems, or really use any architecture (and again use it as a glorified renderer) however... In light of the contraversy. No reason to regret switching!
Your video is well made dude. Composed and edited in a catchy way. I am expecting this title in one of your near videos: "DOTS makes me return to unity again!"
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.
i think the most usual missing points then people talk about game engines is Editor, unity has one godot has one, bevy does not, and that is not important for coding a game, but super important to prototype and compose stuff. I think bevy and other game engines (especially ECS based) should invest some time in editor, and more examples of most common ecs patterns (like drag n drop, composing of systems (one system could depend on another for example) and so on)
I hope that bevy and rust will alow you to develop features that unity and Godot would have made to hard or to unstable. Can't wait to see how this turns out
It's worrying how many developers blame inheritance for creating complex or complicated code, rather than questioning themselves if they are using it correctly and are avoiding common anti patterns. Furthermore, game engines (mostly) don't restrict you from following best practices of underlying programming languages, such as C#. So if you are writing shit C# code in Unity, of course you will write shit C# in Godot. Swapping the engine isn't going to save you from yourself.
I was recently convinced by my dad to start using a language with a good typesystem like rust, I just barely started learning rust because I was bored and demotivated from the Love2d framework. Great video, may the blessings of the indie dev deities bestow upon you fortune and favor.
I've followed a similar path. I started releasing a couple of games on Steam that used Unity but it just seemed to deteriorate around 2020. I invested some time learning Rust and moved towards Bevy and find it absolutely fantastic and I can't wait for it to reach stable. Rust is also one of those languages that make you wonder how you ever coped without it. Going back to C# just feels bad now.
Wow thanks for this. I've been looking for a game engine recently and my day job used F#, where we have a separation of data and behavior. Bevy looks like it'd be great fit.
I mean, I'm all up for finding new engines to see what works best for your project. But this is a little too much. Even with all of unity's issues, If you had just suck it up and stuck to it, you game might've been finished by now. I think moving engines when you're already chest deep into development of a project is not the wisest thing, especially if there's not a critical engine specific issue that literally doesn't let you finish your game.
Yea thats true for most people. I actually enjoy coding and learning new stuff more than anything in game dev, so that's probably also a factor in this decision. But youre right, its surely not a wise decision from an economic standpoint.
One of the reasons I'm window shopping for other game engines is Unity's slow editor. Starting Godot takes seconds, which is soo good when you're working on something on and off. This is especially useful when you're in the "testing out ideas" phase. That said, there's no real reason why Unity *has* to be so slow. It's entirely possible to redesign it to use lazy loading of editors and windows, and utilise threading to pre-emptively load the necessary components in the background. They've partially started work on that, by splitting things into components, but I feel they just don't have the incentive to actually get the editor speed up. Their core demographic are people that load the project in the morning, work over the day with it, only to shut it down in the evening before they go home. If even that, just locking the work station before going home is quite common in a lot of places. As to being forced to work with inheritance, I think that's not quite true. Yes, you need to inherit the right base class for your code, but in no way are you forced to make inheritance trees to build your game, it has all the necessary tools to work with composition instead. That's more on the way you're using it than how you *have* to use it. At least in my experience.
Very professional video made all the more relevant after the recent Unity apocalypse. Game engines are actually meant to be CONFIGURED, like PhotoShop or 3d Studio Max, then programmed so the lack of C# support may not be a big deal if the editor is very complete. Rust seems way to complicated for the average gamedev these days, but Rust has great .Net interop. Can C# scripting be ADDED to Bevy and is it a GOOD idea?
IIRC bevy scripting in other languages is one of their design goals, such as a recent migration from depending on Type IDs to "ComponentIds" to distance from rust specific logic. But as of this moment, it has not been implemented. I think creating an editor is their priority currently
@@loganwoodbury4050 That's interesting. It may make Bevy max out on performance for the regular gamedev. It may be too late for the hoard of Unity developers looking for something else, but ultimately there is always room for quality.
@@Casulite From my view as a programmer coming from SDL and XNA using the mouse to get a desired effect in a game engine is configuring something. Back in my Amiga days Deluxe Paint was used to make images with the MOUSE and that wasn't considered configuring, but you COULD be pixel pushing individual pixels. Applications like Photoshop are more about serially triggering commands that have an effect on the underlying pixels, but aren't really about the pixels. They are more HIGH LEVEL. They should, as it would be way TOO MUCH WORK to hand optimize every pixel especially with the high reze images that for instance a glossy magazine uses. The lesson here for Bevy is that it's RAISING the interface for Designers who design the Game, Level, UI or the overall Experience. That also implies that it shouldn't optimize for Content like Dialog and Lore as other tools like Articy Draft or Arcweave are better. The same goes for creating Assets, because that is better done in something like Blender or Krita. Not that it's prohibited to have such functionality, but using a pipeline of SPECIFIC OPTIMIZED tools for certain tasks would make more sense to me.
Without any negative connotation, I think you are misunderstanding some of the stuff you talked about. Traditional GameObject-type of Component system is unefective for various reasons, so Dots ECS is aiming to outperform it with different memory layout. It has very little to do with the code design. Godot and Unity are very similiar to each other in terms of Component systems. Sure, GDScript is less of a OOP fanboy, but still. In Unity, I see you are reffering some objects from other objects, and it's typically means a bad design. Ideally you should have systems/managers that do all the same stuff (or very similarly) as Bevy. Sure, Bevy ENFORCES you to do it this way, which is good, but boy-o-boy, it has some other problems. I'm by no means any expert, but I've noticed something many game-devs have in common, including me - trying to make the enviroment perfect, switching game engines, tools, technologies, languages, patterns etc. Someone can go as far as creating his own game engine or even his own language (hello JBlow). But for the most part, it's just for the sake of it. It brings a certain joy, but most of the time results in negative perfomance. I've struggled with Unity so much, and I was certain it's a editor issue, but sinse then I've seen tons of very good, very beatiful code architectures made in Unity and realized that in fact it's just my skill issue. Realistically, Unity is the best game engine for indie devs, but you can use whatever tool you know best (I've also seen thousands lines of plain C game or Roller Coaster Tycoon programmed by one guy in assembly). If you want to make games... Just make games.
Switchers don't finish games, they are not serious about their time and dedication they are just playing around. Why don't make games in assembly where you can communicate directly in memory instead then right
If you rely heavily on inheritance using Unity, you're just doing it wrong. It's very much possible and beneficial to design your code to favor composition over inheritance.
I'm unsure if you're still open to feedback-shaped thoughts at this point, but in case you are: - The geometric art direction you've been going with gives me some Tron-esque vibes (less Tron Legacy and more old school Tron, but even so) - I wonder if it's worth leaning into that a little during art refinement - kind of a Geometric Technomantic thing vibe. See also Hyper Light Drifter, the Progenitors from Homeworld, the Zeffo from Jedi Fallen Order, Endless Legends.. anything where ancient-become-archeological advanced technology is a prevalent thing and there's wonderful aesthetic to draw from. - In one of your previous devlogs you put a poll up for naming Fragments - one of the names was "Relics" - I wonder if you can/should co-opt the name as a mechanism for another upgrade distinct from Fragments. Fragments increase stats while Relics could unlock Abilities like Grapple, or a radial burst attack: stuff like that. That way it becomes a decision: "Do I want to boost my stats, or do I want to have this tactically useful ability?". It also lets you achieve progression by re-using an existing and familiar inventory mechanic - just slightly differently.
Just for reference, Unity DOTS is basically Bevy with a C#/Unity flavor and the force of a public traded company behind it. It's still missing features for big or 2d games tho...
I switched from Unity to Godot and then to Bevy for the same reason. Bevy's ECS makes really easy to compose game from smaller systems!. Most developer looking for editor of course but I'm more comfortable with code first game engine
7:20 Quick note: Bevy uses the ECS paradigm, which is "Entity, Component, SystemS", not System. It's a bit annoying that even their wiki got it wrong, but there's a key difference between EC System and ECS, one implements the logic inside the component and the other one implements systems as separate functions from the component, leavening components as data only. Unity does the former while Bevy does the latter. Not your fault, but wanted to leave the note for people to learn about it
I have always struggled as to what engine to use, but in an unproductive manner. I'm just a begginer anyway, but it's really pedagogical to watch your impressions over different engines. So are you sticking with Bevy for future development?
Ah, the pendulum of object oriented to data driven swings again. It's a well observed fact that programmers tend to lean into one side, then new programming languages come out that lean towards the other side to fix problems with the opposite side. Rinse and repeat, since C spawned C++ if not before. One thing you might want to look at is Inversion of Control, along with Test Driven Development. Both help in avoiding the dependency graphs you described. Now, I'm not saying you should stick to Unity, or Godot, or whatever. But it seems to me that your problem lies less in the specific engine, and more in methodology to help writing cleaner code in general. TDD forces you to focus on testable units, and while it does force you to write more boilerplate code it tends to be worth it over the lifetime of a project. Sadly, it's not always straightforward of how to use it in most game engines. Inversion of Control moves the responsibility of connecting components together out of the components "hands," making it do less. And also helps by allowing components to be replaceable easily. Inheritance should never be used to add functionality, and only when something *is* something else. A car *can* be controlled by another entity, it *isn't* a "Mount." A player *isn't* a health bar, they *have* one. And so on. In particular, besides the bloated sluggish part of Unity, and it's lack of source code access, everything you described can be done in Unity just as well as in Godot. Can't speak for Bevy, but it looks like a mistake to work in a less developed game engine where you spend more time coding game engine tasks than your own game. You'll run into the same issue as in Godot, where a bug appears and isn't being solved more often, but with fewer tutorials and people to ask how to get around the issue. Also, don't be afraid to use events or messages. They *are* slower than direct calls, but if used properly the difference isn't noticeable. In particular, damage delivery could be a message or event, allowing you to decouple your code. That way your HealthComponent can respond to damage received, making it possible to add that to enemies, players, breakable boxes, and even projectiles themselves.
one of the big advantages bevy has over godot, unity etc is that its really modular. want to just use the ECS and do everything else yourself? you can. want to rip out and replace the entire renderer? sure. since the engine is Rust and the game code is Rust the separation between engine and game just isnt that big. makes it much easier to understand what the engine does (well, unless you're messing with ECS internals those are a bit obscure).
@@laundmo I'm sure that's great. But there's two issues. One, you spend time writing the game engine that could be spent on making your game. This is fine if you are heavily invested in an open source game engine, I've put in some time on open source projects that I used myself. But making a game is hard, getting it ready to release is even harder. You really, *really* should ask yourself: Do I want to focus on the game engine, or my game? Secondly, I can't help but notice that when a bug appeared that stopped progress on his game in Godot, which is open source and more feature complete, he rather move to another game engine than look into the bug and fixing it. No shame in that, like I said: Which is more important, the game or the game engine. But there's a higher chance of getting game breaking bugs in a newer, more incomplete open source game engine, than there is in a more mature one like Godot. And you *still* need to get into the fine details of how the game engine works to fix those. I had a similar situation when I used a smaller, well designed, game engine. I tried to make use of the stencil buffer, only to find out that the implementation was completely messed up, with the read mask zeroed out and hardly any of the modes used. So I decided to fix it. Which required me to look into OpenGL's implementation of the stencil buffer. Which led me to look into the middleware implementation. Then back to the game engine, only to find out that I have to go fix the window creation code since it didn't even initialise the stencil mode. Back to OpenGL reference docs. Hmm, maybe I should have a look at Unity. Sure, it's not open source, but… It's been weeks since I wrote anything on my game by now.
for real, the more you learn how to actually use rust instead of just learning syntax and applying your previous languages knowledge, the more you fall in love with it
Would you say Rust is safe to jump in directly without experience with other languages if I'm willing to jump over the hurdles, or would you say another introductory language would be a better idea to start with? Personally I like the way the philosophy of rust sounds, and I'd like to begin my journey into programming with that mindset, but I'm wondering if it's reasonably feasible.
@@Kiwi-fl8te Thats a really tough question I havent thought about that much. I guess its always nice to start with a simple language that is easy to learn, so you focus more on programming itself rather than learning the language. I suppose you could start with rust, but it will likely take much longer until you get comfortable with writing code. Its really up to you. The most important thing is to simply start learing any language. If you want to learn rust, go for it. It cant hurt.
@@timberdev I might just try to start with Rust then. I've also considered the most conventional start of learning Python. I'm at least not completely alien to programming logic, as I've okayed around with visual languages before.
2:12 no, I don't think you should rely on inheritance in unity, actually it is a bad idea. The way unity inspector stores data doesn't recognize inheritance, so if you want to switch to inheritance class or switch back to your base class, you lose your inspector data. You can lose lots of setting if your class has lots of variables.
I have pinned this comment to clarify some things about the video.
I've noticed, that there is some confusion about the negative things I pointed out about Unity. While the main three points presented in this video are valid (at least to some degree), I did not make it clear that my motivation to switch away from Unity is only partly because of these points. I wanted to explore other game engines simply for the joy of learning and having some new experiences.
Also I did initially plan to use Godot for the project - switching to yet another game engine was not part of that plan. It just so happened that development was slowed down by the mentioned bug of Godot 4. I then randomly tried out Bevy and Rust and found it to be extremely fun to work with. I did not abandon Godot because of the negative things I mentioned. Moving to bevy was simply due to an unlucky situation I found myself in. I still think Godot is great but Godot 4 was sadly not working for me and it looks like it still isn't.
Game dev is not my job. It is just something I really enjoy doing in my free time. And I believe it is important to also try other options. Unity is still probably the best engine for professional game development.
My goal with this video was to show the journey of me switching game engines and NOT to say that one engine is better than the other. And I pointed out some positive and negative things I encountered along the way.
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 :)
Hey! Creator and lead developer of Bevy here. Loved the video. Let me know if you encounter any issues / have any ideas. We're still in the process of building out Bevy and feedback from developers is important to us!
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
Well this aged like fine wine.. looks like you dodged a bullet with unity!
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
This video aged extremelly well man. 😂
I love how your game looks and the genral concept of it. Keep it up
Yoooo! I was JUST rewatching your videos yesterday and thought I wanted you to come back!
I like what you are doing. You focus on long term goals and putting time into something you enjoy doing and crafting quality work with patience and dedication, not something rushed for views and money. I look up to you for this. Keep going strong bro 💪 ❤
Glad to hear from you again! At the moment Unity remains my absolute favorite game engine, but especially Bevy seems very promising in the future
Can't wait to see your game come forward!
Indie developers would do anything other than game development itself it seems
Might be onto something :)
For us gamedevs, making games & learning new tools is more fun than playing em
@@timberdev could have just written ECS in the first engine rofl...
ECS isn't that complicated concept to grasp
.. but if u like to explore, i recommend checking out Defold Engine ,
cosindering the content of this video, i think u might like it
One of the best advertisement for ECS and rust tbh, I am intrigued 😯😯
amazing. it's cool that more and more people notice rust and use it in their projects. i heard about bevy and it's nice to see that you enjoyed using it
Welcome to the bevy team!
I think you just shifted how I think about ECS. You never know when someone will describe a concept in a certain way that sets your brain off on a new track.
You avoided a bullet man 😢
Regarding the references in Unity, I usually just use a script that houses all my references for my player and have other scripts just take a reference to the reference "hub". Idk if thats good practice but it works for me
Very nice! One small correction: ECS is only a part of DOTS in Unity. The burst compiler and jobs system are also included in DOTS.
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
Great video, good luck with your game!
I think stability is currently Godot's biggest issue (at least for the 4.x versions). It is a bit annoying at times, but personally I'm fine with it because of pretty much everything the engine offers. I feel like the issue with code growing more complex and ugly is possible to be avoided, provided you design your system with avoiding coupling in mind from the get go.
Real shame you came across a pretty nasty bug, but I'm glad you're enjoying your time with Bevy! Excited to see more
I've enjoyed this video, I've actually gone a pretty similar, if shorter journey, where I tested out Unity and Godot but ultimately felt like they were restrictive. Then I tried implementing a small CLI game in engine-less rust for a while, but later I found Bevy. The ECS relieved lifetime headaches, but it was configurable enough that I could make the game without being locked into a bunch of functionality I didn't care for. I migrated my game to Bevy and have loved it, plus the community has been really supportive =] Really happy to see an experienced game dev validating that choice!
What the... He is going for a full pivot. Best of luck with bevy, I wouldn't go for a game engine without an editor, even if it implements ECS
Seems you were 4 weeks ahead of our time, lmao.
Looks like you made the right choice moving away from unity!
You can achieve the same principle of Systems -> Components from ECS in Unity by using MonoBehaviours -> ScriptableObjects and a more clean Architecture between each MonoBehaviour. Try to learn about programming design patterns and it will help a lot with OOP (Dependendy Injection, Singletons, Observer Pattern, just to name a few).
Regarding the Inheritance over Composition, that's a principle of SOLID - Interface Segregation (look it up, its very useful) and it can also be applied in Unity with C#, just as well as you described it for ECS.
I'm sure ECS has its advantages, but Unity isn't the cause of you experiencing these issues - your coding architecture is.
Hope to continue seeing more from your journey.
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
Holly, I've been waiting a video from you for reeeaaaaaly long time. Glad you came back budy!
Saw the thumbnail and thought:
"Let me guess, fed up with Unity switched to Godot and likes but doesn't feels quite right and ends up with Bevy"
...guess I nailed it.
Neat - been following you for sometime your game looks good.
Just one thing about Godot - the event system / Observer pattern is designed to decouple nodes. I am not sure how the C# works in godot but the build in GDScript supports both Composition and inheritance . I am sure you look at the resource class that is used to store data
Godot 4 I think need more time in the oven - but that is my view.
Really keen to see where you take your project.
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
these videos are so satisfying to watch :O
this video was the final thing that made me switch to godot
whether i will stay or not i dont know but we shall see
Good luck :D
That's crazy! Great content. I should start learning rust too.
Hey Man love your content !!! ❤
Hope you feel more inspired with a more functional type of programming design pattern! I just recently started playing with phaser, which also follows a ver classical OOP design pattern. Coming from a more functional approach, I prefer OOP for game dev much more though. Happy developing!
Totally support the decision! I am looking forward to playing the game!
2:10 Unity has dozens of ECS frameworks with hundreds or even thousands of stars on github. I believe this is the largest production-ready ECS game engine right now.
To be honest I love Unity's style and the structure it kind of guides you towards. I try to mostly never store references to other scripts, and instead use static events for communication (Observer design pattern), and I love creating singletons with a private instances and public static methods, like Unity's own systems (GameObject, Input).
You can come up with extremely clean solutions by following the most suitable design patterns for your situation.
As for the editor being slow and cumbersome and bloated, I could not agree more, it's the single most frustrating point about Unity, but I manage to tolerate it just because Unity's scripting solutions are just brilliant in my opinion; literally no matter what it is you're trying to do, you can find a creative way to implement it in a clean way and probably very easily and quickly.
I'm definitely trying other engines in the future, but for now, I think Unity is a solid tool if you're experienced with it specifically.
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
Great video :)! It was pretty interesting seeing you troubleshoot your inconveniences with the game engines. Hope everything goes smoother from now on!
To be honest, most problems you have described in this video are code related, thus on you, you can confidently use composition instead of inheritance with unity. That said, rust is a great choice.
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.
That's an awesome explanation of how Bevy works!
Can wait to see continue your game in godot I been using for 4 months now and this very inspiring to see someone work in godot.
Did you missed the last third of the video? ;-)
Next week:
Why I wrote my own game engine in my own programming language
Falling down the same rabbit hole as Randy lol
Nice video, looking forward to the next devlog!
This video is so cleaaaan, nice editing man. good work!
Wow, you intrigued me with the engine on Rust, would be super interesting to learn
This is hilarious, just like me. I started in Unreal for a month, Went to Godot for about half a year, and recently, I'm starting over in Bevy.
I dissagree with your 3rd point. Its fully possible to use unity as a glorified renderer. Also unity doesn't force you to use inheritance? You can easily make modular systems, or really use any architecture (and again use it as a glorified renderer) however...
In light of the contraversy. No reason to regret switching!
Ayy is that motionCanvas I see? Glad to find another appreciator.
Your video is well made dude. Composed and edited in a catchy way.
I am expecting this title in one of your near videos:
"DOTS makes me return to unity again!"
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.
i finally have a rudimentary understanding of ECS, thankyou
Nice new video.
you should add passive abilities for the player
The research part is the most instructive part lol
i think the most usual missing points then people talk about game engines is Editor, unity has one godot has one, bevy does not, and that is not important for coding a game, but super important to prototype and compose stuff. I think bevy and other game engines (especially ECS based) should invest some time in editor, and more examples of most common ecs patterns (like drag n drop, composing of systems (one system could depend on another for example) and so on)
Nice Game! Keep up the good work.
Not arguing for Unity here, but there is nothing forcing you to use an inheritance based approach for your components.
Great video! Learning about ECS and bevy makes me want to do more composition focused design in my project now haha
Woah, hey, Motion Canvas in the wild, nice!
I hope that bevy and rust will alow you to develop features that unity and Godot would have made to hard or to unstable. Can't wait to see how this turns out
It's worrying how many developers blame inheritance for creating complex or complicated code, rather than questioning themselves if they are using it correctly and are avoiding common anti patterns. Furthermore, game engines (mostly) don't restrict you from following best practices of underlying programming languages, such as C#. So if you are writing shit C# code in Unity, of course you will write shit C# in Godot. Swapping the engine isn't going to save you from yourself.
I was recently convinced by my dad to start using a language with a good typesystem like rust, I just barely started learning rust because I was bored and demotivated from the Love2d framework. Great video, may the blessings of the indie dev deities bestow upon you fortune and favor.
Sounds like you have a wise father!
@@hermestrismegistus9142 yes, he's a computer scientist at a national observatory
Literally the same path and opinion! Good luck with your game!
Best explained Bevy concepts ever!😮
Hey! I was wondering if you were still developing. I can't wait to see the game come out!
I'm glad a new video is out after waiting for a while. I thought you might of dropped the project.
Such a good vid, looking forward to see more
I've followed a similar path. I started releasing a couple of games on Steam that used Unity but it just seemed to deteriorate around 2020. I invested some time learning Rust and moved towards Bevy and find it absolutely fantastic and I can't wait for it to reach stable. Rust is also one of those languages that make you wonder how you ever coped without it. Going back to C# just feels bad now.
Wow thanks for this. I've been looking for a game engine recently and my day job used F#, where we have a separation of data and behavior. Bevy looks like it'd be great fit.
I look forward to the fourth engine change in 9 months!
Cant wait to see full game am sure u be successful
Cant get enough of these vids
Currently making a game using unity's ecs and I personally much prefer it
ITR??? i wasn't expecting to see you here!!
@@kkibi 👋
I mean, I'm all up for finding new engines to see what works best for your project. But this is a little too much.
Even with all of unity's issues, If you had just suck it up and stuck to it, you game might've been finished by now.
I think moving engines when you're already chest deep into development of a project is not the wisest thing, especially if there's not a critical engine specific issue that literally doesn't let you finish your game.
Yea thats true for most people. I actually enjoy coding and learning new stuff more than anything in game dev, so that's probably also a factor in this decision. But youre right, its surely not a wise decision from an economic standpoint.
Glad you can upload again and can't wait to play your game when it came out🎉
Also get some rest:)
3:56 - and the world itself is a Node too!
Nodeception! xD
amazing editing, subbed!
Hmm... Maybe I'll try out Bevy for my next game. From what you described, looks like something I might like.
Unity's closed source nature has certainly shown its weaknesses now lol
FOSS all the way 💪
One of the reasons I'm window shopping for other game engines is Unity's slow editor. Starting Godot takes seconds, which is soo good when you're working on something on and off. This is especially useful when you're in the "testing out ideas" phase.
That said, there's no real reason why Unity *has* to be so slow. It's entirely possible to redesign it to use lazy loading of editors and windows, and utilise threading to pre-emptively load the necessary components in the background. They've partially started work on that, by splitting things into components, but I feel they just don't have the incentive to actually get the editor speed up. Their core demographic are people that load the project in the morning, work over the day with it, only to shut it down in the evening before they go home. If even that, just locking the work station before going home is quite common in a lot of places.
As to being forced to work with inheritance, I think that's not quite true. Yes, you need to inherit the right base class for your code, but in no way are you forced to make inheritance trees to build your game, it has all the necessary tools to work with composition instead. That's more on the way you're using it than how you *have* to use it. At least in my experience.
Very professional video made all the more relevant after the recent Unity apocalypse. Game engines are actually meant to be CONFIGURED, like PhotoShop or 3d Studio Max, then programmed so the lack of C# support may not be a big deal if the editor is very complete. Rust seems way to complicated for the average gamedev these days, but Rust has great .Net interop. Can C# scripting be ADDED to Bevy and is it a GOOD idea?
IIRC bevy scripting in other languages is one of their design goals, such as a recent migration from depending on Type IDs to "ComponentIds" to distance from rust specific logic. But as of this moment, it has not been implemented. I think creating an editor is their priority currently
@@loganwoodbury4050 That's interesting. It may make Bevy max out on performance for the regular gamedev. It may be too late for the hoard of Unity developers looking for something else, but ultimately there is always room for quality.
@@Casulite From my view as a programmer coming from SDL and XNA using the mouse to get a desired effect in a game engine is configuring something. Back in my Amiga days Deluxe Paint was used to make images with the MOUSE and that wasn't considered configuring, but you COULD be pixel pushing individual pixels. Applications like Photoshop are more about serially triggering commands that have an effect on the underlying pixels, but aren't really about the pixels. They are more HIGH LEVEL. They should, as it would be way TOO MUCH WORK to hand optimize every pixel especially with the high reze images that for instance a glossy magazine uses. The lesson here for Bevy is that it's RAISING the interface for Designers who design the Game, Level, UI or the overall Experience. That also implies that it shouldn't optimize for Content like Dialog and Lore as other tools like Articy Draft or Arcweave are better. The same goes for creating Assets, because that is better done in something like Blender or Krita. Not that it's prohibited to have such functionality, but using a pipeline of SPECIFIC OPTIMIZED tools for certain tasks would make more sense to me.
Without any negative connotation, I think you are misunderstanding some of the stuff you talked about. Traditional GameObject-type of Component system is unefective for various reasons, so Dots ECS is aiming to outperform it with different memory layout. It has very little to do with the code design.
Godot and Unity are very similiar to each other in terms of Component systems. Sure, GDScript is less of a OOP fanboy, but still.
In Unity, I see you are reffering some objects from other objects, and it's typically means a bad design. Ideally you should have systems/managers that do all the same stuff (or very similarly) as Bevy. Sure, Bevy ENFORCES you to do it this way, which is good, but boy-o-boy, it has some other problems.
I'm by no means any expert, but I've noticed something many game-devs have in common, including me - trying to make the enviroment perfect, switching game engines, tools, technologies, languages, patterns etc. Someone can go as far as creating his own game engine or even his own language (hello JBlow). But for the most part, it's just for the sake of it. It brings a certain joy, but most of the time results in negative perfomance. I've struggled with Unity so much, and I was certain it's a editor issue, but sinse then I've seen tons of very good, very beatiful code architectures made in Unity and realized that in fact it's just my skill issue. Realistically, Unity is the best game engine for indie devs, but you can use whatever tool you know best (I've also seen thousands lines of plain C game or Roller Coaster Tycoon programmed by one guy in assembly). If you want to make games... Just make games.
Switchers don't finish games, they are not serious about their time and dedication they are just playing around. Why don't make games in assembly where you can communicate directly in memory instead then right
I also recently pivoted to bevy... so far its preeeetty nice!
Unity events and using list is my go to methods to make the most out of the engine.
Awesome video. Thanks for this great content
I thought the animation style looked familiar. The videos look great in Aarthificials tool! Good job!
If you rely heavily on inheritance using Unity, you're just doing it wrong. It's very much possible and beneficial to design your code to favor composition over inheritance.
I'm unsure if you're still open to feedback-shaped thoughts at this point, but in case you are:
- The geometric art direction you've been going with gives me some Tron-esque vibes (less Tron Legacy and more old school Tron, but even so) - I wonder if it's worth leaning into that a little during art refinement - kind of a Geometric Technomantic thing vibe. See also Hyper Light Drifter, the Progenitors from Homeworld, the Zeffo from Jedi Fallen Order, Endless Legends.. anything where ancient-become-archeological advanced technology is a prevalent thing and there's wonderful aesthetic to draw from.
- In one of your previous devlogs you put a poll up for naming Fragments - one of the names was "Relics" - I wonder if you can/should co-opt the name as a mechanism for another upgrade distinct from Fragments. Fragments increase stats while Relics could unlock Abilities like Grapple, or a radial burst attack: stuff like that. That way it becomes a decision: "Do I want to boost my stats, or do I want to have this tactically useful ability?". It also lets you achieve progression by re-using an existing and familiar inventory mechanic - just slightly differently.
Just for reference, Unity DOTS is basically Bevy with a C#/Unity flavor and the force of a public traded company behind it. It's still missing features for big or 2d games tho...
How do you make the amazing animations/visuals comparing Unity and bevy’s composition vs inheritance structures?
I switched from Unity to Godot and then to Bevy for the same reason. Bevy's ECS makes really easy to compose game from smaller systems!.
Most developer looking for editor of course but I'm more comfortable with code first game engine
cool kepp doing what your doing
6:14 song name?
1000th like on ur video keep up the good work ❤
There is an ECS version of Godot. And a Rust version. That's open-source, baby🎉
+rep for using the Vim extension
7:20 Quick note: Bevy uses the ECS paradigm, which is "Entity, Component, SystemS", not System.
It's a bit annoying that even their wiki got it wrong, but there's a key difference between EC System and ECS, one implements the logic inside the component and the other one implements systems as separate functions from the component, leavening components as data only. Unity does the former while Bevy does the latter. Not your fault, but wanted to leave the note for people to learn about it
I have always struggled as to what engine to use, but in an unproductive manner. I'm just a begginer anyway, but it's really pedagogical to watch your impressions over different engines. So are you sticking with Bevy for future development?
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.
Ah, the pendulum of object oriented to data driven swings again. It's a well observed fact that programmers tend to lean into one side, then new programming languages come out that lean towards the other side to fix problems with the opposite side. Rinse and repeat, since C spawned C++ if not before.
One thing you might want to look at is Inversion of Control, along with Test Driven Development. Both help in avoiding the dependency graphs you described. Now, I'm not saying you should stick to Unity, or Godot, or whatever. But it seems to me that your problem lies less in the specific engine, and more in methodology to help writing cleaner code in general.
TDD forces you to focus on testable units, and while it does force you to write more boilerplate code it tends to be worth it over the lifetime of a project. Sadly, it's not always straightforward of how to use it in most game engines.
Inversion of Control moves the responsibility of connecting components together out of the components "hands," making it do less. And also helps by allowing components to be replaceable easily.
Inheritance should never be used to add functionality, and only when something *is* something else. A car *can* be controlled by another entity, it *isn't* a "Mount." A player *isn't* a health bar, they *have* one. And so on.
In particular, besides the bloated sluggish part of Unity, and it's lack of source code access, everything you described can be done in Unity just as well as in Godot. Can't speak for Bevy, but it looks like a mistake to work in a less developed game engine where you spend more time coding game engine tasks than your own game. You'll run into the same issue as in Godot, where a bug appears and isn't being solved more often, but with fewer tutorials and people to ask how to get around the issue.
Also, don't be afraid to use events or messages. They *are* slower than direct calls, but if used properly the difference isn't noticeable. In particular, damage delivery could be a message or event, allowing you to decouple your code. That way your HealthComponent can respond to damage received, making it possible to add that to enemies, players, breakable boxes, and even projectiles themselves.
one of the big advantages bevy has over godot, unity etc is that its really modular. want to just use the ECS and do everything else yourself? you can. want to rip out and replace the entire renderer? sure.
since the engine is Rust and the game code is Rust the separation between engine and game just isnt that big. makes it much easier to understand what the engine does (well, unless you're messing with ECS internals those are a bit obscure).
@@laundmo I'm sure that's great. But there's two issues. One, you spend time writing the game engine that could be spent on making your game. This is fine if you are heavily invested in an open source game engine, I've put in some time on open source projects that I used myself. But making a game is hard, getting it ready to release is even harder. You really, *really* should ask yourself: Do I want to focus on the game engine, or my game?
Secondly, I can't help but notice that when a bug appeared that stopped progress on his game in Godot, which is open source and more feature complete, he rather move to another game engine than look into the bug and fixing it. No shame in that, like I said: Which is more important, the game or the game engine.
But there's a higher chance of getting game breaking bugs in a newer, more incomplete open source game engine, than there is in a more mature one like Godot. And you *still* need to get into the fine details of how the game engine works to fix those.
I had a similar situation when I used a smaller, well designed, game engine. I tried to make use of the stencil buffer, only to find out that the implementation was completely messed up, with the read mask zeroed out and hardly any of the modes used. So I decided to fix it. Which required me to look into OpenGL's implementation of the stencil buffer. Which led me to look into the middleware implementation. Then back to the game engine, only to find out that I have to go fix the window creation code since it didn't even initialise the stencil mode. Back to OpenGL reference docs. Hmm, maybe I should have a look at Unity. Sure, it's not open source, but… It's been weeks since I wrote anything on my game by now.
bevy looks so smooth... 😯
for real, the more you learn how to actually use rust instead of just learning syntax and applying your previous languages knowledge, the more you fall in love with it
so true
Would you say Rust is safe to jump in directly without experience with other languages if I'm willing to jump over the hurdles, or would you say another introductory language would be a better idea to start with? Personally I like the way the philosophy of rust sounds, and I'd like to begin my journey into programming with that mindset, but I'm wondering if it's reasonably feasible.
@@Kiwi-fl8te Thats a really tough question I havent thought about that much. I guess its always nice to start with a simple language that is easy to learn, so you focus more on programming itself rather than learning the language. I suppose you could start with rust, but it will likely take much longer until you get comfortable with writing code. Its really up to you. The most important thing is to simply start learing any language. If you want to learn rust, go for it. It cant hurt.
@@timberdev I might just try to start with Rust then.
I've also considered the most conventional start of learning Python.
I'm at least not completely alien to programming logic, as I've okayed around with visual languages before.
2:12 no, I don't think you should rely on inheritance in unity, actually it is a bad idea. The way unity inspector stores data doesn't recognize inheritance, so if you want to switch to inheritance class or switch back to your base class, you lose your inspector data. You can lose lots of setting if your class has lots of variables.
Finally a new video
FINALLLLLLLYYYYY
Really well made video love it!
Funny enough the man that popularized ECS, Mike Acton, is the same person who wrote the DOTS system for unity.