"Make a Game not an Engine" (Just use Unity/Unreal/Godot bro) 

100% agreed. Don't make an engine that can do everything with no aim in mind. That's a good way to get lost working on an engine for 10 years but you've never made a game with it.

I can get behind that too. The problem I saw with the "make your own engine" advice was when people said your game is better off with a custom engine. Truth is that most people just want to make games and the big 3 are much better at teaching you how to make games than making custom engines. But if you wanna get good at programming specifically, making an engine will definitely teach you a lot. It's about having the right goals.

When I first researched how to start programming games from scratch, I stumbled on that advice to build a game, not an engine. And I'm glad I did because it has saved me a lot of headaches, I'm sure. That advice fits nicely with other tidbits I have picked up from others -- "program the most simple thing possible to solve the problem that you have."

I'm glad to see another channel that advocates for the creation of a custom engine instead of using a pre-made game engine! 2 days ago, I saw a video called "Why I don't use game engines", and now I found your channel. I really support the idea of making your own game engine, in fact I'm making one right now, I have uploaded some devlogs to my youtube channel if you are interested to know about it. Great video.

I have an interesting anecdote related to this: This happened more than 10 years ago at a gamed forum from my local community. A guy was talking about the engine we was building and we were all like "bro, don't waste time creating an engine, just focus on your game, there are many good engines and frameworks out there". This was before Unity was popular but still, there were a couple of good options already. However he replied that his engine had a different approach and was gonna be better that what was out there. Of course we were a bit skeptical. A random guy from some country far away from where the big money is, doing something that could compete with Microsoft XNA and the like? Turns out the engine that guy was working on was what now is known as Godot Engine. In conclusion, if no one made their games from scratch anymore at some point we'd no longer have anyone capable of pushing the boundaries. Nowadays you have anything from "[Genre] Maker" to different open source libraries so you can pick exactly which engineering problems you want to tackle and which want you want to delegate, whether temporarily or permanently. It's also important to understand what you want to achieve. If you just want to create a visual novel and only care about narrative and visual then RenPy works just fine. If you want to learn more about programming and build something tailored to your needs knowing it will take longer then that's perfectly fine. The problem is when people think that building the game from scratch will be easier and faster than dealing with an engine, cause it's almost never the case.

It's so refreshing to hear this. I'm quite bored hearing the bad takes that many devs repeat because a "how to start game dev" video told them.

Thank you for shedding light on this. I actually started making a "game engine" in May I think and I was just doing it because I wanted to but it was kind of an impulse so it turned out a couple weeks later I didn't want to. I put myself in this situation where I built this thing for no reason other than not quitting a project and RU-vid series (took it off my channel thank goodness) and it was really depressing. After that, I started a game project from scratch again with Handmade values except this time I had a clear goal and I've not only stuck with this project but I'm making so much progress because I have clear goals. It's not about what you're making so long as you want to. A lot of people make these huge projects and they get criticized for "recreating the wheel" which is totally stupid because the tools and games of tomorrow are being built by people who are passionate about making good software no matter what that looks like which is a noble cause

Thanks for the wonderful video again :) I often think that people overestimate the work that is needed to get to fundamentals of a game ready, which would be the engine. Especially in 2D it's not too much work. Once I wrote a small 2D engine for a game jam within a week. I could load 2D images, I had audio, keyboard and mouse input, collisions and even a 2D animation system. That's definitely not out of scope for a game. 3D is a bit more involved but depending on what you want to have it's still not too much work, especially if you can reuse your code for projects.

good point that needs to be brought up more. I absolutely hate people that tell you to "just use Unity/Godot/Unreal/raylib/CryEngine/[whatever the next hip thing is]" dropping unity and godot in favour of my own solution for the game I'm creating has brought me way more satisfaction than I initially expected, especially since it let me familiarise with topics of how the game actually works under the hood more in-depth than any common resource on making games out there; meanwhile looking at unity and godot docs all I got was sheer confusion since they were way more abstract than necessary in my case

All purpose = No Use. If you make an engine... Stick to making an engine FOR a specific game, not for EVERY and ANY game. Or, you'll never make anything but an engine, and chances are slim it would compete with the big 3 right now anyway. This was REALLY helpful advice. I have exactly 1 game in mind, but I don't think it's possible in any existing engine. But this advice helped me see if I do need a custom engine...this is how I should build it. Program for a purpose, don't hyper focus on repurposing your program. Unless of course high reusability WAS the goal.

Amen a "game engine" should be a byproduct of your game and not the other way around. There's so many small game engine floating around, completely abandoned. I'm currently working on a game made with Zig and Vulkan and all the engine work I do is just to support my game. In the of it all, I'll have something that I can show to people and if I want to make a similar / sequel to it, I'll just reuse the "engine" of the game.

It's sad that corporations have convinced everyone that they are not capable of making a game, without their specific software. Many of those commercial game engines have tons of bloat that's not necessary for most games. Commercial game engines are convenient; up until that company decides to screw you over; trying to please their investors.

I have a high respect for programmers that are able to build stuff from scratch, I mean it takes quite a lot of work , the rendering , the game logic , the physics alone, implementing algorithm, this way you become for what I believe a true programmer, programmers nowadays are just users, function calls all over the place in my opinion. so if you are making your own game engine for your game I respect that.

imho it doesn't matter if you work on an engine or game - anything that gives you practice is good - the worst you can do is not work on anything at all the real problem is the social pressure - it gives you the impression there is a right way to do things - the truth is there are no perfect solutions, no perfect engine or language, no perfect code or method - there is always a tradeoff

must be all the pygame tutorials I watch, the aglo recommending this to me to keep my spirit up when I have no idea what I'm doing most the time

It wouldn't bother me even if someone decided to make an engine to compete with the big ones. I dislike the disapproval whenever someone wants to do his own thing, like "Bro, are you gonna do that monolith that 50 programmers with years of experience did?". But usually, building your own thing means something more simple than that. If you can rotate a 3d cube on the screen, it's a start. Then add a player camera, move around. Very basic C++/OpenGL or whatever is your toolset, for a basic game you don't need to build a big monolith. Especially for 2D, it's so easy to render sprites and backgrounds, even if you did in pure software rendering in SDL. Then you have a background and a sprite you move with keys. Then maybe you can add collision and describe your level with blocks in a text editor :) Which aligns with your point, that whan someone focuses on building the game rather than the engine, they end up building a very minimal basic engine for the game that is not as scary as when people discourage you from doing so.

Considering making an engine just for your needs: let's say you are making a 3D game. Now you have to blend a character animation between walking and shooting. Now you have to write a whole Animation State Machine and Animation Blending and Animation Blend Tree Spaces, and probably spend weeks on that while all ready-to-use engines have that out of the box. Meanwhile, as indie, alone, you could have made a decent amount of progress IN THE ACTUAL game instead of re-inventing the wheel. Want to add hand IK aiming? Hell, you now have to add support to bone IKs. Good luck - (BUT, at the same time, ozz-animation handles all of that and is engine agnostic, so then you have to integrate it). There's one famous gamedev RU-vidr which I don't remember the name that was making his engine with C++ and live coding it, and then he spent, what, 2 months making animation blending and it was crap in the end? (and he is a C++ beast!).

I tried to make my game with Unity, and tbh the architecture that it imposes on your project is so dumb imo, for an example, for some reason your UI is bound to a gameobject in 3D space, same goes for any other "manager" object. Communication between scripts is only possible by exposing data to all other scripts in the scene and feels hacky af. So I just decided to try learning opengl and see what I can make myself.

I've always felt the same way. Some games I want to make down the line are pretty scopey and make use of just about every technique they used in old SNES games, maybe a couple from PS1 era like Castlevania: SotN, but they all share a pixelart style with more sprite- and palette- focused special effects. Even GameMaker is too bloated and slow for what I want to do. We are making very different performance-usability trade-ins so in that sense my hand is kind of forced

3:09 oh yeah it's "all you need", except that you can spend pretty much an infinite amount of time on any one of those things if you want to get them on a level anywhere close to being marketable. looking at the Hollow Knight example analytically, there's a ton of particle and lighting effects stacked on top of each other. if you were to develop all of those systems from scratch it would take months if not years and at the end it would still look worse. making your own game engine is great for learning (spent a decade building engines in JS, C, and Nim myself), but just don't expect anything marketable will come out of it.

your explanation of a game engine made me clap my hands

I'm in a very strange camp here, I love making engines. I love solving problems efficiently and building abstract types from scratch. But I have never finished a game, there is something about the process of game design that drags me down, and every time I'm finished with the engine and starting work on the design I stop. So for me, I make engines not games.

great take Dylan 🥞

would you think the unreal engine would be good for first person non-shooting but more like medieval style combat games ?

I think this is mainly a problem of how programming is taught in school now. The only method of programming that is ever shown to students is object-oriented programming. They are told and/or implied that you have to have an object for every possible scenario and instance. That is far from the truth. You only need to have what you actually NEED (hence the use of "need to have"). Really, to do this effectively, you need to use a combination of object-oriented programming and iterative programming skills, the ladder of which is never really taught to students (especially when they are forced to use Java for most of their schooling (which punishes excessive use of iterative programming), and are not able to use better programming languages for learning to include the bare minimum & make it work well (ex. C-like and Python)).

Cool! I'd be keen to hear about your experience with Zig for building a game

ok but let's at least agree that Godot is the fairest of them all, went on a ride with her, still can't forget that night, 10/10

I’m Choosing “D” No Matter What

My problems with making your own engine or from scratch are plenty. 1: I can't find good tutorials on how to implement a library for ECS into anything. 2: I want to make 3D games, and I want to work towards bigger environments and games. So a custom engine would most likely not satisfy my needs. 3: The tools in an engine are too many for most, but you'll still find those few gems that either speed up the process or adds something you love. 4: Time. Unity has a graphical animation state machine, visual shader graph, visual particle system. Meaning you do code with visual means that easy things. 5: Stream lined. In Unity I can save my blender project in a folder in my project and it will handle most things. A little work and I got a model, material with normals and textures, animation armarture and animations. I would have to learn to understand Blender's blend files and pick them apart to be able to implement them into my engine. That's a lot of work just to get a necessity to simply work. 6: System. I can drag and drop, select and unpack, pack up, import and export in Unreal, Godot and Unity. All of these things are stuff I'd have to make myself. 7: Every function and feature I take for granted would have to be recreated every time I encounter I'm missing it. 8: Performance. Many engines are optimized like Unreal's c++ programming and nanite, Unity's new ECS and DoT system and Stride's core design for C# along with multi thread support. Even if I coded in c++ I would still have a field day trying to reach the same performance as them. Speaking of. 9: Coding. It's not just adding libraries but also knowing memory allocation, file types, code structures, hardware communication, code structure, graphics and physics implementation. Things I don't know and barely know where to learn. Let alone how to make a base for a software to be a game or engine. Something as simple as including a library like Archs or Svelto ECS into already existing engines or just in Visual Studio is non existent. Not tutorials or any ways explaining how to add these things. Just a github link and files and folders. Not a single step by step what does what and where goes where. 10: Porting. Engines nowadays work on being flexible and able to port to Windows, Mac and Linux as well as Android and sometimes WebGL. Commercial engines can afford a license for consoles which is something normal people usually don't. And this adds another layer to increase your work just to make the game accessible. In short. engines aren't perfect, nothing is. But the things they offer makes even a moron like me able to make high quality results with enough work. And the even more complicated stuff has been made by people already so things that would otherwise be twice the work of your entire project is now available. And people have shown that a little extra work can twist the arm of engines to do what they want.

Not a lot of people realise that maybe people just want to make tools instead of games. and I find it strange to discourage it because without these types of people you wouldn't have any type of game engines in general. when you build something yourself you know how to use the engine fully and it's easy to create what you want instead of having to learn a already pre-made engine. During a game jam this helps a lot because instead of having to learn the engine you can just focus on creating. also game jams are a good way to battle test your game engines it's good practice to make games with your engine so you know it does what you want otherwise you might be spending years on systems you might never use.

I think the neat thing about programming is that you can do whatever you feel like doing, so maybe for some years you just work on a game, and then some years working on an engine or some other program. That being said, I'm more interested in designing combat gameplay, so programming an engine from scratch is hardly my forte haha

My extension of this take : make an arbitrary engine from the stuff you used a lot and frequently when you made your MANY games. This implies you in the first place, make many games without a game engine, but in your style. That's where a engine starts.

A man of culture to i see. those are some fine game engines😉

Yep! It all comes down to what you want to do. Do you wanna make a game? Just use a game engine. Now, if you want to, or have fun, having control and doing everything by yourself, go for a game engine. But keep in mind that if you wanna build a game engine, it's because you want to build the ENGINE, and make games above that, not to JUST make games.

So for someone completely new what would I need to do or where to start if I wanted to make a 2.5d with some lite 3d first person game like blood “build engine” or Star Wars dark force “Jedi engine”?

Well, you got 2 out of 3 :D

I really don't get why so many people are making general-purpose engines. Back in the day every developer made their engine with a game in mind. These engines were also made for other non-programmers to use, such as environment artist and animators. I mean something like a level editor like Source Hammer is still lacking in many of these engines, the ability to just start hacking a level together is amazing.

I've been writing a stupid little library in C for a bit now, and it's going ok. I've got my own math library that's more than likely slower than anything else I could have used... And that's about it right now... I've been wanting to make a 3D FPS game, so I generally know what I need but IDK what the best way to accomplish the whole thing would be. I've thought about switching over to an existing engine but IDK, that doesn't interest me much. I'm trying to figure out how one is supposed to... Well, figure this all out... I have no idea how to even architecture this thing I want to make. Do you have any advice?

Well said !!

Some engines do too much, you can use Raylib, MonoGame, Godot, Flax if it's a simple game, if you want something AAA you need Unreal possibly and also a whole team.

How do I get to the point of competency where I can code something like a voxel engine and then a game on top of that

Plus. I’m Creating 3D Game Engines Not Publishing it On GitHub, Git or GitLab. I Only Publishing it On Other Digital Libraries

I wrote my own engine as I prefer to make 2D tile based games and it works great for what I do

i avoid programming as much as possible even though i'm decent at it so if i have the choice of using an existing engine that does pretty much everything i want better than most people would build on their own i would 100% pick an existing engine and learn its quirks

Absolutely true. That's always what I say whenever I see someone say "Hey look, I made a game engine". I mean, why? I don't think you should make an engine just for a single game or game idea. Even if you did, you wouldn't call it a game engine yet. It's just an abstract layer between your game and the OS/platform. But if you can adapt and morph and improve that same layer (and set of libraries) over time over multiple games, then you might start to call that a game engine. It's not gonna be jack-of-all trades like Unity, it absolutely shouldn't be at all. But it's an engine you've worked on with your blood and sweet nonetheless.

Is toml faster than json?

And who Made Unity thought that?

I've spent more time fighting problems with the Unity engine than on making the actual logic and content of my game over these past 10yrs. I'd have spent slightly less time if I rolled my own. Way way less if I had just modified the Quake engine. Bah, hindsight

3:42 - The main language that I program in is Python. I know it isn't as good as C-like languages, but I use it cuz it helps me focus on programming logic instead of language so that I can learn instead of making functional pieces of code. For the same reason, I really like making engines and libraries because I can learn and when I actually need to write a functional program, I will already have many of the tools necessary to make it happen. However, I do this knowing my position in my education and that when producing a functional program, I will only need to write things which I need. I think there is a huge difference between writing engines like this and writing code to make a game work (like u covered) is that you need to know what to do when. However, I do think that the person programming can affect which one they would want to do (engine vs game only). I really enjoy writing libraries (as stated above) so I can use my own code later. I hate using other people's code many times because, no matter how hard I try, I just have a problem understanding other people's code. So I like to make my own self-developed tools which I can carry with me and give to others to use. I believe there are other people like me in this regard and would much rather make an engine than a game, so that others and themselves can use it later down the line to make games with. With that being said, I do think it is possible to be in the right by making a large engine with intent to make a game out of it, although you must be able to separate the development of the tools and the development of the game into two totally separate entities at two totally separate times.

nice.,

i have two games i want to create custom engine for, im gonna probably lose 10 years on it, but its worthy, but for everything else, i got ue and unity...so ...

I have an idea for a game that's been kicking around in my head for years. There's no way I could "just use...." because none of them are built for the game I want. So the final game would be bloated with stuff it didn't need and I would still have to take time to create stuff that was missing. Using an all-purpose engine is fine if you just want to build another generic FPS where the only difference between your game and the other 75,637 on Steam is the color of your outfits. But look at all the hassle Unknown Worlds had when building Subnautica in Unity. Or the fact that CIG had to massively rework Cryengine for Star Citizen. Those engines lock you into doing things a certain way. They make all games feel interchangeable. It's far better to plan your game, decide how it should feel and work, then build the engine to accomplish exactly that.

I like to open windows and pretend I'm a millionaire. Much easier than doing anything.

One advantage of building yourself is you will know how it all works. 😅

if you only want to make video games i think you should stick to a game engine but if you want to be a embedded system operating systems and video games or maybe websites or machine learning and any combination of that than you need to adapt

My argument would be, writing a game isn't inherently the same as writing an engine, though it may become an engine. Because an engine is more of a framework than a game. There isn't anything wrong with writing a game from scratch. But to imply that is the samething as making an engine can be confusing.

My thinking process is: if I'm to make a 3D game I'll go with unreal. If I'm to make a 2D game I would absolutely want to make my own engine.

Agreed, AAA gaming is becoming generic as hell because everyone and their sister uses unity/unreal. If you want to stand apart from the hordes of people who have no clue how anything works inder the hood, make your own games from scratch. Then after you actually know what youre doing, you can easily pick up one of these engines.

So the choice is between using an engine that can do XY and Z vs building an engine that can do X maybe slightly better. Guess what will allow you to create your game sooner? Players don't care what engine you used. If you make a living with game dev, your bills don't care if they are payed using this or that engine. And if you are a programming beginner you don't even have the option to care. Building a game engine is a hobby, like watching movies. It has the goal of making you happy. There is no productivity in it. Also duplication of effort is not beneficial to society. Imagine if instead of 50 mediocre engines we had 1 that could do everything and do it well.

The question really is, do you want to make money.. Or are you making games for fun or your own satisfaction? If you want to make money, don't waste your time.

No the reason behind it is don't waste your time reinventing the wheel. Use what's available and build onto that. You also don't make your own graphic card from scratch to create your game so why making the engine.

I never got into using Unity, because I think it's a hot mess. Everything seems to be either deprecated or experimental. I prefer Godot, but if I want to create all systems myself and practise my C++ I pick SFML or Raylib.