100% agreed. Don't make an engine that can do everything with no aim in mind. That's a good way to get lost working on an engine for 10 years but you've never made a game with it.
@@DylanFalconer Eh maybe? Unity and Godot became good because a bunch of people made games with them. Then the engine team tweaked and adapted to fix the issues, also expanded the engines capabilities based on feedback. If not a single game has been with the engine then no way it's good. Unless it's your 5th engine and you've learned from past experiences.
@@DylanFalconer can't one do whatever the f* he's passionate about?, lmao 🤣 making your own game engine is a worthwile endevor even if no one oses it imo
@@zarodgaming1844 if you accept the fact that the project will never be useful to anyone, then yes go ahead, nothing is stopping you. An engine is only useful if games are made in it.
@@sagitswag1785 right. Cuz all y'all have been given free education and healthcare only cuz of your contribution to humanity 🤔 There's such a thing as a personal challange, that reverberates through the ages, instead of the empty simping of the ignorant masses, that will only end up hurying you with the very tool you created for them ... where the f* are my meds?! 💀
I can get behind that too. The problem I saw with the "make your own engine" advice was when people said your game is better off with a custom engine. Truth is that most people just want to make games and the big 3 are much better at teaching you how to make games than making custom engines. But if you wanna get good at programming specifically, making an engine will definitely teach you a lot. It's about having the right goals.
I'd argue the exact opposite. Knowing the systems that go into your game first hand will help solve the inevitably difficult problems that always arise with game development. -t. AAA graphics engineer
When I first researched how to start programming games from scratch, I stumbled on that advice to build a game, not an engine. And I'm glad I did because it has saved me a lot of headaches, I'm sure. That advice fits nicely with other tidbits I have picked up from others -- "program the most simple thing possible to solve the problem that you have."
I have an interesting anecdote related to this: This happened more than 10 years ago at a gamed forum from my local community. A guy was talking about the engine we was building and we were all like "bro, don't waste time creating an engine, just focus on your game, there are many good engines and frameworks out there". This was before Unity was popular but still, there were a couple of good options already. However he replied that his engine had a different approach and was gonna be better that what was out there. Of course we were a bit skeptical. A random guy from some country far away from where the big money is, doing something that could compete with Microsoft XNA and the like? Turns out the engine that guy was working on was what now is known as Godot Engine. In conclusion, if no one made their games from scratch anymore at some point we'd no longer have anyone capable of pushing the boundaries. Nowadays you have anything from "[Genre] Maker" to different open source libraries so you can pick exactly which engineering problems you want to tackle and which want you want to delegate, whether temporarily or permanently. It's also important to understand what you want to achieve. If you just want to create a visual novel and only care about narrative and visual then RenPy works just fine. If you want to learn more about programming and build something tailored to your needs knowing it will take longer then that's perfectly fine. The problem is when people think that building the game from scratch will be easier and faster than dealing with an engine, cause it's almost never the case.
I'm glad to see another channel that advocates for the creation of a custom engine instead of using a pre-made game engine! 2 days ago, I saw a video called "Why I don't use game engines", and now I found your channel. I really support the idea of making your own game engine, in fact I'm making one right now, I have uploaded some devlogs to my youtube channel if you are interested to know about it. Great video.
Thank you for shedding light on this. I actually started making a "game engine" in May I think and I was just doing it because I wanted to but it was kind of an impulse so it turned out a couple weeks later I didn't want to. I put myself in this situation where I built this thing for no reason other than not quitting a project and TH-cam series (took it off my channel thank goodness) and it was really depressing. After that, I started a game project from scratch again with Handmade values except this time I had a clear goal and I've not only stuck with this project but I'm making so much progress because I have clear goals. It's not about what you're making so long as you want to. A lot of people make these huge projects and they get criticized for "recreating the wheel" which is totally stupid because the tools and games of tomorrow are being built by people who are passionate about making good software no matter what that looks like which is a noble cause
I totally agree. If nobody works on "reinventing the wheel" then we won't have any progress in tooling. I'm happy to hear your new project is working out for you, stick with it :)
good point that needs to be brought up more. I absolutely hate people that tell you to "just use Unity/Godot/Unreal/raylib/CryEngine/[whatever the next hip thing is]" dropping unity and godot in favour of my own solution for the game I'm creating has brought me way more satisfaction than I initially expected, especially since it let me familiarise with topics of how the game actually works under the hood more in-depth than any common resource on making games out there; meanwhile looking at unity and godot docs all I got was sheer confusion since they were way more abstract than necessary in my case
@Casper's Studio Indeed, it should always be said that taking a dogmatic approach to an engineering problem is foolish. There is, however, the programmer's sense of joy to considers as well - if your game can work in a generic engine and you enjoy using it, then that's the most likely the right course of action.
Thanks for the wonderful video again :) I often think that people overestimate the work that is needed to get to fundamentals of a game ready, which would be the engine. Especially in 2D it's not too much work. Once I wrote a small 2D engine for a game jam within a week. I could load 2D images, I had audio, keyboard and mouse input, collisions and even a 2D animation system. That's definitely not out of scope for a game. 3D is a bit more involved but depending on what you want to have it's still not too much work, especially if you can reuse your code for projects.
It's sad that corporations have convinced everyone that they are not capable of making a game, without their specific software. Many of those commercial game engines have tons of bloat that's not necessary for most games. Commercial game engines are convenient; up until that company decides to screw you over; trying to please their investors.
Amen a "game engine" should be a byproduct of your game and not the other way around. There's so many small game engine floating around, completely abandoned. I'm currently working on a game made with Zig and Vulkan and all the engine work I do is just to support my game. In the of it all, I'll have something that I can show to people and if I want to make a similar / sequel to it, I'll just reuse the "engine" of the game.
3:09 oh yeah it's "all you need", except that you can spend pretty much an infinite amount of time on any one of those things if you want to get them on a level anywhere close to being marketable. looking at the Hollow Knight example analytically, there's a ton of particle and lighting effects stacked on top of each other. if you were to develop all of those systems from scratch it would take months if not years and at the end it would still look worse. making your own game engine is great for learning (spent a decade building engines in JS, C, and Nim myself), but just don't expect anything marketable will come out of it.
There are tons of games that didn't use a 3rd party engine and look great. Tooth and Tail, Stardew Valley, Teardown to name a few. Also, pretty much every game before the 2000s used in-house custom engines. I don't know you but I'd bet you suffer from the same thing I did which is lack of focus. If you spent that time working towards one game or a series of games, it'd be nearly impossible to have a bad looking game after 10 years. Just because you didn't do it doesn't mean others can't. Also doesn't mean you can't - you just chose not to.
@@DylanFalconer please note that I did not say that custom-engine games never look great. the point is that you shouldn't expect to achieve something marketable anywhere near a comparable time frame - repeatedly. we actually want to try making some money here, right? replace "tons of" with "tiny few", especially in relation to the amount of marketable games that are not using a custom engine. sure, it's theoretically possible, like have your girlfriend fund you for a decade like Stardew Valley guy, but these really are exceptions, sorry to say. and yes, if everybody would make their own engines like back in the day then that would be what you had to compete against, and so naturally it would be viable. as for the focus, yeah, certainly, if one is capable to consistently work on only the most essential features, then they'd make fast progress. but honestly, is that realistic? I don't think that this is how our brains work in general, and if you are accountable only to yourself there's no way you'd maintain that. again - speaking generally. I am sure there are some prodigies.
All purpose = No Use. If you make an engine... Stick to making an engine FOR a specific game, not for EVERY and ANY game. Or, you'll never make anything but an engine, and chances are slim it would compete with the big 3 right now anyway. This was REALLY helpful advice. I have exactly 1 game in mind, but I don't think it's possible in any existing engine. But this advice helped me see if I do need a custom engine...this is how I should build it. Program for a purpose, don't hyper focus on repurposing your program. Unless of course high reusability WAS the goal.
It wouldn't bother me even if someone decided to make an engine to compete with the big ones. I dislike the disapproval whenever someone wants to do his own thing, like "Bro, are you gonna do that monolith that 50 programmers with years of experience did?". But usually, building your own thing means something more simple than that. If you can rotate a 3d cube on the screen, it's a start. Then add a player camera, move around. Very basic C++/OpenGL or whatever is your toolset, for a basic game you don't need to build a big monolith. Especially for 2D, it's so easy to render sprites and backgrounds, even if you did in pure software rendering in SDL. Then you have a background and a sprite you move with keys. Then maybe you can add collision and describe your level with blocks in a text editor :) Which aligns with your point, that whan someone focuses on building the game rather than the engine, they end up building a very minimal basic engine for the game that is not as scary as when people discourage you from doing so.
I tried to make my game with Unity, and tbh the architecture that it imposes on your project is so dumb imo, for an example, for some reason your UI is bound to a gameobject in 3D space, same goes for any other "manager" object. Communication between scripts is only possible by exposing data to all other scripts in the scene and feels hacky af. So I just decided to try learning opengl and see what I can make myself.
Yeah, I really don't like all the nonsense you need to go through either. The trade-off is the massive community support and ostensibly the speed-up due to all the pre-built systems. For my current project - I just need to render textured quads (pixel art), draw text, serialise and deserialise (all game data is in toml files), integrate with Lua (game logic in Lua files for easy modding), and handle keyboard/mouse events. I used Rust with glam (OpenGL), serde (Serialise), toml (TOML support), fontdue (Text rendering, very nice library), mlua (Lua interop). This pipeline is quite nice. One thing I'm dreading is weird resolution support. Apologies for the late reply!
imho it doesn't matter if you work on an engine or game - anything that gives you practice is good - the worst you can do is not work on anything at all the real problem is the social pressure - it gives you the impression there is a right way to do things - the truth is there are no perfect solutions, no perfect engine or language, no perfect code or method - there is always a tradeoff
Considering making an engine just for your needs: let's say you are making a 3D game. Now you have to blend a character animation between walking and shooting. Now you have to write a whole Animation State Machine and Animation Blending and Animation Blend Tree Spaces, and probably spend weeks on that while all ready-to-use engines have that out of the box. Meanwhile, as indie, alone, you could have made a decent amount of progress IN THE ACTUAL game instead of re-inventing the wheel. Want to add hand IK aiming? Hell, you now have to add support to bone IKs. Good luck - (BUT, at the same time, ozz-animation handles all of that and is engine agnostic, so then you have to integrate it). There's one famous gamedev TH-camr which I don't remember the name that was making his engine with C++ and live coding it, and then he spent, what, 2 months making animation blending and it was crap in the end? (and he is a C++ beast!).
I'm definitely not against libraries (or even engines) - I just wanted to outline the misconception. Building game engines is not for everyone or for every game! Most games can be created in one of the big 3.
Know your scope and what you're capable of. Even if you used the best tools, without the fundamental knowledge of how to use them you'd fall flat on your face anyway.
I think this is mainly a problem of how programming is taught in school now. The only method of programming that is ever shown to students is object-oriented programming. They are told and/or implied that you have to have an object for every possible scenario and instance. That is far from the truth. You only need to have what you actually NEED (hence the use of "need to have"). Really, to do this effectively, you need to use a combination of object-oriented programming and iterative programming skills, the ladder of which is never really taught to students (especially when they are forced to use Java for most of their schooling (which punishes excessive use of iterative programming), and are not able to use better programming languages for learning to include the bare minimum & make it work well (ex. C-like and Python)).
I didn't go to school, but I have noticed this trend of over-abstraction before implementing anything throughout my career, such as it is. I think grouping data types with functions that act on those types can still be quite useful. I'm talking about circumstances where the code is very specific, like working with a generic Graph, or a Hex grid (two examples I have used it for recently). Unified/Universal Function Call Syntax (UFCS) allows that to be done pretty nicely even without classes.
I really don't get why so many people are making general-purpose engines. Back in the day every developer made their engine with a game in mind. These engines were also made for other non-programmers to use, such as environment artist and animators. I mean something like a level editor like Source Hammer is still lacking in many of these engines, the ability to just start hacking a level together is amazing.
I have a high respect for programmers that are able to build stuff from scratch, I mean it takes quite a lot of work , the rendering , the game logic , the physics alone, implementing algorithm, this way you become for what I believe a true programmer, programmers nowadays are just users, function calls all over the place in my opinion. so if you are making your own game engine for your game I respect that.
I've always felt the same way. Some games I want to make down the line are pretty scopey and make use of just about every technique they used in old SNES games, maybe a couple from PS1 era like Castlevania: SotN, but they all share a pixelart style with more sprite- and palette- focused special effects. Even GameMaker is too bloated and slow for what I want to do. We are making very different performance-usability trade-ins so in that sense my hand is kind of forced
I'm in a very strange camp here, I love making engines. I love solving problems efficiently and building abstract types from scratch. But I have never finished a game, there is something about the process of game design that drags me down, and every time I'm finished with the engine and starting work on the design I stop. So for me, I make engines not games.
I am somewhat similar. I can spend ages with my engines but even remotely finishing a game that is more than a game jam game, no way. So I see these game jams more like opportunities on how to improve my engine.
I think the neat thing about programming is that you can do whatever you feel like doing, so maybe for some years you just work on a game, and then some years working on an engine or some other program. That being said, I'm more interested in designing combat gameplay, so programming an engine from scratch is hardly my forte haha
My problems with making your own engine or from scratch are plenty. 1: I can't find good tutorials on how to implement a library for ECS into anything. 2: I want to make 3D games, and I want to work towards bigger environments and games. So a custom engine would most likely not satisfy my needs. 3: The tools in an engine are too many for most, but you'll still find those few gems that either speed up the process or adds something you love. 4: Time. Unity has a graphical animation state machine, visual shader graph, visual particle system. Meaning you do code with visual means that easy things. 5: Stream lined. In Unity I can save my blender project in a folder in my project and it will handle most things. A little work and I got a model, material with normals and textures, animation armarture and animations. I would have to learn to understand Blender's blend files and pick them apart to be able to implement them into my engine. That's a lot of work just to get a necessity to simply work. 6: System. I can drag and drop, select and unpack, pack up, import and export in Unreal, Godot and Unity. All of these things are stuff I'd have to make myself. 7: Every function and feature I take for granted would have to be recreated every time I encounter I'm missing it. 8: Performance. Many engines are optimized like Unreal's c++ programming and nanite, Unity's new ECS and DoT system and Stride's core design for C# along with multi thread support. Even if I coded in c++ I would still have a field day trying to reach the same performance as them. Speaking of. 9: Coding. It's not just adding libraries but also knowing memory allocation, file types, code structures, hardware communication, code structure, graphics and physics implementation. Things I don't know and barely know where to learn. Let alone how to make a base for a software to be a game or engine. Something as simple as including a library like Archs or Svelto ECS into already existing engines or just in Visual Studio is non existent. Not tutorials or any ways explaining how to add these things. Just a github link and files and folders. Not a single step by step what does what and where goes where. 10: Porting. Engines nowadays work on being flexible and able to port to Windows, Mac and Linux as well as Android and sometimes WebGL. Commercial engines can afford a license for consoles which is something normal people usually don't. And this adds another layer to increase your work just to make the game accessible. In short. engines aren't perfect, nothing is. But the things they offer makes even a moron like me able to make high quality results with enough work. And the even more complicated stuff has been made by people already so things that would otherwise be twice the work of your entire project is now available. And people have shown that a little extra work can twist the arm of engines to do what they want.
Building a game engine is a complex subject, it requires years of expertise, a vast amount of knowledge , if you are unwilling to learn about game engine programming and you just want to make games stick with an engine, and yet you still have to learn that engine as well, game programming, game engine programming are two different worlds in my opinion, and you just end being up an user to that engine.
Not a lot of people realise that maybe people just want to make tools instead of games. and I find it strange to discourage it because without these types of people you wouldn't have any type of game engines in general. when you build something yourself you know how to use the engine fully and it's easy to create what you want instead of having to learn a already pre-made engine. During a game jam this helps a lot because instead of having to learn the engine you can just focus on creating. also game jams are a good way to battle test your game engines it's good practice to make games with your engine so you know it does what you want otherwise you might be spending years on systems you might never use.
My extension of this take : make an arbitrary engine from the stuff you used a lot and frequently when you made your MANY games. This implies you in the first place, make many games without a game engine, but in your style. That's where a engine starts.
Some engines do too much, you can use Raylib, MonoGame, Godot, Flax if it's a simple game, if you want something AAA you need Unreal possibly and also a whole team.
In my experience it's a great language and having access using C code directly is very handy for things that may be unimplemented. I drank the Rust coolaid and haven't used Zig in a while, so can't be super specific but I'll outline some things I like. The standard library has really nice functions and data structures. ArrayList and HashMap (esp. the ez StringHashMap) built-in are the two most useful structures for gamedev in my opinion. The defer keyword is great, every time you allocate something, make sure to defer a free (unless it's got a longer lifetime than the block, of course). Something I don't like is that I can't know whether I'm passing by ref or not as Zig just decides based on the data-type of the parameter. I tend to use a lot of structs, then when I add something like an ArrayList to a struct, it may pass by ref. I didn't look into the exact rules as I ended up drinking the Rust coolaid while on holiday. Apologies for the late reply, still getting used to reading and replying to comments.
@@DylanFalconer that's excellent, thanks! I'm equally apologetic about my tardiness. Interesting that it "decides" to pass by ref or value. That's something I'm not sure I'd want to give up coming from C. You're on the Rust train huh? So are we likely to see you rewrite your C engine in Rust? ;) Also I didn't mention in my original comment, but I fully agree with the idea of making your own engine. If nothing else, it's an excellent learning activity.
Yep! It all comes down to what you want to do. Do you wanna make a game? Just use a game engine. Now, if you want to, or have fun, having control and doing everything by yourself, go for a game engine. But keep in mind that if you wanna build a game engine, it's because you want to build the ENGINE, and make games above that, not to JUST make games.
So for someone completely new what would I need to do or where to start if I wanted to make a 2.5d with some lite 3d first person game like blood “build engine” or Star Wars dark force “Jedi engine”?
3:42 - The main language that I program in is Python. I know it isn't as good as C-like languages, but I use it cuz it helps me focus on programming logic instead of language so that I can learn instead of making functional pieces of code. For the same reason, I really like making engines and libraries because I can learn and when I actually need to write a functional program, I will already have many of the tools necessary to make it happen. However, I do this knowing my position in my education and that when producing a functional program, I will only need to write things which I need. I think there is a huge difference between writing engines like this and writing code to make a game work (like u covered) is that you need to know what to do when. However, I do think that the person programming can affect which one they would want to do (engine vs game only). I really enjoy writing libraries (as stated above) so I can use my own code later. I hate using other people's code many times because, no matter how hard I try, I just have a problem understanding other people's code. So I like to make my own self-developed tools which I can carry with me and give to others to use. I believe there are other people like me in this regard and would much rather make an engine than a game, so that others and themselves can use it later down the line to make games with. With that being said, I do think it is possible to be in the right by making a large engine with intent to make a game out of it, although you must be able to separate the development of the tools and the development of the game into two totally separate entities at two totally separate times.
I agree with everything you said in this comment, and the other one addressing OOP. I also hate using other people's code for the same reasons, but I've gotten to the point of making my own operating system. Using a low level language like C or FORTH allows you to focus even more of your attention on programming logic than python, but you might end up having to focus on programming logic a bit too much.
I know there are people with your disposition and preferences, such as The Cherno here on TH-cam. He wants to build tools and engines, not games. There's a place for you because you will build the tools that others will use to save time. Thanks for your contribution!
I've been writing a stupid little library in C for a bit now, and it's going ok. I've got my own math library that's more than likely slower than anything else I could have used... And that's about it right now... I've been wanting to make a 3D FPS game, so I generally know what I need but IDK what the best way to accomplish the whole thing would be. I've thought about switching over to an existing engine but IDK, that doesn't interest me much. I'm trying to figure out how one is supposed to... Well, figure this all out... I have no idea how to even architecture this thing I want to make. Do you have any advice?
For 3D FPS games, your best bet is to just learn how 3D renderers work. Once you can draw 3D things on the screen, well the rest depends what you are making...
i avoid programming as much as possible even though i'm decent at it so if i have the choice of using an existing engine that does pretty much everything i want better than most people would build on their own i would 100% pick an existing engine and learn its quirks
Absolutely true. That's always what I say whenever I see someone say "Hey look, I made a game engine". I mean, why? I don't think you should make an engine just for a single game or game idea. Even if you did, you wouldn't call it a game engine yet. It's just an abstract layer between your game and the OS/platform. But if you can adapt and morph and improve that same layer (and set of libraries) over time over multiple games, then you might start to call that a game engine. It's not gonna be jack-of-all trades like Unity, it absolutely shouldn't be at all. But it's an engine you've worked on with your blood and sweet nonetheless.
i have two games i want to create custom engine for, im gonna probably lose 10 years on it, but its worthy, but for everything else, i got ue and unity...so ...
I've spent more time fighting problems with the Unity engine than on making the actual logic and content of my game over these past 10yrs. I'd have spent slightly less time if I rolled my own. Way way less if I had just modified the Quake engine. Bah, hindsight
if you only want to make video games i think you should stick to a game engine but if you want to be a embedded system operating systems and video games or maybe websites or machine learning and any combination of that than you need to adapt
As a graphics engineer who works in industry, I don't advise this. Be familiar with the engines, but don't tie your knowledge to them so much that you don't truly understand the fundamentals. We can sus that out quickly.
I have an idea for a game that's been kicking around in my head for years. There's no way I could "just use...." because none of them are built for the game I want. So the final game would be bloated with stuff it didn't need and I would still have to take time to create stuff that was missing. Using an all-purpose engine is fine if you just want to build another generic FPS where the only difference between your game and the other 75,637 on Steam is the color of your outfits. But look at all the hassle Unknown Worlds had when building Subnautica in Unity. Or the fact that CIG had to massively rework Cryengine for Star Citizen. Those engines lock you into doing things a certain way. They make all games feel interchangeable. It's far better to plan your game, decide how it should feel and work, then build the engine to accomplish exactly that.
My argument would be, writing a game isn't inherently the same as writing an engine, though it may become an engine. Because an engine is more of a framework than a game. There isn't anything wrong with writing a game from scratch. But to imply that is the samething as making an engine can be confusing.
I did distinguish between engines for 3rd party or unknown game use vs the engine built for a specific game. Every game has an engine, it may not have a name but it'll be required to transform the data, handle the input and display the current state
@@DylanFalconer Respectfully my problem is -- if everything is an engine, the term engine has no meaning. Admittedly the term engine is nebulous. But it does imply it being a framework that can be used to power multiple games.
@@DylanFalconer If you'll indulgence me, I would better like to explain my issue with calling everything an engine. I am currently working on making a game. I'm designing it so it can be expanded and reused. The reason I wouldn't call what I have a game engine is because it's purpose made for the project I'm working on. While it could be adapted later, and if I made a similar project adapting it wouldn't be a problem, that's not the intent of the code base. The code is designed for the game. The code isn't designed for future games. I'll stay out of your hair now, and have a wonderful weekend!
@@IamusTheFox I think it can still be referred to as an engine. Unless the game itself loads the data and everything needed. If it is a separate subsystem of the game that handles all the loading of data and drawing of things that the game calls into and is its own separate thing then that is still the engine, even if it is very specific to one thing which is your particular game and nothing else. Like a car, even if it's built from the ground up totally by yourself, you would still call what actually drives the wheels the engine no matter how custom or integrated it is. It may only work for that car and none else but it is still the engine of the car.
I never got into using Unity, because I think it's a hot mess. Everything seems to be either deprecated or experimental. I prefer Godot, but if I want to create all systems myself and practise my C++ I pick SFML or Raylib.
Agreed, AAA gaming is becoming generic as hell because everyone and their sister uses unity/unreal. If you want to stand apart from the hordes of people who have no clue how anything works inder the hood, make your own games from scratch. Then after you actually know what youre doing, you can easily pick up one of these engines.
It will be a wake up call, when everything starts to become soo full of glitches and bugs and not many know enough to fix anything, Oh wait it is already like that. lol
So the choice is between using an engine that can do XY and Z vs building an engine that can do X maybe slightly better. Guess what will allow you to create your game sooner? Players don't care what engine you used. If you make a living with game dev, your bills don't care if they are payed using this or that engine. And if you are a programming beginner you don't even have the option to care. Building a game engine is a hobby, like watching movies. It has the goal of making you happy. There is no productivity in it. Also duplication of effort is not beneficial to society. Imagine if instead of 50 mediocre engines we had 1 that could do everything and do it well.
Perfectly said. In an era where people are not just using engine but they are using multiple assets and leveraging AI, you will be stuck making 1970s game if you want to make an engine. Everyone I know who built their engine ended up making sub par games with 1980 graphics. If your idea is more ambitious and you want to iterate fast on an idea, then use an existing engine. The market is harsh right now and game dev is a business. Making your own engine is just a hobby.
If you want to make a game with hyper-realistic 3d graphics then I agree. If you only care about getting to market ASAP then I agree. If you don't care about becoming a better programmer then I agree. If you are making a game that doesn't do anything technically difficult then I agree. If everyone you know who built their own engine made bad games - what makes you think they would have built better games using an engine? That's a different skill called game design - has nothing to do with the tech (provided the tech to achieve their design is possible). If your idea is "more ambitious" it may not even be possible in the big 3 modern engines. I disagree about making a 1970s looking game if you make your own engine. There are plenty of modern examples: Into the Breach, Eastward, Factorio, Noita, - tiny teams Owlboy, The Witness - small studios Making an engine is only a hobby if you never use it for commercial products. For you (and most people), it looks like using an existing tool is the best solution because you have different goals. This video was actually about the wide misconception of the quote - that you should build tech specific to your needs and not generalise for no reason. EDIT: I just found this interesting read: gist.github.com/raysan5/909dc6cf33ed40223eb0dfe625c0de74 It's always still a trade-off. But it seems many people think it's worth it.
I completely disagree with you about this, but I'm glad you took the time to post your opinion. It's situational and not the point of this video anyway which is about the misconstrued quote in the title. If you think engineering something is a hobby because someone else has already done a half-decent job at it, then how do you expect we will get different things in the future? Who is going to make the "best single" engine when eventually nobody knows how to make them? If making an engine doesn't interest you or suit your needs, then don't do it - it's that simple.
@@DylanFalconer To be honest I was overly emotional when writing that. I agree that different people have different goals and I should not enforce my goals on others. Sorry about that. To put it in context it is a very pivotal time in my life for various reasons. I am switching career to solo game dev from something unrelated. I have little to no experience with programming or anything game dev really and on top of that I have a time limit to make something before my savings run out. You can see why I feel a bit rushed and want to just put out something to prove that I can do this (it's scary). Also I enjoy the artistic and design parts a lot more than programming. Yes, my goals are different. I do agree that someone has to make new engines or we would be in danger of stagnation. But those people have their motivations in a different order than me. There is no pressure building on their ass, so they can afford to take the idealistic approach. Also not everyone that wants to make games has 10 years of programming experience. A lot of people are motivated by the final product coming to existence, not by the act of programming and solving problems. TL;DR: people make engines because they love crafting a great product, not for productivity reasons.
The question really is, do you want to make money.. Or are you making games for fun or your own satisfaction? If you want to make money, don't waste your time.
No the reason behind it is don't waste your time reinventing the wheel. Use what's available and build onto that. You also don't make your own graphic card from scratch to create your game so why making the engine.
@@DylanFalconer yes and your arguments are wrong. Time is money. Don't waste your time building something that already exist. If you are not an expert in the game engine industry, you don't know the architecture and pit fails, your engine will suck. You will be introducing many new bugs, reinventing the wheel and it will be slowing you down. If you wanna build an engine build an engine but if you wanna make a game focus on making the game not an engine. Reducing dependencies is not necessary; look on the other languages. In website industry people are using packages which sometimes contains like 20 lines of code. Could they rewrite it from scratch? Sure, but what's the point? Also one thing is making simple 2D game with sprites and other thing is making 3D games with LOD, VFX, ambient sounds, fog, advance physics/game mechanics. You are competing in game industry not engine industry. You need to make better games not better engines.
@@just-jiu Factorio proves what can be done when developers actually know how to program and not just press buttons in an editor. its amazingly optimized and not some sluggish unity drivel that goes unresponsive and takes 40 seconds to load.
@@happygofishing more people are playing the "slow" Rust which take 2 hours to load than the super fast Factorio. DayZ is also written from scratch and after several years of development it's sluggish and cannot beat even default camera behavior from unity. Unity is just a tool and if you cannot use it properly your game will be slow and buggy. But it's better than not having any game at all. There are several major games written in DOTS Unity which performs well. You purposefully picked 2 edge cases to support your statement.
100% agreed. Don't make an engine that can do everything with no aim in mind. That's a good way to get lost working on an engine for 10 years but you've never made a game with it.
Yeah, but perhaps that 10 year engine project could be a competitor to Unity/Godot if that's what one wants to work on!
@@DylanFalconer Eh maybe? Unity and Godot became good because a bunch of people made games with them. Then the engine team tweaked and adapted to fix the issues, also expanded the engines capabilities based on feedback. If not a single game has been with the engine then no way it's good. Unless it's your 5th engine and you've learned from past experiences.
@@DylanFalconer can't one do whatever the f* he's passionate about?, lmao 🤣 making your own game engine is a worthwile endevor even if no one oses it imo
@@zarodgaming1844 if you accept the fact that the project will never be useful to anyone, then yes go ahead, nothing is stopping you. An engine is only useful if games are made in it.
@@sagitswag1785 right.
Cuz all y'all have been given free education and healthcare only cuz of your contribution to humanity 🤔
There's such a thing as a personal challange, that reverberates through the ages, instead of the empty simping of the ignorant masses, that will only end up hurying you with the very tool you created for them
... where the f* are my meds?! 💀
I can get behind that too. The problem I saw with the "make your own engine" advice was when people said your game is better off with a custom engine. Truth is that most people just want to make games and the big 3 are much better at teaching you how to make games than making custom engines. But if you wanna get good at programming specifically, making an engine will definitely teach you a lot. It's about having the right goals.
I'd argue the exact opposite. Knowing the systems that go into your game first hand will help solve the inevitably difficult problems that always arise with game development. -t. AAA graphics engineer
When I first researched how to start programming games from scratch, I stumbled on that advice to build a game, not an engine. And I'm glad I did because it has saved me a lot of headaches, I'm sure.
That advice fits nicely with other tidbits I have picked up from others -- "program the most simple thing possible to solve the problem that you have."
"program the most simple thing possible to solve the problem that you have." - I especially like this one.
I have an interesting anecdote related to this: This happened more than 10 years ago at a gamed forum from my local community. A guy was talking about the engine we was building and we were all like "bro, don't waste time creating an engine, just focus on your game, there are many good engines and frameworks out there". This was before Unity was popular but still, there were a couple of good options already. However he replied that his engine had a different approach and was gonna be better that what was out there. Of course we were a bit skeptical. A random guy from some country far away from where the big money is, doing something that could compete with Microsoft XNA and the like?
Turns out the engine that guy was working on was what now is known as Godot Engine.
In conclusion, if no one made their games from scratch anymore at some point we'd no longer have anyone capable of pushing the boundaries. Nowadays you have anything from "[Genre] Maker" to different open source libraries so you can pick exactly which engineering problems you want to tackle and which want you want to delegate, whether temporarily or permanently.
It's also important to understand what you want to achieve. If you just want to create a visual novel and only care about narrative and visual then RenPy works just fine. If you want to learn more about programming and build something tailored to your needs knowing it will take longer then that's perfectly fine. The problem is when people think that building the game from scratch will be easier and faster than dealing with an engine, cause it's almost never the case.
It's so refreshing to hear this. I'm quite bored hearing the bad takes that many devs repeat because a "how to start game dev" video told them.
Thanks - I still think it's important to acknowledge that it's a trade-off either way :)
I'm glad to see another channel that advocates for the creation of a custom engine instead of using a pre-made game engine! 2 days ago, I saw a video called "Why I don't use game engines", and now I found your channel. I really support the idea of making your own game engine, in fact I'm making one right now, I have uploaded some devlogs to my youtube channel if you are interested to know about it. Great video.
Nice, I'll check it out :)
Thank you for shedding light on this. I actually started making a "game engine" in May I think and I was just doing it because I wanted to but it was kind of an impulse so it turned out a couple weeks later I didn't want to. I put myself in this situation where I built this thing for no reason other than not quitting a project and TH-cam series (took it off my channel thank goodness) and it was really depressing. After that, I started a game project from scratch again with Handmade values except this time I had a clear goal and I've not only stuck with this project but I'm making so much progress because I have clear goals. It's not about what you're making so long as you want to. A lot of people make these huge projects and they get criticized for "recreating the wheel" which is totally stupid because the tools and games of tomorrow are being built by people who are passionate about making good software no matter what that looks like which is a noble cause
I totally agree. If nobody works on "reinventing the wheel" then we won't have any progress in tooling. I'm happy to hear your new project is working out for you, stick with it :)
good point that needs to be brought up more. I absolutely hate people that tell you to "just use Unity/Godot/Unreal/raylib/CryEngine/[whatever the next hip thing is]"
dropping unity and godot in favour of my own solution for the game I'm creating has brought me way more satisfaction than I initially expected, especially since it let me familiarise with topics of how the game actually works under the hood more in-depth than any common resource on making games out there; meanwhile looking at unity and godot docs all I got was sheer confusion since they were way more abstract than necessary in my case
@Casper's Studio Indeed, it should always be said that taking a dogmatic approach to an engineering problem is foolish. There is, however, the programmer's sense of joy to considers as well - if your game can work in a generic engine and you enjoy using it, then that's the most likely the right course of action.
Thanks for the wonderful video again :)
I often think that people overestimate the work that is needed to get to fundamentals of a game ready, which would be the engine. Especially in 2D it's not too much work. Once I wrote a small 2D engine for a game jam within a week. I could load 2D images, I had audio, keyboard and mouse input, collisions and even a 2D animation system. That's definitely not out of scope for a game.
3D is a bit more involved but depending on what you want to have it's still not too much work, especially if you can reuse your code for projects.
Was this the one with a boombox by chance?
It's sad that corporations have convinced everyone that they are
not capable of making a game, without their specific software.
Many of those commercial game engines have tons of bloat that's
not necessary for most games. Commercial game engines are
convenient; up until that company decides to screw you over; trying
to please their investors.
Amen a "game engine" should be a byproduct of your game and not the other way around. There's so many small game engine floating around, completely abandoned. I'm currently working on a game made with Zig and Vulkan and all the engine work I do is just to support my game. In the of it all, I'll have something that I can show to people and if I want to make a similar / sequel to it, I'll just reuse the "engine" of the game.
3:09 oh yeah it's "all you need", except that you can spend pretty much an infinite amount of time on any one of those things if you want to get them on a level anywhere close to being marketable.
looking at the Hollow Knight example analytically, there's a ton of particle and lighting effects stacked on top of each other.
if you were to develop all of those systems from scratch it would take months if not years and at the end it would still look worse.
making your own game engine is great for learning (spent a decade building engines in JS, C, and Nim myself), but just don't expect anything marketable will come out of it.
There are tons of games that didn't use a 3rd party engine and look great.
Tooth and Tail, Stardew Valley, Teardown to name a few.
Also, pretty much every game before the 2000s used in-house custom engines.
I don't know you but I'd bet you suffer from the same thing I did which is lack of focus.
If you spent that time working towards one game or a series of games, it'd be nearly impossible to have a bad looking game after 10 years.
Just because you didn't do it doesn't mean others can't.
Also doesn't mean you can't - you just chose not to.
@@DylanFalconer please note that I did not say that custom-engine games never look great. the point is that you shouldn't expect to achieve something marketable anywhere near a comparable time frame - repeatedly. we actually want to try making some money here, right?
replace "tons of" with "tiny few", especially in relation to the amount of marketable games that are not using a custom engine. sure, it's theoretically possible, like have your girlfriend fund you for a decade like Stardew Valley guy, but these really are exceptions, sorry to say. and yes, if everybody would make their own engines like back in the day then that would be what you had to compete against, and so naturally it would be viable.
as for the focus, yeah, certainly, if one is capable to consistently work on only the most essential features, then they'd make fast progress. but honestly, is that realistic? I don't think that this is how our brains work in general, and if you are accountable only to yourself there's no way you'd maintain that. again - speaking generally. I am sure there are some prodigies.
All purpose = No Use.
If you make an engine...
Stick to making an engine FOR a specific game, not for EVERY and ANY game. Or, you'll never make anything but an engine, and chances are slim it would compete with the big 3 right now anyway.
This was REALLY helpful advice. I have exactly 1 game in mind, but I don't think it's possible in any existing engine. But this advice helped me see if I do need a custom engine...this is how I should build it.
Program for a purpose, don't hyper focus on repurposing your program. Unless of course high reusability WAS the goal.
It wouldn't bother me even if someone decided to make an engine to compete with the big ones. I dislike the disapproval whenever someone wants to do his own thing, like "Bro, are you gonna do that monolith that 50 programmers with years of experience did?".
But usually, building your own thing means something more simple than that. If you can rotate a 3d cube on the screen, it's a start. Then add a player camera, move around. Very basic C++/OpenGL or whatever is your toolset, for a basic game you don't need to build a big monolith.
Especially for 2D, it's so easy to render sprites and backgrounds, even if you did in pure software rendering in SDL. Then you have a background and a sprite you move with keys. Then maybe you can add collision and describe your level with blocks in a text editor :)
Which aligns with your point, that whan someone focuses on building the game rather than the engine, they end up building a very minimal basic engine for the game that is not as scary as when people discourage you from doing so.
I tried to make my game with Unity, and tbh the architecture that it imposes on your project is so dumb imo, for an example, for some reason your UI is bound to a gameobject in 3D space, same goes for any other "manager" object. Communication between scripts is only possible by exposing data to all other scripts in the scene and feels hacky af. So I just decided to try learning opengl and see what I can make myself.
Yeah, I really don't like all the nonsense you need to go through either. The trade-off is the massive community support and ostensibly the speed-up due to all the pre-built systems.
For my current project - I just need to render textured quads (pixel art), draw text, serialise and deserialise (all game data is in toml files), integrate with Lua (game logic in Lua files for easy modding), and handle keyboard/mouse events. I used Rust with glam (OpenGL), serde (Serialise), toml (TOML support), fontdue (Text rendering, very nice library), mlua (Lua interop). This pipeline is quite nice.
One thing I'm dreading is weird resolution support.
Apologies for the late reply!
imho it doesn't matter if you work on an engine or game - anything that gives you practice is good - the worst you can do is not work on anything at all
the real problem is the social pressure - it gives you the impression there is a right way to do things - the truth is there are no perfect solutions, no perfect engine or language, no perfect code or method - there is always a tradeoff
Considering making an engine just for your needs: let's say you are making a 3D game. Now you have to blend a character animation between walking and shooting. Now you have to write a whole Animation State Machine and Animation Blending and Animation Blend Tree Spaces, and probably spend weeks on that while all ready-to-use engines have that out of the box. Meanwhile, as indie, alone, you could have made a decent amount of progress IN THE ACTUAL game instead of re-inventing the wheel. Want to add hand IK aiming? Hell, you now have to add support to bone IKs. Good luck - (BUT, at the same time, ozz-animation handles all of that and is engine agnostic, so then you have to integrate it).
There's one famous gamedev TH-camr which I don't remember the name that was making his engine with C++ and live coding it, and then he spent, what, 2 months making animation blending and it was crap in the end? (and he is a C++ beast!).
I'm definitely not against libraries (or even engines) - I just wanted to outline the misconception. Building game engines is not for everyone or for every game! Most games can be created in one of the big 3.
Know your scope and what you're capable of. Even if you used the best tools, without the fundamental knowledge of how to use them you'd fall flat on your face anyway.
I think this is mainly a problem of how programming is taught in school now. The only method of programming that is ever shown to students is object-oriented programming. They are told and/or implied that you have to have an object for every possible scenario and instance. That is far from the truth. You only need to have what you actually NEED (hence the use of "need to have"). Really, to do this effectively, you need to use a combination of object-oriented programming and iterative programming skills, the ladder of which is never really taught to students (especially when they are forced to use Java for most of their schooling (which punishes excessive use of iterative programming), and are not able to use better programming languages for learning to include the bare minimum & make it work well (ex. C-like and Python)).
I didn't go to school, but I have noticed this trend of over-abstraction before implementing anything throughout my career, such as it is.
I think grouping data types with functions that act on those types can still be quite useful. I'm talking about circumstances where the code is very specific, like working with a generic Graph, or a Hex grid (two examples I have used it for recently). Unified/Universal Function Call Syntax (UFCS) allows that to be done pretty nicely even without classes.
I really don't get why so many people are making general-purpose engines. Back in the day every developer made their engine with a game in mind. These engines were also made for other non-programmers to use, such as environment artist and animators. I mean something like a level editor like Source Hammer is still lacking in many of these engines, the ability to just start hacking a level together is amazing.
I have a high respect for programmers that are able to build stuff from scratch, I mean it takes quite a lot of work , the rendering , the game logic , the physics alone, implementing algorithm, this way you become for what I believe a true programmer, programmers nowadays are just users, function calls all over the place in my opinion. so if you are making your own game engine for your game I respect that.
I've always felt the same way. Some games I want to make down the line are pretty scopey and make use of just about every technique they used in old SNES games, maybe a couple from PS1 era like Castlevania: SotN, but they all share a pixelart style with more sprite- and palette- focused special effects. Even GameMaker is too bloated and slow for what I want to do. We are making very different performance-usability trade-ins so in that sense my hand is kind of forced
I'm in a very strange camp here, I love making engines. I love solving problems efficiently and building abstract types from scratch. But I have never finished a game, there is something about the process of game design that drags me down, and every time I'm finished with the engine and starting work on the design I stop. So for me, I make engines not games.
I am somewhat similar. I can spend ages with my engines but even remotely finishing a game that is more than a game jam game, no way.
So I see these game jams more like opportunities on how to improve my engine.
I think the neat thing about programming is that you can do whatever you feel like doing, so maybe for some years you just work on a game, and then some years working on an engine or some other program.
That being said, I'm more interested in designing combat gameplay, so programming an engine from scratch is hardly my forte haha
My problems with making your own engine or from scratch are plenty.
1: I can't find good tutorials on how to implement a library for ECS into anything.
2: I want to make 3D games, and I want to work towards bigger environments and games. So a custom engine would most likely not satisfy my needs.
3: The tools in an engine are too many for most, but you'll still find those few gems that either speed up the process or adds something you love.
4: Time. Unity has a graphical animation state machine, visual shader graph, visual particle system. Meaning you do code with visual means that easy things.
5: Stream lined. In Unity I can save my blender project in a folder in my project and it will handle most things. A little work and I got a model, material with normals and textures, animation armarture and animations.
I would have to learn to understand Blender's blend files and pick them apart to be able to implement them into my engine. That's a lot of work just to get a necessity to simply work.
6: System. I can drag and drop, select and unpack, pack up, import and export in Unreal, Godot and Unity. All of these things are stuff I'd have to make myself.
7: Every function and feature I take for granted would have to be recreated every time I encounter I'm missing it.
8: Performance. Many engines are optimized like Unreal's c++ programming and nanite, Unity's new ECS and DoT system and Stride's core design for C# along with multi thread support. Even if I coded in c++ I would still have a field day trying to reach the same performance as them. Speaking of.
9: Coding. It's not just adding libraries but also knowing memory allocation, file types, code structures, hardware communication, code structure, graphics and physics implementation.
Things I don't know and barely know where to learn. Let alone how to make a base for a software to be a game or engine.
Something as simple as including a library like Archs or Svelto ECS into already existing engines or just in Visual Studio is non existent. Not tutorials or any ways explaining how to add these things. Just a github link and files and folders. Not a single step by step what does what and where goes where.
10: Porting. Engines nowadays work on being flexible and able to port to Windows, Mac and Linux as well as Android and sometimes WebGL. Commercial engines can afford a license for consoles which is something normal people usually don't. And this adds another layer to increase your work just to make the game accessible.
In short. engines aren't perfect, nothing is. But the things they offer makes even a moron like me able to make high quality results with enough work.
And the even more complicated stuff has been made by people already so things that would otherwise be twice the work of your entire project is now available.
And people have shown that a little extra work can twist the arm of engines to do what they want.
Building a game engine is a complex subject, it requires years of expertise, a vast amount of knowledge , if you are unwilling to learn about game engine programming and you just want to make games stick with an engine, and yet you still have to learn that engine as well, game programming, game engine programming are two different worlds in my opinion, and you just end being up an user to that engine.
must be all the pygame tutorials I watch, the aglo recommending this to me to keep my spirit up when I have no idea what I'm doing most the time
Not a lot of people realise that maybe people just want to make tools instead of games.
and I find it strange to discourage it because without these types of people you wouldn't have any type of game engines in general.
when you build something yourself you know how to use the engine fully and it's easy to create what you want instead of having to learn a already pre-made engine. During a game jam this helps a lot because instead of having to learn the engine you can just focus on creating.
also game jams are a good way to battle test your game engines it's good practice to make games with your engine so you know it does what you want otherwise you might be spending years on systems you might never use.
Yeah, there are a few people on the Discord server that just want to make tools and engines.
+1 on game jams being a good proving ground.
your explanation of a game engine made me clap my hands
My extension of this take : make an arbitrary engine from the stuff you used a lot and frequently when you made your MANY games. This implies you in the first place, make many games without a game engine, but in your style. That's where a engine starts.
Some engines do too much, you can use Raylib, MonoGame, Godot, Flax if it's a simple game, if you want something AAA you need Unreal possibly and also a whole team.
an engine written on top of Raylib would be nice, say a scene/map editor and other helpers.
ok but let's at least agree that Godot is the fairest of them all, went on a ride with her, still can't forget that night, 10/10
Cool! I'd be keen to hear about your experience with Zig for building a game
In my experience it's a great language and having access using C code directly is very handy for things that may be unimplemented. I drank the Rust coolaid and haven't used Zig in a while, so can't be super specific but I'll outline some things I like.
The standard library has really nice functions and data structures. ArrayList and HashMap (esp. the ez StringHashMap) built-in are the two most useful structures for gamedev in my opinion.
The defer keyword is great, every time you allocate something, make sure to defer a free (unless it's got a longer lifetime than the block, of course).
Something I don't like is that I can't know whether I'm passing by ref or not as Zig just decides based on the data-type of the parameter. I tend to use a lot of structs, then when I add something like an ArrayList to a struct, it may pass by ref. I didn't look into the exact rules as I ended up drinking the Rust coolaid while on holiday.
Apologies for the late reply, still getting used to reading and replying to comments.
@@DylanFalconer that's excellent, thanks! I'm equally apologetic about my tardiness.
Interesting that it "decides" to pass by ref or value. That's something I'm not sure I'd want to give up coming from C.
You're on the Rust train huh? So are we likely to see you rewrite your C engine in Rust? ;)
Also I didn't mention in my original comment, but I fully agree with the idea of making your own engine. If nothing else, it's an excellent learning activity.
great take Dylan 🥞
would you think the unreal engine would be good for first person non-shooting but more like medieval style combat games ?
Yep! It all comes down to what you want to do. Do you wanna make a game? Just use a game engine.
Now, if you want to, or have fun, having control and doing everything by yourself, go for a game engine. But keep in mind that if you wanna build a game engine, it's because you want to build the ENGINE, and make games above that, not to JUST make games.
Plus. I’m Creating 3D Game Engines Not Publishing it On GitHub, Git or GitLab. I Only Publishing it On Other Digital Libraries
How do I get to the point of competency where I can code something like a voxel engine and then a game on top of that
handmade hero is a nice place to start
So for someone completely new what would I need to do or where to start if I wanted to make a 2.5d with some lite 3d first person game like blood “build engine” or Star Wars dark force “Jedi engine”?
Make SMALL games and only add in what you need at the time to finish. And actually finish, no matter how trivial the game may be.
I’m Choosing “D” No Matter What
A man of culture to i see. those are some fine game engines😉
3:42 - The main language that I program in is Python. I know it isn't as good as C-like languages, but I use it cuz it helps me focus on programming logic instead of language so that I can learn instead of making functional pieces of code. For the same reason, I really like making engines and libraries because I can learn and when I actually need to write a functional program, I will already have many of the tools necessary to make it happen. However, I do this knowing my position in my education and that when producing a functional program, I will only need to write things which I need. I think there is a huge difference between writing engines like this and writing code to make a game work (like u covered) is that you need to know what to do when. However, I do think that the person programming can affect which one they would want to do (engine vs game only). I really enjoy writing libraries (as stated above) so I can use my own code later. I hate using other people's code many times because, no matter how hard I try, I just have a problem understanding other people's code. So I like to make my own self-developed tools which I can carry with me and give to others to use. I believe there are other people like me in this regard and would much rather make an engine than a game, so that others and themselves can use it later down the line to make games with. With that being said, I do think it is possible to be in the right by making a large engine with intent to make a game out of it, although you must be able to separate the development of the tools and the development of the game into two totally separate entities at two totally separate times.
I agree with everything you said in this comment, and the other one addressing OOP.
I also hate using other people's code for the same reasons, but I've gotten to the point of making my own operating system. Using a low level language like C or FORTH allows you to focus even more of your attention on programming logic than python, but you might end up having to focus on programming logic a bit too much.
I know there are people with your disposition and preferences, such as The Cherno here on TH-cam. He wants to build tools and engines, not games.
There's a place for you because you will build the tools that others will use to save time. Thanks for your contribution!
If you like Python and not want to get bogged down in C you can try Nim then, It is a Python-like language that compiles down to fast C code.
I've been writing a stupid little library in C for a bit now, and it's going ok. I've got my own math library that's more than likely slower than anything else I could have used... And that's about it right now... I've been wanting to make a 3D FPS game, so I generally know what I need but IDK what the best way to accomplish the whole thing would be. I've thought about switching over to an existing engine but IDK, that doesn't interest me much. I'm trying to figure out how one is supposed to... Well, figure this all out... I have no idea how to even architecture this thing I want to make. Do you have any advice?
For 3D FPS games, your best bet is to just learn how 3D renderers work. Once you can draw 3D things on the screen, well the rest depends what you are making...
Well, you got 2 out of 3 :D
i avoid programming as much as possible even though i'm decent at it so if i have the choice of using an existing engine that does pretty much everything i want better than most people would build on their own i would 100% pick an existing engine and learn its quirks
Well said !!
And who Made Unity thought that?
I wrote my own engine as I prefer to make 2D tile based games and it works great for what I do
Is toml faster than json?
Depends entirely on the parser, I just like the syntax more. It's easier since I'm hand-writing most of these files
Absolutely true. That's always what I say whenever I see someone say "Hey look, I made a game engine". I mean, why?
I don't think you should make an engine just for a single game or game idea. Even if you did, you wouldn't call it a game engine yet. It's just an abstract layer between your game and the OS/platform. But if you can adapt and morph and improve that same layer (and set of libraries) over time over multiple games, then you might start to call that a game engine. It's not gonna be jack-of-all trades like Unity, it absolutely shouldn't be at all. But it's an engine you've worked on with your blood and sweet nonetheless.
i have two games i want to create custom engine for, im gonna probably lose 10 years on it, but its worthy, but for everything else, i got ue and unity...so ...
Tip : write the game while writing the engine
I've spent more time fighting problems with the Unity engine than on making the actual logic and content of my game over these past 10yrs. I'd have spent slightly less time if I rolled my own. Way way less if I had just modified the Quake engine. Bah, hindsight
if you only want to make video games i think you should stick to a game engine but if you want to be a embedded system operating systems and video games or maybe websites or machine learning and any combination of that than you need to adapt
As a graphics engineer who works in industry, I don't advise this. Be familiar with the engines, but don't tie your knowledge to them so much that you don't truly understand the fundamentals. We can sus that out quickly.
@@johnjackson9767 This seems to be one of the best reasons to make a small game engine even if you never finish it, it is an opportunity for growth.
I have an idea for a game that's been kicking around in my head for years. There's no way I could "just use...." because none of them are built for the game I want. So the final game would be bloated with stuff it didn't need and I would still have to take time to create stuff that was missing. Using an all-purpose engine is fine if you just want to build another generic FPS where the only difference between your game and the other 75,637 on Steam is the color of your outfits. But look at all the hassle Unknown Worlds had when building Subnautica in Unity. Or the fact that CIG had to massively rework Cryengine for Star Citizen. Those engines lock you into doing things a certain way. They make all games feel interchangeable. It's far better to plan your game, decide how it should feel and work, then build the engine to accomplish exactly that.
My argument would be, writing a game isn't inherently the same as writing an engine, though it may become an engine. Because an engine is more of a framework than a game. There isn't anything wrong with writing a game from scratch. But to imply that is the samething as making an engine can be confusing.
I did distinguish between engines for 3rd party or unknown game use vs the engine built for a specific game. Every game has an engine, it may not have a name but it'll be required to transform the data, handle the input and display the current state
@@DylanFalconer Respectfully my problem is -- if everything is an engine, the term engine has no meaning. Admittedly the term engine is nebulous. But it does imply it being a framework that can be used to power multiple games.
@@DylanFalconer If you'll indulgence me, I would better like to explain my issue with calling everything an engine. I am currently working on making a game. I'm designing it so it can be expanded and reused.
The reason I wouldn't call what I have a game engine is because it's purpose made for the project I'm working on. While it could be adapted later, and if I made a similar project adapting it wouldn't be a problem, that's not the intent of the code base. The code is designed for the game. The code isn't designed for future games.
I'll stay out of your hair now, and have a wonderful weekend!
@@IamusTheFox I think it can still be referred to as an engine. Unless the game itself loads the data and everything needed. If it is a separate subsystem of the game that handles all the loading of data and drawing of things that the game calls into and is its own separate thing then that is still the engine, even if it is very specific to one thing which is your particular game and nothing else. Like a car, even if it's built from the ground up totally by yourself, you would still call what actually drives the wheels the engine no matter how custom or integrated it is. It may only work for that car and none else but it is still the engine of the car.
@@dawsonpate7385 would you call SDL or sfml a game engine?
One advantage of building yourself is you will know how it all works. 😅
I never got into using Unity, because I think it's a hot mess. Everything seems to be either deprecated or experimental.
I prefer Godot, but if I want to create all systems myself and practise my C++ I pick SFML or Raylib.
This comment aged well
nice.,
Thanks
I like to open windows and pretend I'm a millionaire.
Much easier than doing anything.
My thinking process is: if I'm to make a 3D game I'll go with unreal. If I'm to make a 2D game I would absolutely want to make my own engine.
Same 4 me
Agreed, AAA gaming is becoming generic as hell because everyone and their sister uses unity/unreal. If you want to stand apart from the hordes of people who have no clue how anything works inder the hood, make your own games from scratch. Then after you actually know what youre doing, you can easily pick up one of these engines.
Yes. No one has the grit to actually work and learn the craft anymore.
It will be a wake up call, when everything starts to become soo full of glitches and bugs and not many know enough to fix anything, Oh wait it is already like that. lol
So the choice is between using an engine that can do XY and Z vs building an engine that can do X maybe slightly better. Guess what will allow you to create your game sooner?
Players don't care what engine you used. If you make a living with game dev, your bills don't care if they are payed using this or that engine. And if you are a programming beginner you don't even have the option to care.
Building a game engine is a hobby, like watching movies. It has the goal of making you happy. There is no productivity in it.
Also duplication of effort is not beneficial to society. Imagine if instead of 50 mediocre engines we had 1 that could do everything and do it well.
Perfectly said. In an era where people are not just using engine but they are using multiple assets and leveraging AI, you will be stuck making 1970s game if you want to make an engine. Everyone I know who built their engine ended up making sub par games with 1980 graphics. If your idea is more ambitious and you want to iterate fast on an idea, then use an existing engine. The market is harsh right now and game dev is a business. Making your own engine is just a hobby.
If you want to make a game with hyper-realistic 3d graphics then I agree.
If you only care about getting to market ASAP then I agree.
If you don't care about becoming a better programmer then I agree.
If you are making a game that doesn't do anything technically difficult then I agree.
If everyone you know who built their own engine made bad games - what makes you think they would have built better games using an engine? That's a different skill called game design - has nothing to do with the tech (provided the tech to achieve their design is possible).
If your idea is "more ambitious" it may not even be possible in the big 3 modern engines.
I disagree about making a 1970s looking game if you make your own engine. There are plenty of modern examples:
Into the Breach, Eastward, Factorio, Noita, - tiny teams
Owlboy, The Witness - small studios
Making an engine is only a hobby if you never use it for commercial products.
For you (and most people), it looks like using an existing tool is the best solution because you have different goals.
This video was actually about the wide misconception of the quote - that you should build tech specific to your needs and not generalise for no reason.
EDIT: I just found this interesting read: gist.github.com/raysan5/909dc6cf33ed40223eb0dfe625c0de74
It's always still a trade-off. But it seems many people think it's worth it.
I completely disagree with you about this, but I'm glad you took the time to post your opinion. It's situational and not the point of this video anyway which is about the misconstrued quote in the title.
If you think engineering something is a hobby because someone else has already done a half-decent job at it, then how do you expect we will get different things in the future?
Who is going to make the "best single" engine when eventually nobody knows how to make them?
If making an engine doesn't interest you or suit your needs, then don't do it - it's that simple.
@@DylanFalconer To be honest I was overly emotional when writing that. I agree that different people have different goals and I should not enforce my goals on others. Sorry about that.
To put it in context it is a very pivotal time in my life for various reasons. I am switching career to solo game dev from something unrelated. I have little to no experience with programming or anything game dev really and on top of that I have a time limit to make something before my savings run out.
You can see why I feel a bit rushed and want to just put out something to prove that I can do this (it's scary). Also I enjoy the artistic and design parts a lot more than programming. Yes, my goals are different.
I do agree that someone has to make new engines or we would be in danger of stagnation. But those people have their motivations in a different order than me. There is no pressure building on their ass, so they can afford to take the idealistic approach. Also not everyone that wants to make games has 10 years of programming experience. A lot of people are motivated by the final product coming to existence, not by the act of programming and solving problems.
TL;DR: people make engines because they love crafting a great product, not for productivity reasons.
The low barrier to entry of commercial engines has been a net negative for the industry creatively and technically.
The question really is, do you want to make money.. Or are you making games for fun or your own satisfaction? If you want to make money, don't waste your time.
No the reason behind it is don't waste your time reinventing the wheel. Use what's available and build onto that. You also don't make your own graphic card from scratch to create your game so why making the engine.
Did you watch the video?
@@DylanFalconer yes and your arguments are wrong. Time is money. Don't waste your time building something that already exist. If you are not an expert in the game engine industry, you don't know the architecture and pit fails, your engine will suck. You will be introducing many new bugs, reinventing the wheel and it will be slowing you down. If you wanna build an engine build an engine but if you wanna make a game focus on making the game not an engine. Reducing dependencies is not necessary; look on the other languages. In website industry people are using packages which sometimes contains like 20 lines of code. Could they rewrite it from scratch? Sure, but what's the point? Also one thing is making simple 2D game with sprites and other thing is making 3D games with LOD, VFX, ambient sounds, fog, advance physics/game mechanics. You are competing in game industry not engine industry. You need to make better games not better engines.
@@just-jiu Which arguments are wrong?
@@just-jiu Factorio proves what can be done when developers actually know how to program and not just press buttons in an editor. its amazingly optimized and not some sluggish unity drivel that goes unresponsive and takes 40 seconds to load.
@@happygofishing more people are playing the "slow" Rust which take 2 hours to load than the super fast Factorio. DayZ is also written from scratch and after several years of development it's sluggish and cannot beat even default camera behavior from unity. Unity is just a tool and if you cannot use it properly your game will be slow and buggy. But it's better than not having any game at all. There are several major games written in DOTS Unity which performs well. You purposefully picked 2 edge cases to support your statement.