Get 40% off CodeCrafters + 1 week free! app.codecrafters.io/join?via=BarneyCodes Been a while since you've seen my mug on here, hopefully it's not too confronting!
"Don't do everything yourself" and "use an engine" aren't synonymous and shouldn't be used this way, IMHO. I usually compare it to cooking. I don't want to build my own stove and cast my own pan, etc. However, the existing engines are like McDonalds kitchen, which is the other extreme. I want to buy a pan, pick between iron cast or Teflon, maybe go for a wok shape, etc... but ultimately I want to setup my own kitchen for the kind of cooking I'll be doing. I really don't want to go into the McDonalds kitchen to try to adapt it for making pasta or pizza. Even the sentiment of "just make a game". Game isn't a painting that you just paint. Game is a piece of software. Games are basically the only software that have this kind of tooling. Every other software is built via normal build processes, not by launching an app, that has a button to make another app. Like, I don't disagree with your sentiment in general, and most of your points, I'm just adding this to point out why engine still might not be the answer.
I think another common trap once you use an engine is to get stuck making tools. Tools are nice to have and you might be able to sell them, but in the end if your goal is to release games then spending time polishing tools does not achieve that goal.
Ahh I'll definitely have to look out for this when I start using an engine, thanks for the heads up!! It's so easy to procrastinate when you can kid yourself that it's productive!
I think this totally depends on what tools you're already provided. I have used a "ready for production" game engine (Unity) for quite a few years and its still nearly impossible for me to work on solo projects because I still make editor tools. What matters more, in my opinion, is whether the tools you're provided feel satisfactory or if you feel you could do better.
Trap that's been luring me in: "Games with bespoke engines are easier to release updates for because the engine can be modified at any time. i.e. EVE Online"
Most voxel games (on the level of Minecraft) even are perfectly suited for game engines; it's only if you want to go super crazy with high fidelity voxels, voxel raytracing, particle physics etc. that an engine might fail you
Someone else already mentioned this somewhere else, and you also replied, so I guess I'll just add to the pot: The line between "from-scratch" and "full engine" is often quite blurred. I agree with you that, in a lot of cases, doing things from scratch is often significantly more time-consuming, difficult, and annoying in the long-run. However, I think the subjectivity of the matter comes a lot more from where exactly you start. When you're developing your games, at least as far as I'm aware, you're not using assembly at all. Arguably, you could be going a lot more "from-scratch" if you wanted to, be it machine code, building a computer from the logic-circuit up, or even mining and refining the materials for the computer yourself. I quite liked the sheep and knitting analogy you used, but I wouldn't really say it's fully accurate. I might be able to shear the wool off the sheep myself, but at the same time, I could also buy the wool directly from a farm, while still spinning the wool into yarn myself. I think this can be applied to game dev in many ways, too. Sure, I could write my entire game using a custom physics engine, but at the same time, I could also use a physics library. Maybe I could opt to use a higher-level language such as Python, so that all the memory management is handled for me, unlike with languages such as C. I suppose what I'm trying to say is that it's not a binary between from-scratch and game engine, it's a spectrum between the two. I can go full game engine if I want to, but I could also opt to use a library, such as LWJGL or Raylib, which removes many of the difficulties which come associated with writing a full game engine from scratch. Aside from that, though, I'm loving your channel! It's hard to find non-clickbaity videos where there isn't some guy screaming into the microphone.
Great comment, and I have to agree! I left out frameworks/libraries entirely from my video which may have been a bit of an oversight, they definitely offer a very nice middle ground where you can still get your hands dirty, but you don't need to start from 0. My main aim with this video was just to get people to think about what they are actually trying to achieve and I think in most cases, going from scratch is not the answer! Thanks again for the comment and the kind words!
being able to say "I made the game engine from scratch" can be such a good selling point. The fact that a game isn't bound by an engine's limitations is what really makes for unique experiences. But agreed that you'll be spending more time squashing bugs than design and features. Probably a good idea to at least prototype in an engine and then possibly transition to a custom engine when it needs it.
My understanding is very limited, but I feel like there would often be things that are said to be limitations of the engine but are actually limitations of the developer (obviously there would be ACTUAL limitations, but they're probably a lot wider than what some people think) Like you say, it's probably wise to prototype in an engine first and then figure out if you need something custom!
Well, I've got this on my mind after a few programmer friends asked me about just moving to an engine while the game is considerably done, so I'll join the rant- I'm currently on like... 8 months of gamedev, and while I didn't go for a game engine, I didn't make it from scratch, per se... I'm using a game library, Raylib to be specific. That did help a bunch because all the work for the collision, the shaders etc have been "skipped", but it's still focused on programming, which is my forte, and I still have the flexibility of coding "from scratch", since I can just overload or not include parts of the game library that I'm using. There is a reason for me to do that, and I'll mention it soon. I've not that much finished-game-gamedev experience. I've only some small platforming things and some collision details solved to my name, but I've tagged along platforming gamedevs on bugs and glitches enough to feel comfortable, and that's what's making me comfortable with my choice, most of all. There's also the thing that I have a long-term plan of supporting the game once I have it done, with varying levels of success taken into account. The capability to be able to adjust the "root" level of the physics to deal with pesky corner cases years after the launch is something that I'm sure that I'll need, and the level of optimization is really important for the genre (Platform Fighter, which needs to be CONSISTENTLY at 60 fps), so those are the main reasons I'm picking the game library route. Would I recommend to go for game libraries to just put commercial games out there? Dear GOD no, even with the "skip" that the library gives its still too much effort. Do I regret going the way that I'm going at it? No, at least not yet, and I got a feeling that I won't. Does it take some major concentration and patience to do it? Yes. Every step needs much more preparation before the reward of seeing stuff take place in your screen. It is a huge commitment, and you need to think thoroughly to go through it. If you think it is necessary though, don't be afraid to do it. Just keep in mind, you'll have to appreciate the smaller things much more to keep yourself motivated. But I'm sure it is worth it.
I didn't mention frameworks in my video which was a bit of an oversight on my part, but I think they're a great middle ground where you get a lot of control, but you've also got some building blocks to work with that hopefully make it realistic/sustainable to actually make things with it! I might have to explore some framework options in the future, because I do really enjoy doing things in a more code-oriented way!
I've been meaning to check bevy out for a while now, it seems really interesting! I think a framework (or similar) might be a really great way for me to still feel hands on and code-oriented, without having to do everything from scratch!
@BarneyCodes Being code orientated while not having to so absolutely everything is what I really like about Bevy. Also, Bevy docs are simply amazing. Ps. Great video by the way 👏🏿
I loved your video. I totally get you, and I somewhat agree and disagree. Building things from scratch (provided you have experience) is a bit more straight forward because you're familiar with the process. Especially when it comes to 2D games, you can easily make a game without really an engine. I've done it in the past. But using a commercial engine like UE5 or Unity can be sooooo much better ONLY if you already know how to use them. Like you mentioned, lighting, bloom, etc. no need to configure a framebuffer yourself and code it yourself or even tweak shaders, you can just enable Bloom from the game engine option or click and drag a light actor into the scene. But... the downside of an engine is that, very much like programming things from scratch, it takes A LONG TIME TO LEARN THE ENGINE... and get used to it. So, in other words, you're back at square 1. Not to mention some engines require languages you might have never programmed in... such as GDScript or C#... I've only ever done C++. Either way, I don't regret not using an engine because it made me a better programmer. Now I've just installed UE5 and I'm learning Paper2D... Hopefully I can fully transition to it simply because... sound effects and music for free, and letter formatting for free that comes with an engine... as well as other visual effects, ohh that's just so convenient...!!! Less technical work for me to do and more focusing on the actual game! I just subbed, awesome video the way you phrased everything is to the point and very well explained!
Thanks for the great comment! Totally agree that there's a BIG investment in learning everything required to use an engine. Hopefully, having done things from scratch in the past, we'll have a good starting point and the transition shouldn't be too painful! There's always a bit of bumbling around when learning something new (like a new language), but I think the more you do it, the easier it is, because the concepts are transferable, it's the HOW that changes! Good luck for your UE5 journey!
I think factorio is basically the perfect example of NEEDING to make your own engine because it's doing something super unique (just like the example I gave in the video of Noita etc)
as a (not game) developer I understand the urge to do everything on your own, that way you know how everything works and you can always customize, expand and change the behaviour to work with the other parts of the project, you don't rely on other packages and you learn a lot of plain knowledge and Principles behind some things as well as learning and having control over optimizations. Since i've never done stupidly big projects it worked out so far, but I can imagine the scope of the project just balloons out of control quick But on the other other hand, when you do a lot of things custom in the right way, eventually you'll have an ever growing toolset that you can use in other projects too, but then you also need to maintain its functions for all applications which is again a lot of work
You can learn sooo much by doing things yourself, and the feeling of control is really nice, but like you say maintaining it all becomes just as much of a job as using it to build things! Very much comes down to what you're trying to achieve I think!
Yes. Now I'll watch the video. Edit. Loads of good points. I'm definitely in the camp of build an engine around a crazy concept and see if a viable game can be made, rather than make a game people want to play.
That's definitely how I got started in game dev too, always just trying something technically interesting that I wanted to code, then try and turn that into a game. I carried that mentality forward though when I was setting out with the goal of making a game which was a bit silly of me haha!
While I agree with most of what you are saying, it also gave me the impression that you are underestimating the struggles of using an already made engine. Which isn't to say that your overall message isn't true. I actually agree that making your own engine should be the exception. But the time investment in learning someone else's solution is not negligible, specially when compared to making your own simplified version. I used Unity for years, and I'm too familiar with banging my head against some unity's system, trying to make it work. Weeks later I give up and make my own in an afternoon. This isn't an isolated event. Also not uncommon is updating the engine and breaking the entire project. Also not isolated. Then there's the more pressing problem of not having a very good free and open source solution out there, in my opinion. Licensed engines, like unity will impose extra costs on you as well. Which sucks on a profession that's very hard to make a living on. Anyway, this is a good video. Subscribed. I'm curious to know how your opinion will update after your use one of these engines for your next projects!
That is almost certainly the case, since I haven't done anything more than mess around a little bit in a pre-made engine. I'm sure there are all sorts of struggles and headaches that come along with using them, especially on larger/more complex games! I think frameworks are a very good middle ground of giving you some more control while also giving you enough to finish projects in a reasonable time frame. I'm sure my opinion will become a bit more nuanced as time goes on, but I think in general my stance is "make sure you've got a GOOD reason to do it from scratch" and at the moment, I don't have one!
@@BarneyCodes However, one thing is certain: for prototyping, exploring game design, etc, it has to be a full blown engine. You need to iterate quickly. So unity, game maker, have to be part of the toolkit. Even if you want to move it back to another engine later.
I think learning, having fun, and making a technically complex game that can't be made with a pre-made engine are the only really legitimate reasons. I genuinely enjoy the programming that I'm doing while working on my engine, but my main goal is to release games, in which case, as you say, it doesn't really make sense to make my own engine!
1. Making engines and making frameworks are entirely two different things. 2. Godot is nowhere near enough for practical game developement. 3. Unity is bloated, I don't know a single good game that doesn't lag in comparison with AAA games that don't and actually look better. 4. Unreal Engine is also bloated. Same arguments as with Unity. I remember playing Green Hell and it was... not fun. On my GTX 960 (at that time), Witcher 3 on normal settings was giving me around 80-ish fps and looked good, while green hell looked like a 2011 game at best at settings that gave me at most 60 fps. I understand that people that use these engines usually overlook the underlying processes, techniques and architecture and spiral into the route of bad practices, resulting in a bad player experience. Licensing is another part of all of this. Game engines try to be a magic bullet, solution for all problems, but in reality, you're stuck on reimplementing your own graphics pipeline, your own physics, your own UI, implementing your own game mechanics, and for people that don't - marketplace exists, which add on to the problem by brute-forcing the solution, sometimes trying to fit them all together. IMHO - practical engines/frameworks that solve only one problem (your game) are better for many reasons.
@@kickflipthisYes. And you still have to implement 90% of what you want or find hacky ways because of lack of support. I'm not saying it's impossible, just not practical.
Those public engines are made in a way that lets you click together a simple "game" in an evening. Once you're really into using them and coding around their quirks, they become nothing more than a framework that lets you open a window, upload textures and shaders and handle user input. You can have this in a few kilobytes using something like SDL, GLFW, Raylib or whatever, or you can waste a gigabyte for an engine of which you don't have a clue what it even does with all the resources.
I did overlook frameworks quite a bit in this video, which is my mistake! I can definitely see them being a good middle ground where you still get a fair bit of control, but also get given enough to be able to actually finish a project in a reasonable time frame.
i think game engine's need to expose more of the garbage collector or let the developer manage resources themselves it seems there's really no such thing as a full proof garbage collected game engine, many big unity games suffer from memory leaks which devs are always fighting. another issue seems to be the engine wanting to load every resource in the entire level, instead of streaming textures in and out which is supposed to be a feature of off the shelf engines but it seems that in many cases it'll decide to load everything into ram, the devs never think about this stuff they blame unity or unreal.
Get 40% off CodeCrafters + 1 week free! app.codecrafters.io/join?via=BarneyCodes
Been a while since you've seen my mug on here, hopefully it's not too confronting!
"Don't do everything yourself" and "use an engine" aren't synonymous and shouldn't be used this way, IMHO.
I usually compare it to cooking. I don't want to build my own stove and cast my own pan, etc. However, the existing engines are like McDonalds kitchen, which is the other extreme. I want to buy a pan, pick between iron cast or Teflon, maybe go for a wok shape, etc... but ultimately I want to setup my own kitchen for the kind of cooking I'll be doing. I really don't want to go into the McDonalds kitchen to try to adapt it for making pasta or pizza.
Even the sentiment of "just make a game". Game isn't a painting that you just paint. Game is a piece of software. Games are basically the only software that have this kind of tooling. Every other software is built via normal build processes, not by launching an app, that has a button to make another app.
Like, I don't disagree with your sentiment in general, and most of your points, I'm just adding this to point out why engine still might not be the answer.
Very good point that I somehow managed to miss. Frameworks definitely have a place and can be a great middle ground
I think another common trap once you use an engine is to get stuck making tools. Tools are nice to have and you might be able to sell them, but in the end if your goal is to release games then spending time polishing tools does not achieve that goal.
Ahh I'll definitely have to look out for this when I start using an engine, thanks for the heads up!! It's so easy to procrastinate when you can kid yourself that it's productive!
I think this totally depends on what tools you're already provided. I have used a "ready for production" game engine (Unity) for quite a few years and its still nearly impossible for me to work on solo projects because I still make editor tools. What matters more, in my opinion, is whether the tools you're provided feel satisfactory or if you feel you could do better.
Trap that's been luring me in:
"Games with bespoke engines are easier to release updates for because the engine can be modified at any time. i.e. EVE Online"
Most voxel games (on the level of Minecraft) even are perfectly suited for game engines; it's only if you want to go super crazy with high fidelity voxels, voxel raytracing, particle physics etc. that an engine might fail you
Bro I really hope you finish strong and update us along the way. I need some legitimate dev log content in my life
Haha thanks mate, that's the plan!
Someone else already mentioned this somewhere else, and you also replied, so I guess I'll just add to the pot:
The line between "from-scratch" and "full engine" is often quite blurred. I agree with you that, in a lot of cases, doing things from scratch is often significantly more time-consuming, difficult, and annoying in the long-run. However, I think the subjectivity of the matter comes a lot more from where exactly you start.
When you're developing your games, at least as far as I'm aware, you're not using assembly at all. Arguably, you could be going a lot more "from-scratch" if you wanted to, be it machine code, building a computer from the logic-circuit up, or even mining and refining the materials for the computer yourself.
I quite liked the sheep and knitting analogy you used, but I wouldn't really say it's fully accurate. I might be able to shear the wool off the sheep myself, but at the same time, I could also buy the wool directly from a farm, while still spinning the wool into yarn myself.
I think this can be applied to game dev in many ways, too. Sure, I could write my entire game using a custom physics engine, but at the same time, I could also use a physics library. Maybe I could opt to use a higher-level language such as Python, so that all the memory management is handled for me, unlike with languages such as C.
I suppose what I'm trying to say is that it's not a binary between from-scratch and game engine, it's a spectrum between the two. I can go full game engine if I want to, but I could also opt to use a library, such as LWJGL or Raylib, which removes many of the difficulties which come associated with writing a full game engine from scratch.
Aside from that, though, I'm loving your channel! It's hard to find non-clickbaity videos where there isn't some guy screaming into the microphone.
Great comment, and I have to agree! I left out frameworks/libraries entirely from my video which may have been a bit of an oversight, they definitely offer a very nice middle ground where you can still get your hands dirty, but you don't need to start from 0.
My main aim with this video was just to get people to think about what they are actually trying to achieve and I think in most cases, going from scratch is not the answer!
Thanks again for the comment and the kind words!
being able to say "I made the game engine from scratch" can be such a good selling point. The fact that a game isn't bound by an engine's limitations is what really makes for unique experiences. But agreed that you'll be spending more time squashing bugs than design and features.
Probably a good idea to at least prototype in an engine and then possibly transition to a custom engine when it needs it.
My understanding is very limited, but I feel like there would often be things that are said to be limitations of the engine but are actually limitations of the developer (obviously there would be ACTUAL limitations, but they're probably a lot wider than what some people think)
Like you say, it's probably wise to prototype in an engine first and then figure out if you need something custom!
Well, I've got this on my mind after a few programmer friends asked me about just moving to an engine while the game is considerably done, so I'll join the rant-
I'm currently on like... 8 months of gamedev, and while I didn't go for a game engine, I didn't make it from scratch, per se... I'm using a game library, Raylib to be specific.
That did help a bunch because all the work for the collision, the shaders etc have been "skipped", but it's still focused on programming, which is my forte, and I still have the flexibility of coding "from scratch", since I can just overload or not include parts of the game library that I'm using. There is a reason for me to do that, and I'll mention it soon.
I've not that much finished-game-gamedev experience. I've only some small platforming things and some collision details solved to my name, but I've tagged along platforming gamedevs on bugs and glitches enough to feel comfortable, and that's what's making me comfortable with my choice, most of all.
There's also the thing that I have a long-term plan of supporting the game once I have it done, with varying levels of success taken into account.
The capability to be able to adjust the "root" level of the physics to deal with pesky corner cases years after the launch is something that I'm sure that I'll need, and the level of optimization is really important for the genre (Platform Fighter, which needs to be CONSISTENTLY at 60 fps), so those are the main reasons I'm picking the game library route.
Would I recommend to go for game libraries to just put commercial games out there? Dear GOD no, even with the "skip" that the library gives its still too much effort.
Do I regret going the way that I'm going at it? No, at least not yet, and I got a feeling that I won't.
Does it take some major concentration and patience to do it? Yes. Every step needs much more preparation before the reward of seeing stuff take place in your screen.
It is a huge commitment, and you need to think thoroughly to go through it. If you think it is necessary though, don't be afraid to do it.
Just keep in mind, you'll have to appreciate the smaller things much more to keep yourself motivated. But I'm sure it is worth it.
I didn't mention frameworks in my video which was a bit of an oversight on my part, but I think they're a great middle ground where you get a lot of control, but you've also got some building blocks to work with that hopefully make it realistic/sustainable to actually make things with it!
I might have to explore some framework options in the future, because I do really enjoy doing things in a more code-oriented way!
so incredibly real
I feel like something like Bevy, sits really nicely in between a game engine and a framework. Its what ive been exploring recently.
I've been meaning to check bevy out for a while now, it seems really interesting! I think a framework (or similar) might be a really great way for me to still feel hands on and code-oriented, without having to do everything from scratch!
@BarneyCodes Being code orientated while not having to so absolutely everything is what I really like about Bevy. Also, Bevy docs are simply amazing.
Ps. Great video by the way 👏🏿
Wicked Engine!
I had to look it up cos I've never heard of it before, but it looks very interesting! I might have to investigate further!
@@BarneyCodes skip it, move on to Almond Engine.. I made it, #1 best engine
I loved your video. I totally get you, and I somewhat agree and disagree. Building things from scratch (provided you have experience) is a bit more straight forward because you're familiar with the process. Especially when it comes to 2D games, you can easily make a game without really an engine. I've done it in the past. But using a commercial engine like UE5 or Unity can be sooooo much better ONLY if you already know how to use them. Like you mentioned, lighting, bloom, etc. no need to configure a framebuffer yourself and code it yourself or even tweak shaders, you can just enable Bloom from the game engine option or click and drag a light actor into the scene. But... the downside of an engine is that, very much like programming things from scratch, it takes A LONG TIME TO LEARN THE ENGINE... and get used to it. So, in other words, you're back at square 1. Not to mention some engines require languages you might have never programmed in... such as GDScript or C#... I've only ever done C++.
Either way, I don't regret not using an engine because it made me a better programmer. Now I've just installed UE5 and I'm learning Paper2D... Hopefully I can fully transition to it simply because... sound effects and music for free, and letter formatting for free that comes with an engine... as well as other visual effects, ohh that's just so convenient...!!! Less technical work for me to do and more focusing on the actual game!
I just subbed, awesome video the way you phrased everything is to the point and very well explained!
Thanks for the great comment! Totally agree that there's a BIG investment in learning everything required to use an engine. Hopefully, having done things from scratch in the past, we'll have a good starting point and the transition shouldn't be too painful!
There's always a bit of bumbling around when learning something new (like a new language), but I think the more you do it, the easier it is, because the concepts are transferable, it's the HOW that changes!
Good luck for your UE5 journey!
You forget factorio, the most polished game since snake. Built on a custom engine for 10+ years to massive success
I think factorio is basically the perfect example of NEEDING to make your own engine because it's doing something super unique (just like the example I gave in the video of Noita etc)
interesting perspective
You should put visuals of your game in the first seconds of the video, I didn't notice I was looking at one of your videos before I saw the game
Oh that's a good idea, thanks for the tip!
as a (not game) developer I understand the urge to do everything on your own, that way you know how everything works and you can always customize, expand and change the behaviour to work with the other parts of the project, you don't rely on other packages and you learn a lot of plain knowledge and Principles behind some things as well as learning and having control over optimizations.
Since i've never done stupidly big projects it worked out so far, but I can imagine the scope of the project just balloons out of control quick
But on the other other hand, when you do a lot of things custom in the right way, eventually you'll have an ever growing toolset that you can use in other projects too, but then you also need to maintain its functions for all applications which is again a lot of work
You can learn sooo much by doing things yourself, and the feeling of control is really nice, but like you say maintaining it all becomes just as much of a job as using it to build things!
Very much comes down to what you're trying to achieve I think!
Yes. Now I'll watch the video.
Edit. Loads of good points. I'm definitely in the camp of build an engine around a crazy concept and see if a viable game can be made, rather than make a game people want to play.
That's definitely how I got started in game dev too, always just trying something technically interesting that I wanted to code, then try and turn that into a game. I carried that mentality forward though when I was setting out with the goal of making a game which was a bit silly of me haha!
would be awesome if you make some tutorials about gdextension
I'll have to learn about it myself first, but if I come across anything cool I'll definitely share it!
While I agree with most of what you are saying, it also gave me the impression that you are underestimating the struggles of using an already made engine. Which isn't to say that your overall message isn't true. I actually agree that making your own engine should be the exception. But the time investment in learning someone else's solution is not negligible, specially when compared to making your own simplified version. I used Unity for years, and I'm too familiar with banging my head against some unity's system, trying to make it work. Weeks later I give up and make my own in an afternoon. This isn't an isolated event. Also not uncommon is updating the engine and breaking the entire project. Also not isolated. Then there's the more pressing problem of not having a very good free and open source solution out there, in my opinion. Licensed engines, like unity will impose extra costs on you as well. Which sucks on a profession that's very hard to make a living on.
Anyway, this is a good video. Subscribed. I'm curious to know how your opinion will update after your use one of these engines for your next projects!
That is almost certainly the case, since I haven't done anything more than mess around a little bit in a pre-made engine. I'm sure there are all sorts of struggles and headaches that come along with using them, especially on larger/more complex games!
I think frameworks are a very good middle ground of giving you some more control while also giving you enough to finish projects in a reasonable time frame.
I'm sure my opinion will become a bit more nuanced as time goes on, but I think in general my stance is "make sure you've got a GOOD reason to do it from scratch" and at the moment, I don't have one!
@@BarneyCodes However, one thing is certain: for prototyping, exploring game design, etc, it has to be a full blown engine. You need to iterate quickly. So unity, game maker, have to be part of the toolkit. Even if you want to move it back to another engine later.
Fun fact. I’ve subscribed because you make your own engine 😂
Oh no 😅 I'll still be doing some low level stuff, just not when I want to make a game!
Please take one step back from the camera lol
Lol yeah I need to get a wider-angle lens, the one I've got is too zoomed in and I can't go back any further hahaha
I don't get that why would anyone think it is a better idea to create an own game engine...
I think learning, having fun, and making a technically complex game that can't be made with a pre-made engine are the only really legitimate reasons.
I genuinely enjoy the programming that I'm doing while working on my engine, but my main goal is to release games, in which case, as you say, it doesn't really make sense to make my own engine!
1. Making engines and making frameworks are entirely two different things.
2. Godot is nowhere near enough for practical game developement.
3. Unity is bloated, I don't know a single good game that doesn't lag in comparison with AAA games that don't and actually look better.
4. Unreal Engine is also bloated. Same arguments as with Unity. I remember playing Green Hell and it was... not fun. On my GTX 960 (at that time), Witcher 3 on normal settings was giving me around 80-ish fps and looked good, while green hell looked like a 2011 game at best at settings that gave me at most 60 fps.
I understand that people that use these engines usually overlook the underlying processes, techniques and architecture and spiral into the route of bad practices, resulting in a bad player experience.
Licensing is another part of all of this.
Game engines try to be a magic bullet, solution for all problems, but in reality, you're stuck on reimplementing your own graphics pipeline, your own physics, your own UI, implementing your own game mechanics, and for people that don't - marketplace exists, which add on to the problem by brute-forcing the solution, sometimes trying to fit them all together.
IMHO - practical engines/frameworks that solve only one problem (your game) are better for many reasons.
"Godot is nowhere near enough for practical game development"
Have you used godot? Have you seen the shipping games using it?
@@kickflipthisYes. And you still have to implement 90% of what you want or find hacky ways because of lack of support. I'm not saying it's impossible, just not practical.
Those public engines are made in a way that lets you click together a simple "game" in an evening. Once you're really into using them and coding around their quirks, they become nothing more than a framework that lets you open a window, upload textures and shaders and handle user input. You can have this in a few kilobytes using something like SDL, GLFW, Raylib or whatever, or you can waste a gigabyte for an engine of which you don't have a clue what it even does with all the resources.
I did overlook frameworks quite a bit in this video, which is my mistake! I can definitely see them being a good middle ground where you still get a fair bit of control, but also get given enough to be able to actually finish a project in a reasonable time frame.
i think game engine's need to expose more of the garbage collector or let the developer manage resources themselves it seems there's really no such thing as a full proof garbage collected game engine, many big unity games suffer from memory leaks which devs are always fighting.
another issue seems to be the engine wanting to load every resource in the entire level, instead of streaming textures in and out which is supposed to be a feature of off the shelf engines but it seems that in many cases it'll decide to load everything into ram, the devs never think about this stuff they blame unity or unreal.