The right mindset to develop your own engine is that you're not developing an ENGINE, you're developing a GAME. Your codebase grows every time you code, you have full control over it, you make the data available the way you like (for me this is the number 1 reason), you can fix something in the moment instead of waiting for someone else to do it. You can develop your own tools, such as a level editor, etc., of course, and that will benefit you, but it's not necessary from the start. You don't have to try to create a set of tools for everything. It's a gradual process until you realize what exactly do you need from the tools. BTW if no one will try to develop an engine, who will maintain existing ones?
There's a guy in the corner of my room brandishing a lead pipe at me 24/7 and whenever I try to make a game engine he starts raising it, so I've decided it's not really worth the effort.
Time. If you're making a game engine then you're hobby is making a game engine. If you want to make a game then use an existing engine. Choose the level of abstraction you want to work at and do that. Your argument would also work lower level. What's stopping you making your own language and compiler? Why use C/C++ when you can design your own language and compiler to assembler? It's not that hard. You understand C and memory control but C has pointers. You can make a.memory safe version. You understand enough about memory management, it's no different in Assembler. So why not? You can always jump back to higher level languages. So why not? Time.
Time seems to be a big one. It's true, you can keep following that argument down and everyone has to pick a point at which they stop but I also think there are more blurred lines between each level. For instance I say my hobby is making games and I include the engine in that. It's not one or the other. Thank you for your response Rob!
This idea that "you can't make a game and an engine at the same time" and that the correct way to make a game is by using an engine is simply false. People have been making games before general purpose game engines were a thing. Will it take longer? Probably, but maybe you come up with a workflow that suits you better than any other engine and the time spent on making the engine is made up for. Even if it takes longer, that will only apply the first time you are making the engine features. You just don't want to do it and that's fine, but that's not the only way.
@@TheExtremeCube no-one is saying you can't. Building an engine is a task in of itself. You can absolutely build your own engine if that's the level of abstraction you want. Why not stop at engine? Why not build your language and own compiler down to machine code? Why not build your own instruction set. All your arguments count the same, choose the level of abstraction you want to build at. The loser you go, the longer it's takes and it won't necessarily be generic enough for other games. Also note: the majority of players won't care what the engine is. They just want to enjoy the game.
@@RobLang you yourself said "if you want to build an engine then your hobby is making an engine, if you want to make games use an existing engine". It's just not true, it's dissuading people unnecessarily . As for why stop at engine, well I'm not saying how anyone should be making games, but personally I think making your own engine lets you still focus on your game most of the time (vs making your own compiler and language which is completely irrelevant to any specific game), and gives you much finer control over how you want to make your game (ECS vs game objects vs inheritance), everything can be tailor made for you and your game.
@@TheExtremeCube and that's where I disagree. You don't need to make an engine to make a game. It's irrelevant to the act of actually making a game because the abstraction layer is much higher. Most games don't *need* to tailor every aspect of the engine to be fun. That's premature optimisation. In the same way that your engine would be tailored to you so much better if you built your own compiler. I had this same argument in the web back in the 90s. On Windows 95 there wasn't a default web server (before Apache, IIS was NT4, etc) so you had to buy one in or build your own: C++ listening on a port and then implement the whole flipping HTTP standard (well, most of it). If you wanted to run your own intranet web host, that's what you did. That's not making a web page out of HTML but the argument against buying one was that you'd understand so much more about the web doing so and tailor it etc etc etc. The user didn't care about the web host, or the cleanliness of the HTML, they just wanted to read what was on the page. It took a fair amount of time and effort to write all that C++, which didn't affect the web page at all. I do see where you're coming from and I accept some games really do need their own engine. However, if you're a new game dev sans you're watching UA-cam channels like this, you should be aiming for something simple. Get something completed. If you're a seasoned developer and you understand the scale of work required then choose the abstraction level that's right for you. For the new devs who want to make a game: choose an engine and build your game or all you'll be doing is building an engine.
Time and Understanding. If you don't have much time to make a game, then you want to end up with an already made Game Engine. If time does not matter, then you can start, how you want. As time in that Game Development progresses, you need to understand a lot of things. Graphics Rendering with OpenGL and GLFW is straightforward. Follow a few tutorials, code along (do not Copy-Paste because you won't understand them) and you'll get the basics. In case that you progress with 3D for example, then you need to understand more than just graphics. If you want something related to FPS Parkour Game, then you need to handle a lot of things, such as physics and much more. Levels can be a piece of cake, but the understanding of the concepts that you want to make can be hard with custom Engines. Unreal and Unity provide physics, which makes things easier. I don't know much about Physics, but I know that it is hard to understand. I ended up choosing to go with a custom Game Engine in Java (because I like cross-platform and Linux) anyway because time does not matter and I want my own game to be playable on any platform. And yes, I could have chosen C or C++, but since I don't own a MacBook, I guess that I have to go with Linux and Windows CXX Compilers.
Fanastic to hear about your java engine. There are definitely a lot of people feeling time pressure to deliver when they don't have a lot of dev time. Thanks for your response!
At the moment for me, time is a factor, but I just have projects I already want to make in motion plus I like switching between design, programing, music and art at differnt stages to learn. Building an engine for me will be when I want to move in to a more technical realm and a deep understanding of things and probably something I'll explore when I have more overall experince and some more time.
Too many project ideas seem to hit all creative people I know, but I really like how you do all the other elements of game dev. I can see why time is the biggest factor for you. Thanks for responding, mate!
I have had a game engine concept/idea (how it stores data, how to make games in it etc.) for almost 2 years where my engine would be written in Zig (a relatively new and fast programming language). The thing is: every time I decide to start working on it, I can't really find the best entry point to make my engine (renderer, game object system, modular engine structure etc.), so I've always been stuck on the beginning. After I watched your video, I realized I should start small (probably write the engine in Kotlin, use OpenGL instead of Vulkan) and then transfer my knowledge to the Zig codebase. This way I don't need to think about memory management and optimization and all the other stuff that distracts me, but I can focus on the actual engine a lot more. Thanks for your great video. It brought me a step closer to creating my game engine. :)
I feel like something that is easy to miss about using general purpose engines is that you don't need to use every tool that it gives you. One of the benefits of using an existing engine like Unity is that you can be more selective about what you want to focus on because of the core features that work out of box. You don't need to use Unity's physics system if you want to learn more about how to implement physics from scratch. You can make custom camera scripts instead of using Cinemachine. If you're more interested in how rendering works, there are ways to write shaders without using shader graph (although idk about bypassing the render pipelines). I made scripts for navigation/pathfinding using A* once in lieu of Unity's navigation. There are even ways to write custom editor tools if you're into that. Taken to the extreme, you could just take the game object/transform system, entity-component system, all of the convenient editor tools (hierarchy, inspector, scene/game view, etc.), and maybe the renderer, and write custom scripts for everything else. Handling all the editor tooling and file i/o for scenes from scratch, even if you're using something like ImGUI, is a pain (speaking from experience), so I can see why not everyone would want to invest that time. Making a game engine, you can choose which features you want to add by scoping games accordingly, but you can likewise choose to be selective and exclude features that you wish to use from an existing engine if your game requires something different. In essence, you're building out your own "subengine" within the more general purpose engine that is tailored to the games that you want to make.
The main thing that is stopping me is the lack of knowledge of making desktop apps with GUIs. I know how to make web apps using HTML/CSS/JS/NodeJS/p5.js and command line apps with Python, but thats it.
@@Skeffles Yes I've made loads of HTML (well, more JavaScript than anything) games, and have had to explore game engine specifics such as basic 3d rendering (of rectangular shapes) and some momentum and friction/slide physics. I haven't made any games in Python however, as I see it as more of a tool for messing with your PC than a tool for developing games. I've always wanted to make my own web based game engine, but I wouldn't know how to add features like compilation to an actual PC OS.
When I first started trying to make my own games I started making my own engine, partly because I didn't realize other options were available -- I made two drafts of an unoptimized 3D rendering engine that would be terrible for actual games. The I backed up and just made couple arcade style games, and a simple 2D engine almost by accident. Having said that, now I just want to get my games made, with most requiring 3D for the concept. At this point, I'd rather just save time by using Unity and Godot, especially for the for complex 3D ideas that actually do require a lot of things that would take a lot of time to develop and a lot of optimization to be practical.
I was clueless for a long time what good architecture is. But one day, I just saw an abstract view of an organism and lego blocks and it just clicked. The simple guidlene was just to make "reusable blocks of logic" and structuring it as an abstract organism: "organs talking to each other". By taking this simple guideline seriously, it made my code like 100x times better than the mess I was producing back then. Turns out, it can be sometimes pretty hard to get simple, but in no moment I am lost in the woods since I have a clear guide on what needs to be accomplished to make the code-architecture better. I can only recommend to seriously apply this guideline to any feature or class you create. Ask questions like "Is this class or approach really reusable, or is it bound to conditions?", "Are those conditions really necessary/irreduceable and cannot be reduced?" Working on these questions can be hard, but also interesting and insightful (you will be surprised how much fluff can be reduced and thrown away you previously thought was necessary), and the process will ultimately lead you to a better architecture that can truly scale. Hope this advice can help someone else, too! ;)
@@emperor8716 See, that's the thing. It doesn't perfectly match a paradigm. The only dogmatic elements I am thinking of are "reusable blocks" and "organs talking to each other". The rest automatically follows. So It does actually follow the core idea of OOP, but it is compatible with low-level blocks such as memory layout in ECS.
Making a game "engine" isn't that bad if you're focusing on making the engine under the game at hand instead of remaking Unity or Godot. For lots of games, it's surprisingly easy. You'll be surprised by how much of a game engine you don't actually use. (I use Godot mostly though lol)
Unity and Unreal add layers of abstraction which make them general purpose, that abstraction comes with its own cost in complexity. If your writing a simple game you can get far more done with less work with something like RayLib. I switched to RayLib recently and small 2D games are so much simpler to structure and understand.
The main pros I see for making your own engine are: 1. You own it and never have to pay an engine if your game takes off. 2. You have features that are tailored to developing your games. And 3. You learn more about how things are working at a lower level which will lead to better optimizations down the road. Personally, at a hobbyist level. I have a hard time seeing the time investment being worth it for these things when you can get the same three pros using Godot. It's open source which means you can add your own features to the engine and it will never cost you anything. I feel like you'd be better off with the pre-built Godot feature set, and then modifying the engine as needed rather than building your own engine.
Yes open source engines, such as godot, offer many of the same benefits as a custom engine. For many people it's the perfect solution, however they don't often take advantage of it. I don't know many people that have changed or even know where to start making changes to godot. For people using open source engines, I think having tried your own engine helps you with that.
Bevy bring the ambient occlusion and collisions and physics. Backface culling too, and you can use shape::box for that. You'll need to write your own mesher; a culled mesher to not draw any voxels not visible would be equivalent to a future feature of Bevy doing occlusion culling, and Bevy has automatic occlusion culling but only if you use the new geometry stuff that's not really good for voxels. Still, you may need greedy meshing, depending on what you're doing: I'm using greedy meshing to generate run length encoded data for storing chunks on disk, and using the RLE data to generate the binary meshing bitmap in many, many fewer operations, so the RLE data also became my in-memory format which saves a ton of RAM usage. Getting all of this from theoretical "we have data structures describing where voxels are" to practical "the voxels are drawn on screen and there are collisions" is bridged by using Bevy's drawing facilities, physics, lighting, input, etc.. Even if you did no culling and just used shape::box, Bevy does shape::box by instancing, which isn't the slowest thing in the world-it's ridiculously fast compared to any other approach you want to use that doesn't involve combining adjacent boxes into larger, complex meshes-but with a zillion objects in the buffer you might be making one draw call but the GPU still needs to draw a zillion objects. It could be playable even though the frame rate would be kind of low, but at the very least you probably need to use a culled mesher and accept the sub-optimal framerate and still stay above 144Hz VR.
@@johnmoser3594 Bevy is capable for voxel games. Yes. But... it is an engine that plugs directly into Rust as a crate. Which is different from how Godot and other GUI engines (not including Unreal) do things.
Here's one possibility to consider: retro system programming. Try making a DOS game and testing your builds in DOSBox. The software environment will be almost nonexistent, so you'll be calling the BIOS to set video modes and directly writing pixels to VRAM for graphics, bit-banging the PC Speaker for simple sound effects, and querying the keyboard controller for input. Would double as an opportunity to learn a bit of x86 assembly programming as well. And you know what they say about limitations breeding creativity? Plenty of limitations in the computing environment of the dawn of PC gaming to play into. You could do an entire game in text-mode, using coloured characters and their backgrounds as pseudo-graphics, like Apogee and Epic started out with (Kroz and ZZT respectively). You could try and make something out of CGA's limited palettes of red/green/yellow and magenta/cyan/white with a user-selectable background colour (Apogee made at least three such games). If that's too much of an artistic challenge, then take a shot at EGA's 16-colour mode (way too many games to count). For sound, the PC Speaker is one step above the most basic possible sound output device, with its monophonic square wave output, yet countless games made good use of it (with a few abusing its enable-disable register to control it in the simplest possible way for noisy sample playback). Fancy some music? Well, there's the widely-supported OPL2 FM synthesis chip found on the Adlib card to play with. It pairs well with PC Speaker sound effects. Just try playing Doom with Adlib for the music and PC Speaker for the sound effects, or Cosmo's Cosmic Adventure (another Apogee title). Oh, and if you decide you want to sell your DOS game, making it available for modern audiences is easy: just ship a pre-configured DOSBox installation, like many games on Steam and GOG already do.
C++ is one of the biggest reasons i haven't been trying to develop an Engine but oh my god I had no idea monogame was actually opengl but c# edition, thanks so much for the video skeffles, I'll start looking into it probably won't use it for a serious game but I'll definately give it a try
Im making a 3D "engine" from scratch for my simulation game. I put engine in quotation marks because its really more like the thinnest possible layer of tooling that I can write to make the game. I find it a ton of fun, and it is so insanely rewarding once you reach big milestones. The time misconception is a big one. Some people seem to think that if you make your own engine for a game that your game will take 10 years to finish. I mean I'm making a 3D engine from scratch (and that includes all the math so that I can understand and learn it better), and I anticipate that within 6 months from now I can pretty much block out my entire game and create all the core systems and scaffolding needed to make it. And because I have written every single internal API and line of code, I can work much faster in it than if I have to use a 3rd party engine and have to constantly refer to docs.
@@gameworkerty Pretty much on track :) I could start blocking out the game already to be honest, but Im finishing off the animation systems (at least the first revision), which strictly isn't essential for blocking out the game but nice to have to get a better feel for how the game feels. I went a bit ham on the rendering and spent more than I needed on that probably, but it was a ton of fun, and that is at a level in terms of fidelity where it should be enough pretty far into development.
I've made 2D and 3D game engines and I'm publicly trying to make another one. I couldn't agree more, with everything you said. Nothing will kill your game engine faster than trying to add complicated features you think you need before you have a real problem and you need to solve it. Don't just make something like an entity component system because it's the "correct" thing to do before you have a single entity in your game engine. Think before you type. (I'm talking to myself here too.)
My recommendation is usually something like, if you know how to program and you're mathematically inclined and have some spare time, then go for it, create your own engine. If you're not mathematically inclined, then you may still be capable of doing it depending on what level of complexity you're aiming for. If it's 2D then do it, it's simple enough that you don't need complex math to pull it off. If you want something 3D, then consider one of the numerous open source engines. Start simple with one of the Doom's or Quake's as they've been ported everywhere and are more than good enough for most games. If you're lazy or not at all mathematically or programmatically inclined, then Unreal, Unity and Godot are all quite capable, and Godot is one of those open source engines. You don't need any great skills to make a game, especially these days, so just go for it regardless of what you choose to do.
If you’re just making a simple game, it can be worth the time to make your own engine because you’re developing a codebase that is YOURS that you can reuse on ANY project. That’s very valuable to you and those that hire you. (Just make sure you protect rights to code you bring with you and don’t let those people try to take ownership of said code.
I've had a few concepts, mostly simulation & rpg mechanics, and some rendering, which I've wanted to play with for some time, but it probably take a lot longer for me to implement them in my own engine, rather than to use similar features of an existing engine, or implement them as addons, and time, right now, is my biggest constraint. I don't really have a lot of free time. I also have not done a whole lot of graphical work already, which would be an additional new paradigm to learn, on top of all of the engine stuff. Lastly, I think that I may not be so interested in making games, as I am in making tools, hence my interest in engine design, which has caused me to consider that I might want to start smaller, and just make an editor (of code, maps, graphics, etc.) for now, that could produce the resources used by another engine (possibly mine) in the future. If I develop tools that I like using, maybe I will be more likely to stick with whatever projects I work on in the future, since I won't be so consistently put off by slow, draconian vim and emacs.
The best way to develop an engine is make a BIG game from scratch and after the game is finished and polished then just extract the engine from it into it's own project and add the rest of the features
Weirdly enough, I never really made a real game, but I have created a game engine. It's a simple one that runs in the Windows cmd, I developed it using C# without any external libraries. It can't do much, but it can display colored images and move them around
@Skeffles I'm trying to re-write it from scratch using the stuff I learned while making it, hopefully I'll get it to run a bit better but I'm mostly making it as a proof of concept and I'm not actually intend on making a game with it as it is quite primitive (pixels are just characters with a background and foreground color attributes), has no support for sound and can only run on windows
Entirely depends on your goals. If your goal is learning about game dev and getting better at programming sure go for it. If your goal is creating a game within the fastest time possible, no. I've been programming for like 10 years and I consider myself to be pretty competent at it. I just can't picture myself benefitting from reinventing the wheel. Even if it's 1 year to create a full fledged engine comparable to Unreal or Godot, that 1 year with the same effort is enough to fully understand what it takes to create a game from scratch in those engines, even if you don't master it, and come up with lots of relatively complex prototypes or even finished work by then. With that 1 year of making an engine you develop a couple very small scale games at best, realistically speaking? Unless you genuinely enjoy coding and have a huge passion or you want to work on as an Game Engine Developer there is not much reason for it. I don't particularly enjoy coding for its own sake, I do it because it's a means to an end, either for a working product I have in mind or for money. And even if you failed at either making a game with your own custom engine or with an existing one, at least with something like Unreal or Godot, you get out with marketable tools for future jobs. Sure you get benefits like full ownership and control but from my perspective that is totally meaningless and prefer dealing with an engine's problems that might not even be that bad. I can't think of many successful examples of games that were custom written within a reasonable time by solo devs or by very small teams: Stardew Valley (4 years), Starsector (13+ years) and Dwarf Fortress (16 years). Stardew Valley is the only outlier and the creator ConcernedApe himself said it's not worth going the custom engine route unless it's strictly necessary.
It's certainly not for everyone but what makes you think you need a 'fully fledged engine'? My second point in the video was about building up each feature with small games. And why don't you think it's a marketable skill? Unless you're looking for something very specialised, I'd hire the engine dev.
Sorry if this is stupid to ask. Realistically, as someone who just started using godot a week ago (just got into gamedev), would i be able to make my game and its engine iness than a year? I have seen online that it usually takes a6 months to a year to make an engine... This really turned me away from that and i decided to use godot, which is really nice and intuitive. But I might switch to making my own engine if it turns out that its a beter option for thelong run. Apologies for bad english.
If you wan to go places you buy a car, if you want to enjoy the process of building, you build a car (I have a cousin that is a mechanic and he basically rebuild his first car just because he enjoyed). Making you own car might give you more understanding of how vehicles works, and you might have more control over how everything works in your vehicle, but at the end, it will do what vehicles do. Honestly building a game engine is more about enjoying the process , some people love it, but if you want just to make games then use an already made game engine, Don't get me wrong, that doesn't mean you don't enjoy the process of creating the game, on the contrary, using a game engine will help you enjoy the process of making the game even more as you can focus in that process instead of the process of making the game engine. Later on if you find yourself in a place where any of the game engines can't take you where you really want, then you can consider making your own. I personally just want to make games, and I need to be as productive as possible, so I chose an already made engine and went with it. That was the best decision for me, I enjoy the process of making the game, at the same time that I can finish the games in a productive way without reinventing the wheel. How long it will take you to create a game engine depends on several factors. For Example, you are new to gamedev, but how much you know about programming? how much time can you dedicate to it a day? how complex will it be? etc etc.
@@ARQUIVAS I am extremely grateful for your reply. That analogy was perfect and the statements and questions you posed really helped me out on what I wanted to do. Thank you.
That is a good analogy but I find it has a few flaws. If you want to go places you don't necessarily need a car. It can be much easier and quicker to use a small vehicle such as a skateboard, scooter or bike than buying and learning how to drive a car. Each of which are much easier to make. This all ties to the Time section of the video. You don't need feature parity with a pre established engine. You need just enough for your game to work. It all depends on the requirements for your game.
@@Skeffles "You need just enough for your game to work. It all depends on the requirements for your game." Exactly my point. I know you enjoy building your game engine and more things like this and that's awesome, but is not necessary unless you want to do it, or if none of the game engines will help you create the game you want, this will apply to any type of software. The analogy still applies, it's a lot easier to build a smaller mean of transportation like a bike than a car, of course, but is still easier to get an already made bike and ride, why would I want to make a bike instead of buying one? The same reason as we've been telling. Me and my friends used to make skateboards when we were kids out of wood planks and luggage wheels, but that was the fun, making them, trying them, falling 🤣🤣, how much fun. But with bikes, we just got bikes and the fun was in riding and going places.
ive always wanted to give it a go, but i feel like id be very overwhelmed with where to start or where to look for resources etc. i know most of the graphics pipeline theory, but i dont have the know how to do it in practice
Go for it! There are plenty of great tutorials for whatever pipelines or frameworks you prefer. Personally I use the monogame framework because it deals with a lot of rendering and platform specific code and I can really focus on the core logic.
@@Skeffles i have looked into monogame and tbh, it was one of my candidates. i do have a slight amount of c# knowledge, but studying monogame and c# together doesnt sound like too much of a hurdle to overcome
@@smuel2k I guess it depends how challenging you want to make it. I recommend getting an idea of how to make game systems with monogame and then transition away to that more challenging framework with the knowledge you gained.
Your first point doesn't make it any faster to develop an engine, it just spreads the time cost out. It also means you don't have a good engine, you have an engine that has stuff added continuously as you need new features for games, which leads to refactoring (more time) or a maintenance nightmare and lots of bugs (if you just kludge it all up to "save time"). You also skipped over 3D stuff. Ambient occlusion, backface culling, and a whole hell of a lot of rendering optimizations that involve a bunch of stuff done with shaders and compute are all going to take you forever to implement. 2D is pretty trivial. People wrote 2D games in a week with Commodore BASIC. You aren't going to get the most basic 3D features you get with Bevy-things like lighting, collisions, or rendering methods that allow your game to run at more than 3fps-unless you spend several months implementing all the 3D stuff in Bevy.
What if I want to make a game engine that's like Build engine? But able to use 3d models too. Like Quake/unreal or even classic wow style models, but I haves no coding knowledge. Where would be the best start for a complete newbie.
Game engines follow similar rules to games. Don't start with your dream engine. Start off small and work your way up. For you, I'd suggest 2 things to look into which both have quite a lot of tutorials if you google it. First, 3D rendering with a framework such as opengl or vulcan. Then look at how to load those model types. Second, a small game in a custom game engine to see what is involved. I suggest a framework like monogame. Then you can combine what you've learnt in each of these.
@@Skeffles Ok, thank you. Also I ordered some books on python and C++ to learn coding too. Just wasn’t sure which is the best place to start and what programs to get.
The same reason I leverage any pre-existing toolkit/framework/library/etc: it's just faster. If I had to write everything from scratch, I'd never get anything done. It's called standing on the shoulders of giants. If we threw re-use out the window, we'd all still be coding in machine code binary (no, not even assembly - that's reuse). Yeah, sometimes pre-existing codebases suck. It's only when they impede my progress enough that I think "I could do better" do I consider something else. And there's enough options out there, I always look for some other codebase. Necessity is the mother of invention, and I've just not found it necessary to write my own.
math is stopping me from creating a game Engine, I really like the idea of studying how game Engines like Unity operate and the process of building one (for educational purposes, not for actually making a Game), but I really dont want to learn the math behind it because it's so boring
Fantastic video, found it very interesting, at some point in my life I'd love to give it ago and try to make my own, I think currently I just have so many ideas for games and I at least want to get one released and then start thinking about making my own basic engine. I like what you said about keeping it basic and adding to it when you need a new feature I feel like some people would just overlook that but its important!
Thank you Saul! It is always tricky to work out when to do it, when you've got so many game ideas. Either way it'd be awesome to see EngineBySaul one day.
Nah, take the halfway point and use a framework. It handles all the boring under the hood stuff (game loop, rendering, input, etc), while you still have the write pure code instead of dragging and dropping stuff
I believe for the vast majority of game developers, this is bad advice. As a beginner, this will misguide game developers into thinking they have to do everything themselves, and instead of taking a week learning the basics of an existing engine, they'll spend a month reinventing the wheel and learning unrelated knowledge without getting any progress done on the game they want to make. And as an experienced developer, they can just tweak the engines they already know to work their way. A game engine is not only about its capabilities, its about its community. If you get stuck on an existing engine, there is a community you can rely on to help you get back on track. If you want to make a game engine, by all means do so, but if you want to make a game, just use an existing engine, the feature overhead is really not that big of a deal, and even if some features look useless now, they may become really handy in the future as you learn more about the engine.
Not necessarily, if your game has a feature that isn't really possible on your current engine then using a custom engine is probably better. Also skill set say if you dont know how to use any of the prebuilt engines out there, it may actually be faster to just use what you know. Or if you want to learn how to write a game engine for example, or just because you want to. All of the reasons are perfectly valid to developing your own engine.
@@Skeffles Basically I love it so much that I don't see myself touching to engine dev if it isn't to contribute to godot x) And i actually thought about it and tried to fix a bug but I'm still a C++ beginer It wasn't even by necessity, and being a solo dev I think I probably won't need to work at an engine level especially taking into account gdextension (usage of C++ without the need to compile the engine) But I understand the point and I agree, working on engines gives a deeper understanding and is a good thing to eventually do
most of us have written many multiple engines, dont asume we are all using unity. if you are over 30 then you probably were writing engines when half the unity kids were still in nappies.
Ok, if your passion is "making game engines" then do so. But, for the most part game devs should spend their limited time making games. Like, do you think a painter makes any kind of gain from making their own paint and paint brushes? Or a chief farming their own food? Or what if a UA-camr had to first invent a camera? Its meaningless unfortunately, because with limited time, one shouldn't reinvent the wheel unless doing so is necessary for a specific game concept unachievable otherwise. A unique camera for a special shot. A rare ingredient. Or some special paint or way to apply it. Spend the time making those to get the game you need. But lotd of people just...training themselves to make the same features that already exist elsewhere but optimized doesn't serve most peoples time. 1- Make a game engine if engines are your main passion 2- Make exactly what you need for the game you can't make otherwise. Those are the only reasons to do this as a game dev. Otherwise game devs should...dev games instead. The biggest reasons beyond time and skill that people shouldn't do this, is necessity. People do not need to do this 99% of the time. Rare edge cases like Dwarf Fortress or Noita, or some other game designed different...require this. But most every other game can just be made in existing tools. So why learn blacksmithing to make a lesser version of the same knife you can buy at the grocery store? Just to cut a tomato? There isn't a valid reason in almost every case. That's why they keep saying don't do it. If game engines are just your thing though, this is a good video introducing them.
If I want to become a chef, I will only learn about ingredients and recipes for the meals I want to make. I have no interest in agriculture, farming, harvesting.etc
The best chefs in the world do and it makes a big difference. They learn about the harvesting of ingredients, the culture of where the food originates, why food is prepared a certain way, etc.
Making a game engine is great as an experience, career and overall skill boost in the long run But if someone really just want to make great games, this is a bad way of going about it. Saying that you shouldnt compare to games made in other game engines is as stupid as Godot developers saying they dont compete with Unity or Unreal. Total bs lol There is no need for a custom game engine unless you really want to optimize or need a specific featureset, just like Scrap Mechanic or Noita.
Sure it won't take long to have a sprite that can jump and shoot but that's just like 10% of qctual game development. You still have to work on the actual content for your game. Not to mention non-engine related tasks such as marketing and managing your community. Making a game engine while making a game is simply not possible for many people especially if they wish to finish a game in a reasonable amount of time.
You're right. It's definitely not possible for everyone and there is so much more to making games. The amount of hats us solo devs have to wear is crazy.
what stop in my to make my own game engine 1. i don't really enjoy cording 2. my project have to big scope for example do you expect my to make 3D fps multiplayer game with out i game engine sory men that is not happening as solo developer that make all kind off things like 3D model, make image and texture make the levels dising and code thos system like player movement i don't thing i will able to do all thos big project's with out a game engine however one thing i have finger out one off thos day is if your game is to simple and like flappy bird clone it may be easier to make thos game with out i game engine i don't thing i will be difficult to do with using apis and your code off your choice i my C# and open gl if it small scale project like thos but if your game is to complex like the game im try to create now that is 3D have physics i wand to by multiplayer make my own shaders and split screen as optin i don't i game like this it able to replicate for my with out a game engine i personally don't have plan to make my own game engine hoever it may give a try make very sample project with out a game engine as experiment in the future for now i wand to finish the complex fps game im working after that i will see what to do
Making engine is a general solution while making a game is a specific solution. They require different mindsets and skill sets. Hence why some will like to make custom engine, while other will prefer using existing ones.
Honestly if you are advanced developer and know to make good games then you can consider it. But for beginners like me its really just a draw out of learning the gamedev. But if you begin to work lets say in a small indie studio, then yes it is serious thing. Just look at Far Cry using Cry Engine or EA FC with Frostbite. Sometimes its worth to create an engine for your game, because it fits the needs you have and you don't need to call Unreal support to see why it is doing this. Rather you ask your devs and they can alter it. So while I can agree, its really not for people starting or being fresh at gamedev. Rather for intermediates becoming more experienced.
This is viable for simple shitty 2d games, but if you want to make something more serious, good luck with that lol. lemme just make a duplicate of unreal lol. "you only need the features your game needs" so far i've used up to 15-20 systems that unreal has that have decades of development in them and hundreds of people working on them.
because i will spend years making a game engine, and get barely any result. then i should spend another few years actually making a game. i would rather get some actual results i can play, share, and live of, compared to a open source project, which only a few people know, and which cant be profitted off. ok, you can create your own linux from scratch, your own cpu from scratch, your own game engine from scratch, but it is really worth it? if you enjoy spending your time on this, you're welcome. i personally dont, i prefer getting useful results, which are indeed, worth my time.
-Why Don't You Make Your OWN Game Engine? -There's only two paths: make games or make engine -And third for extra rare guys who're really can make the engine and games
Everytime that i see people saying that you either make games or make engines i feel like those people never tried making one or never got out of the begginer stage. If you are starting from scratch and you're creating a AAA game, sure it might be too much work but if you're creating simple 2d games, an experiencied developer might get a simple engine running for this project in 2 months. The thing is: You're not going to be doing **everything** from scratch. You'll use open source projects like jolt for physics and collision. Dear IMGui to create a simple editor, BGFX for HAL, Yoga for a UI engine, etc. If you know which 3rd party libs to use and have some experience, most of the work will go towards the architecture side of things. Sure, complex 3d games will require more things and more complex things to get up and running, but it's just not the case for 99% of indies, even when you're doing 3D because your 3D games will be simple and won't require a fancy Forward+ rendering, multiple passes for complex post processing and PBR rendering, DLSS integration so on and so forth.
@@Skeffles I'm an 2d artist and have bad skills in programming but with Game Engine (Unity, Godot, Blitz Max, Tic-80) I can make my own games but I never learn How To Create a game engine (I need so much works and knowledge for it). I think people who're can make game engine are amazing!
The right mindset to develop your own engine is that you're not developing an ENGINE, you're developing a GAME. Your codebase grows every time you code, you have full control over it, you make the data available the way you like (for me this is the number 1 reason), you can fix something in the moment instead of waiting for someone else to do it. You can develop your own tools, such as a level editor, etc., of course, and that will benefit you, but it's not necessary from the start. You don't have to try to create a set of tools for everything. It's a gradual process until you realize what exactly do you need from the tools.
BTW if no one will try to develop an engine, who will maintain existing ones?
These are such good points. So many people are quick to say "Others will make my engine" but if everyone thought like that there would be no engines.
There's a guy in the corner of my room brandishing a lead pipe at me 24/7 and whenever I try to make a game engine he starts raising it, so I've decided it's not really worth the effort.
Sounds like John Riccitiello is having a crazy retirement lol
Time. If you're making a game engine then you're hobby is making a game engine. If you want to make a game then use an existing engine. Choose the level of abstraction you want to work at and do that.
Your argument would also work lower level. What's stopping you making your own language and compiler? Why use C/C++ when you can design your own language and compiler to assembler?
It's not that hard. You understand C and memory control but C has pointers. You can make a.memory safe version. You understand enough about memory management, it's no different in Assembler. So why not? You can always jump back to higher level languages. So why not? Time.
Time seems to be a big one.
It's true, you can keep following that argument down and everyone has to pick a point at which they stop but I also think there are more blurred lines between each level. For instance I say my hobby is making games and I include the engine in that. It's not one or the other.
Thank you for your response Rob!
This idea that "you can't make a game and an engine at the same time" and that the correct way to make a game is by using an engine is simply false. People have been making games before general purpose game engines were a thing. Will it take longer? Probably, but maybe you come up with a workflow that suits you better than any other engine and the time spent on making the engine is made up for. Even if it takes longer, that will only apply the first time you are making the engine features. You just don't want to do it and that's fine, but that's not the only way.
@@TheExtremeCube no-one is saying you can't. Building an engine is a task in of itself. You can absolutely build your own engine if that's the level of abstraction you want.
Why not stop at engine? Why not build your language and own compiler down to machine code? Why not build your own instruction set. All your arguments count the same, choose the level of abstraction you want to build at. The loser you go, the longer it's takes and it won't necessarily be generic enough for other games.
Also note: the majority of players won't care what the engine is. They just want to enjoy the game.
@@RobLang you yourself said "if you want to build an engine then your hobby is making an engine, if you want to make games use an existing engine". It's just not true, it's dissuading people unnecessarily . As for why stop at engine, well I'm not saying how anyone should be making games, but personally I think making your own engine lets you still focus on your game most of the time (vs making your own compiler and language which is completely irrelevant to any specific game), and gives you much finer control over how you want to make your game (ECS vs game objects vs inheritance), everything can be tailor made for you and your game.
@@TheExtremeCube and that's where I disagree. You don't need to make an engine to make a game. It's irrelevant to the act of actually making a game because the abstraction layer is much higher. Most games don't *need* to tailor every aspect of the engine to be fun. That's premature optimisation. In the same way that your engine would be tailored to you so much better if you built your own compiler.
I had this same argument in the web back in the 90s. On Windows 95 there wasn't a default web server (before Apache, IIS was NT4, etc) so you had to buy one in or build your own: C++ listening on a port and then implement the whole flipping HTTP standard (well, most of it). If you wanted to run your own intranet web host, that's what you did. That's not making a web page out of HTML but the argument against buying one was that you'd understand so much more about the web doing so and tailor it etc etc etc. The user didn't care about the web host, or the cleanliness of the HTML, they just wanted to read what was on the page. It took a fair amount of time and effort to write all that C++, which didn't affect the web page at all.
I do see where you're coming from and I accept some games really do need their own engine. However, if you're a new game dev sans you're watching UA-cam channels like this, you should be aiming for something simple. Get something completed. If you're a seasoned developer and you understand the scale of work required then choose the abstraction level that's right for you.
For the new devs who want to make a game: choose an engine and build your game or all you'll be doing is building an engine.
Time and Understanding. If you don't have much time to make a game, then you want to end up with an already made Game Engine. If time does not matter, then you can start, how you want.
As time in that Game Development progresses, you need to understand a lot of things. Graphics Rendering with OpenGL and GLFW is straightforward. Follow a few tutorials, code along (do not Copy-Paste because you won't understand them) and you'll get the basics. In case that you progress with 3D for example, then you need to understand more than just graphics. If you want something related to FPS Parkour Game, then you need to handle a lot of things, such as physics and much more. Levels can be a piece of cake, but the understanding of the concepts that you want to make can be hard with custom Engines. Unreal and Unity provide physics, which makes things easier. I don't know much about Physics, but I know that it is hard to understand.
I ended up choosing to go with a custom Game Engine in Java (because I like cross-platform and Linux) anyway because time does not matter and I want my own game to be playable on any platform. And yes, I could have chosen C or C++, but since I don't own a MacBook, I guess that I have to go with Linux and Windows CXX Compilers.
Fanastic to hear about your java engine.
There are definitely a lot of people feeling time pressure to deliver when they don't have a lot of dev time.
Thanks for your response!
because im an idiot
Relatable
Relatable
I was going to say the same.
Same here
Relatable
At the moment for me, time is a factor, but I just have projects I already want to make in motion plus I like switching between design, programing, music and art at differnt stages to learn. Building an engine for me will be when I want to move in to a more technical realm and a deep understanding of things and probably something I'll explore when I have more overall experince and some more time.
Too many project ideas seem to hit all creative people I know, but I really like how you do all the other elements of game dev. I can see why time is the biggest factor for you.
Thanks for responding, mate!
I have had a game engine concept/idea (how it stores data, how to make games in it etc.) for almost 2 years where my engine would be written in Zig (a relatively new and fast programming language). The thing is: every time I decide to start working on it, I can't really find the best entry point to make my engine (renderer, game object system, modular engine structure etc.), so I've always been stuck on the beginning.
After I watched your video, I realized I should start small (probably write the engine in Kotlin, use OpenGL instead of Vulkan) and then transfer my knowledge to the Zig codebase. This way I don't need to think about memory management and optimization and all the other stuff that distracts me, but I can focus on the actual engine a lot more.
Thanks for your great video. It brought me a step closer to creating my game engine. :)
Fantastic! Let me know when you have got something, even if it's just the most basic starting point.
Good luck random guy!
Start with the renderer, that way you can visualize all subsequent things
I feel like something that is easy to miss about using general purpose engines is that you don't need to use every tool that it gives you. One of the benefits of using an existing engine like Unity is that you can be more selective about what you want to focus on because of the core features that work out of box. You don't need to use Unity's physics system if you want to learn more about how to implement physics from scratch. You can make custom camera scripts instead of using Cinemachine. If you're more interested in how rendering works, there are ways to write shaders without using shader graph (although idk about bypassing the render pipelines). I made scripts for navigation/pathfinding using A* once in lieu of Unity's navigation. There are even ways to write custom editor tools if you're into that.
Taken to the extreme, you could just take the game object/transform system, entity-component system, all of the convenient editor tools (hierarchy, inspector, scene/game view, etc.), and maybe the renderer, and write custom scripts for everything else. Handling all the editor tooling and file i/o for scenes from scratch, even if you're using something like ImGUI, is a pain (speaking from experience), so I can see why not everyone would want to invest that time.
Making a game engine, you can choose which features you want to add by scoping games accordingly, but you can likewise choose to be selective and exclude features that you wish to use from an existing engine if your game requires something different. In essence, you're building out your own "subengine" within the more general purpose engine that is tailored to the games that you want to make.
The main thing that is stopping me is the lack of knowledge of making desktop apps with GUIs. I know how to make web apps using HTML/CSS/JS/NodeJS/p5.js and command line apps with Python, but thats it.
Have you ever considered making a game with HTML or PyGame. That'd have you exploring loads of game engine specifics.
@@Skeffles Yes I've made loads of HTML (well, more JavaScript than anything) games, and have had to explore game engine specifics such as basic 3d rendering (of rectangular shapes) and some momentum and friction/slide physics. I haven't made any games in Python however, as I see it as more of a tool for messing with your PC than a tool for developing games. I've always wanted to make my own web based game engine, but I wouldn't know how to add features like compilation to an actual PC OS.
It's pretty easy on python with PySide
When I first started trying to make my own games I started making my own engine, partly because I didn't realize other options were available -- I made two drafts of an unoptimized 3D rendering engine that would be terrible for actual games. The I backed up and just made couple arcade style games, and a simple 2D engine almost by accident. Having said that, now I just want to get my games made, with most requiring 3D for the concept. At this point, I'd rather just save time by using Unity and Godot, especially for the for complex 3D ideas that actually do require a lot of things that would take a lot of time to develop and a lot of optimization to be practical.
I was clueless for a long time what good architecture is. But one day, I just saw an abstract view of an organism and lego blocks and it just clicked. The simple guidlene was just to make "reusable blocks of logic" and structuring it as an abstract organism: "organs talking to each other". By taking this simple guideline seriously, it made my code like 100x times better than the mess I was producing back then. Turns out, it can be sometimes pretty hard to get simple, but in no moment I am lost in the woods since I have a clear guide on what needs to be accomplished to make the code-architecture better.
I can only recommend to seriously apply this guideline to any feature or class you create. Ask questions like "Is this class or approach really reusable, or is it bound to conditions?", "Are those conditions really necessary/irreduceable and cannot be reduced?" Working on these questions can be hard, but also interesting and insightful (you will be surprised how much fluff can be reduced and thrown away you previously thought was necessary), and the process will ultimately lead you to a better architecture that can truly scale. Hope this advice can help someone else, too! ;)
Basically you rediscovered the ECS architecture.
@@emperor8716 See, that's the thing. It doesn't perfectly match a paradigm. The only dogmatic elements I am thinking of are "reusable blocks" and "organs talking to each other". The rest automatically follows. So It does actually follow the core idea of OOP, but it is compatible with low-level blocks such as memory layout in ECS.
Making a game "engine" isn't that bad if you're focusing on making the engine under the game at hand instead of remaking Unity or Godot. For lots of games, it's surprisingly easy. You'll be surprised by how much of a game engine you don't actually use.
(I use Godot mostly though lol)
Unity and Unreal add layers of abstraction which make them general purpose, that abstraction comes with its own cost in complexity. If your writing a simple game you can get far more done with less work with something like RayLib. I switched to RayLib recently and small 2D games are so much simpler to structure and understand.
Try Bevy.
because I have to make my own programming language first, duh
The main pros I see for making your own engine are: 1. You own it and never have to pay an engine if your game takes off. 2. You have features that are tailored to developing your games. And 3. You learn more about how things are working at a lower level which will lead to better optimizations down the road.
Personally, at a hobbyist level. I have a hard time seeing the time investment being worth it for these things when you can get the same three pros using Godot. It's open source which means you can add your own features to the engine and it will never cost you anything. I feel like you'd be better off with the pre-built Godot feature set, and then modifying the engine as needed rather than building your own engine.
Yes open source engines, such as godot, offer many of the same benefits as a custom engine. For many people it's the perfect solution, however they don't often take advantage of it. I don't know many people that have changed or even know where to start making changes to godot. For people using open source engines, I think having tried your own engine helps you with that.
If you make a voxel game, you kinda need to make your own engine just so stuff runs at a playable speed.
Bevy bring the ambient occlusion and collisions and physics. Backface culling too, and you can use shape::box for that. You'll need to write your own mesher; a culled mesher to not draw any voxels not visible would be equivalent to a future feature of Bevy doing occlusion culling, and Bevy has automatic occlusion culling but only if you use the new geometry stuff that's not really good for voxels. Still, you may need greedy meshing, depending on what you're doing: I'm using greedy meshing to generate run length encoded data for storing chunks on disk, and using the RLE data to generate the binary meshing bitmap in many, many fewer operations, so the RLE data also became my in-memory format which saves a ton of RAM usage. Getting all of this from theoretical "we have data structures describing where voxels are" to practical "the voxels are drawn on screen and there are collisions" is bridged by using Bevy's drawing facilities, physics, lighting, input, etc..
Even if you did no culling and just used shape::box, Bevy does shape::box by instancing, which isn't the slowest thing in the world-it's ridiculously fast compared to any other approach you want to use that doesn't involve combining adjacent boxes into larger, complex meshes-but with a zillion objects in the buffer you might be making one draw call but the GPU still needs to draw a zillion objects. It could be playable even though the frame rate would be kind of low, but at the very least you probably need to use a culled mesher and accept the sub-optimal framerate and still stay above 144Hz VR.
@@johnmoser3594 Bevy is capable for voxel games. Yes. But... it is an engine that plugs directly into Rust as a crate. Which is different from how Godot and other GUI engines (not including Unreal) do things.
Thanks a lot. I'm just thinking and kinda lost on how to solve specific problems
Here's one possibility to consider: retro system programming. Try making a DOS game and testing your builds in DOSBox. The software environment will be almost nonexistent, so you'll be calling the BIOS to set video modes and directly writing pixels to VRAM for graphics, bit-banging the PC Speaker for simple sound effects, and querying the keyboard controller for input. Would double as an opportunity to learn a bit of x86 assembly programming as well.
And you know what they say about limitations breeding creativity? Plenty of limitations in the computing environment of the dawn of PC gaming to play into. You could do an entire game in text-mode, using coloured characters and their backgrounds as pseudo-graphics, like Apogee and Epic started out with (Kroz and ZZT respectively). You could try and make something out of CGA's limited palettes of red/green/yellow and magenta/cyan/white with a user-selectable background colour (Apogee made at least three such games). If that's too much of an artistic challenge, then take a shot at EGA's 16-colour mode (way too many games to count). For sound, the PC Speaker is one step above the most basic possible sound output device, with its monophonic square wave output, yet countless games made good use of it (with a few abusing its enable-disable register to control it in the simplest possible way for noisy sample playback). Fancy some music? Well, there's the widely-supported OPL2 FM synthesis chip found on the Adlib card to play with. It pairs well with PC Speaker sound effects. Just try playing Doom with Adlib for the music and PC Speaker for the sound effects, or Cosmo's Cosmic Adventure (another Apogee title).
Oh, and if you decide you want to sell your DOS game, making it available for modern audiences is easy: just ship a pre-configured DOSBox installation, like many games on Steam and GOG already do.
The start. I'd love to attempt it one day but where to start. What language what to do first. Just those first few steps I can't see.
Very interesting video. I agree with a lot of people saying "time". I'd prefer to spend my free time on making games, rather than making an engine!
Seems that no one has any time 😂
Thanks for the response Shelf!
C++ is one of the biggest reasons i haven't been trying to develop an Engine but oh my god I had no idea monogame was actually opengl but c# edition, thanks so much for the video skeffles, I'll start looking into it probably won't use it for a serious game but I'll definately give it a try
Im making a 3D "engine" from scratch for my simulation game. I put engine in quotation marks because its really more like the thinnest possible layer of tooling that I can write to make the game. I find it a ton of fun, and it is so insanely rewarding once you reach big milestones. The time misconception is a big one. Some people seem to think that if you make your own engine for a game that your game will take 10 years to finish. I mean I'm making a 3D engine from scratch (and that includes all the math so that I can understand and learn it better), and I anticipate that within 6 months from now I can pretty much block out my entire game and create all the core systems and scaffolding needed to make it. And because I have written every single internal API and line of code, I can work much faster in it than if I have to use a 3rd party engine and have to constantly refer to docs.
That's fantastic! I'm glad you're enjoying it.
I also find working with my own API easier than trying to understand others.
Hey man 1 month left in your estimate, was it on track or were you waaaay off?
@@gameworkerty Pretty much on track :) I could start blocking out the game already to be honest, but Im finishing off the animation systems (at least the first revision), which strictly isn't essential for blocking out the game but nice to have to get a better feel for how the game feels. I went a bit ham on the rendering and spent more than I needed on that probably, but it was a ton of fun, and that is at a level in terms of fidelity where it should be enough pretty far into development.
I've made 2D and 3D game engines and I'm publicly trying to make another one. I couldn't agree more, with everything you said. Nothing will kill your game engine faster than trying to add complicated features you think you need before you have a real problem and you need to solve it. Don't just make something like an entity component system because it's the "correct" thing to do before you have a single entity in your game engine. Think before you type. (I'm talking to myself here too.)
My recommendation is usually something like, if you know how to program and you're mathematically inclined and have some spare time, then go for it, create your own engine. If you're not mathematically inclined, then you may still be capable of doing it depending on what level of complexity you're aiming for. If it's 2D then do it, it's simple enough that you don't need complex math to pull it off. If you want something 3D, then consider one of the numerous open source engines. Start simple with one of the Doom's or Quake's as they've been ported everywhere and are more than good enough for most games. If you're lazy or not at all mathematically or programmatically inclined, then Unreal, Unity and Godot are all quite capable, and Godot is one of those open source engines. You don't need any great skills to make a game, especially these days, so just go for it regardless of what you choose to do.
If you’re just making a simple game, it can be worth the time to make your own engine because you’re developing a codebase that is YOURS that you can reuse on ANY project. That’s very valuable to you and those that hire you. (Just make sure you protect rights to code you bring with you and don’t let those people try to take ownership of said code.
I've had a few concepts, mostly simulation & rpg mechanics, and some rendering, which I've wanted to play with for some time, but it probably take a lot longer for me to implement them in my own engine, rather than to use similar features of an existing engine, or implement them as addons, and time, right now, is my biggest constraint. I don't really have a lot of free time. I also have not done a whole lot of graphical work already, which would be an additional new paradigm to learn, on top of all of the engine stuff. Lastly, I think that I may not be so interested in making games, as I am in making tools, hence my interest in engine design, which has caused me to consider that I might want to start smaller, and just make an editor (of code, maps, graphics, etc.) for now, that could produce the resources used by another engine (possibly mine) in the future. If I develop tools that I like using, maybe I will be more likely to stick with whatever projects I work on in the future, since I won't be so consistently put off by slow, draconian vim and emacs.
The best way to develop an engine is make a BIG game from scratch and after the game is finished and polished then just extract the engine from it into it's own project and add the rest of the features
Weirdly enough, I never really made a real game, but I have created a game engine. It's a simple one that runs in the Windows cmd, I developed it using C# without any external libraries. It can't do much, but it can display colored images and move them around
Sounds like a fantastic base to make a game. Do you have plans to develop it further?
@Skeffles I'm trying to re-write it from scratch using the stuff I learned while making it, hopefully I'll get it to run a bit better but I'm mostly making it as a proof of concept and I'm not actually intend on making a game with it as it is quite primitive (pixels are just characters with a background and foreground color attributes), has no support for sound and can only run on windows
@@DKaldes Sounds like a good approach. Let me know when you've made some progress on it!
Entirely depends on your goals. If your goal is learning about game dev and getting better at programming sure go for it. If your goal is creating a game within the fastest time possible, no.
I've been programming for like 10 years and I consider myself to be pretty competent at it. I just can't picture myself benefitting from reinventing the wheel.
Even if it's 1 year to create a full fledged engine comparable to Unreal or Godot, that 1 year with the same effort is enough to fully understand what it takes to create a game from scratch in those engines, even if you don't master it, and come up with lots of relatively complex prototypes or even finished work by then.
With that 1 year of making an engine you develop a couple very small scale games at best, realistically speaking?
Unless you genuinely enjoy coding and have a huge passion or you want to work on as an Game Engine Developer there is not much reason for it. I don't particularly enjoy coding for its own sake, I do it because it's a means to an end, either for a working product I have in mind or for money.
And even if you failed at either making a game with your own custom engine or with an existing one, at least with something like Unreal or Godot, you get out with marketable tools for future jobs.
Sure you get benefits like full ownership and control but from my perspective that is totally meaningless and prefer dealing with an engine's problems that might not even be that bad.
I can't think of many successful examples of games that were custom written within a reasonable time by solo devs or by very small teams: Stardew Valley (4 years), Starsector (13+ years) and Dwarf Fortress (16 years). Stardew Valley is the only outlier and the creator ConcernedApe himself said it's not worth going the custom engine route unless it's strictly necessary.
It's certainly not for everyone but what makes you think you need a 'fully fledged engine'? My second point in the video was about building up each feature with small games.
And why don't you think it's a marketable skill? Unless you're looking for something very specialised, I'd hire the engine dev.
Sorry if this is stupid to ask. Realistically, as someone who just started using godot a week ago (just got into gamedev), would i be able to make my game and its engine iness than a year? I have seen online that it usually takes a6 months to a year to make an engine... This really turned me away from that and i decided to use godot, which is really nice and intuitive. But I might switch to making my own engine if it turns out that its a beter option for thelong run.
Apologies for bad english.
If you wan to go places you buy a car, if you want to enjoy the process of building, you build a car (I have a cousin that is a mechanic and he basically rebuild his first car just because he enjoyed).
Making you own car might give you more understanding of how vehicles works, and you might have more control over how everything works in your vehicle, but at the end, it will do what vehicles do. Honestly building a game engine is more about enjoying the process , some people love it, but if you want just to make games then use an already made game engine, Don't get me wrong, that doesn't mean you don't enjoy the process of creating the game, on the contrary, using a game engine will help you enjoy the process of making the game even more as you can focus in that process instead of the process of making the game engine. Later on if you find yourself in a place where any of the game engines can't take you where you really want, then you can consider making your own. I personally just want to make games, and I need to be as productive as possible, so I chose an already made engine and went with it. That was the best decision for me, I enjoy the process of making the game, at the same time that I can finish the games in a productive way without reinventing the wheel.
How long it will take you to create a game engine depends on several factors. For Example, you are new to gamedev, but how much you know about programming? how much time can you dedicate to it a day? how complex will it be? etc etc.
@@ARQUIVAS I am extremely grateful for your reply. That analogy was perfect and the statements and questions you posed really helped me out on what I wanted to do. Thank you.
@@TutiFruti-ky3bj glad it helped you!
That is a good analogy but I find it has a few flaws. If you want to go places you don't necessarily need a car. It can be much easier and quicker to use a small vehicle such as a skateboard, scooter or bike than buying and learning how to drive a car. Each of which are much easier to make.
This all ties to the Time section of the video. You don't need feature parity with a pre established engine. You need just enough for your game to work. It all depends on the requirements for your game.
@@Skeffles "You need just enough for your game to work. It all depends on the requirements for your game." Exactly my point. I know you enjoy building your game engine and more things like this and that's awesome, but is not necessary unless you want to do it, or if none of the game engines will help you create the game you want, this will apply to any type of software.
The analogy still applies, it's a lot easier to build a smaller mean of transportation like a bike than a car, of course, but is still easier to get an already made bike and ride, why would I want to make a bike instead of buying one? The same reason as we've been telling.
Me and my friends used to make skateboards when we were kids out of wood planks and luggage wheels, but that was the fun, making them, trying them, falling 🤣🤣, how much fun. But with bikes, we just got bikes and the fun was in riding and going places.
im still in the process of learning c++ i am yet to make a game engine
Why i would make a game engine bc :I want full control over it no fees no paid plans and ease of use and i will know what my game engine is capable of
ive always wanted to give it a go, but i feel like id be very overwhelmed with where to start or where to look for resources etc. i know most of the graphics pipeline theory, but i dont have the know how to do it in practice
Go for it! There are plenty of great tutorials for whatever pipelines or frameworks you prefer.
Personally I use the monogame framework because it deals with a lot of rendering and platform specific code and I can really focus on the core logic.
@@Skeffles i have looked into monogame and tbh, it was one of my candidates. i do have a slight amount of c# knowledge, but studying monogame and c# together doesnt sound like too much of a hurdle to overcome
@@smuel2k I guess it depends how challenging you want to make it. I recommend getting an idea of how to make game systems with monogame and then transition away to that more challenging framework with the knowledge you gained.
Your first point doesn't make it any faster to develop an engine, it just spreads the time cost out. It also means you don't have a good engine, you have an engine that has stuff added continuously as you need new features for games, which leads to refactoring (more time) or a maintenance nightmare and lots of bugs (if you just kludge it all up to "save time"). You also skipped over 3D stuff. Ambient occlusion, backface culling, and a whole hell of a lot of rendering optimizations that involve a bunch of stuff done with shaders and compute are all going to take you forever to implement.
2D is pretty trivial. People wrote 2D games in a week with Commodore BASIC. You aren't going to get the most basic 3D features you get with Bevy-things like lighting, collisions, or rendering methods that allow your game to run at more than 3fps-unless you spend several months implementing all the 3D stuff in Bevy.
I did. It's called Brux GDK, and it's free and open source. ;3
What if I do both
What if I want to make a game engine that's like Build engine? But able to use 3d models too. Like Quake/unreal or even classic wow style models, but I haves no coding knowledge. Where would be the best start for a complete newbie.
Game engines follow similar rules to games. Don't start with your dream engine. Start off small and work your way up.
For you, I'd suggest 2 things to look into which both have quite a lot of tutorials if you google it.
First, 3D rendering with a framework such as opengl or vulcan. Then look at how to load those model types.
Second, a small game in a custom game engine to see what is involved. I suggest a framework like monogame.
Then you can combine what you've learnt in each of these.
@@Skeffles Ok, thank you. Also I ordered some books on python and C++ to learn coding too. Just wasn’t sure which is the best place to start and what programs to get.
@@orca1361 Those books sound great. Python and C++ were the first languages I learnt at uni. Definitely go with python first if you're new to code.
@@Skeffles I was wondering which one to learn first and how hard is it to self taught coding
@@orca1361 Don't forget if you get stuck there are loads of great blogs and videos explaining everything too.
The same reason I leverage any pre-existing toolkit/framework/library/etc: it's just faster. If I had to write everything from scratch, I'd never get anything done. It's called standing on the shoulders of giants. If we threw re-use out the window, we'd all still be coding in machine code binary (no, not even assembly - that's reuse).
Yeah, sometimes pre-existing codebases suck. It's only when they impede my progress enough that I think "I could do better" do I consider something else. And there's enough options out there, I always look for some other codebase. Necessity is the mother of invention, and I've just not found it necessary to write my own.
math is stopping me from creating a game Engine, I really like the idea of studying how game Engines like Unity operate and the process of building one (for educational purposes, not for actually making a Game), but I really dont want to learn the math behind it because it's so boring
What level of maths are you expecting a game engine to need? I don't think it needs anything more than a regular game.
@@Skeffles the low level math related to computer graphics
You don't need advanced math to create game engines. School math is sufficient. John Carmack is the proof.
i made a game engine for fun i enjoyed it and that's all that matters to me
just like when you are doing gamedev for a hobby
Brilliant to hear about your engine!
Fantastic video, found it very interesting, at some point in my life I'd love to give it ago and try to make my own, I think currently I just have so many ideas for games and I at least want to get one released and then start thinking about making my own basic engine. I like what you said about keeping it basic and adding to it when you need a new feature I feel like some people would just overlook that but its important!
Thank you Saul! It is always tricky to work out when to do it, when you've got so many game ideas.
Either way it'd be awesome to see EngineBySaul one day.
@@Skeffles maybe one day 👀
you just gained a new subscriber❤ . Although I just started learning to code, I'm hopeful to become a great software engineer
Thank you. I wish you well with your coding adventures! Remember, software about finding solutions to problems, not necessarily about writing code.
Nah, take the halfway point and use a framework. It handles all the boring under the hood stuff (game loop, rendering, input, etc), while you still have the write pure code instead of dragging and dropping stuff
Because the programming aspect of game dev is the least fun, and I already get more of it than I want while using an engine.
I believe for the vast majority of game developers, this is bad advice.
As a beginner, this will misguide game developers into thinking they have to do everything themselves, and instead of taking a week learning the basics of an existing engine, they'll spend a month reinventing the wheel and learning unrelated knowledge without getting any progress done on the game they want to make.
And as an experienced developer, they can just tweak the engines they already know to work their way.
A game engine is not only about its capabilities, its about its community. If you get stuck on an existing engine, there is a community you can rely on to help you get back on track.
If you want to make a game engine, by all means do so, but if you want to make a game, just use an existing engine, the feature overhead is really not that big of a deal, and even if some features look useless now, they may become really handy in the future as you learn more about the engine.
Not necessarily, if your game has a feature that isn't really possible on your current engine then using a custom engine is probably better. Also skill set say if you dont know how to use any of the prebuilt engines out there, it may actually be faster to just use what you know. Or if you want to learn how to write a game engine for example, or just because you want to. All of the reasons are perfectly valid to developing your own engine.
i just suck at coding man
Keep coding and you'll become super at it!
Not even Godot that has hundreds of developers could make a proper 3D physics engine, what makes you think you can do it alone?
When you write games for 8bit computers, you usually HAVE to make your own game engine 😀
If you make own engine it would be harder to hire people to work with
Godot is stopping me
What is it about Godot that stops you?
@@Skeffles Basically I love it so much that I don't see myself touching to engine dev if it isn't to contribute to godot x) And i actually thought about it and tried to fix a bug but I'm still a C++ beginer
It wasn't even by necessity, and being a solo dev I think I probably won't need to work at an engine level especially taking into account gdextension (usage of C++ without the need to compile the engine)
But I understand the point and I agree, working on engines gives a deeper understanding and is a good thing to eventually do
@@Skeffles + Godot is perfect
actually though
@question_mark Godot does a lot right. I'm glad you're enjoying it!
most of us have written many multiple engines, dont asume we are all using unity. if you are over 30 then you probably were writing engines when half the unity kids were still in nappies.
Ok, if your passion is "making game engines" then do so.
But, for the most part game devs should spend their limited time making games.
Like, do you think a painter makes any kind of gain from making their own paint and paint brushes? Or a chief farming their own food? Or what if a UA-camr had to first invent a camera?
Its meaningless unfortunately, because with limited time, one shouldn't reinvent the wheel unless doing so is necessary for a specific game concept unachievable otherwise. A unique camera for a special shot. A rare ingredient. Or some special paint or way to apply it.
Spend the time making those to get the game you need. But lotd of people just...training themselves to make the same features that already exist elsewhere but optimized doesn't serve most peoples time.
1- Make a game engine if engines are your main passion
2- Make exactly what you need for the game you can't make otherwise.
Those are the only reasons to do this as a game dev. Otherwise game devs should...dev games instead.
The biggest reasons beyond time and skill that people shouldn't do this, is necessity. People do not need to do this 99% of the time. Rare edge cases like Dwarf Fortress or Noita, or some other game designed different...require this. But most every other game can just be made in existing tools. So why learn blacksmithing to make a lesser version of the same knife you can buy at the grocery store? Just to cut a tomato?
There isn't a valid reason in almost every case. That's why they keep saying don't do it.
If game engines are just your thing though, this is a good video introducing them.
If I want to become a chef, I will only learn about ingredients and recipes for the meals I want to make.
I have no interest in agriculture, farming, harvesting.etc
The best chefs in the world do and it makes a big difference. They learn about the harvesting of ingredients, the culture of where the food originates, why food is prepared a certain way, etc.
Making a game engine is great as an experience, career and overall skill boost in the long run
But if someone really just want to make great games, this is a bad way of going about it.
Saying that you shouldnt compare to games made in other game engines is as stupid as Godot developers saying they dont compete with Unity or Unreal. Total bs lol
There is no need for a custom game engine unless you really want to optimize or need a specific featureset, just like Scrap Mechanic or Noita.
Sure it won't take long to have a sprite that can jump and shoot but that's just like 10% of qctual game development. You still have to work on the actual content for your game. Not to mention non-engine related tasks such as marketing and managing your community.
Making a game engine while making a game is simply not possible for many people especially if they wish to finish a game in a reasonable amount of time.
You're right. It's definitely not possible for everyone and there is so much more to making games. The amount of hats us solo devs have to wear is crazy.
Godot can be recompiled and it’s light
That's a reason you like Godot, not a reason to avoid making your engine 😂
Because I don't know how to code
what stop in my to make my own game engine
1. i don't really enjoy cording
2. my project have to big scope for example do you expect my to make 3D fps multiplayer
game with out i game engine sory men that is not happening
as solo developer that make all kind off things like 3D model, make image and texture make the levels dising and code thos system like player movement i don't thing i will able to do all thos big project's with out a game engine
however one thing i have finger out one off thos day is if your game is to simple and like flappy bird clone it may be easier to make thos game with out i game engine
i don't thing i will be difficult to do with using apis and your code off your choice i my C# and open gl if it small scale project like thos
but if your game is to complex like the game im try to create now that is 3D have physics i wand to by multiplayer make my own shaders and split screen as optin i don't i game like this it able to replicate for my with out a game engine
i personally don't have plan to make my own game engine hoever it may give a try make very sample project with out a game engine as experiment in the future
for now i wand to finish the complex fps game im working after that i will see what to do
True, I wouldn't suggest mixing engine dev with a complex game like that.
Good luck with your game!
Bro talkin like we be creating a game engine in the next minute 😂
Go for it!
I wanna make games, not game engines. And I don't need to reinvent the wheel to create my game.
If everyone thought like that then there would be no engine for you to use.
Making engine is a general solution while making a game is a specific solution. They require different mindsets and skill sets. Hence why some will like to make custom engine, while other will prefer using existing ones.
Because I'm using potato laptop, I don't have money to buy high specs computer.
Because im fuucking stupid and lazy
Honestly if you are advanced developer and know to make good games then you can consider it. But for beginners like me its really just a draw out of learning the gamedev. But if you begin to work lets say in a small indie studio, then yes it is serious thing. Just look at Far Cry using Cry Engine or EA FC with Frostbite. Sometimes its worth to create an engine for your game, because it fits the needs you have and you don't need to call Unreal support to see why it is doing this. Rather you ask your devs and they can alter it. So while I can agree, its really not for people starting or being fresh at gamedev. Rather for intermediates becoming more experienced.
This is viable for simple shitty 2d games, but if you want to make something more serious, good luck with that lol. lemme just make a duplicate of unreal lol. "you only need the features your game needs" so far i've used up to 15-20 systems that unreal has that have decades of development in them and hundreds of people working on them.
It is really hard. Only do so if you have special needs. It is better to make plugins to existing engine.
Thanks for watching. I'd argue having a basic understanding on engines helps for making those plugins, but if you can it without then great!
because i will spend years making a game engine, and get barely any result. then i should spend another few years actually making a game.
i would rather get some actual results i can play, share, and live of, compared to a open source project, which only a few people know, and which cant be profitted off.
ok, you can create your own linux from scratch, your own cpu from scratch, your own game engine from scratch, but it is really worth it?
if you enjoy spending your time on this, you're welcome.
i personally dont, i prefer getting useful results, which are indeed, worth my time.
-Why Don't You Make Your OWN Game Engine?
-There's only two paths: make games or make engine
-And third for extra rare guys who're really can make the engine and games
I disagree that there are only two paths. That's a very limited mindset.
Everytime that i see people saying that you either make games or make engines i feel like those people never tried making one or never got out of the begginer stage. If you are starting from scratch and you're creating a AAA game, sure it might be too much work but if you're creating simple 2d games, an experiencied developer might get a simple engine running for this project in 2 months.
The thing is: You're not going to be doing **everything** from scratch. You'll use open source projects like jolt for physics and collision. Dear IMGui to create a simple editor, BGFX for HAL, Yoga for a UI engine, etc. If you know which 3rd party libs to use and have some experience, most of the work will go towards the architecture side of things. Sure, complex 3d games will require more things and more complex things to get up and running, but it's just not the case for 99% of indies, even when you're doing 3D because your 3D games will be simple and won't require a fancy Forward+ rendering, multiple passes for complex post processing and PBR rendering, DLSS integration so on and so forth.
@@Skeffles I'm an 2d artist and have bad skills in programming but with Game Engine (Unity, Godot, Blitz Max, Tic-80) I can make my own games but I never learn How To Create a game engine (I need so much works and knowledge for it).
I think people who're can make game engine are amazing!
My 3D dream gane is well supported in current engines.
How did you assess this?
Most engines have a feature list and documentation@@Skeffles
I ain’t doing allat
what a waste of bandwith
“Why don’t you make a game engine” that’s your mistake, I’ve already done that AND USED IT HAHAHA
Common sense
Thanks for the response. Maybe I just lack that 🤔