'Make a Game not an Engine' (Just use Unity/Unreal/Godot bro)

preview_player
Показать описание

"Make games, not engines" is often misunderstood to mean that one should not create games from scratch but rather use third party engines like Unity, Unreal, or Godot.

I have a little rant about how building specific engines for games is the way to go. Once capabilities are created, they can be carried forward into your next project.

Of course, all this assumes that one actually wants to be a good programmer - it's okay if you don't.

#unity #unrealengine #godot
#gamedev #gameengine #sdl2 #glfw #gameengineseries
Рекомендации по теме
Комментарии
Автор

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.

bonehelm
Автор

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.

rafaelbordoni
Автор

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.

LisandroLorea
Автор

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

handmadegamesdev
Автор

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.

Lebert
Автор

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

evan_game_dev
Автор

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.

Skeffles
Автор

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.

hawkbirdtree
Автор

good point that needs to be brought up more. I absolutely hate people that tell you to "just use 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

DaMiK
Автор

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.

tv
Автор

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.

Pariatech
Автор

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.

honaleri
Автор

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.

Optimus
Автор

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

bobobobos
Автор

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.

holleey
Автор

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.

Noble_Savage
Автор

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.

TheExtremeCube
Автор

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

AlfredBaudischCreations
Автор

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.

DmitryZajarchenko
Автор

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

dragonfire