Hey guys! Ardent Wilds, the game I've been working on for the last year(s) now has a Steam page! If you're feeling generous, please give it a wishlist, every bit helps
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" 😂
@@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.
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.
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'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.
@@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.
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.
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.
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.
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.
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 got a 2D engine I built over years expanding and improving all the while. I made it cause I didn't like any other engine I tried and I wanted the experience of making my own. At this point it supports open world 2D tile based games and 2D tile based level based games.
I'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
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.
Holy shit...I've created a game engine and didn't even realize it. I made a blackjack card game a while back, but while making it, I adapted the code so it could be used to make other games, like hold 'em and cribbage. It wasn't anything amazing, but you could make a table, make a deck, create different sized decks as well as define any set of ranks and suits, create players, implement different rules, etc. I never considered that a "game engine". It was just a card game app I made with multiple card games. Cool. :)
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.
@@draebobplayz yes, but... it's probably still gonna take a little while. I've decided to strip it off of its over-engineered-ness and try to keep it more focused, so maybe I can release it at some point. I'm still quite burned out from it, though. I worked on it some 2 months ago but couldn't keep going for more than about two weeks...
Finally, a fair video on this subject. My second job after a short one of game dev, was game engine programmer for somewhere around 2-3 years. It was the place where I learned tons of stuff. After that I went back to game dev and I felt like I was never learning at the same level. I had the same experience as you had with Unreal, I felt it was really slow for coding, it was killing my productivity because of big compile times, I was literally taking a break while it was compiling. On the other engine(it was not a small one - had most of the popular game engine functionalities, including fully functional editor), I was always opening the project directly with the debugger attached. Game Engine Programming is amazing, a lot of stuff is challenging, but highly rewarding. You can learn tons of programming and you can get in a lot of depth on a bunch of domains - if you want to learn physics you can do it, if you want to learn AI, you can do that too, if you want to design really big systems, guess what, you will have tons of chances.
I've 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 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.
@@purple781 Grab the source code, build a minimal set of assets to run the engine, and then just build on top of all that. Having some experience with modding the games helps a lot Ideally you would use a fork that cleans up & modernises the engine a bit, so that it runs well on modern systems and such. When I used idTech 3, I forked ioquake3 for instance The rest is just using the tools that work with the engine. For level design it's TrenchBroom and q3map2, at least if you're talking about idTech 3. 4 is a bit all over the place in that regard
@@sdsdfdu4437 Oh my, I either didn't see this or my reply got deleted I did use a few wikis and the idTech 4 Discord when figuring out that one, but idTech 3 was so simple I could either intuit it (from Half-Life modding experience) or figure out what something does by reading the source code
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.
@@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
To be very clear, a framework is not like a library. The main difference is, your code calls a library, a framework calls your code, so a game engine is a kind of framework similar to React (in the webdev world). Typically you can't use more than one framework at a time (try to use both Godot and Unity at the same time and you will fail), but you can easily use multiple libraries.
@@astroid-ws4py I suggest you read "Design Patterns Elements of Reusable Object-Oriented Software," a.k.a Gang of Four, one of the most influential books on modern software architecture over the last 30 years. Particularly on page 26, where they define a framework: "A framework is a set of cooperating classes that make up a reusable design for a specific class of software..." "...The framework dictates the architecture of your application. It will define the overall structure, its partitioning into classes and objects, the key responsibility thereof, how the classes and objects collaborate, and the thread of control..." Based on this definition, a game engine is a framework because it enforces structure on the code.
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!
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
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!
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.
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 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!
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.
If you create a Game Engine based on existing libraries and add a couple of your own libraries (for example, a graphical system or your own prefab system), then this sounds reasonable and fair, because doing everything from scratch is simply pointless and will took much years. So if someone decides to create a large games, use ready libraries in Development Game Engines. But if you want to create small simple 2D or 3D games, it makes sense to write everything from scratch. I want to create big and medium games. and I need the appropriate tool with the necessary libraries. If i want make own small games, i use SFML.
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.
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.
Passion is essential for driving creativity and motivation, but it's important to balance it with practical considerations. Spending too much time on a complex project like building a game engine can lead to burnout and hinder progress on your actual game. Focusing on creating a well-designed and enjoyable game should be the primary goal. Even if you use a pre-existing game engine, you can still showcase your skills through innovative gameplay, compelling storytelling, and high-quality visuals. Once you've established a successful game, you can explore engine development as a separate project or collaborate with others who have expertise in that area.
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.
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....
I'm in the process of making my own game engine in Vulkan, since I use OpenBSD, and no commercially available engine runs on it. Godot does, but it's half broken on the BSD's. Even at work we use an in-house game engine, because we target consoles, and the company has already been making video games before Unity was a thing, so we have lots of resources internally about making game engines from scratch.
I really wish there was something as simple as say : TONY HAWK PRO SKATER : I.e. 1)CREATE A MAP: CHAPTER ONE SET ; SO YOU CREATE THE FIRST “LEVEL” TRAFFIC (PEOPLE, CARS, NPC’S) INSTEAD OF RAILS, BOXES AND STAIRS, THAT ARE AVAIL YOU CAN ACTUALLY CREATE LIKE A CITY THAT YOUR “CREATE A PLAYER” CAN WALK AROUND IN. YOU CAN ALSO CREATE INTERATCTIVE NPC’S THAT U AS THE CREATIVE PLAYER CAN INTERACT WITH AS WELL AS LIKE (STAR WARS KOTR) WRITE IN THE DIALOGUE & THUS PUSH THE STORY FUTHUR OR PAY PHONES THAT RING OR JOBS THAT YOU CAN ATTAIN VIA ACCESIBLE BUILDINGS IN THE MAP YOU HAVE CREATED) CREATE A CHARACTER; CHAPTER 2 MAYBE YOU WAANA BE A RACE CAR DRIVER, A MOTORCYCLE DRIVER, A MOB BOSSS, A PRO SKATER, PRO BIKER BMX’R EVEN. A PRO BASKET BALL PLAYER OR A ROCK STAR) ALL IS AVAIL, IN AN OPEN WORLD STYLE) BUT BASICALLY YOU AS THE DEVELOPER GET TO CHOSE WHAT KIND OF STORY YOU WANT TO WRITE FOR THE CHARACTER, INCLUDING THE DIALOGUE & WHAT HAPPENS WITH EACH CHOICE MADE) C: WRITE THE STORY USING PROMPTS LIKE “HEROS JOURNEY” “VILLIANS DIMISE” “SAVE THE DAMSEL” “BECOME THE GREATEST” “HORROR” “SCI-FI UFO ALIEN TAKE OVER” “ZOMBIE APOCALYPSE” ECT… Basically following the intro, conflict, resolution, plateau, conflict,resolution, nearly giving up, conflict, climax, final resolution and ending. (_____/\__/\____/\____) Introduction ____ conflict / resolution \ plateau ____ nearly giving up__ / main conflict / climax \ final resolution__& ending. Basically having all this be done with out any source coding or complicated understanding of game developing as much as it’s done like how you build a park in THPS or creating a. Character in Fight Night or Knights of the Old Republic or Tony Hawks Pro Skater. Something that is simple, let’s you add the dialogue and pick an action. So if I wanted to create a mafia style game set in the 20, 30, 40 or 50’s I could choose that pack and work within it. If I wanted to create a zombie apocalypse based in the 60’s and my main character is loosely based on Janis Joplin or Jimi Hendrix, I could write it out and there is a pack for it. Or I want to build a game that is a smash up sci fi of terminator and rainbow six Vegas but based in the 80s and feels like The Wolverines fighting the red Communist there would be a pack for it. Or a Wild West setting zombie apocalypse and I can write what all the characters say, what they’re capable of and how the beginning, middle & end plays out, then I’m able to upload my game so that other people can play it and leave feed back or even add details and build onto it. Probably be a lot ugghhhh but it would be so rad and so fun and so much more than I’m actually understanding. Simple yet complex and innovative.
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.
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.
That's just depressing. With all the modern languages we have, engines, Udemy, UA-cam tutorials, cheap assets..etc I couldn't release a simple 2d platformer 🥺
It took me about 40 hours to get a first picture on my screen. 2D Game Engine written in C++ with an ECS. I stopped working on it a few weeks alter, because ... yeah I want to make a game and don't have unlimited time xD And since I want to make nothing super special, I don't need a custom Engine, Unity or Godot will do.
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.
you definitely can make a game engine rival unity or unreal with 1 dev or more but definitely less than 100. there are many "game engines" that equal to unity and unreal with mutiplatform support made by a single dev, if you watch game dev channels or Twitters you will know what I'm talking about. although it’s essential to recognize that unity and unreal extend far beyond your typical game engines. they encompass a wide array of things beyond what normal game engine would have, including 3D modeling, texturing, painting, film production, animation, motion graphics, , vr and xr, and more. so unity and unreal serve as comprehensive frameworks rather than mere game engines. now that framework would require 100 devs.
I am working on a 2D sandbox game. For some performance considerations, I am using my own "engine", if you could call it that. It is mostly an SDL wrapper to simplify things, with some basic systems to manage loading stuff, animations, etc, though it does have a game loop, and features get added as I need them. My biggest hurdle, honestly is finding graphics, since I am no artist, like... at all. I would say for 2D, rolling your own engine is probably fine, but for 3D I would most likely use an engine. The thought of attempting my own is painful.
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.
Game engines does not really do much. They are not doing rendering, they are not doing physics, they are not doing sounds - it's all done by 3rd party libraries, game engine just combine that. They don't do game logic - you do. We import models from Blender or AI. That includes animations. Soooo.. maybe level design? Yes, but as for universal engines are universal we have to have HUGE guidelines for level designer which consist entirely of "forget that this features exist in game engine, we are not using them, use this 3 features only or I'll hit you in the face, thank you!" So it might be better to start with your own location editor, so level design restrictions will be applied automatically. Because features which can break restrictions are not implemented at all.
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. )
I have made a WebGL renderer from scratch that could load obj files and textures and render them using basic shaders, fly around in the scene, and add some simple animations. Just to have done it once. But that was about all the time I want to invest into this topic. Otherwise I would suggest to choose a game engine if your goal is actually making a game in the end. Something more complex than a simple 2D platformer.
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.
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.
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.
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.
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 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.
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.
The answer is a resounding NO unless you have some very unique needs that go beyond 2d and 3d. You are MUCH better off spending your time on the actual game itself than on the tools. Should an artist go mine, grind, refine their own pigments before they start drawing? No, you should just get paints. If you spend 2 years working with, say, Unreal - you will know it's ins and outs just as well, and there will be more documentation because other people write that. And features come up much faster because several people work on it full-time, not just you. There is literally zero reason to make a proprietary engine.
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
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.
@@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.
Oftentimes, especially if you're an indie developer or a small company, the primary reason you'd make your own game engine in the modern day is simply for the prestige of doing so. It's rarely the most practical option, and probably shouldn't be your go-to solution if all you want to do is make a game. A game engine is an absolutely monolithic undertaking, not well-suited for novices. That being said, there are some advantages of using your own engine, obviously, licensing is no longer an issue, and you can fine-tune it to do exactly what you need it to do in the manner you want it to. Again though, you have to balance the pros and cons of undertaking a project like that, it'll be extremely time-consuming and you have to decide if that time cost is worth it. Godot is a great choice if you just want a small lightweight engine for 2D that's excellent for rapid prototyping. I'd go with that if that's what you're looking for, rather than creating your own engine unless you really want to/need to for some reason.
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 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.
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.
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?
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.
Hey guys! Ardent Wilds, the game I've been working on for the last year(s) now has a Steam page!
If you're feeling generous, please give it a wishlist, every bit helps
hey can you do a tutorial of making a game engine in 2024 please
Coding sloth is that you?
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
>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
@@bruh7237 he made cpu with integrated gpu that is actually good
Sounds like he had a great life to me
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.
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'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 ???
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.
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.
The youtube channel Called The Cherno is focused almost entirely around building game engines.
Yep!
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.
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.
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
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.
That thing about trying things differently and then understanding why the reasoning behind the convention hit home.
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.
This video cured my depression
How though?
@@davidrudpedersen5622bruh
Seriously how though?
I am depressed too
@@scorpysubb nah man u can't say that
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
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?
Holy shit...I've created a game engine and didn't even realize it.
I made a blackjack card game a while back, but while making it, I adapted the code so it could be used to make other games, like hold 'em and cribbage.
It wasn't anything amazing, but you could make a table, make a deck, create different sized decks as well as define any set of ranks and suits, create players, implement different rules, etc.
I never considered that a "game engine". It was just a card game app I made with multiple card games.
Cool. :)
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.
Hey, are you still working on this?
@@draebobplayz yes, but... it's probably still gonna take a little while. I've decided to strip it off of its over-engineered-ness and try to keep it more focused, so maybe I can release it at some point. I'm still quite burned out from it, though. I worked on it some 2 months ago but couldn't keep going for more than about two weeks...
Finally, a fair video on this subject. My second job after a short one of game dev, was game engine programmer for somewhere around 2-3 years. It was the place where I learned tons of stuff. After that I went back to game dev and I felt like I was never learning at the same level.
I had the same experience as you had with Unreal, I felt it was really slow for coding, it was killing my productivity because of big compile times, I was literally taking a break while it was compiling. On the other engine(it was not a small one - had most of the popular game engine functionalities, including fully functional editor), I was always opening the project directly with the debugger attached.
Game Engine Programming is amazing, a lot of stuff is challenging, but highly rewarding. You can learn tons of programming and you can get in a lot of depth on a bunch of domains - if you want to learn physics you can do it, if you want to learn AI, you can do that too, if you want to design really big systems, guess what, you will have tons of chances.
I've 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.
how do you use idtech like that?
@@purple781 Grab the source code, build a minimal set of assets to run the engine, and then just build on top of all that. Having some experience with modding the games helps a lot
Ideally you would use a fork that cleans up & modernises the engine a bit, so that it runs well on modern systems and such. When I used idTech 3, I forked ioquake3 for instance
The rest is just using the tools that work with the engine. For level design it's TrenchBroom and q3map2, at least if you're talking about idTech 3. 4 is a bit all over the place in that regard
@@sdsdfdu4437 Oh my, I either didn't see this or my reply got deleted
I did use a few wikis and the idTech 4 Discord when figuring out that one, but idTech 3 was so simple I could either intuit it (from Half-Life modding experience) or figure out what something does by reading the source code
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.
@@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 am extremely interested in seeing you create more engine-based videos or series. I would watch them all (probably multiple times)
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
What's wrong with C99?
@@amir32806 I never said anything was wrong with C99, just that there is some new stuff.
c and c++ diverged a long time ago, almost too different languages now outside of the smaller core syntax.
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
To be very clear, a framework is not like a library. The main difference is, your code calls a library, a framework calls your code, so a game engine is a kind of framework similar to React (in the webdev world). Typically you can't use more than one framework at a time (try to use both Godot and Unity at the same time and you will fail), but you can easily use multiple libraries.
Framework is more like a collection of libraries that were lumped together into one big monolithic library.
@@astroid-ws4py I suggest you read "Design Patterns Elements of Reusable Object-Oriented Software," a.k.a Gang of Four, one of the most influential books on modern software architecture over the last 30 years. Particularly on page 26, where they define a framework: "A framework is a set of cooperating classes that make up a reusable design for a specific class of software..." "...The framework dictates the architecture of your application. It will define the overall structure, its partitioning into classes and objects, the key responsibility thereof, how the classes and objects collaborate, and the thread of control..."
Based on this definition, a game engine is a framework because it enforces structure on the code.
@@tordjarv3802
Well thank you for the definition, I understand what you mean.
React is a library, tho
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!
would love to see follow up videos on this topic!
Seeing so many people starting to make their own engines is really inspiring . i wish i had the skills to do so though ..
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
Engine is a very loose term which gets misrepresented thanks to full on workshop applications like Unity, Unreal and Godot
@@ultimate9056 Ah, fair enough. We build our own using libraries like SFML or SDL and our own knowledge
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!
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.
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!
poggers
engine/build tools/tips&tricks series would be cool
This video was so nice, straight to the point, informative and fun, I hope this is going to turn into a series
also another big advantage of building your engine is: you're allowed to use any license you want
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!
The most comprehensive videos that point you in the right direction I have seen!
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)
If you create a Game Engine based on existing libraries and add a couple of your own libraries (for example, a graphical system or your own prefab system), then this sounds reasonable and fair, because doing everything from scratch is simply pointless and will took much years. So if someone decides to create a large games, use ready libraries in Development Game Engines.
But if you want to create small simple 2D or 3D games, it makes sense to write everything from scratch. I want to create big and medium games. and I need the appropriate tool with the necessary libraries. If i want make own small games, i use SFML.
I was thinking about this and I found this video on my recommended, Google’s data collection is insane
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.
There’s no game-industry event reason why I’m here.
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.
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
basic game engine = rendering + editor + physics + basic components (camera, light) + possibility to add custom scripts and assets
Passion is essential for driving creativity and motivation, but it's important to balance it with practical considerations. Spending too much time on a complex project like building a game engine can lead to burnout and hinder progress on your actual game.
Focusing on creating a well-designed and enjoyable game should be the primary goal. Even if you use a pre-existing game engine, you can still showcase your skills through innovative gameplay, compelling storytelling, and high-quality visuals. Once you've established a successful game, you can explore engine development as a separate project or collaborate with others who have expertise in that area.
Nice work PJ, was a very entertaining and informative video :)
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???
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....
I'm in the process of making my own game engine in Vulkan, since I use OpenBSD, and no commercially available engine runs on it.
Godot does, but it's half broken on the BSD's.
Even at work we use an in-house game engine, because we target consoles, and the company has already been making video games before Unity was a thing, so we have lots of resources internally about making game engines from scratch.
I really wish there was something as simple as say : TONY HAWK PRO SKATER : I.e.
1)CREATE A MAP: CHAPTER ONE SET ; SO YOU CREATE THE FIRST “LEVEL” TRAFFIC (PEOPLE, CARS, NPC’S) INSTEAD OF RAILS, BOXES AND STAIRS, THAT ARE AVAIL YOU CAN ACTUALLY CREATE LIKE A CITY THAT YOUR “CREATE A PLAYER” CAN WALK AROUND IN. YOU CAN ALSO CREATE INTERATCTIVE NPC’S THAT U AS THE CREATIVE PLAYER CAN INTERACT WITH AS WELL AS LIKE (STAR WARS KOTR) WRITE IN THE DIALOGUE & THUS PUSH THE STORY FUTHUR OR PAY PHONES THAT RING OR JOBS THAT YOU CAN ATTAIN VIA ACCESIBLE BUILDINGS IN THE MAP YOU HAVE CREATED)
CREATE A CHARACTER; CHAPTER 2 MAYBE YOU WAANA BE A RACE CAR DRIVER, A MOTORCYCLE DRIVER, A MOB BOSSS, A PRO SKATER, PRO BIKER BMX’R EVEN. A PRO BASKET BALL PLAYER OR A ROCK STAR) ALL IS AVAIL, IN AN OPEN WORLD STYLE) BUT BASICALLY YOU AS THE DEVELOPER GET TO CHOSE WHAT KIND OF STORY YOU WANT TO WRITE FOR THE CHARACTER, INCLUDING THE DIALOGUE & WHAT HAPPENS WITH EACH CHOICE MADE)
C: WRITE THE STORY USING PROMPTS LIKE “HEROS JOURNEY” “VILLIANS DIMISE” “SAVE THE DAMSEL” “BECOME THE GREATEST” “HORROR” “SCI-FI UFO ALIEN TAKE OVER” “ZOMBIE APOCALYPSE” ECT…
Basically following the intro, conflict, resolution, plateau, conflict,resolution, nearly giving up, conflict, climax, final resolution and ending.
(_____/\__/\____/\____)
Introduction ____ conflict / resolution \ plateau ____ nearly giving up__ / main conflict / climax \ final resolution__& ending.
Basically having all this be done with out any source coding or complicated understanding of game developing as much as it’s done like how you build a park in THPS or creating a. Character in Fight Night or Knights of the Old Republic or Tony Hawks Pro Skater. Something that is simple, let’s you add the dialogue and pick an action.
So if I wanted to create a mafia style game set in the 20, 30, 40 or 50’s I could choose that pack and work within it. If I wanted to create a zombie apocalypse based in the 60’s and my main character is loosely based on Janis Joplin or Jimi Hendrix, I could write it out and there is a pack for it.
Or I want to build a game that is a smash up sci fi of terminator and rainbow six Vegas but based in the 80s and feels like The Wolverines fighting the red Communist there would be a pack for it.
Or a Wild West setting zombie apocalypse and I can write what all the characters say, what they’re capable of and how the beginning, middle & end plays out, then I’m able to upload my game so that other people can play it and leave feed back or even add details and build onto it.
Probably be a lot ugghhhh but it would be so rad and so fun and so much more than I’m actually understanding.
Simple yet complex and innovative.
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.
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.
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 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, UA-cam tutorials, cheap assets..etc I couldn't release a simple 2d platformer 🥺
2:44 with the robot scene cracked me up haha
It took me about 40 hours to get a first picture on my screen. 2D Game Engine written in C++ with an ECS. I stopped working on it a few weeks alter, because ... yeah I want to make a game and don't have unlimited time xD And since I want to make nothing super special, I don't need a custom Engine, Unity or Godot will do.
I will be glad to see new videos on this topic!
I don't really have a reason to make a game engine, but I think it would be very fun to add features to a game engine as I need them
Great commitment to putting but pics whenever you say but
This was hugely helpful, would love a series of those
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.
you definitely can make a game engine rival unity or unreal with 1 dev or more but definitely less than 100.
there are many "game engines" that equal to unity and unreal with mutiplatform support made by a single dev, if you watch game dev channels or Twitters you will know what I'm talking about.
although it’s essential to recognize that unity and unreal extend far beyond your typical game engines. they encompass a wide array of things beyond what normal game engine would have, including 3D modeling, texturing, painting, film production, animation, motion graphics, , vr and xr, and more.
so unity and unreal serve as comprehensive frameworks rather than mere game engines. now that framework would require 100 devs.
I am working on a 2D sandbox game. For some performance considerations, I am using my own "engine", if you could call it that. It is mostly an SDL wrapper to simplify things, with some basic systems to manage loading stuff, animations, etc, though it does have a game loop, and features get added as I need them. My biggest hurdle, honestly is finding graphics, since I am no artist, like... at all. I would say for 2D, rolling your own engine is probably fine, but for 3D I would most likely use an engine. The thought of attempting my own is painful.
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.
Game engines does not really do much. They are not doing rendering, they are not doing physics, they are not doing sounds - it's all done by 3rd party libraries, game engine just combine that. They don't do game logic - you do. We import models from Blender or AI. That includes animations. Soooo.. maybe level design? Yes, but as for universal engines are universal we have to have HUGE guidelines for level designer which consist entirely of "forget that this features exist in game engine, we are not using them, use this 3 features only or I'll hit you in the face, thank you!"
So it might be better to start with your own location editor, so level design restrictions will be applied automatically. Because features which can break restrictions are not implemented at all.
Bro the on the other hand flipping stock photo got me by the balls 😂😂😂😂
You have a really cute cat as your logo. It will bring you much luck!
Thanks but it’s a sloth 🤣
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
Even if you don'take your own engine, I recommend everyone try to build their own tools at some point.
I want to make my own game engine simply for the sake of doing so, so I'm not questioning if I really want to.
I have made a WebGL renderer from scratch that could load obj files and textures and render them using basic shaders, fly around in the scene, and add some simple animations. Just to have done it once. But that was about all the time I want to invest into this topic. Otherwise I would suggest to choose a game engine if your goal is actually making a game in the end. Something more complex than a simple 2D platformer.
i admire your work so much, you’re a true inspiration!
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 absolutely adored all the images. Outstanding video and content!
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.
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.
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.
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.
amazing video! explains everything you need to get started very accurately :3
Nice ending
for me, a simple game engine/framework should implement these features:
- rendering
- physics handling
- input handling
- and asset loading
wawawiwa! Great success!(My journey just started...gonna edit any update and if not...bye)
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.
This was crisp! Keep it up man!
Me: "I would like to try making a game engine once, seems fun!"
UA-cam: "Well, do I have the perfect video for you."
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.
The answer is a resounding NO unless you have some very unique needs that go beyond 2d and 3d.
You are MUCH better off spending your time on the actual game itself than on the tools.
Should an artist go mine, grind, refine their own pigments before they start drawing? No, you should just get paints.
If you spend 2 years working with, say, Unreal - you will know it's ins and outs just as well, and there will be more documentation because other people write that. And features come up much faster because several people work on it full-time, not just you.
There is literally zero reason to make a proprietary engine.
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
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.
Oftentimes, especially if you're an indie developer or a small company, the primary reason you'd make your own game engine in the modern day is simply for the prestige of doing so. It's rarely the most practical option, and probably shouldn't be your go-to solution if all you want to do is make a game. A game engine is an absolutely monolithic undertaking, not well-suited for novices.
That being said, there are some advantages of using your own engine, obviously, licensing is no longer an issue, and you can fine-tune it to do exactly what you need it to do in the manner you want it to. Again though, you have to balance the pros and cons of undertaking a project like that, it'll be extremely time-consuming and you have to decide if that time cost is worth it. Godot is a great choice if you just want a small lightweight engine for 2D that's excellent for rapid prototyping. I'd go with that if that's what you're looking for, rather than creating your own engine unless you really want to/need to for some reason.
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.
Great video and explanations, thank you!
your channel is great education for me
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.
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?
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.
best 14 mins ii ever spent usefully