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

@GiantSlothGames

8 ай бұрын

This is the way. Free yourself from corporate greed!

@mesmodev

8 ай бұрын

Same lol

@Dailyfiver

8 ай бұрын

Literally same

@DINGOS30

8 ай бұрын

It really does send a message. What's stopping Godot, Unreal or any other software from doing it?

@TheNextDecade244

8 ай бұрын

​@@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" 😂

@GiantSlothGames

Жыл бұрын

haha true

@pieterpretorius1014

8 ай бұрын

just comment the living hell out of the code so you don't forget what it was used for

@Yesalter

7 ай бұрын

@@pieterpretorius1014I force myself to do that with xml documentation except I get lazy and put returns the object in the returns what

@skycaptain95

7 ай бұрын

Why would you build a 2D engine? Those were outdated 20 years ago!

@Mnmn-xi6cj

7 ай бұрын

@@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.

@anon1963

Жыл бұрын

ever heard of the cherno?

@knowlife4

Жыл бұрын

@@anon1963 Yep, been watching him for years, but besides him there are very limited options

@chaimadhaoifi

3 ай бұрын

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.

@goczt

7 ай бұрын

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?

@arthurmoyer2657

7 ай бұрын

@@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.

@goczt

6 ай бұрын

​@@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?

@gamerpedia1535

6 ай бұрын

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

@watchmytvjctechnology8448

5 ай бұрын

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.

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.

@GiantSlothGames

Жыл бұрын

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).

@ayoubbelatrous9914

Жыл бұрын

@@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.

@lydianlights

Жыл бұрын

@@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.

@anon1963

Жыл бұрын

@@ayoubbelatrous9914 what's your repo

@ayoubbelatrous9914

Жыл бұрын

@@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.

@pai64

8 ай бұрын

Like godot

@chaimadhaoifi

3 ай бұрын

can you help me please with an idea to create a game for elderly ???

This video cured my depression

@davidrudpedersen5622

10 ай бұрын

How though?

@jonanddy

9 ай бұрын

@@davidrudpedersen5622bruh

@nachorodriguez6380

9 ай бұрын

Seriously how though?

@GursimarSinghMiglani

Ай бұрын

I am depressed too

@scorpysubb

Ай бұрын

imagine being depressed, skill issue honestly

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 :)

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.

@sdsdfdu4437

8 ай бұрын

Using idTech sounds really cool, did you have any resources on getting started or did you just kinda dive in and figure things out?

@Admer456

8 ай бұрын

@@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.

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.

@GiantSlothGames

Жыл бұрын

This is definitely a good strategy!

@georgemoreas5410

7 ай бұрын

Feeding two birds with one scone

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.

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.

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

@GiantSlothGames

Жыл бұрын

Yep!

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

@crew_the3rd

10 күн бұрын

Good luck, hope you make some YT vids.

@curlydev2

9 күн бұрын

@@crew_the3rd Of course

This video was so nice, straight to the point, informative and fun, I hope this is going to turn into a series

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 am extremely interested in seeing you create more engine-based videos or series. I would watch them all (probably multiple times)

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.

You can do most C89 code in C++, but as you move into C99, C11 and C17 things becomes more interesting.

@nrwchd

8 ай бұрын

for newer C standard you gotta slap extern "C" to tell the C++ compiler to use C compiler instead

The most comprehensive videos that point you in the right direction I have seen!

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'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.

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 hugely helpful, would love a series of those

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

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.

@sournois90

Жыл бұрын

what's its name?

That thing about trying things differently and then understanding why the reasoning behind the convention hit home.

>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

@bruh7237

12 күн бұрын

what about making your own gpu

@element1111

6 күн бұрын

hello Jonathan Blow

@NotVoid0069

6 күн бұрын

@@element1111 what

I will be glad to see new videos on this topic!

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).

@GiantSlothGames

Жыл бұрын

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 😅

@KutluKanyilmaz

Жыл бұрын

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?

@polygnomial

Жыл бұрын

@@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.

@polygnomial

Жыл бұрын

@@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.

Nice work PJ, was a very entertaining and informative video :)

I absolutely adored all the images. Outstanding video and content!

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!

@GiantSlothGames

Жыл бұрын

Thanks so much man!

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

would love to see follow up videos on this 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.

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!

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

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!

This was crisp! Keep it up man!

Great video and explanations, thank you!

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.

@luckybutunlucky8937

10 ай бұрын

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.

@snesmocha

7 ай бұрын

@@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

@valblazeyt

6 ай бұрын

@@luckybutunlucky8937cuda is only for nvidia

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.

@joeharris9273

11 ай бұрын

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.

@xcoder1122

10 ай бұрын

@@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.

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.

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

Thanks a lot, very clear explanation, good job with the video

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.

@GiantSlothGames

Жыл бұрын

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.

@chainingsolid

Жыл бұрын

Theres also the book "Game Programing Patterns" by Robert Nystrom (free online)

poggers engine/build tools/tips&tricks series would be cool

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!

Great commitment to putting but pics whenever you say but

I was thinking about this and I found this video on my recommended, Google’s data collection is insane

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.

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.

@rmt3589

8 ай бұрын

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.

2:44 with the robot scene cracked me up haha

your channel is great education for me

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.

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.

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.

@platin2148

8 ай бұрын

Hmm so that means you can also use angle for rendering so that it might work on a other platform.

@nickgennady

8 ай бұрын

@@platin2148 angle???

wawawiwa! Great success!(My journey just started...gonna edit any update and if not...bye)

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.

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.

@GiantSlothGames

Жыл бұрын

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.

@obake6290

Жыл бұрын

@@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.

@Finding_Fortune

9 ай бұрын

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....

Me: "I would like to try making a game engine once, seems fun!" KZread: "Well, do I have the perfect video for you."

Bro this is awesome!!!

also another big advantage of building your engine is: you're allowed to use any license you want

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.

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

Huge video, thank you so much!

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.

2:01 There is a shooter game made in the warcraft 3 engine, such mods exist. XD At least a side scroller. Its insane how far modders have pushed the engine

Language: Jai or Odin. Or C with function overloading from C++, ideally coupled with some basic meta-programming because C still has some unnecessary failure cases and boiler plate requirements. I'd recommend Handmade Hero for learning how to do an engine the right way, even though the series is almost a decade old by now.

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 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.

You have a really cute cat as your logo. It will bring you much luck!

@GiantSlothGames

Жыл бұрын

Thanks but it’s a sloth 🤣

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.

@igorthelight

Жыл бұрын

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.

@CodeDibertzStride

7 ай бұрын

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.

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. )

@GiantSlothGames

Жыл бұрын

That sounds really cool actually. I'll have to check them out :D

@olbluelips

4 ай бұрын

cool approach

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).

@astroid-ws4py

Жыл бұрын

FWIW, You can always write GDExtensions to do the processing in there at the native level.

@wiktorwektor123

Жыл бұрын

@@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.

@jeffmccloud905

Жыл бұрын

you should consider using Unity and ECS/DOTS

@wiktorwektor123

Жыл бұрын

@@jeffmccloud905 Unity doesn't play well on Linux. Are you blind about 1st point?

@jeffmccloud905

Жыл бұрын

@@wiktorwektor123 Unity runs on Linux.

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?

I would like to remind people that Rollercoaster Tycoon was made by a solo dev in 2 years using 99% assembly.

@EnemyOTS

8 ай бұрын

That's just depressing. With all the modern languages we have, engines, Udemy, KZread tutorials, cheap assets..etc I couldn't release a simple 2d platformer 🥺

for me, a simple game engine/framework should implement these features: - rendering - physics handling - input handling - and asset loading

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.

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.

i need to master all of that

Thanks Slot. 😁

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.

@blackcitadel37

Жыл бұрын

Better go with raylib for that.

@PomuLeafEveryday

7 ай бұрын

​@@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

Nice ending

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

@platin2148

8 ай бұрын

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.

If you enjoy working on game rendering engines, good at it, and want non-gamedev salary, consider looking for a job in the adjacent area, CAD/CAM/CAE. I’ve been doing it for a decade now, and I still enjoy what I do at work. People in the CAD industry don’t usually use off the shelf game engines because the requirements are very different. CAD software doesn’t need asset pipelines, AI, dynamic weather, deferred shading or particle systems. OTOH, game engines weren’t designed to handle meshes with many millions of vertices, volumetric meshes (like tetrahedral ones), or CSG things (volumes bounded by Bezier or NURBS patches). Still, other than that the problem is pretty similar: both modern games and modern CAD/CAE need good looking realtime and interactive rendering of incredibly complicated stuff.

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

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.

@Admer456

Жыл бұрын

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.

@SweetieSnowyCelestia

Жыл бұрын

@@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?

@Admer456

Жыл бұрын

@@SweetieSnowyCelestia You can still do that, glslangValidator can be used as a library too.

So since I'm someone who loves more sound design rather then track arrangement, I would also prefer actually then being a designer rather than a programer. Thus, no custom engine from my side. I still find how ever a custom engine progammer quite calming at their work.

I saw a video of what game engine to use when you have no coding experience. And here, a step further: Make your own game engine! xD One of my ideas for a game is to explain in the game how to use the game engine to make games, simply because, yes, there are resources, but they are not centralized and don't give as much freedom to play with as W3C does with HTML.

i’m making a source-inspired game engine using c# and a sdl2 wrapper, i have a window with working images and audio which i made in 4 hours :)

best 14 mins ii ever spent usefully

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

@aronimo5800

11 ай бұрын

Rly hope u do the series about how do make a game engine in the video

Thanks, this video is very motivating! I want to do something niche, which is why I'm even interested. I want to re-implement and build on an old freeware game called Lunatic Rave 2. It's a clone of the arcade game Beatmania IIDX. There is another one available, but it is built in Java and no longer open source. I want to make one that's fully libre and built on C++ and OpenGL. What's really crazy is that the author of Lunatic Rave 2 has been approached about opening up the source of his old game... but he can't, because he lost the source code!

Successful indy games often revolve around a custom engine that does something novel. It'd be a nightmare trying to create games like Braid or No Man's Sky in Unity.

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?

Hi, turn it into a series!