So you want to make a Game Engine!? (WATCH THIS before you start)

So since Unity fucked up.. Hey I'm ready for my own Engine

>make my own cpu >make my own language in it >make my own engine with it >make my game with it >die as a 84yo man who made a pingpong video game

Totally agree with you but I'm like two years deep in building a 2D game engine and your point of "you know the code and don't have to lockup documentation" has turned into "why did I do that again and why is there no documentation" 😂

The world needs more engine programming videos, please turn this into a series.

for me the biggest advantage I get from building my own engine is that script reloading times take around 2ms to reload a 10 000 line csharp assembly at runtime. worth 12 months spent on the engine.

As someone who has built their own game engine (Look up Rank: Warmaster if you care), here is my take away from it: 1. It took many years (read 5) to develop a full 3D engine that handles space flight, RTS, 4X, etc. That means networking/multiplayer, planetary rendering, movement and collision w/ damage model, audio, configurable inputs (including HOTAS, but mouse and keyboard of course), IAUS AI system, VTFS (Volume Tiled Forward Shading), Cascade shadow maps, PBR, Bloom, UI system (ie. windowing, buttons, etc.), 3 scripting engines (one for frame by frame animations, one for campaigns, and one for generic use), etc. Just writing code for importing files/meshes and save/load games is it's own thing. The list goes on, which is more the point I'm trying to make. There is a LOT to be done. Admittedly the game I am building was built along side it, but this was full time. So best to understand your scope and how much time you can spend as well as how good are you really to do it? So if you have that kind of time and money to put those years in, and feel you can, go for it. Otherwise, it can be best to learn an existing engine. 2. C vs C++: Keep in mind that processors aren't getting any faster realistically, however they are adding MANY processors. Because of generally how C++ handles data versus how C handles data, from personal experience, taking your C source and multi-threading it is FAR FAR easier to get full use of the other threads than C++ is able to. ie. DOP vs OOP basically. I went from a single thread loading textures taking 70 second to 16 seconds on a quad core as an example (other things were happening during load, that liked the texture decoding not to be on the main thread). Terrain code bogging down the main thread? Throw it to a different CPU, etc. Movement and weapons fire slowing things down? Throw it on another thread, and it only takes a day to do it. So for me, the performance difference matters. But YMMV. If you can do it, great! More power to you! If you are just starting out, your life will move on and you'll likely never finish it. You'll learn a lot though. If you are a veteran coder and want your next big challenge, a game engine would certainly qualify. So my 2 cents on the matter. I hope I didn't hijack anything.

I'm making a game with my own engine, mostly doing it because it's more enjoyable. I don't love all the cruft that comes with the big engines and usually don't need it for most of my games. It's really nice to compile the whole game in like five seconds and just run it.

It was really nice to see a video that didn't just conclude with "Don't make your own engine". I think that for some people; it's just more fun to build something from the ground up and it made me sad that people who might get a real kick out of it were just being told "Don't"-before they even really tried. Good stuff :)

Great video, I agree with everything you said (also working on a custom engine). It's crazy how monstrous Unreal and Unity became and how long it takes to startup, compile scripts etc even for the simplest projects.

My idea is instead of one building an entire game engine, one should consider building a framework FROM a game that one has already made. In that way, code could still be customized and fixed to ones liking; its easier and it is actually: feeding two birds with one piece of bread ( that is, I said this analogy, instead of the violent saying/analogy of "it kills two birds with one stone"). Thus, in building a framework, one could build their game and have reusable code that could be adjusted and used over and over again for each game that one builds. Now, this is the way that I used to make my games back when I learned vanilla Java and JavaScript, because I enjoyed the coding process, the learning process, the bragging rights and other things mentioned in this video.

This video cured my depression

The youtube channel Called The Cherno is focused almost entirely around building game engines.

Just wanted to learn about game engines a bit and I have to say the quality of your video is top notch. It's not just the video production itself but I can't tell how many times people don't put chapters, timestamps or links in the description and people have to use the comments to fill the gaps. Not only that but you constantly put in easily screenshotable slides for further research and/or reading and I want to say I really appreciate that.

One point I definitely do not agree on is "to not make an engine if you are building a game". The problem with this is we will be left with engine developers who have no idea what someone developing a game wants out of an engine. Sure, using commercial engines give you the jumpstart on your project and you feel you saved time, but if you are making anything sophisticated, you keep grappling with engine issues later down the line, which completely offsets the time you saved by using an engine (in my experience, this is more frustrating since you are left to the whims of someone else's decision making).

As someone who has been working on an open source game engine for >10 years I have to say this whole video is spot on. It wonderfully sums up everything I would personally convey to someone about game engine development.

I've made a lots of small engine to make rpgs and plateformers in pygame mainly. Here's a general guideline to make a 2D game engine if you use a basic game framework (like MonoGame, SDL, etc) * start creating a game_context class where you can store all you basic methods like : * draw stuff on the screen * load images * handle camera * draw text etc.. * create a game_object class that handles tags, properties and erased objects * create a Scene system that contain and update objects : * don't forget to add z_sort property to your objects so the scene render / update them in order (usefull to make multi-layer games) * create general purpose objects such as : * Tilemaps * Level Patterns * Physics Entities * Animated Objects * improve your objects * add more complex features such as : * slopes physics * zoom * shaders (glsl) and there is you engine ;) pls pin me

Finally, a fair video on this subject. My second job after a short one of game dev, was game engine programmer for somewhere around 2-3 years. It was the place where I learned tons of stuff. After that I went back to game dev and I felt like I was never learning at the same level. I had the same experience as you had with Unreal, I felt it was really slow for coding, it was killing my productivity because of big compile times, I was literally taking a break while it was compiling. On the other engine(it was not a small one - had most of the popular game engine functionalities, including fully functional editor), I was always opening the project directly with the debugger attached. Game Engine Programming is amazing, a lot of stuff is challenging, but highly rewarding. You can learn tons of programming and you can get in a lot of depth on a bunch of domains - if you want to learn physics you can do it, if you want to learn AI, you can do that too, if you want to design really big systems, guess what, you will have tons of chances.

I've got a 2D engine I built over years expanding and improving all the while. I made it cause I didn't like any other engine I tried and I wanted the experience of making my own. At this point it supports open world 2D tile based games and 2D tile based level based games.

I think this is one of the best and most easily-digestible videos on game engines out there. Very cool! Definitely agree with a lot of points here like game engines taking a ton of time, but on the same token, damn is it fun and cool when something you've made actually works. And wins you brownie points with other devs too ;) Thanks for the video!

I've been building a framework for roguelikes in Lua/love2d, and tbh I think Lua scales pretty damn well. I've had practically no issues with it so far. I agree, though, that it takes over your time. I've been at it for some 5 years, on and off, and it's still far from ready, and I've burned myself out several times, and... the games I originally wanted to make, well, they're still just prototypes, because they ended up becoming just guinea pigs for testing my framework's features -- which by the way are constantly changing drastically because I keep experimenting different ideas of how to do things to satisfy my personal demands, which further delays the ETA. That said, it's been quite a ride, and I've been enjoying it. It started, by the way, not because I wanted to make a framework, but because I wanted my own rendering code, and to abstract quite some boilerplate. But then I kept adding to it.