When you talked about that feeling when you waste too much time watching movies or playing games and become hungry for being creative...i know that feeling very well and it's awesome that other people feel the same.
Wouldn't call watching movie or playing game a waste, it's spent time doing something you love and enjoy doing just like programming. Everything even coding can feel as a waste of time if you don't take a break from time to time.
I was writing my own game engine in C for about half a year, which was very, very interesting. Though it was actually more interesting to stick to the engine than to the game, it was supposed to run. As I found an interesting in computer graphics I am writing a software renderer currently. It's amazing to see what a graphics card actually does when you send your vertices and textures to it. *can totally recommend that*
@Dylan, if you are interested, I still have my, I coded for 3 months my engine video on my channel. And it's very nice to see your channel because it hits home.
I'm reading about game engine architecture and game maths, and it's an incredibly fascinating topic to study. I'm currently working on development of games in Unity, but I won't lie and say I wasn't interested in writing even a simple engine just to see myself render a 3D model myself and control it. that rewarding feeling of building something and watching it work is what drove me to study Computer Science in the first place.
It was very thoughtful to also mention the other side (why not to build an engine) in the end, since it often is the way to go if it is about making money. But as a learning experience / hobby, building an engine alongside a game is really fun and insightful.
8:28 to 9:36 encapsulates my entire philosophy. Sure, I don't _need_ to know 6502 assembly when I could be using Rust, but I sure as hell want to, and it would be Cool To Know.
I agree with everything you said, and yet I won't go for developing my own engine. One can easily get drown in this process, when what we actually want here is to deliver our games (MVPS) fast. Even if I will have to accept some engine's paradigm, that's a fair price for getting 100% concentrated on developing your game and not the engine. Besides, when it comes to releasing one game, your own engine or a wrap-up on some framework will do fine, you did the job, you released the game. When you have done it all and then you want to release another game, you will still have to make a lot of improvements to your engine, to widen it's usecases and to make it suit your new game needs. But if your first game was done via some complete and standalone engine, be it UE, GD or Unity, you will most likely be extremely efficient with it, no matter if you don't really like it's paradigm. Once again, I agree with you. Making your own engine is lotta fun and brings a lot of knowledge, I have been through it. But it just feels like we sometimes should accept the help from people who dedicate themselves to engine development and power our games by their engines. UPD: I just wanted to bring another side of the argument here.
I agree with you, that's pretty much how human society works. We rely on others work constantly, it's possible to just dive into the inner workings of games and programming until your death and never be done. While that's fine if that's your purpose. I don't see anything wrong with using an engine unless it just doesn't suit your goals.
@@ghosthunter0950 I'd argue that human societies need both approaches. Many elegant and efficient ways of doing things have been discovered because someone took the time to reinvent the wheel instead of using someone else's work.
Underrated comment right here. When you ignore half of Unity's features because you're making a 2D turn-based game it just becomes bloatware. Learning programming properly frees you from the shackles of general purpose engines
I notice that most that say don't create a engine did so as a starter project even though it's a quite advanced project. You need to know how other engines work and even make games in them before getting to the point of making your own. It's like never watching a movie before and trying to make a big production movie for your first one. It won't work unless your willing to learn everything that comes with a game engine.
Yeah, there are some big caveats. I made this video at a time where the whole of gamedev social media was flooded with "Don't make games from scratch - it's a waste of time." I just wanted to provide some counter arguments for why you may want to consider it.
I had been looking at making a game engine for some time but thought it was only possible to make on in c++ and just decided to keep using unreal but now I genuinely want to make a personal engine so me and my friend can understand it better from the ground up
You can make a game or engine from scratch in many languages, even JavaScript (see Crosscode on Steam) and Java (see Thinmatrix UA-cam channel). Good luck with your project 👍
You're absolutely right. We need to focus on what we need, and nothing more. Biggest mistake I made earlier in my journey was to make a "game engine" instead of figuring out what I actually need, and what would be the features, and most importantly limitations of the engine. The Total Chaos is a gorgeous mod created for the DOOM II engine. See it. It looks mindblowing and beautiful. It showed me that we can create great games with a very limited and simple game engine too.
Thank you for making this video, I personally felt very validated after watching it, you conveyed the pain and joy that comes with the endless search for more knowledge perfectly
I just switched my degree to CS; I was Electrical Engineering before. The passion for math, learning, & creation that CS has ignited in me is unlike anything I’ve experience before. It’s awesome. And the possibility of shaping my own game with my very own game engine pumps me up even more !
Ive tried to get into Unreal and Unity, but it feels like unnecessary complicated. On the other hand, SDL or SFML felt like I was in control, and I had way more motivation to finish my games.
I have not tried SDL myself, so I cannot speak to its usage from a personal perspective. However, many great 2D projects use it (it doesn't support 3D itself AFAIK, but you can probably write some custom extensions for 3D). If you want to get a 2D game up and running ASAP and not worry about writing a renderer - it's a lot of work - you may be able to use SDL and keep a lot of control at the same time as saving time.
@@DylanFalconer I'm working on a 3D game using SDL. Their renderer is 2D only but you can also not use that and just use SDL to create an OpenGL context the same way you would with GLFW. It can also create a Vulkan or Direct3D context and has some extra features like audio, timers, cross platform threads, etc. It's a very useful library and used by AAA studios. Valve uses it in a bunch of their games and I think even Steam itself uses it.
Whenever I get back into creating games after my two web projects are done, I'm certainly going to be making my own engine for it. I've found in general that sometimes it's really good to build most things yourself, because the in depth knowledge and understanding you gain is far more valuable than the end product you create, in this case a game engine. I applied the same type of thinking to my web dev projects, that when creating a blog & e-commerce site, instead of just using an existing CMS and e-commerce platform I built my own. It made me progress and "level up" as a programmer 10x as fast as when I used to do projects only using existing libraries and frameworks, because I gained an actual understanding of what I was doing.
I am writing an engine for side scroller bomberman using fully destructable fractal geometry. I fall under the "simulation heavy" category you touched on. Also, I hate being vendor locked. Or, locked into an IDE. Hypothetically Unreal dev doesn't need to be done with their IDE. But never seen anyone develop that way. And even if you __CAN__ you are still locked into being forced to install visual studio for the compiler. Ever try to compile a visual studio project from outside visual studio using the command prompt? Damn near impossible. Visual studio loads a whole bunch of weird state into the terminal it uses in the IDE.
Nice. Yeah I actually really dislike the VS build system. In recent years with Unity DOTS I think heavy simulations are more viable over there but haven't experimented myself! Good luck with your game!
I made a horrible mistake. After poking Unity for a few times I decided I need to figure it out from scratch. I have no proper background, I'm not even remotely a programmer and math made me literally cry when I was a kid, but I don't care because I can't stand doing something without understanding what's going on behind the scenes. I literally needed to understand, what lies beneath the «SDL_CreateWindow()» in order to calm down. Turns out, it literally is just boilerplate that you won't ever want to type nor can you change too much. Every time I googled something and tried to replicate it in unity I was like «is it the best thing? isn't RB controller an overkill? cuz it sure feels better than vanilla one, but it's physics. Also it can actually climb stairs of appropriate size without any code, why do people say it can't? and why are there no lessons of physics materials and everyone just sets them to be ultra slippery? how do I make bigger levels if I ever want to make a giant world? why is my empty project with a capsule and a few cubes 1.2 gigs in size? how detailed should my meshes be? why blender and unity have normal maps flipped? how do I make ragdolls? how do I load a custom collision mesh? how do I make something happen just once?». And sometimes there's just zero info. Like, how do I «properly» replicate RE1 HD graphics? I don't want to separately render and manually place cutouts of the pre-rendered BG in front of the camera like I'm building a scene for theater. I'm sure there's got to be a better way to just combine an image and frame of the game. And animator is hell even if you have just half a dozen of animations. It's already a pain in the ass and you didn't even get to contextual things like picking up a gun vs opening a door. Or animation layering. While all you want to do conceptually is «if A is pressed & not running -> play anim "strafe_right"». But instead you need to drag and drop and set up all kinds of crap in several menus to do it. And then repeat it for other animations. Or reinvent the entire thing in code. Or pay for the custom plugin. I'd rather have that feature for code actually. And ouside of unity. It's very helpful to see how your code literally flows from A to B. But while it works for things like shaders and SMs - I'm not sure how useful it is for actual code. Seems like it would be very limited.
You know I just watched another video released around a similar time and it was the person talking at you the entire time. All I could think is: you are discussing 5 different engines here and have not shown us a single screen shot of those engines, their UI or resulting semi-game you produced, which makes this video somewhat monotonous. This video is exactly what I had in mind as I sat watching the other. The examples and your points are well received, and kudos for your presentation. I am definitely in the "DIY game engine" group.
I'm building my largest game, from scratch, in my own programming language in Zig, and I agree with everything in this video. Some people use commercial game engines because they come with level editors... but if your game is simple enough, and you're a competent enough programmer, you can just create your own editor. Are there are huge positives: I know exactly how my editor works, and it is minimal since it only does what it needs to do. It also only took 1 month to program. Why spend years "learning" how to make a game in Unity when you can just make your own level editor in a month lol.
Yeah, at the time I made this video the general online landscape was "What? Make a game engine? Are you insane? What a waste of time." So I just wanted to provide a counter argument. I still maintain that people who aren't interested in programming should NOT try to make their own engines. Good luck with your game :) Will you release a demo?
@@DylanFalconer Absolutely, but not until after I've announced the game. (Which I intend to do this year, for a possible 2025 release.) It's gonna be big. (At least for a puzzle game.)
if its fun to you - go for it - to me, it was non-negotiable - using existing engine just wasnt fun, and didnt fit my needs either...it brought me many (3) work opportunities...realize that making an engine generally dwarfs what you would be doing in most corporate jobs...thanks to it im very confident in jobsearch, and i have never been turned down, and getting a good pay is easier too - as simple as saying "i have a proof" to any arguments...of course im still working on it, but honestly, getting much better as a programmer is enough (its also extremely fulfilling to build your own rendering pipeline, networking, and seeing it work) - best of luck to anyone reading this:)
Very very very very important video. Thank you. This is something I needed. And yes, I made it to the end :D. I am no more sure about working on my own engine
Man, I didn't realize that I was watching an emerging youtube channel :) a bit of feedback on this video; The video would be more interesting if you edited the transitions with some background music, BIG text with colored background and if you cut away the long pauses between sentences. I really recommend watching Mark Brown with GMTK to see what I mean. Good luck man!
I notice that most runaway indie successes are in fact NOT built with Unity or Unreal, despite the prevalent narrative that you should always use an engine (usually Unity) if you want to ship something. Minecraft is built entirely in Java. Fez and Stardew Valley are made with XNA Framework. Angry Birds was made from scratch, probably in Objective-C. Bindings of Isaac was made in Flash, and the second from scratch in C++. Divinity Original Sin was made with a custom C++ engine and .NET tooling. I couldn't find what Hades was built with but their previous titles were built with XNA/MonoGame. Going with your video, I learned that Deadcells was not made in Unity either. I'm not saying it's a direct cause and effect, there's a lot more than engine choice that goes into a game success, but this is interesting nonetheless. Personally I write my game from scratch in C++ because the project's scope is small enough that it's not a huge leap from using Unity, and I get to own the whole thing, which as a programmer is a lot more motivating for me than using Unity.
One stand-out example of a great and successful indie title which uses Unity is Hollow Knight. That game doesn't need to do anything too ambitious in terms of performance, only having a few things happening at any time. They could afford to focus much more on art, design, game-play, etc, because of their scope. Another great example made with Unity is Oxygen Not Included. However, they have the opposite problem, where they can't push out enough performance with the engine (or perhaps it's just not a priority for them - can't say for sure), so they limit their map size and the longer you play, the slower things run. Either way, if you want to be a better programmer, then making your own engine is the right path to go down. If you want to focus on other aspects of game development (design, story, lore, art, animation, etc), then I'd only recommend rolling your own with a very limited scope, or just using an engine.
I wouldn't say most, you're nitpicking a bit. There's many popular games made in unity. Valheim is a good more recent example, Cities: skylines, INSIDE (spiritual successor to limbo,) super hot, hearthstone, hollow knight, ori and the blind forest, DUSK, enter the gungeon, cuphead, subnautica, android version of temple run, outer wilds, return of the obra dinn, pillars of eternity. Those are some I wrote down. There's many more. As for games made without a popular engine, a few more are dwarf fortress (which inspired Minecraft quite a bit,) shovelknight, factorio, noita, teardown, foundation, darkest dungeon, guacamelee, terraria (xna), and the HD spelunky remake, to list a few. It really depends on what you enjoy doing, the engine doesn't really matter. I enjoy using Godot engine, and can work quickly in it, but I'm still quite interested in making a game without an engine. Sites like gameprogrammingpatterns.com are useful for ideas on how to structure a game.
Imo the reason why you see a lot of these custom built games succeed compared to a sea of failed projects made with the huge engines comes down more to the fact that someone that is able to create a game like Minecraft, Stardew Valley, Braid, The Witness themselves from scratch already has a higher level of skill and experience than some kid or hobbyist trying to make something in Unity. So I think it's more of a correlation that people or teams with custom built engines are more skilled and therefore succeed more often than that being the actual cause.
Thank you for this video. I'm tinkering with xna/monogame rn trying my best to design a coherent drag and drop manager that I can plug in various contexts. I've been in and out of gamedev as a hobby, and recently went back. Wondering if I'm just dumb for thinking I actually want to do my own engine for fun. I always bounce when using an engine for feeling like I don't have fun with them Unity and Godot never clicked in me. When I wanted to do something fun, I got stuck learning the tool, instead of learning how to actually do the thing I want. I used both to some extent. And that feels like is not my lack of knowledge as a software engineer, but as a "unity/godot developer" specifically Also I don't have a game in mind, I never do really. But I have ideas I want to implement because it seems fun to learn how to implement it, it make so much more sense to just write my little sandbox and have fun. Thank you
I’m no programmer but I like the idea of having my own game engine mainly because you have your own ui know how everything works and own splash screen best part you don’t have to pay for any features
This actually made me really confident in myself to make my own engine, I have tried unity in unreal, it's just these one things like 3d modeling or 3d modeling and the code not working because they made it so complicated and none of the tutorials work(that was long) but this has given me confidence knowing that I might just succeed, and gave some very useful tips, this video is awesome and helped me alot. Time to get to work! Edit: Turns out I'm not gonna make a game engine, but once I return to unity what I can do is modify it by adding my own scripts, it's sorta like I control the game engine in a way Edit: I'm now normally using unreal now
@@GDT-Studio BUT, there is a plot twist, when my game releases in future updates I am gonna add a sandbox mode that is basically a simplified game egine for pc and console.
This video was very informative but the lack of energy in the way you presented the info made it hard to not fall asleep or to just loose interest. So, up the energy and keep up the good work
Sadly there I was never able to find a 3d rendering framework that is super simple to set up like raylib and proviedes great graphics out of the box like unreal engine for example. Im trying to create something like that myself now and i realy hope im able to pull it of...
Good example is unreal where I can’t even render a texture on screen (for debugging) without using built in canvas that can only be used if you inherit a certain class and can only be used in 1 function.
I use a game engine because it helps me with a lot of things and i can actually focus on making the game. But I will try some day to make my own engine.
i'm in the process of finishing up my 2d engine, and this is what the development has looked like: 70% of dev time: building up the engine 10% of dev time: writing game logic 20% of dev time: making the resources a game engine (especially a solo-devved one) is a person's brain-child
I like the idea of doing this in any language that I prefer. Perhaps Go is my favorite. But I am wondering about porting to Android for example. It could be a big headache.
Well, you can write native mobile apps in Go, though I have no experience with it myself. As long as your game can run in Go, if that's what will bring you the most joy to work with, I say go for it! I found some examples and documentation here pkg.go.dev/golang.org/x/mobile/app
SDL is not particularly high-level, its point is portability between different platforms, so you don't have to write separate, specific code for handling window/frame instances, sound etc. for every environment. If you want extreme portability, I would recommend SDL+OpenGL 2.1 and doing everything in 32-bit ;-) OpenGL 2.1 works on old graphics cards to the point beyond which nobody cares.
It always a struggling for me to decide make my own engine or use existing to make my games, and I end up using existing engine. and idk which library to use for making it
I'd say it really depends what you want to do. If you want to focus more on publishing games rather than becoming an expert programmer, then it's probably best to use an engine if your game idea will work well in one of them.
Yea UA-camrs use engines to make thery game but neaver make thery own i like seeing people make game engines its nice went to make my own game engine ones i gat a laptop and learn codeing
@@FourSeven47 I think Temple OS is very impressive and its a great work to motivate others by. I don't think it's very usable for regular tasks, though I haven't tried it myself.
People can choose to focus on building your game or your engine. But remember, eventually gamedev is a business, you need to delivery something at some points for profit. If it’s not for profit then the fun path to research open up to everyone anytime.. as a hobby.
I'm facing this reality myself at the moment. Though it does depend on your skill level. A skilled professional programmer could create underlying tech much faster than those of us who need to learn everything from scratch.
@@DylanFalconer I think it's rare to have someone who can both forge well-designed gameplay and technical skills. But good technicans mostly learn from great designers like Nintendo. Replicate the mechanism with their great engineering and add up their own things from there. I just feel like I have to point this issue out to all indies, as most don't know what they are building and what they may get as result.
I don't know about Unity because I have never used it, but Godot and Unreal are both opensource Engines that you can modify to work in a way that you want them to. Thus not really suffering from some of the points you mention. Though Unreal is severely heavily bloated to the point that if you were to make an 8bit, 2D scrolling shooter in UE5 you would need a modern computer to run it, while making the same 8bit, 2Dscroller in something like Phaser3 (Another open source engine) will run on a potato.
How easy are they to modify? Do you have any examples? Depending on your scope that may be way more work than just creating something. Yeah, Unreal's target audience isn't people that want to make 2d games so that's fine. It's up to us to pick the best tool for the job.
@@DylanFalconer I've not tried modifying any of the engines, I just know that they are. Editing someone else's code is always going to be harder than making your own, it is just the way it is. It's also a skill you are going to need if you ever want to work in a team.
No idea what Dylen thinks, but imho yes. Finishing a game, especially 3D, is already hard enough. You can implement the basics like rendering the teapot in OpenGL if you want to learn, but for a typical solo dev, especially if you're not very experienced, it's really a huge amount of work. The benefits of using the engine far outweigh the limitations. There are some cases where it might be needed like that non-euclidean game, but for typical games you'll be fine with engines, really.
I hate when people say that watching movies or playing games is a waste. It's spent time, not wasted time and it's spent doing something you like and enjoy like watch some movie or play some game or do some programming project. Also about that feeling that you are wasting your time that happens when you do too much of something no matter what it is. For example if you spend a lot of time on coding then your brain will make you feel that it's pointless and a waste in order to make you take a break and something else, all because the brain wants diversity.
Hi, I am a Python beginner, here asking if you can please build for the public an open source Python application that will convert our Python script close as possible into purely a Javascript code basically making it 1000* times easier for the vast majority of people to develop Javascript applications to quite an extent, therefore... we can have the best of both worlds. It doesn't have to be anywhere complicated like a 3D game engine, Thanks.
@@SnakeEngine C compilers give errors when trying to pass the wrong type to functions. If you mean the fact that you can convert any pointer type to any other, what's wrong with that? What OOP features do you think are worth exploring?
So that you can fine tune that wheel to exactly fit and work your car alone, instead of having a generic wheel that may not work for your car and isn't easy to edit
@@GlacialSkyfarer sounds good in theory. In reality, unless you are making something like no men's sky or teardown etc. You wont need a custom engine and any mainstream engine would most likely cover your needs.
@@rytif Nice one again. The fact remains. If you want to embark on a programming journey and you are only after knowledge with the resulting game being an afterthought, build it from scratch. If you actually want to make a non-trivial game and deliver it in any realistic amount of time, use an engine. Engine bloat and build times don't matter if the actual making of the game takes a 1000 times less time to do by leveraging an engine. AAA games from enormous companies don't reinvent the wheel every time. A solo dev with not even 0.0001% of their time and resources shouldn't either.
@Mr30friends 1st of all you're assuming everyones a solo dev 2nd there are some pros of making your own engine some very reputable games use a custom engine for example ff14 and destiny. Just because it saves time doesn't mean using a pre built engine is the defacto option lol
I have seen many indy/hobby game developers falling down the rabbit-hole of building their own engine. Getting stuck in mucking around it for years, and never actually building a game from it. Bottom line: DONT develop your own engine if you actually want to make a game. Only build one if you are interested in the tech behind rendering, physics etc, but not if your goal is to make a game. If you want to make a GAME: have a look at Unity or Unreal first, those serve 95% of all game development needs, and you can actually get stuff done. In the case of Minecraft: it was made before convenient consumer-grade game engines where popular, and Notch was not some inexperienced Indy, but worked on several game engines before and had an extensive backlog of knowledge how to build them.
I agree, if you think your game project can be done in Unity or Unreal and you only care about making and releasing a game, then do not build your own engine. If you do decide to build an engine, there are many libraries which can make your life easier. Most people who build engines don't want to write physics libraries, so they use something like Bullet. Rendering is usually the meat of the engine, so if you can find a rendering engine you like, and it suits your needs, use that. Good luck out there!
I think it's worth mentioning that Unity and Unreal are not very suitable for certain types of game, and in such cases you may still want to consider building your own engine. E.g. citybuilders or games like factorio, since the standard engines cannot cope with so many entities as efficiently, and the engines are too bloated for those kinds of games. This is also what Dylan mentioned, not being able to optimize past a certain point. Also these standard engines don't really work well if you want to do things like random level generation or very procedurally generated games.
@@vortexbuffer5892 I dont know Unreal well enough, but in the case of Unity, there is a lot that can be archived with custom systems and workarounds. A beginner might naively drag objects into a scene, and then run into performance problems at one point. But for example implementing a game like Facturio is quite possible, when separating the gamelogic from the object rendering, and using combined meshes for LOD (zooming out in the map). You could literally simulate and display thousands of separate machine elements in a scene. The same goes for procedural level generation. All possible in Unity (I did implement a large scale terrain and structure generator). Meshes can be create in Unity quick enough for realtime procedural generation. A custom engine might have some performance edge in those specific scenarios, but those parts are only a small part of what else a game engine must implement. Outside of edge cases (very specific hardware support, 64k demos, very specific world simulations, or high budget AAA productions) I dont see any typical game that could not be implemented in Unity. Its often just a question of how experienced the developer is in creating custom solutions.
@@oliverb.8995 I'd recommend checking out The Cherno's playlist. This is for C++ ua-cam.com/play/PLlrATfBNZ98dC-V-N3m0Go4deliWHPFwT.html If you want to use something closer to plain C, perhaps check out Handmade Hero ua-cam.com/video/Ee3EtYb8d1o/v-deo.html
Making your own engine when you wanna make just your game is the same as forging your own steel when you just wanna build your own car. Just buy existing parts and modify it to your needs. You don't need to do everything from scratch.
@@DylanFalconer You can make your own game engine if you want to learn more about it but it will slow down development of your game. If you wanna make a game, make a game. You can clearly learn concepts like pathfinding, physics, etc. and use existing libraries implementing it instead of spending time doing the same work again. There are so many concepts and features in game engine that you need several years to explore and reimplement them. Back in high school I built my own OS from scratch. Spent several years on it. Now I can say it was great experience and I learned a lot but what I really wanted was just my own linux distro from scratch instead of writing kernel, bootloader, drivers and so on. Being a good programmer is 90% theory 10% execution. Everybody can write bunch of ifs but you need to know a lot of software architecture, design patterns and the ideal solutions to problems you are trying to solve. Its' great that you can write matrix transformations, collision physics and so on from scratch but when your architecture is a mess then it didn't make sense to implement it from scratch in the first place. You can learn architecture of the software by reverse engineering opensource projects, reading and implementing it.
@@just-jiu I've worked in unity and pygame over the last two years and the learning curve is the bane of either. The thing about unity is, if you KNOW unity and your game leverages all the tools it provides, then yeah its great. More than half the people who ever read this comment will use a fraction of the tools it provides, then have a massive engine overhead filled with memory leaks. After working with pygame for two years now, my last game jam made a comparable product to the unity game jam I did a year ago. It did not slow me down in the slightest because I never used half of what Unity offered back then. I can say that the pygame ran on my cousins 300$ school laptop w/ duo core celeron CPU, increasing my potential market by a wide margin. Meanwhile I have to restart Battletech on my 3060 after 2h of gameplay because memory leaks in Unity are still prevalent, even with Paradox's professional team of developers.
This is exactly what we're told not to do in the gaming industry, when starting out. Starting out, first thing you learn is that one person can't do everything, because one person just isn't good "enough" at doing everything, but everyone has a strength, things they are good at, and things they are not. When you learn the trade, and become part of a team, that team gains experience by having successfully developed products in the past. Only when you have the experience, should you consider creating your own game engine, as if "games" themselves were not expensive enough to produce, "game engines" are a whole other set of problems to overcome.
I understand the sentiment, and I haven't released a game yet, so perhaps I just don't have the experience. However, programming a game and a game engine are pretty much the same thing. The widespread use of third party engines is a relatively new event. Most games before the 2000s were build with custom engines. A custom engine does not mean that it has to be a general purpose solution for every conceivable problem - and usually they are designed specifically for a particular game. Unreal Engine was initially created for the game Unreal and designed specifically for first-person shooters. You can still see the legacy of that today when using the engine to build a game (or at least you could last time I used UE4). If you are worried primarily about expense, then we are talking about different things. I'm talking about personal achievement and wanting to do something difficult because it's fun to challenge oneself.
New To programming, like python, tried HTML/CSS/JS web pages not My thing, now learning UE and yes, it feels like bending a mental pipe, maybe I should try make python engine :)
If you are interested in python gamedev check out DaFluffyPotato here on YT, he has some good content with PyGame. Good luck! ua-cam.com/channels/YNrBrBOgTfHswcz2DdZQFA.html
I think you are arguing one point here and then another point that contradicts the first which seems to be common with these types of videos. You say an advantage of using a framework is that you get to choose the language (to be able to choose the most productive language I take it as what you mean). Then you say that a disadvantage of using Unity is that it uses a garbage collector and that is slow. But pretty much all languages use a garbage collector except for C/C++ and Rust. So the second point means you would have to choose one of those for performance and then you may just as well choose C++ and code in a game engine. And in reality it would take you many years of work to achieve the same performance as UE or Unity (with the data oriented pipeline at least). Wouldn't the best be to learn to live with those engines, quirks and all, and perhaps supplementing with making a game in a framework such as SDL to learn a bit of the foundation? This is assuming you want to make a complex game at some point. For simple games anything seems good enough.
I disagree on turning off the phone with deep work, but I do recommend turning off useless notification and unsubscribing from all non essential emails. I hardly get notifications unless its important
This argument, of course, only works if you're a decent programmer who is capable of making an engine with a good performance and cross-platform support, and you have time. Otherwise, you pretty much have no other options. That being said, why don't y'all check out this really cool Rust (🚀) engine called Bevy?
I believe i added those caveats in the video. If you aren't interested in programming then you probably shouldn't try to build your own engine. You can get decent cross-platform support with a few libraries - depends what platforms you are talking about. What's cool about Bevy?
Everyone keeps saying that but i find it so damn stupid. The time you need to make something like an engine can be used making actual games. The amount of open sourced engines already out there with basicly all the work already done is staggering. So if an engine doesnt fit your need, which i highly doubt since there is always an engine for everything, you could judt contribute to already existing engines. Unless software engineering is the path you want
Don't forget to talk about the crazy ordeal that crosscode had to do to port their games to other platforms... building a game engine, while a big learning process and powertrip for some is completely useless nowadays if your goal is to make a game, any game engine can make any type of games or rendering, yes it is bloated and have many many stuff that is irrelevant to your project, but whatever at least the system is there if you ever need them because flexibility is an important part of gamedev. Just for the building part and porting and engine is juste a bless, otherwise good luck reading the white papers and getting all the waivers and engine approved to ship a build on xbox/switch/ps. Even if you don't plan on getting out on these platform it's still comforting to know it's a possibility. Furthermore you can in fact strip unity of almost everything and use low level coding if you want, i know a friend did this took him 4 years and still haven't even came close to release anything, but hey he still can build on every platform with his heavily modified personal unity version.
I followed CrossCode's development from when it was a tech demo on the impact.js forums. That was back in 2012. It would be another 6 years before Unity 2D was released, and 5 years until Nintendo Switch was released. While I agree with your sentiment that platform porting is made easier for a lot of games using 3rd party engines, in this case, there was no way to foresee that Switch would not support HTML5, especially since the Wii U did support HTML5 games and came out around the same time as CrossCode started development. I can't speak about stripping out Unity's features. Sounds like a nightmare, though. Is your friend able to directly use C++ for gameplay code, or must he use C#?
@@DylanFalconer No he's not using C++ tho it's still in C#, but basically from my limited understanding he's basically gone full ECS way before ECS was even in the mind of unity, so he stripped everything useless from game objects, cameras, animations, rendering and everything except the IL2CPP compiling and platforms build. making his game run in like .1 second while pressing play, and crunching the build size like crazy. but like he's a genius really, a mathematician capable of reading and writing assembly code, a good mentor on many aspect of a prod. but nonetheless this kind of overextended controls kinda hurts a lot during development, I mean this is basically saying you cut all extra fat, but you have to do everything almost from scratch as well ... which is really not time efficient if you're on a budget
Are you referring to the short essay about building games and finding reusable pieces as you build more and more? I'm not proposing that everyone build their own general purpose competitor to the big 3. In fact in my engine series on this channel I outline that the engine is designed for a particular game, it's not a general purpose amalgamation of features that may or may not be needed stitched together - which is what I think people imagine when they hear the term "Game Engine".
Reason #1: You hate money and profit and only write code for fun. Reason #2: You have too much time on your hands and decide you want to create Wheel 2.0
Nearly all games were built without 3rd party engines until recently. Even these days, people choose to write their own engines for their games. Some examples include: Stardew Valley, Minecraft, The Witness, Equilinox, Amnesia, Fez, et al. Many of these examples are solo Devs, too. As for whether I'm aware of the time and difficulty, I have been working on my own engine and game for 5 months so I have some incomplete picture. It is very difficult and time consuming, but if you have passion for something then you enjoy the challenge. If you are wanting to make an engine like Hazel, then you are probably not wanting to ship a game anytime soon. Hazel is designed as a general purpose engine which can be used to make many types of games. Most engines are built to solve specific problems and therefore take less time and effort. If you do not want to make your own engine because you just aren't interested that is totally fine. Many successful and high quality games are being released via 3rd party engines. Good luck!
Time and difficulty to build your own game engine is relative to what you are trying to accomplish. If you are looking to make the next Battlefield game, then expect to spend years writing your own version of Frostbite Engine. For someone making Space Invaders? The task of making a game engine is much simpler, and very achievable by a solo developer. The key is to understand that not everything needs to be written from scratch. Even Hazel isn't fully from scratch. That engine leverages a fair amount of vendor code Box2D, Entt, ImGui, GLFW, and more...
UA-camrs only makes videos on why to make a game engine never make how to make a game engine
I'm glad you brought that up. That's exactly what I've been working on for the last few weeks. Stay tuned 😃
You........are.........
Unable
Don't keep liking, just comment it forward, and get the answer, that's the power of users
@@DylanFalconer Good lie
@@DylanFalconer is it ready?
When you talked about that feeling when you waste too much time watching movies or playing games and become hungry for being creative...i know that feeling very well and it's awesome that other people feel the same.
Wouldn't call watching movie or playing game a waste, it's spent time doing something you love and enjoy doing just like programming. Everything even coding can feel as a waste of time if you don't take a break from time to time.
" it's awesome that other people feel the same."
actually, its a bit sad lol
@@igorgiuseppe1862 How is the drive to be creative sad?
@@igorgiuseppe1862 your preference about human collective instinc is sad bro.
I was writing my own game engine in C for about half a year, which was very, very interesting. Though it was actually more interesting to stick to the engine than to the game, it was supposed to run.
As I found an interesting in computer graphics I am writing a software renderer currently. It's amazing to see what a graphics card actually does when you send your vertices and textures to it.
*can totally recommend that*
@Dylan, if you are interested, I still have my, I coded for 3 months my engine video on my channel. And it's very nice to see your channel because it hits home.
I'm reading about game engine architecture and game maths, and it's an incredibly fascinating topic to study. I'm currently working on development of games in Unity, but I won't lie and say I wasn't interested in writing even a simple engine just to see myself render a 3D model myself and control it. that rewarding feeling of building something and watching it work is what drove me to study Computer Science in the first place.
It's a rewarding feeling for sure. Sadly, one has to temper the seeking of knowledge with the practicalities of life
It was very thoughtful to also mention the other side (why not to build an engine) in the end, since it often is the way to go if it is about making money. But as a learning experience / hobby, building an engine alongside a game is really fun and insightful.
8:28 to 9:36 encapsulates my entire philosophy. Sure, I don't _need_ to know 6502 assembly when I could be using Rust, but I sure as hell want to, and it would be Cool To Know.
Yeah, curiousity leads us down interesting paths
I was wrong about Heaps.io. Upon further examination, I would consider it to be an engine.
Wot! Someone admits beign wrong In interwebz...
I agree with everything you said, and yet I won't go for developing my own engine. One can easily get drown in this process, when what we actually want here is to deliver our games (MVPS) fast. Even if I will have to accept some engine's paradigm, that's a fair price for getting 100% concentrated on developing your game and not the engine. Besides, when it comes to releasing one game, your own engine or a wrap-up on some framework will do fine, you did the job, you released the game. When you have done it all and then you want to release another game, you will still have to make a lot of improvements to your engine, to widen it's usecases and to make it suit your new game needs. But if your first game was done via some complete and standalone engine, be it UE, GD or Unity, you will most likely be extremely efficient with it, no matter if you don't really like it's paradigm.
Once again, I agree with you. Making your own engine is lotta fun and brings a lot of knowledge, I have been through it. But it just feels like we sometimes should accept the help from people who dedicate themselves to engine development and power our games by their engines.
UPD: I just wanted to bring another side of the argument here.
I agree with you, that's pretty much how human society works. We rely on others work constantly, it's possible to just dive into the inner workings of games and programming until your death and never be done. While that's fine if that's your purpose. I don't see anything wrong with using an engine unless it just doesn't suit your goals.
@@ghosthunter0950 I'd argue that human societies need both approaches. Many elegant and efficient ways of doing things have been discovered because someone took the time to reinvent the wheel instead of using someone else's work.
Build your own engine to make your game. Don't build a general purpose engine for others to make theirs.
Underrated comment right here. When you ignore half of Unity's features because you're making a 2D turn-based game it just becomes bloatware. Learning programming properly frees you from the shackles of general purpose engines
I notice that most that say don't create a engine did so as a starter project even though it's a quite advanced project. You need to know how other engines work and even make games in them before getting to the point of making your own. It's like never watching a movie before and trying to make a big production movie for your first one. It won't work unless your willing to learn everything that comes with a game engine.
Yeah, there are some big caveats.
I made this video at a time where the whole of gamedev social media was flooded with "Don't make games from scratch - it's a waste of time."
I just wanted to provide some counter arguments for why you may want to consider it.
I had been looking at making a game engine for some time but thought it was only possible to make on in c++ and just decided to keep using unreal but now I genuinely want to make a personal engine so me and my friend can understand it better from the ground up
You can make a game or engine from scratch in many languages, even JavaScript (see Crosscode on Steam) and Java (see Thinmatrix UA-cam channel). Good luck with your project 👍
Make an in game level editor, might give you a taster before committing to the whole hog.
I've been thinking about this too. I was looking at my utils library and decided a full framework would be a great next step.
You're absolutely right. We need to focus on what we need, and nothing more. Biggest mistake I made earlier in my journey was to make a "game engine" instead of figuring out what I actually need, and what would be the features, and most importantly limitations of the engine. The Total Chaos is a gorgeous mod created for the DOOM II engine. See it. It looks mindblowing and beautiful. It showed me that we can create great games with a very limited and simple game engine too.
Thank you for making this video, I personally felt very validated after watching it, you conveyed the pain and joy that comes with the endless search for more knowledge perfectly
I just switched my degree to CS; I was Electrical Engineering before. The passion for math, learning, & creation that CS has ignited in me is unlike anything I’ve experience before. It’s awesome. And the possibility of shaping my own game with my very own game engine pumps me up even more !
This guys like a Game Dev Guru. My creation positivity went thru the roof after watching. Keep making videos
Ive tried to get into Unreal and Unity, but it feels like unnecessary complicated. On the other hand, SDL or SFML felt like I was in control, and I had way more motivation to finish my games.
I have not tried SDL myself, so I cannot speak to its usage from a personal perspective. However, many great 2D projects use it (it doesn't support 3D itself AFAIK, but you can probably write some custom extensions for 3D).
If you want to get a 2D game up and running ASAP and not worry about writing a renderer - it's a lot of work - you may be able to use SDL and keep a lot of control at the same time as saving time.
@@DylanFalconer I'm working on a 3D game using SDL. Their renderer is 2D only but you can also not use that and just use SDL to create an OpenGL context the same way you would with GLFW. It can also create a Vulkan or Direct3D context and has some extra features like audio, timers, cross platform threads, etc.
It's a very useful library and used by AAA studios. Valve uses it in a bunch of their games and I think even Steam itself uses it.
@@weirddan455 That's a good point, there are a bunch of extra features in SDL compared with GLFW.
Why nobody remembers Allegro :'{
funny joke ever
started learning c recently without any background in programming, this video is very reassuring
Whenever I get back into creating games after my two web projects are done, I'm certainly going to be making my own engine for it. I've found in general that sometimes it's really good to build most things yourself, because the in depth knowledge and understanding you gain is far more valuable than the end product you create, in this case a game engine. I applied the same type of thinking to my web dev projects, that when creating a blog & e-commerce site, instead of just using an existing CMS and e-commerce platform I built my own. It made me progress and "level up" as a programmer 10x as fast as when I used to do projects only using existing libraries and frameworks, because I gained an actual understanding of what I was doing.
Love the philosophical approach near the end. Greetings from Germany 🇩🇪
@wal oody I am thinking about moving to Germany should I
@@XxOlliePlayzxX where are you living rn? Germany is going through rough times... to be honest, I thought about leaving Germany several times by now.
@@AlphAndroiD I am living in attalla Alabama
actually working on an inhouse framwork and this is very helpful video thanks
Glad it was helpful!
I am writing an engine for side scroller bomberman using fully destructable fractal geometry.
I fall under the "simulation heavy" category you touched on.
Also, I hate being vendor locked.
Or, locked into an IDE. Hypothetically Unreal dev doesn't need to be done with their IDE.
But never seen anyone develop that way. And even if you __CAN__ you are still locked into
being forced to install visual studio for the compiler. Ever try to compile a visual studio project
from outside visual studio using the command prompt? Damn near impossible. Visual studio
loads a whole bunch of weird state into the terminal it uses in the IDE.
Nice. Yeah I actually really dislike the VS build system. In recent years with Unity DOTS I think heavy simulations are more viable over there but haven't experimented myself! Good luck with your game!
@@DylanFalconer Thanks!
I made a horrible mistake. After poking Unity for a few times I decided I need to figure it out from scratch. I have no proper background, I'm not even remotely a programmer and math made me literally cry when I was a kid, but I don't care because I can't stand doing something without understanding what's going on behind the scenes. I literally needed to understand, what lies beneath the «SDL_CreateWindow()» in order to calm down. Turns out, it literally is just boilerplate that you won't ever want to type nor can you change too much. Every time I googled something and tried to replicate it in unity I was like «is it the best thing? isn't RB controller an overkill? cuz it sure feels better than vanilla one, but it's physics. Also it can actually climb stairs of appropriate size without any code, why do people say it can't? and why are there no lessons of physics materials and everyone just sets them to be ultra slippery? how do I make bigger levels if I ever want to make a giant world? why is my empty project with a capsule and a few cubes 1.2 gigs in size? how detailed should my meshes be? why blender and unity have normal maps flipped? how do I make ragdolls? how do I load a custom collision mesh? how do I make something happen just once?».
And sometimes there's just zero info. Like, how do I «properly» replicate RE1 HD graphics? I don't want to separately render and manually place cutouts of the pre-rendered BG in front of the camera like I'm building a scene for theater. I'm sure there's got to be a better way to just combine an image and frame of the game.
And animator is hell even if you have just half a dozen of animations. It's already a pain in the ass and you didn't even get to contextual things like picking up a gun vs opening a door. Or animation layering. While all you want to do conceptually is «if A is pressed & not running -> play anim "strafe_right"». But instead you need to drag and drop and set up all kinds of crap in several menus to do it. And then repeat it for other animations. Or reinvent the entire thing in code. Or pay for the custom plugin.
I'd rather have that feature for code actually. And ouside of unity. It's very helpful to see how your code literally flows from A to B. But while it works for things like shaders and SMs - I'm not sure how useful it is for actual code. Seems like it would be very limited.
You know I just watched another video released around a similar time and it was the person talking at you the entire time. All I could think is: you are discussing 5 different engines here and have not shown us a single screen shot of those engines, their UI or resulting semi-game you produced, which makes this video somewhat monotonous.
This video is exactly what I had in mind as I sat watching the other. The examples and your points are well received, and kudos for your presentation. I am definitely in the "DIY game engine" group.
I'm building my largest game, from scratch, in my own programming language in Zig, and I agree with everything in this video. Some people use commercial game engines because they come with level editors... but if your game is simple enough, and you're a competent enough programmer, you can just create your own editor. Are there are huge positives: I know exactly how my editor works, and it is minimal since it only does what it needs to do. It also only took 1 month to program. Why spend years "learning" how to make a game in Unity when you can just make your own level editor in a month lol.
Yeah, at the time I made this video the general online landscape was "What? Make a game engine? Are you insane? What a waste of time." So I just wanted to provide a counter argument. I still maintain that people who aren't interested in programming should NOT try to make their own engines.
Good luck with your game :) Will you release a demo?
@@DylanFalconer Absolutely, but not until after I've announced the game. (Which I intend to do this year, for a possible 2025 release.) It's gonna be big. (At least for a puzzle game.)
Nice video, Thanks
if its fun to you - go for it - to me, it was non-negotiable - using existing engine just wasnt fun, and didnt fit my needs either...it brought me many (3) work opportunities...realize that making an engine generally dwarfs what you would be doing in most corporate jobs...thanks to it im very confident in jobsearch, and i have never been turned down, and getting a good pay is easier too - as simple as saying "i have a proof" to any arguments...of course im still working on it, but honestly, getting much better as a programmer is enough (its also extremely fulfilling to build your own rendering pipeline, networking, and seeing it work) - best of luck to anyone reading this:)
Very very very very important video. Thank you. This is something I needed. And yes, I made it to the end :D. I am no more sure about working on my own engine
Man, I didn't realize that I was watching an emerging youtube channel :) a bit of feedback on this video; The video would be more interesting if you edited the transitions with some background music, BIG text with colored background and if you cut away the long pauses between sentences. I really recommend watching Mark Brown with GMTK to see what I mean. Good luck man!
I appreciate the feedback, GMTK is a great channel indeed
I'll try!
I notice that most runaway indie successes are in fact NOT built with Unity or Unreal, despite the prevalent narrative that you should always use an engine (usually Unity) if you want to ship something. Minecraft is built entirely in Java. Fez and Stardew Valley are made with XNA Framework. Angry Birds was made from scratch, probably in Objective-C. Bindings of Isaac was made in Flash, and the second from scratch in C++. Divinity Original Sin was made with a custom C++ engine and .NET tooling. I couldn't find what Hades was built with but their previous titles were built with XNA/MonoGame. Going with your video, I learned that Deadcells was not made in Unity either. I'm not saying it's a direct cause and effect, there's a lot more than engine choice that goes into a game success, but this is interesting nonetheless.
Personally I write my game from scratch in C++ because the project's scope is small enough that it's not a huge leap from using Unity, and I get to own the whole thing, which as a programmer is a lot more motivating for me than using Unity.
One stand-out example of a great and successful indie title which uses Unity is Hollow Knight. That game doesn't need to do anything too ambitious in terms of performance, only having a few things happening at any time. They could afford to focus much more on art, design, game-play, etc, because of their scope.
Another great example made with Unity is Oxygen Not Included. However, they have the opposite problem, where they can't push out enough performance with the engine (or perhaps it's just not a priority for them - can't say for sure), so they limit their map size and the longer you play, the slower things run.
Either way, if you want to be a better programmer, then making your own engine is the right path to go down. If you want to focus on other aspects of game development (design, story, lore, art, animation, etc), then I'd only recommend rolling your own with a very limited scope, or just using an engine.
I wouldn't say most, you're nitpicking a bit. There's many popular games made in unity. Valheim is a good more recent example, Cities: skylines, INSIDE (spiritual successor to limbo,) super hot, hearthstone, hollow knight, ori and the blind forest, DUSK, enter the gungeon, cuphead, subnautica, android version of temple run, outer wilds, return of the obra dinn, pillars of eternity. Those are some I wrote down. There's many more. As for games made without a popular engine, a few more are dwarf fortress (which inspired Minecraft quite a bit,) shovelknight, factorio, noita, teardown, foundation, darkest dungeon, guacamelee, terraria (xna), and the HD spelunky remake, to list a few. It really depends on what you enjoy doing, the engine doesn't really matter.
I enjoy using Godot engine, and can work quickly in it, but I'm still quite interested in making a game without an engine. Sites like gameprogrammingpatterns.com are useful for ideas on how to structure a game.
Imo the reason why you see a lot of these custom built games succeed compared to a sea of failed projects made with the huge engines comes down more to the fact that someone that is able to create a game like Minecraft, Stardew Valley, Braid, The Witness themselves from scratch already has a higher level of skill and experience than some kid or hobbyist trying to make something in Unity. So I think it's more of a correlation that people or teams with custom built engines are more skilled and therefore succeed more often than that being the actual cause.
Loved the content, subscribed right away. Keep these coming 👍
Thank you for this video. I'm tinkering with xna/monogame rn trying my best to design a coherent drag and drop manager that I can plug in various contexts.
I've been in and out of gamedev as a hobby, and recently went back. Wondering if I'm just dumb for thinking I actually want to do my own engine for fun. I always bounce when using an engine for feeling like I don't have fun with them
Unity and Godot never clicked in me. When I wanted to do something fun, I got stuck learning the tool, instead of learning how to actually do the thing I want. I used both to some extent. And that feels like is not my lack of knowledge as a software engineer, but as a "unity/godot developer" specifically
Also I don't have a game in mind, I never do really. But I have ideas I want to implement because it seems fun to learn how to implement it, it make so much more sense to just write my little sandbox and have fun. Thank you
Good luck on your journey! I have been having similar thoughts and am on my way back in for another good try. We are both going to make it!
I was expecting the video to start with a "what are you? weak?" joke
I’m no programmer but I like the idea of having my own game engine mainly because you have your own ui know how everything works and own splash screen best part you don’t have to pay for any features
Why you should: *So you can make the best and most enjoyable game because you know exactly what everything does*
This actually made me really confident in myself to make my own engine, I have tried unity in unreal, it's just these one things like 3d modeling or 3d modeling and the code not working because they made it so complicated and none of the tutorials work(that was long) but this has given me confidence knowing that I might just succeed, and gave some very useful tips, this video is awesome and helped me alot. Time to get to work!
Edit: Turns out I'm not gonna make a game engine, but once I return to unity what I can do is modify it by adding my own scripts, it's sorta like I control the game engine in a way
Edit: I'm now normally using unreal now
Good luck! Would love to see updates on your progress
I will love to see your engine, if it releases i hope it gets support
@@GDT-Studio eh, I kinda just went back to unity, stuff just wouldn't work
@@GDT-Studio BUT, there is a plot twist, when my game releases in future updates I am gonna add a sandbox mode that is basically a simplified game egine for pc and console.
Thanks
This video was very informative but the lack of energy in the way you presented the info made it hard to not fall asleep or to just loose interest. So, up the energy and keep up the good work
Sadly there I was never able to find a 3d rendering framework that is super simple to set up like raylib and proviedes great graphics out of the box like unreal engine for example.
Im trying to create something like that myself now and i realy hope im able to pull it of...
Good luck, that sounds difficult! Let us know if you have a public version~
Good example is unreal where I can’t even render a texture on screen (for debugging) without using built in canvas that can only be used if you inherit a certain class and can only be used in 1 function.
You are so incredibly impressive. I want you to know that
great video mate, keep it up
Thanks 🤗
Thanks for this video! Great job👏
Glad you liked it!
I use a game engine because it helps me with a lot of things and i can actually focus on making the game. But I will try some day to make my own engine.
Great advice.
I kinda agree and i am going to make my own custom game engine
Good luck!
Thx!
'small' problems going from javascript to haskell LOL
I like having control over what happens behind the screen of my game, so I love using frameworks like SDL or GLFW
Likewise, after trying both I think I prefer GLFW for its simpler API and callbacks
great vid!
i'm in the process of finishing up my 2d engine, and this is what the development has looked like:
70% of dev time: building up the engine
10% of dev time: writing game logic
20% of dev time: making the resources
a game engine (especially a solo-devved one) is a person's brain-child
I like the idea of doing this in any language that I prefer. Perhaps Go is my favorite. But I am wondering about porting to Android for example. It could be a big headache.
Well, you can write native mobile apps in Go, though I have no experience with it myself. As long as your game can run in Go, if that's what will bring you the most joy to work with, I say go for it! I found some examples and documentation here pkg.go.dev/golang.org/x/mobile/app
Do you recommend OpenGL for rendering, or something higher level, like SDL?
I replied to your other comment rather than this one by accident!
@@DylanFalconer No problem 😊
SDL is not particularly high-level, its point is portability between different platforms, so you don't have to write separate, specific code for handling window/frame instances, sound etc. for every environment. If you want extreme portability, I would recommend SDL+OpenGL 2.1 and doing everything in 32-bit ;-) OpenGL 2.1 works on old graphics cards to the point beyond which nobody cares.
It always a struggling for me to decide make my own engine or use existing to make my games, and I end up using existing engine. and idk which library to use for making it
I'd say it really depends what you want to do. If you want to focus more on publishing games rather than becoming an expert programmer, then it's probably best to use an engine if your game idea will work well in one of them.
Thank you very much.
You are welcome!
Yea UA-camrs use engines to make thery game but neaver make thery own i like seeing people make game engines its nice went to make my own game engine ones i gat a laptop and learn codeing
After getting into development of game engine, are you interested in how OS works or is it the other way around for you?
I'm very keen to learn more when I have some time. I'd like to start with Ben Eater's 6502 series building a computer from scratch.
@@DylanFalconer Sounds great! 😁 What do you think of Temple OS?
@@FourSeven47 I think Temple OS is very impressive and its a great work to motivate others by. I don't think it's very usable for regular tasks, though I haven't tried it myself.
good vid, im clueless
People can choose to focus on building your game or your engine.
But remember, eventually gamedev is a business, you need to delivery something at some points for profit.
If it’s not for profit then the fun path to research open up to everyone anytime.. as a hobby.
I'm facing this reality myself at the moment. Though it does depend on your skill level. A skilled professional programmer could create underlying tech much faster than those of us who need to learn everything from scratch.
@@DylanFalconer I think it's rare to have someone who can both forge well-designed gameplay and technical skills.
But good technicans mostly learn from great designers like Nintendo. Replicate the mechanism with their great engineering and add up their own things from there.
I just feel like I have to point this issue out to all indies, as most don't know what they are building and what they may get as result.
I don't know about Unity because I have never used it, but Godot and Unreal are both opensource Engines that you can modify to work in a way that you want them to. Thus not really suffering from some of the points you mention.
Though Unreal is severely heavily bloated to the point that if you were to make an 8bit, 2D scrolling shooter in UE5 you would need a modern computer to run it, while making the same 8bit, 2Dscroller in something like Phaser3 (Another open source engine) will run on a potato.
How easy are they to modify? Do you have any examples? Depending on your scope that may be way more work than just creating something. Yeah, Unreal's target audience isn't people that want to make 2d games so that's fine. It's up to us to pick the best tool for the job.
@@DylanFalconer I've not tried modifying any of the engines, I just know that they are.
Editing someone else's code is always going to be harder than making your own, it is just the way it is. It's also a skill you are going to need if you ever want to work in a team.
how about 3D games, do you think it's a crazy idea for a solo dev ?
No idea what Dylen thinks, but imho yes. Finishing a game, especially 3D, is already hard enough. You can implement the basics like rendering the teapot in OpenGL if you want to learn, but for a typical solo dev, especially if you're not very experienced, it's really a huge amount of work. The benefits of using the engine far outweigh the limitations. There are some cases where it might be needed like that non-euclidean game, but for typical games you'll be fine with engines, really.
I have no interest in making a game. But making an engine, you learn about asset loading, the graphics pipeline, animation, physics, etc.
I hate when people say that watching movies or playing games is a waste. It's spent time, not wasted time and it's spent doing something you like and enjoy like watch some movie or play some game or do some programming project.
Also about that feeling that you are wasting your time that happens when you do too much of something no matter what it is. For example if you spend a lot of time on coding then your brain will make you feel that it's pointless and a waste in order to make you take a break and something else, all because the brain wants diversity.
I am building a game engine in JavaScript and using BabylonJS.
Only soy devs use js😂
Hi, I am a Python beginner, here asking if you can please build for the public an open source Python application that will convert our Python script close as possible into purely a Javascript code basically making it 1000* times easier for the vast majority of people to develop Javascript applications to quite an extent, therefore... we can have the best of both worlds. It doesn't have to be anywhere complicated like a 3D game engine, Thanks.
I have to ask, why C and not C++?
I have yet to be convinced that C++ has anything I want.
@@DylanFalconer How about OOP features and type safety?
@@SnakeEngine C compilers give errors when trying to pass the wrong type to functions. If you mean the fact that you can convert any pointer type to any other, what's wrong with that? What OOP features do you think are worth exploring?
@@DylanFalconer Inheritance and polymorphism.
@@SnakeEngine I see. I haven't found those features to be very useful myself. What's good about them?
You might as well use an open source game engine. Why reinvent the wheel?
So that you can fine tune that wheel to exactly fit and work your car alone, instead of having a generic wheel that may not work for your car and isn't easy to edit
@@GlacialSkyfarer
sounds good in theory.
In reality, unless you are making something like no men's sky or teardown etc. You wont need a custom engine and any mainstream engine would most likely cover your needs.
@@rytif cool story. Make your own OS next.
@@rytif Nice one again.
The fact remains. If you want to embark on a programming journey and you are only after knowledge with the resulting game being an afterthought, build it from scratch.
If you actually want to make a non-trivial game and deliver it in any realistic amount of time, use an engine.
Engine bloat and build times don't matter if the actual making of the game takes a 1000 times less time to do by leveraging an engine.
AAA games from enormous companies don't reinvent the wheel every time. A solo dev with not even 0.0001% of their time and resources shouldn't either.
@Mr30friends 1st of all you're assuming everyones a solo dev 2nd there are some pros of making your own engine some very reputable games use a custom engine for example ff14 and destiny. Just because it saves time doesn't mean using a pre built engine is the defacto option lol
I have seen many indy/hobby game developers falling down the rabbit-hole of building their own engine. Getting stuck in mucking around it for years, and never actually building a game from it. Bottom line: DONT develop your own engine if you actually want to make a game. Only build one if you are interested in the tech behind rendering, physics etc, but not if your goal is to make a game.
If you want to make a GAME: have a look at Unity or Unreal first, those serve 95% of all game development needs, and you can actually get stuff done.
In the case of Minecraft: it was made before convenient consumer-grade game engines where popular, and Notch was not some inexperienced Indy, but worked on several game engines before and had an extensive backlog of knowledge how to build them.
I agree, if you think your game project can be done in Unity or Unreal and you only care about making and releasing a game, then do not build your own engine. If you do decide to build an engine, there are many libraries which can make your life easier. Most people who build engines don't want to write physics libraries, so they use something like Bullet. Rendering is usually the meat of the engine, so if you can find a rendering engine you like, and it suits your needs, use that. Good luck out there!
I think it's worth mentioning that Unity and Unreal are not very suitable for certain types of game, and in such cases you may still want to consider building your own engine. E.g. citybuilders or games like factorio, since the standard engines cannot cope with so many entities as efficiently, and the engines are too bloated for those kinds of games. This is also what Dylan mentioned, not being able to optimize past a certain point. Also these standard engines don't really work well if you want to do things like random level generation or very procedurally generated games.
@@vortexbuffer5892 I dont know Unreal well enough, but in the case of Unity, there is a lot that can be archived with custom systems and workarounds. A beginner might naively drag objects into a scene, and then run into performance problems at one point. But for example implementing a game like Facturio is quite possible, when separating the gamelogic from the object rendering, and using combined meshes for LOD (zooming out in the map). You could literally simulate and display thousands of separate machine elements in a scene.
The same goes for procedural level generation. All possible in Unity (I did implement a large scale terrain and structure generator). Meshes can be create in Unity quick enough for realtime procedural generation. A custom engine might have some performance edge in those specific scenarios, but those parts are only a small part of what else a game engine must implement.
Outside of edge cases (very specific hardware support, 64k demos, very specific world simulations, or high budget AAA productions) I dont see any typical game that could not be implemented in Unity.
Its often just a question of how experienced the developer is in creating custom solutions.
How do I make a game engine? I need a tutorial
2D or 3D?
@@DylanFalconer 3d
@@oliverb.8995 I'd recommend checking out The Cherno's playlist. This is for C++ ua-cam.com/play/PLlrATfBNZ98dC-V-N3m0Go4deliWHPFwT.html
If you want to use something closer to plain C, perhaps check out Handmade Hero ua-cam.com/video/Ee3EtYb8d1o/v-deo.html
@@DylanFalconer hi, what about 2D? Same references?
I'm making a 3d game engine using opengl.
Nice, good luck!
Making your own engine when you wanna make just your game is the same as forging your own steel when you just wanna build your own car. Just buy existing parts and modify it to your needs. You don't need to do everything from scratch.
That's true if you don't care about learning more about programming.
@@DylanFalconer You can make your own game engine if you want to learn more about it but it will slow down development of your game. If you wanna make a game, make a game. You can clearly learn concepts like pathfinding, physics, etc. and use existing libraries implementing it instead of spending time doing the same work again. There are so many concepts and features in game engine that you need several years to explore and reimplement them. Back in high school I built my own OS from scratch. Spent several years on it. Now I can say it was great experience and I learned a lot but what I really wanted was just my own linux distro from scratch instead of writing kernel, bootloader, drivers and so on. Being a good programmer is 90% theory 10% execution. Everybody can write bunch of ifs but you need to know a lot of software architecture, design patterns and the ideal solutions to problems you are trying to solve. Its' great that you can write matrix transformations, collision physics and so on from scratch but when your architecture is a mess then it didn't make sense to implement it from scratch in the first place. You can learn architecture of the software by reverse engineering opensource projects, reading and implementing it.
@@just-jiu I've worked in unity and pygame over the last two years and the learning curve is the bane of either.
The thing about unity is, if you KNOW unity and your game leverages all the tools it provides, then yeah its great. More than half the people who ever read this comment will use a fraction of the tools it provides, then have a massive engine overhead filled with memory leaks.
After working with pygame for two years now, my last game jam made a comparable product to the unity game jam I did a year ago. It did not slow me down in the slightest because I never used half of what Unity offered back then. I can say that the pygame ran on my cousins 300$ school laptop w/ duo core celeron CPU, increasing my potential market by a wide margin.
Meanwhile I have to restart Battletech on my 3060 after 2h of gameplay because memory leaks in Unity are still prevalent, even with Paradox's professional team of developers.
No, I don't think I will.
Im one of the people the haky selution in unity game engine
This is exactly what we're told not to do in the gaming industry, when starting out. Starting out, first thing you learn is that one person can't do everything, because one person just isn't good "enough" at doing everything, but everyone has a strength, things they are good at, and things they are not. When you learn the trade, and become part of a team, that team gains experience by having successfully developed products in the past. Only when you have the experience, should you consider creating your own game engine, as if "games" themselves were not expensive enough to produce, "game engines" are a whole other set of problems to overcome.
I understand the sentiment, and I haven't released a game yet, so perhaps I just don't have the experience. However, programming a game and a game engine are pretty much the same thing.
The widespread use of third party engines is a relatively new event. Most games before the 2000s were build with custom engines. A custom engine does not mean that it has to be a general purpose solution for every conceivable problem - and usually they are designed specifically for a particular game. Unreal Engine was initially created for the game Unreal and designed specifically for first-person shooters. You can still see the legacy of that today when using the engine to build a game (or at least you could last time I used UE4).
If you are worried primarily about expense, then we are talking about different things. I'm talking about personal achievement and wanting to do something difficult because it's fun to challenge oneself.
New To programming, like python, tried HTML/CSS/JS web pages not My thing, now learning UE and yes, it feels like bending a mental pipe, maybe I should try make python engine :)
If you are interested in python gamedev check out DaFluffyPotato here on YT, he has some good content with PyGame. Good luck! ua-cam.com/channels/YNrBrBOgTfHswcz2DdZQFA.html
I think you are arguing one point here and then another point that contradicts the first which seems to be common with these types of videos.
You say an advantage of using a framework is that you get to choose the language (to be able to choose the most productive language I take it as what you mean). Then you say that a disadvantage of using Unity is that it uses a garbage collector and that is slow. But pretty much all languages use a garbage collector except for C/C++ and Rust. So the second point means you would have to choose one of those for performance and then you may just as well choose C++ and code in a game engine. And in reality it would take you many years of work to achieve the same performance as UE or Unity (with the data oriented pipeline at least).
Wouldn't the best be to learn to live with those engines, quirks and all, and perhaps supplementing with making a game in a framework such as SDL to learn a bit of the foundation? This is assuming you want to make a complex game at some point. For simple games anything seems good enough.
I disagree on turning off the phone with deep work, but I do recommend turning off useless notification and unsubscribing from all non essential emails. I hardly get notifications unless its important
This argument, of course, only works if you're a decent programmer who is capable of making an engine with a good performance and cross-platform support, and you have time. Otherwise, you pretty much have no other options. That being said, why don't y'all check out this really cool Rust (🚀) engine called Bevy?
I believe i added those caveats in the video. If you aren't interested in programming then you probably shouldn't try to build your own engine. You can get decent cross-platform support with a few libraries - depends what platforms you are talking about. What's cool about Bevy?
@@DylanFalconer Bevy is really configurable, fully ECS (with automatic dependency injection!), uses Vulkan (and iirc optionally Direct3D on Windows), actively developed, and has a really nice community.
Thanks,but I'll stick to id Tech engine instead. :)
Sounds good!
Everyone keeps saying that but i find it so damn stupid. The time you need to make something like an engine can be used making actual games. The amount of open sourced engines already out there with basicly all the work already done is staggering. So if an engine doesnt fit your need, which i highly doubt since there is always an engine for everything, you could judt contribute to already existing engines. Unless software engineering is the path you want
Don't forget to talk about the crazy ordeal that crosscode had to do to port their games to other platforms... building a game engine, while a big learning process and powertrip for some is completely useless nowadays if your goal is to make a game, any game engine can make any type of games or rendering, yes it is bloated and have many many stuff that is irrelevant to your project, but whatever at least the system is there if you ever need them because flexibility is an important part of gamedev. Just for the building part and porting and engine is juste a bless, otherwise good luck reading the white papers and getting all the waivers and engine approved to ship a build on xbox/switch/ps. Even if you don't plan on getting out on these platform it's still comforting to know it's a possibility. Furthermore you can in fact strip unity of almost everything and use low level coding if you want, i know a friend did this took him 4 years and still haven't even came close to release anything, but hey he still can build on every platform with his heavily modified personal unity version.
I followed CrossCode's development from when it was a tech demo on the impact.js forums. That was back in 2012. It would be another 6 years before Unity 2D was released, and 5 years until Nintendo Switch was released.
While I agree with your sentiment that platform porting is made easier for a lot of games using 3rd party engines, in this case, there was no way to foresee that Switch would not support HTML5, especially since the Wii U did support HTML5 games and came out around the same time as CrossCode started development.
I can't speak about stripping out Unity's features. Sounds like a nightmare, though. Is your friend able to directly use C++ for gameplay code, or must he use C#?
@@DylanFalconer No he's not using C++ tho it's still in C#, but basically from my limited understanding he's basically gone full ECS way before ECS was even in the mind of unity, so he stripped everything useless from game objects, cameras, animations, rendering and everything except the IL2CPP compiling and platforms build. making his game run in like .1 second while pressing play, and crunching the build size like crazy. but like he's a genius really, a mathematician capable of reading and writing assembly code, a good mentor on many aspect of a prod. but nonetheless this kind of overextended controls kinda hurts a lot during development, I mean this is basically saying you cut all extra fat, but you have to do everything almost from scratch as well ... which is really not time efficient if you're on a budget
As a wise man once said "Build a game, not an engine"
Are you referring to the short essay about building games and finding reusable pieces as you build more and more? I'm not proposing that everyone build their own general purpose competitor to the big 3.
In fact in my engine series on this channel I outline that the engine is designed for a particular game, it's not a general purpose amalgamation of features that may or may not be needed stitched together - which is what I think people imagine when they hear the term "Game Engine".
Reason #1: You hate money and profit and only write code for fun. Reason #2: You have too much time on your hands and decide you want to create Wheel 2.0
Are you aware of the time and dificulty to build a game engine?. No body will build a game engine and make a their games from it (Except from Hazel)
Nearly all games were built without 3rd party engines until recently. Even these days, people choose to write their own engines for their games. Some examples include: Stardew Valley, Minecraft, The Witness, Equilinox, Amnesia, Fez, et al. Many of these examples are solo Devs, too.
As for whether I'm aware of the time and difficulty, I have been working on my own engine and game for 5 months so I have some incomplete picture. It is very difficult and time consuming, but if you have passion for something then you enjoy the challenge.
If you are wanting to make an engine like Hazel, then you are probably not wanting to ship a game anytime soon. Hazel is designed as a general purpose engine which can be used to make many types of games. Most engines are built to solve specific problems and therefore take less time and effort.
If you do not want to make your own engine because you just aren't interested that is totally fine. Many successful and high quality games are being released via 3rd party engines. Good luck!
Time and difficulty to build your own game engine is relative to what you are trying to accomplish. If you are looking to make the next Battlefield game, then expect to spend years writing your own version of Frostbite Engine. For someone making Space Invaders? The task of making a game engine is much simpler, and very achievable by a solo developer. The key is to understand that not everything needs to be written from scratch. Even Hazel isn't fully from scratch. That engine leverages a fair amount of vendor code Box2D, Entt, ImGui, GLFW, and more...
Click biat title but fine content
that was useless info
ఠ ͟ಠ。。。
Bruh