So you want to make a Game Engine!? (WATCH THIS before you start)
Vložit
- čas přidán 5. 06. 2024
- Ever thought of building your own game engine? Watch this video to find out what you need to know before making one!
Donate or become a member: ko-fi.com/giantslothgames
Learn OpenGL:
learnopengl.com/
GDC Talk - Approaching Zero Driver Overhead (AZDO) in OpenGL:
www.gdcvault.com/play/1020791...
TheCherno:
www.youtube.com/@TheCherno/vi...
--------------------------------------------------------------------
Timestamps
--------------------------------------------------------------------
0:00 : Intro
1:07 : What is a game engine?
2:16 : Game engines vs frameworks
2:52 : Why make a game engine
4:34 : Career opportunities
5:38 : Advantages of building a custom engine
8:01 : Disadvantages
9:16 : What you NEED to know
9:57 : Choosing a Programming Language
11:22 : Choosing a Graphics API
13:10 : Where to start
14:08 : Outro
Discord: / discord
Twitter: / giantslothgames
Subscribe to my channel: / giantslothgames
Videolink: • So you want to make a ...
--------------------------------------------------------------------
#devlog #indie #gamedev - Hry
So since Unity fucked up.. Hey I'm ready for my own Engine
This is the way. Free yourself from corporate greed!
Same lol
Literally same
It really does send a message. What's stopping Godot, Unreal or any other software from doing it?
@@DINGOS30 That's true about Unreal, but the thing that prevents Godot from doing this is that it's published under a MIT license. Completely Open Source and free to do literally anything you want with it, up to and including selling the entire engine for cash without any sort of limitation other than "it must come with this license attached".
If they try anything, any rando can literally just fork it, call it "Hodot" and avoid any shit they try to do.
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" 😂
haha true
just comment the living hell out of the code so you don't forget what it was used for
@@pieterpretorius1014I force myself to do that with xml documentation except I get lazy and put returns the object in the returns what
Why would you build a 2D engine? Those were outdated 20 years ago!
@@skycaptain95 I had no prior experience in game engine programming or OpenGL. Reducing the scope to 2D allowed me to cut some corners for advanced topics like 3d lighting. I also chose OpenGL instead of Vulkan because the entry barrier is much lower in my opinion. Also I knew I would only be able to create a 2D game because creating 3D assets takes too much work for a single dev that also develops the engine.
The world needs more engine programming videos, please turn this into a series.
ever heard of the cherno?
@@anon1963 Yep, been watching him for years, but besides him there are very limited options
can you help me please with an idea to create a game for elderly
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.
Big true. Honestly the slow compile & startup times is the thing that probably annoys me most about Unreal for example haha. And their Live Coding doesn't always work (and even that takes pretty long sometimes lol).
@@GiantSlothGames with unreal engine c++ is a very slow to compile language so its obvious why ue is slow, what bothers me is why does unity take 30-50 seconds to reload the c# assembly i am using mono same as unity. with a sizable c# project tested around 10000 lines my engine out performs unity by 15,000 times.
@@ayoubbelatrous9914 yeah unity is a total mess. but that's what happens when you're a 20 year old piece of legacy software that needs to do absolutely everything.
@@ayoubbelatrous9914 what's your repo
@@anon1963 its not a public engine.
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.
Like godot
can you help me please with an idea to create a game for elderly ???
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 think you came to the conclusion of C code being easier to multithread comes from your prejudice of preferring C and possibly you having more experience with C than with modern C++. No-one stops you from designing performance-critical parts of the systems in a C-style (or any other 'better' way, it is the responsibility of a programmer to make an informed decision and not just mindlessly "default" to any approach). C++ is not a strictly OOP language, it doesn't force you to make everything a class or whatever, so DOD or whatever the new buzzword is can be employed at the same level of efficiency in C++ as in C (and as I would argue later - more efficient in C++). I understand that I am just guessing here, but probably your experience was bad, because:
1. You thought C++ is OOP language, so you designed your code in OOP way without much experience how to actually make it efficient and extensible. This is not what you can just do without extensive prior experience, nor it is what you should default to when using C++. C++ provides tools that support a lot of other paradigms of design (including DOD, functional and more).
2. Your approach to multithreading was "in terms of C", meaning you tried to employ C-style MT patterns in a code designed in an OOP way (which is, again, not synonymous to C++).
In practice, modern C++ provides very good out-of-the box solutions to solve tasks that require multithreading. An example might be that you can easily make your 'std::for_each' loop run in parallel *just by adding a single argument* 'std::parallel_policy' to it (presuming your code was suitable for parallel execution). The same trick works with a lot of other standard algorithms too. Good luck parallelizing generic search algorithm in a C container. In addition to having all the concurrency capabilities of C, C++ provides wrappers and handy abstractions to make things easier and safer (even coroutines in the newer standards).
There also is a point to be made about C++ having more means of expression that improve performance such as lamdas. Lambdas can be inlined by compilers as opposed to function pointers, so if your sorting or linear search algorithm in C uses a callback comparator - in C++ with lambdas it would be 10-30% faster (which is HUGE). You wouldn't reimplement your sort every time you want it to do something slightly different or use macros to make sure the code is inline, would ya?
@@goczt Ah the internet. No, C++ is not a strictly OOP language, but when you talk it’s about understanding the audience, not debating minutia of technicalities. I don’t feel like getting into a religious debate over computer languages. Generally when someone uses or thinks of C++, they think of it’s OOP implementations, especially for data (ie. Put things in classes, etc.). There is nothing preventing data structures, or other means to store the data in a DOP friendly way. (It’s DOD now? This is why I don’t bother with buzz word bingo.) So I could have explained the nuance of making DOP friendly data, or just say C vs C++. I accomplished what I wanted to say in a few sentences rather than writing a novel about it (which you have). The issue of DOP was so important that even Unity did their DOTS initiative, which is what I was attempting to express without writing paragraphs the reader didn’t want to sift through.
I think it is best not to assume someone’s background. I’m not a believer in jumping through a lot of hoops just to be a purist, a mistake a lot of programmers I see do. I believe in modular and functional programming. I learned assembly on the 8086 in High School, just to date myself, and was introduced to OOP in the early 90s, and have been doing OOP most of my career. I’ve seen coding fads come and go. Perhaps next time, just explain how something might be done in a different way than stated, rather than assuming something about someone else. It’s best to write something that enhances what someone mentioned rather than making assumptions and accusations about someone’s style or prejudices.
@@arthurmoyer2657
The primary conclusion I wanted to make is: We need to teach people to be reasonable about their design choices, to make informed decision based on pros, cons and software requirements, and not to just do fallacious over-generalizations like - prefer C to C++ because C++ is OOP and OOP is slow and bad and smells funny.
Yes, i totally admit, even in my initial reply, that I was 'thinking', 'guessing' and assuming. I'm not doing internet stalker-like research over someone's persona just to reply to them in the youtube comment section, can't really blame anyone for that.
You advice to explain how something might be done in a different way than stated, but you didn't really 'state' anything of a substance on the topic that I have a problem with. You didn't mention any concrete techniques or specific design issues that you've encountered and made a rather misleading generalization "C++ = OOP" and explicitly said "C++ vs C" while not feeling like getting in a debate over computer languages. Perhaps my advice for you would be - next time try to convey your thoughts in way that does not arbitrarily redefines things you're talking about to minimize the probability of being misinterpreted.
Coming back to "explain how something might be done in a different way" - I actually did, I mentioned C++'s execution policies that help making concurrency in C++ easier, and lambdas which both improve performance and design. You didn't address any of these, not following your own advice, but instead started lecturing me on the topic of internet debate.
>rather than writing a novel about it (which you have)
Yeah, and?
Your C vs C++ argument seems to be the general consensus from my rudimentary search
People tend to find that C has better optimization and performance at the cost of lack of built-in higher-level extractions.
I am currently planning to learn a new language and I think you gave me inspiration on where to start!
Much appreciated
I think you should start by implementing simple then from time to times adding new features, but if brfore you start you already thinking about multiplayer stuff, your project is dead before even born, cause all of the existing engine or libs or frameWorks weren't at the level they are now form start, they just keep on adding features .
Moreover i think someone should start by a 2d engine first, by doing so you'll probably finish the project than pick something you can't chew. So let times helping building something robust.
>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
what about making your own gpu
hello Jonathan Blow
@@element1111 what
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 :)
This video cured my depression
How though?
@@davidrudpedersen5622bruh
Seriously how though?
I am depressed too
imagine being depressed, skill issue honestly
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 is definitely a good strategy!
Feeding two birds with one scone
The youtube channel Called The Cherno is focused almost entirely around building game engines.
Yep!
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.
I've dabbled in engine programming since 2019, when I had my first experience with idTech 4, a.k.a. the Doom 3 engine. Yeah, I'm one of those weird types who avoid Unity and Unreal.
I recall making this large terrain mesh in Blender, right? I put it in my level which was otherwise just one huge empty box (the engine is designed for indoor levels!), and since I compiled the engine in debug mode, it was tripping a certain assert in the physics code. "Ray length was greater than 4096" or something. I copied the message, Ctrl+F'ed it in Visual Studio, and it took me right to the engine's raycasting code, used by its built-in physics engine as well as places in the game code and other things.
It was only then that I realised I was effectively reading something that's considered part of the engine code. It felt kind of surreal to be there, since I was used to the engine being nothing but a black box. Apparently, whoever designed the engine did not really expect areas to be wider than 4096 units. It was a rather arbitrary limitation, so I just removed it!
Anyway, in very late 2019 I started to mess with simple post-processing shaders, later adding a shader to blend 3 different materials on a terrain mesh according to vertex colours, and overall learning a lot about how the engine kinda worked on the inside. In 2020 I made another little game, now with my slightly modified idTech 4.
Then I decided to go down to idTech 3, because idTech 4 is from 2004 and I wanted a real 90s game engine to make a proper retro FPS. And there I learned. A LOT. I made several changes to the renderer, rolled my own particle system, a basic vegetation system, modified the animation system, added a dynamic music system (though nowadays this'd be a game feature in my book vs. an engine feature), and such.
In late 2021, I decided to try writing one from scratch mainly because of the fact idTech is GPL-licenced, and I'd like something a tad more permissive. It went well for a year until I found myself experimenting with Godot in December 2022. Wonderful little engine, but still not my kinda idTech-style workflow. Nah nah. I'm still at it, but Godot's a great source of inspiration and excellent for some quick prototyping.
So... what was the point of all I just wrote?
I guess I just wanna say it's perfectly fine to go for a custom game engine if you have a good reason for it. Personally I was never ever happy with mainstream engines, because I'm just simply used to my idTech-style workflow and I see in it what other people don't. I'm just looking for a solution that fits my needs.
And I mean it. I've tried Unigine, CryEngine, Unreal Engine, NeoAxis, Flax Engine and a few others, and I really just cannot get used to them.
Using idTech sounds really cool, did you have any resources on getting started or did you just kinda dive in and figure things out?
@@sdsdfdu4437 The core reason I used idTech engines is simply my past experience in modding Half-Life and a bit of Half-Life 2. So, knowing how to make maps and some other stuff for those games, meant I already kinda knew a good part of idTech already.
And indeed, everything was very familiar to me in idTech land, the difference was in the tooling and details. There are hardly any resources, by the way. The best you'll get are game modding guides for Quake and Doom 3, not their engines specifically. Doom 3 was the worst offender in terms of tooling, also.
The landscape is slowly changing over time, as some Doom 3 forks are finally getting GLTF support, so you don't have to bother with some export scripts for Blender 2.7x that nobody knows if they work. But also TrenchBroom support because DarkRadiant sucks so bad.
In the end I'd say knowing how to read the code, and very well so, is a vital part in learning the engine. Also you can learn some of their tricks by analysing the existing games' assets. Though there should also be some small modding Discord servers where you can ask questions and stuff.
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.
You can do most C89 code in C++, but as you move into C99, C11 and C17 things becomes more interesting.
for newer C standard you gotta slap extern "C" to tell the C++ compiler to use C compiler instead
This video was so nice, straight to the point, informative and fun, I hope this is going to turn into a series
I am extremely interested in seeing you create more engine-based videos or series. I would watch them all (probably multiple times)
That thing about trying things differently and then understanding why the reasoning behind the convention hit home.
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.
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
Good luck, hope you make some YT vids.
@@crew_the3rd Of course
nice vid!! motivated me to actually go through with making an engine. Id LOVE it if you were to make more vids about this topic
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!
Thanks so much man!
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.
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).
I don’t even really disagree with you tbh. I have similar experiences. I mostly made that point with aspiring game developers in mind.
Also what you mentioned about engine devs not knowing what a gamedev wants out of an engine is a great point.
Like someone else wrote here, building up a framework of reusable code that eventually turns into a game engine is probably the way to go (its the way I do it pretty much.) Maybe I should have included that in the vid somewhere 😅
I consider myself an intermediate programmer, and I can't exactly imagine what you mean when you say "something sophisticated". Could you name something sophisticated that you couldn't easily do in Unity, for example?
@@KutluKanyilmaz Sure.
1. GPU Instancing.
2. Multi-threading.
3. SIMD operations.
4. Memory allocation: Zero control over here. Let alone limited.
5. Streaming assets (CPU to GPU)
These are just a few areas of the top of my head where Unity offers limited control, if it does at all. Talk to someone building games from scratch for 20 years, and their list would be much longer.
Sure, some things Unreal would do better than Unity, or vice versa. But the point wasn't regarding some specific game engine. It is about when you make a game on any engine, some architecural decisions have already been taken for you and you simply need to deal with them, often resulting in sub-optimal solutions, or no solutions at all.
@@GiantSlothGames I understand. I personally feel game engines are a long way off from being really good. Plus, these days you never can trust a company to take decisions in the interst of gamedevs, many times it is solely marketing decisions. For example, if my project depended on the performance improvement of DOTS, I would be left hanging forever waiting for them to fix the glitches.
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.
what's its name?
Nice work PJ, was a very entertaining and informative video :)
You had more to say than I've grown to expect from these kinds of videos. You're a standout - subbed.
I will be watching. :o
The most comprehensive videos that point you in the right direction I have seen!
I will be glad to see new videos on this topic!
This was hugely helpful, would love a series of those
So I'm in a school that focuses on programming and two or three times a year we have "projects". They basically give you 30 days to build and present a game on a specific theme. We do that in raw c++. No engines, nothing. Just graphics libraries and thousands of lines of code. The thing is I didn't know it was considered an engine. Good to know
great video, earned a sub for sure. the topics you want to cover are exactly what id like to see, managing of large projects is something id very much like to know how to do :D
would love to see follow up videos on this topic!
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.
If you want to develop a game, use an existing game engine. Writing your own game engine is fun, but it's so much work that you'll never have time to develop a game for it as well. The days when you could build a game and a game engine for it at the same time have been over for more than 20 years.
For example, the Build game engine (on which Duke Nukem 3D and many other games are based) was developed by one man, but he never did anything other than develop that engine. He never developed a single game with it. This was done by other employees of the same company, who only worked on the games and never on the engine.
It's also not worth developing a complex engine and then using it for only one game. Remember: if you have developed a game engine, it is a standalone product. You can sell/license that engine and already earn an income that way. Leave the game development to other people. It's a bit like developing an app: you might be good at writing low-level backend code, but not at creating beautiful user interfaces, or vice versa. Leave the user interfaces to the people who can do them well, and let the backend be developed by people who prefer low-level coding. If you try to do everything yourself, you have to be good at everything at once, and no one is equally good at everything.
Many people have told me that creating your own game engine is a great for your portfolio for getting your foot in the door for GameDev and that you learn a lot of very useful skills along the way.
We can't all be environment and quest designers. The engine guys are the ones who really make the game feel great and crisp. The best gameplay experiences I've ever played have been on engines that were created not pre-made engines.
@@joeharris9273 Except that many game companies are not interested in developing game engines anymore, so it depends where you want to apply for a job. Many game companies today just use ready to use engines, like the Unreal engine. If you prefer working on engines, be sure to hire at a company that actually still does develop their own engines.
Most people prefer to just make an games, though, and if you just want to do that, I recommend using Unity. Unity has become an incredible powerful engine and contrary to other engines, it's still easy to start with, at least the basics are easy to learn and understand and you get great results in no time. It can get quite complex if you want to use all the advanced features later on but for a simple game you won't require too much fancy stuff. Rather focus on the game play itself. Many indie games have mediocre graphics and are based on simple concepts but quite often are more fun to play than big AAA titles and that's what a game is all about in the end.
Honestly, I have been toying with the idea of learning to use LibGDX for java since I had recently had a object oriented programming class myself which really helped me get started with java.
Another option for getting rendering done across multiple platforms is to use a cross platform rendering abstraction APIs something like WGPU or BGFX or Vulkan (there are implementations on top of Metal and DirectX12) so you do not need to rewrite the rendering code for each platform and just let the library delegate the job to the appropriate underlying rendering API.
Let me say that most programmers these days don't even know how to utilize the API for their operating system. Windows has it's own API that the devs made for the public to interact with. Same with Mac and Linux. All that API code for each OS is what game engines are built upon. That's the difference between beginner programmers and experienced ones, game engines do have a place but Unity and Unreal basically does all the hard thinking for you, but it also restricts you in performance and usage. Windows.h for the CPU and CUDA for the GPU. That's really all you need to make a game engine. Although Windows.h is only for Windows but each operating system has it's own API with it's own pluses and minuses. Anyways making your own engine will make the difference between you being a beginner and someone with real experience, like someone who knows Python vs someone who knows C/C++. It's just better.
@@luckybutunlucky8937making a game engine has never been easier… you barely have to wrangle hell itself
And the whole developers not wanting to touch windows.h, WHY WOULD ANYONE WANT TO TOUCH IT IN THE FIRST PLACE. Both Linux and macOS are posix and share many different subsystems, windows is the black sheep using hellish stuff like lpcstr to denote a long pointer const string in a language that forces declaration of variable types…
I’d much rather let sdl or glfw do the core lifting of initializing a window. Then manually optimizing open gl per os situation than to ever touch the windows.h header. Granted ik how to wrangle it just fine, it’s just hell and slow and takes so much time
@@luckybutunlucky8937cuda is only for nvidia
I loved this video! Straight to the point and great tips for starting out! When I started out a few years back I tried lwjgl and made everything based off of the fact that I thought I knew enough java and linear algebra. I was kinda wrong, but it was a great foundation, later I tried again with lwjgl but followed learnopengl as an example, and kinda documented my process, which helped. But as some might say, third time's the charm, and the best implementation with a complete documentation and ecs implemented was done in C++. I'm still bummed out by the fact that how much you have to implement yourself when doing things like this, but it's mainly the process what's fun for me. Also, knowing the ins and outs of a basic rendering pipeline allowed me to be much more efficient at using Unity for example, making smaller projects getting done pretty fast. What I would've liked if you also included in the video that the things you talked about were only about rendering. Networking, physics, UI, etc. are a whole another topic, and (unless you use premade things like dear imgui and bullet) they're pretty hard to do! Dropped a sub for sure!
I subbed so I can catch when you start the engine video series, so... kinda have to do it now 😁 Really, though, this was a very informative video and would totally eat up more information on the topic.
Pls make more videos about game engine! Making a game engine is something I never imagined I will have to do but it seems to be a good idea if I want to learn about making games.
You are awesome. I was stuck about where to start since I wanted to try to make a game engine. Now I know how to and it is working out quite well. Thank you!
This was crisp! Keep it up man!
I absolutely adored all the images. Outstanding video and content!
Another great set of knowledge that will be essential for a task like creating a game engine from scratch would be learning OO Design Patterns. If you don't know what these are, I recommend reading Gang Of Four Design Patterns. Took a software subsystems class in college, and it's been the most useful course so far.
Oh yeah definitely. Not only OO but also stuff like data oriented design could also be useful.
And yeah, basic comp sci stuff in general will be useful, like complexity analysis etc. and having some general experience with frequently used algos and data structures.
Theres also the book "Game Programing Patterns" by Robert Nystrom (free online)
Great video and explanations, thank you!
This is a good video. Only thing that I'd like to add is absolutely do not underestimate the time it takes to develop a game engine. Chances are, if the game you want to make is not a simple 2d platformer or a simple rpg with a tilemap or something, the most likely outcome is that your project will fail.
The only case I heard where someone could deliver a 3d game with a custom engine was a guy who spent 3 years of his college course studying that + 5 years working only on that subject, until he made a simple simulation game. And still, it was little more than something that displayed Blender 3d models after they were converted to his custom format.
Currently I am doing an editor for fractal flames, much simpler than a game engine, and in the start it was complete hell.
It was like fighting a hydra, every head cut created three more to kill. It took a long time to get used to C++ features like template metaprogramming, and I had to write some small libraries for XML serialization and OpenCL execution. Setting up the build and dependencies and getting the IDE to correctly index all the code to get intellisense was no easy task either.
After lots of rewrites, I could implement something that read a fractal from the file and rendered it offscreen to an image with the quality of available apps in less than 2000 lines of code, and I felt really proud of myself.
Even though it's better now, I expect to change a lot of the code once I implement the UI, and btw only adding the ui library dependency until it built a hello world window took me 4 hours.
Absolutely do not underestimate the complexity of this task, it can kill your project!
Good to mention as well is WebGPU which is a standard API for graphics. It can run on OpenGL, Vulkan, Metal, etc. depending on the platform
Bro this is awesome!!!
Me: "I would like to try making a game engine once, seems fun!"
CZcams: "Well, do I have the perfect video for you."
Great video! Agree with all the things you said.
One thing to keep in mind about OpenGL vs Vulkan though (from my understanding at least): The OpenGL standard is no longer being developed, and it has being deprecated by Apple. It is still supported though (even by Apple), and vendor implementations still seem to be updated.
Yeah, you're definitely right.
The apple thing I probably should have mentioned. Aren't they stuck on version 4.1 or something like that permanently? Quite a bit of modern functionality missing I think. (Though I don't think Apple supports Vulkan do they? With them wanting to move everyone over to Metal.)
Personally if I were starting today I'd go with Vulkan tbh, the API is just much cleaner.
@@GiantSlothGames I think its even older than that, like OpenGL 2 or 3. I remember reading something along those lines from either the Zink blog or the X-Plane blog.
Apple does not support Vulkan either, hence the MoltenVK project.
OpenGL 4.1 is technically supported on Mac. Although I've encountered a number of silly driver bugs programming for mac on 3.3 that have taken a number of hours to fix, that I wish I just coded for windows. Not to mention you can't use any of the modern concepts like compute shaders or DSA in versions > 4.1....
2:44 with the robot scene cracked me up haha
poggers
engine/build tools/tips&tricks series would be cool
20 years of professional development of game engine unity and unreal has according to ex Rovio dev whose name I shall not disclose said it would require 100 engineers to develop new game engine.
True!
But he probably mean "game engine that could rival Unity or Unreal engine" ;-)
Something simple could be created much faster and by just one person.
A game engine and Open source is it possible, 100 engineers?, honestly I don't know be required. For example Stride engine do not reach 100 devs but this engine is amazing.
Cool video.
I am making engine in C. I got 2 renderers done using OpenGL ES 3.3. One for 2D and other is pixel renderer that mimics how Atari renders.
Goal for engine is to be bunch of single library files (c, no header files) that each file has 1 job to do.
Hmm so that means you can also use angle for rendering so that it might work on a other platform.
@@platin2148 angle???
also another big advantage of building your engine is: you're allowed to use any license you want
I was thinking about this and I found this video on my recommended, Google’s data collection is insane
Thanks a lot, very clear explanation, good job with the video
Thank you for this. Would love to see a series on it.
One of the games I was working on(Will wait a LONG TIME before continuing) has a scope that has gotten out of hand. Basically:
I need a custom game engine/pseudoOS for running most of it, a custom(unlockable) programming language, and a pseudo-game engine that works with that language.
For now, I'm gonna keep focusing on Unity. As all the others(until the ones incorporating this one) only need Unity. But, I'm trying to understand exactly what I would need. Just to keep the gears turning.
For the record, we are no longer gonna "keep focusing on Unity". Will have this, and another, project be worked on in attempting to make my own engine. Learning Godot too.
Great commitment to putting but pics whenever you say but
Huge video, thank you so much!
Id definitely love to try and make a game from ground up to have some "fun" with all the technicalities and math, but for now I just really want to put out a few games at least. Generally things are easier learnt from finish to start, so making an engine should be easier done once I've learned how at least one works.
for a game i’d like to make someday i ive considered making a custom engine, tho more likely i’ll just make a bunch of custom stuff for godot and use that. but mostly because of the sheer scale i want to achieve, well past 64 bit float, and a custom physics engine which works with that
Nice ending
I think a lot of people make a mistake thinking they want to make an engine rather than a game. An engine is an abstraction layer which can take as long to make as a game. A game without an engine is easier because you’re not abstracting for an end user that wants to make generic games. Specified code is easy to write, general code is hard to write.
Really good Video 😀. I am also starting to build my own engine. I would really like to see more videos about game engine programming. I would also like to know how you started. Have you watched The Cherno or how did you start game engine programming?
A game engine is a program or set of programs which define the laws of physics for a particular space and provides an interface with which one can build, edit and otherwise interact with things within said space in the domain of text and/or graphics and/or audio at the very least whether this be more traditional physical objects physics or physics relative to how card games work.
Personally, I went with a deranged hybrid approach born of my own self-taught nature. I'm writing a text adventure... from scratch. As such, the actual game engine - the stuff that handles all the interactions, the text parsing, the saving and loading, the areas, the NPCs, the rudimentary AI etc... that's all written by me from scratch.
But I was under no illusion that I could somehow learn how to deal with UI and graphical elements, even for an almost purely text game, and especially since I ideally wanted to have some nice fades, text formatting and whatnot.
So originally, I packaged the whole thing up in a WPF project. Worked pretty damn well, was robust... on windows. But of course, could only ever run on windows.
Fast forward to now, and the core engine is still entirely mine, but I'm using Godot for the front-end. Basically, I have a single go-between script that serves as the middleman between the core game and Godot - taking the raw string inputs and keypresses from Godot, and passing them onto the C#, and then passing back instructions for the UI elements. (Oh, and of course technically, it's not C# but Mono... I'm not entirely sure there's a meaningful distinction though at this point - I was able to port the pure C# project into "Mono" without changing anything really).
The benefit of this approach is that the two pieces are largely independent of one another; the core game engine doesn't care what engine the UI is using, it's just sending fairly anonymous calls that are picked up by Godot, and receiving similarly generic inputs that could come from anything. So if I need to update the version of Godot I'm using, or switch front-end entirely, I only have to adjust some of those UI calls.
In fact, the process of porting the entire existing project from WPF to Godot took only about 1 month, for this reason.
And because of all this, I was also able to reach the realisation that I could package my traditional novels... in the same engine as the game. Because it's a glorified text delivery system, with a polished Godot front-end. So I'm currently selling (or trying to sell) traditional novels on Steam.
(If anyone's curious, search the Steam store for my name. )
That sounds really cool actually. I'll have to check them out :D
cool approach
I would like to remind people that Rollercoaster Tycoon was made by a solo dev in 2 years using 99% assembly.
That's just depressing. With all the modern languages we have, engines, Udemy, CZcams tutorials, cheap assets..etc I couldn't release a simple 2d platformer 🥺
fwiw, it took me six months to code a 2D engine to handle UI in Open GL in C++. No editor, 3D, physics, audio, networking etc. Not even scalable fonts. The time went into getting all the input events handled and the essential widgets, of which multiline text and editable text were the hardest. If I had to add 3D etc. I'd definitely have to bring others on board (which is what Cherno ended up doing). Bottom line: think long and hard before doing an engine. Even the big studios with tons of resources and sunk costs are giving up.
Another advantage to existing popular engines is that you can hire people to work on your game and not have to train them on your engine.
Well done
hey great video. Im not super interested in game developing myself but i do find it fascinating how it works. Is it possible to develop your own graphics api? what advantages could come from doing so?
Thanks Slot. 😁
With python speed is not a problem. you can use the cython or nuitka compiler. They compile to c/c++ and than to native code.
loved this video...there are too many discouraging videos on this topic...i love creating my "simple" game engine, and because of it, i got 2 work opportunities so far, got way more confident as a programmer as well...in general, there wont be many workplaces that will develop something that rivals the complexity of, even if simple, game engine (not counting fang)...you basically insure your future...good luck to everyone, and dont let videos that catastrophize steer you away from your passion!
You have a really cute cat as your logo. It will bring you much luck!
Thanks but it’s a sloth 🤣
One of my friends decided to make an indie game. But instead of choosing an already existing game engine, he decided to make it himself. A year has passed, he made the engine half. And now he feels a wild emotional burnout about his game. Probably for someone to make a game engine is important and useful, but if a person just wants to make games and develop as a game designer, maybe he should not do this.
Thanks for this. Im thinking about using javascript to brush up and get better with the language. This is very helpful. Thinking about using typescript. Would it be ok of i use typescript? Do you have any recommendation. Thanks again for this video.
For Graphics api’s use DX11 for Windows, VK for Linux, Metal for MacOS. There should be a abstraction over this anyways.
If you are lazy take a look at sokol shows a pretty unified gfx layer.
I've decided to pick my own path based on different criteria:
1) I'm Linux user so engine must work under Linux
2) This left almost only Godot for me.
3) Godot cannot handle fast processing large amounts of data required for my game. I've tested it and frame took around 200ms, which is like 5PFS.
4) I've decided to write my game in Zig (C like language but with much more control and safety).
FWIW, You can always write GDExtensions to do the processing in there at the native level.
@@astroid-ws4py I've tried, Godot is OOP engine with many virtual functions and this is what slowed everything down. I simply cannot do that in that engine. No matter the approach I took.
you should consider using Unity and ECS/DOTS
@@jeffmccloud905 Unity doesn't play well on Linux. Are you blind about 1st point?
@@wiktorwektor123 Unity runs on Linux.
Excellent content - I'm actually making an engine in python/openGL - lemme tell ya, the typing thing hit hard at some point, mainly actually, while implementing math. Otherwise, it's a pretty comfortable (and performant) ride thus far.
RE: Some of the language discussion going on here, one of the big weights for choosing C++ over Rust for me is that all the SDKs for content production apps (Maya, Rhino, the Adobe suite, etc.) have all been written in C++ 30 years ago and aren't ever going to make the switch. Piggybacking existing tooling as much as possible is a powerful approach to gamedev I never see anyone talking about, you can dramatically simplify your engine by just developing in a polished environment with a robust feature set and only having to worry about IO and rendering on your end. Plus you have the possibility of releasing whatever tools you develop as standalone plugins for a secondary income source.
This guy's animation timeline UI is extremely impressive, but I'm definitely just going to write an exporter for Maya, lmao
Probably wouldn’t use Rust as that will annoy you if you want to write script like code. Also one doesn’t need to care too much about full safety and conformity. For C++ i probably suggest to use a subset of C++ don’t use too much of the stds or get rid of them in general.
Ahhh, if you want to build an engine with GPU support, start from SDL2 or freeGLUT. SDL2 gives you cross platform access to basic OS functionality plus audio and input with controller support, also it's just a library. Use what you want, compile what you need. Plus, there are other language bindings for it: Rust, Pascal, Lua and Python.
Better go with raylib for that.
@@blackcitadel37Raylib isn't as cross platform as SDL, it's not the focus of the Raylib creators. SDL is usually the first to get console support out of the many libraries for making games.
the vision got me tbh
I was between developing games or develop an engine. Now I'm mostly sure to go for the engine and maybe make it my bachelor's degree project
Rly hope u do the series about how do make a game engine in the video
your channel is great education for me
thanks 👍
I just want to use a modern and nice-to-use language, for that I chose kotlin since its syntax is so mature and has many amazing features, but I would have to use the JVM for that which would make it slower than something made for example in rust, and sadly kotlin multiplatform is still very slow compared to the jvm, for that I also decided to use vulkan since I can do my best to optimize it, quite the roadmap, but I'm sure it's doable with time.
great video btw.
i need to master all of that
I would probably create one just for fun and personal achievement
this is the way
I am thinking about learning coding and all, barely looked at any tutorials, I have this fear of never actually learning anything from them and just never being able to become independent from them. (I found a term for that named “Tutorial Hell.”) I also looked a little bit at Harvard CS50, I viewed about an hour or two of one of the lectures on a video, haven’t enrolled in the online course though. I’m thinking about a “engine” for 2D games that could be similar to things from Doom, RPGMaker, and maybe RAGE slightly as I want to make one that isn’t really for level to level 2D platformers like Mario, Sonic, Spelunky, etc… but more like maybe something like Zelda II, Super Adventure Island II, Super Paper Mario, etc… I guess a good way to describe it is that it could feel like a Zelda game but in a 2D Platforming style, or a Story, action RPG as a 2D Platformer. I don’t know where I want to start in full on learning coding though. If Harvards CS50 would be good in learning enough to be able to independently write code yourself
I'd like to see maybe a video on how you made that decal system. Is it based on a tutorial?
I'll touch on that in my next devlog vid probably :D
best 14 mins ii ever spent usefully
If you have dreams of some day shipping your game on multiple console you're going to end up learning a new Graphics API for each. Invariably this will lead you to making your own transpiler so you only have to write a shader once.
What I do currently is I have the glslang + SPIRV-cross libraries. Those two combined basically function as a transpiler for GLSL -> to pretty much any shading language. Glslang generates SPIRV and SPIRV-cross can generate code in most shading languages from that spirv-binary. I currently already use it for my OGL implementation even though it's not strictly necessary. (Since OGL obviously works with glsl out of the box.) It's still useful because I can do some reflection + allows me to use the "Vulkan" dialect of glsl even in OpenGL.
Ótimo vídeo!
DX11 > GL
Performance, Stability, Drivers, Debugging stability, Shader language that doesn't change depending on the GPU/Driver you are using (basically stuff that NV cards allow you, same stuff will prevent shaders from compiling on AMD or Intel cards), Asynchronous API, More verbose error messages, Semantics in shaders, Stability across vendors.
Chances are you will actually use your engine to make cross-platform game are pretty low. Might aswell use Vk, but it is more demanding (in terms of stuff that you'd have to manage) than GL/DX 11.
As for the consoles, chances are - performance might aswell become your bottleneck and you'd have to use PROPRIETARY (omg he used that word, how dare he) API and implement graphics backend for that platform.
But, I don't think that performance will be the real culprit here, rather stability and other stuff might be.
Also, if you will do basic 2D engine - GL should be enough, but be warned about drivers, GLSL differences across different GPU vendors and other potential issues.
If you use modern OpenGL with SPIR-V extensions, you won't have to worry about each vendor's GLSL compiler implementation. Instead, you'll be compiling it offline just like with FXC.
But yeah, OpenGL 3.3, without any extensions from 4.x, is pretty inferior.
@@Admer456 but i want to compile shaders at runtime, since generating them offline takes so much time because amount of shader permutations is larger than amount of stars in the universe combined?
@@SweetieSnowyCelestia You can still do that, glslangValidator can be used as a library too.
This Video Helped😅
wawawiwa! Great success!(My journey just started...gonna edit any update and if not...bye)
I at one point built a small engine on top of pygame, nothing fancy and probably really inefficient, but it has stuff i have used on most of my projects since. It’s to the point I am currently building a text editor and have imported a good portion of the engine lol.
This is great
I'm currently learning the Vulkan API and its really a lot of work to setup and stil no Triangle in sight...