🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Begin by learn create own game engine or directly learn create game via game engine like UE?

Started by
8 comments, last by Tom Sloper 1 year, 10 months ago

Hello, I have a question. For someone how want to learn the game engine development but also search to prove his skills in game development in general.

By what this person need to begin to learn: need to learn C++/OpenGL/SDL then recreate the basis of a game like Minecraft from Scratch?

Or learn C++ (then C++ UE Version, so C++ Blueprint) + Unreal Engine, etc ...?

What is the best between begin by learn how to create own game engine (use for own game) or how to create game (with a pre-existent game engine like UE)?

Knowing that I search to become Game Engine Software Developer.

PS: I already know well Python and C, so C++ would be relatively easy to learn. I will soon have 4 mouths to learn at full-time, so I have time, complexity and difficulty do not scare me. And by create my own game engine, I'm some fool how want to do better that Unity or UE. I just want to create MY own game engine, with my philosophy, my objectives, etc … If I can create the game engine I dream in 10 years (or more), that will be fine.

Advice on which path is better and why it is better, will be really helpful and thankful.

Advertisement

Do not attempt to create an engine if you have no experience making games at all beforehand.

I've been creating my own game engine for, funnily, also about 10 years by now. Since about 3 years I'm at a place where I'm seriously having better workflows that I could achieve with Unity, but since you mentioned that you don't mind it taking 10 years, hey, there's a chance.

But you need to have an idea about how other engines work, and games in general, before you being working on your own. For example, alongside my engine I'm developing an 2d action-rpg with an expected 40h of story-content. I started this project in Rpg-Maker XP, and many of the design-choices are inspired by how the rpg-maker is actually really terrible in many regards. So I aim to produce workflows that allow me to produce similar content, but better, larger, and with lot less overhead. How'd I know any of this if I didn't previously try? I wouldn't.

Similarily, working in other game-engines that are not quite as limiting as the rpg-maker can be a different source of inspiration. Even if I hate unity with a passion there are certain aspects that are worth mimiking. My visual scripting-language is entirely based around the concept of blueprints, again with my own spin and improvements, but not possible îf I hadn't had some experience in Unreal.

So definitely get some experience with games to even be able to know what a game-engine requires, rougly. For reference, I had about 4 years rpg-maker experience when I started my own engine, and I've started getting experience with Unreal about 2 years after I began. Unity was even later in my job, but I definitely wish I'd started with both sooner, would have guided me in a better direction from the start.

@Juliean

Thanks for the answer. So, I will create a game (probably never 2D, but 3D) with Unreal Engine to understand what really is a game engine and a game (as deep as I could). Then, when time come to the day that I judge I understand enough to even believe that I can realisticall start learn and greate my own game engine.

Thanks.

I second that plan – you need to know what the tool is supposed to do, before you can create a good tool.

Trying a few different engines will also be helpful, because there are different ways of accomplishing tasks. Checking out Unreal, versus Godot, versus Unity, versus something a little more esoteric (Cube, C4, Construct, Lumberyard, …), will be helpful for comparison. Also, focus on engines where the source code is available, so you can step/debug into the engine to actually see what's going on. (Unfortunately, this counts out Unity, where the engine itself doesn't come with source.)

enum Bool { True, False, FileNotFound };

TheColorlessWitch said:
Advice on which path is better and why it is better, will be really helpful and thankful.

Two good options based on your description, either may be better or worse depending on your details and preferences.

Option 1 is to start with an existing engine like Unreal (since you mentioned C++) and dig in. Try to make something very small. Follow tutorials. You'll be doing a mix of mostly design and a little programming, but in short order you can create games where the logic is simple but the graphics and technology are amazing because they come from the engine.

Option 2 is to program using libraries like you mentioned, SDL is a good one of many, and build it all leveraging those libraries. Start with programs like a pong, connect four, and tetris. You'll be doing a ton of programming and digging into references, and very little design or gameplay logic. You'll learn more about programming and processes, but the game won't be very shiny until you iterate on it for a while.

The first option can get you exposed to more functionality that employers are looking for, but it will be only within the context of the engine, mostly tutorials, and won't be varied, mostly will be superficial programming. The second option gets you exposed to more code and potentially more programming practices, but it will not show you how big engines work.

Don't plan on re-creating Minecraft. The game you know today in 2022 is almost nothing like the one developed by a single person in 2009 as a procedural cave dungeon. The game you know today is a multi-billion dollar project spanning more than a decade of continuous development. About the only similarity is the use of voxel blocks.

Juliean said:
Do not attempt to create an engine if you have no experience making games at all beforehand.

Agree to that, but you can start with some other things:

Learn C++/OpenGL/SDL, input / output, audio, etc.
Make a very simple game. (Pong, PacMan).
Add support to load assets like meshes, textures…
Make another simple game (Doom, Minecraft), and see which parts of the former game you can reuse.
Also see what you should have done different, and learn from mistakes or bad designs you now regret.
You may need to change the code base, sometimes you'll decide to rewrite something from scratch.

It does not make sense to start with developing a game engine, but it totally works to start with simple games.
After some time, you probably get some basic engine out of that, covering at least the runtime systems.
Then you can add more features (integrate a physics engine) but also tools (editor, scripting language). Whatever you need while working on more small and simple game prototypes.

Nothing speaks against looking at other engines while doing all this, or just whenever you're curious about how they do some feature you're currently interested in.
You ask us to help out on a decision, but i do not see a need for this decision.

Thanks for all the answer. That help me.

I am in your shoes, so I can relate. Except that I chose to build my own engine, because not understanding what makes the technology tick feels REALLY disappointing to me. I guess if you can find the right mindset, then you can also find the right source of motivation - because you will need A LOT of motivation if you choose to make an engine. I'm not understating here, as I'm sure you also picked up from the other comments.

You wrote that you don't know C++ - expect that to take more than 1 year. If you don't know graphics programming, then that's a solid 3-4 years. Building memory allocators and tracking systems also 2 years. A lot of these topics take a long time, depending on your skill level, education, and perspiration. But they are all intertwined and studied simultaneously. 10 years is a really good and realistic estimate.

Also, don't give up. I think the world needs more people who are not scared of deep-diving into the technology stack rather than just pressing buttons in Unity - otherwise we will get to a place where nobody understands how our software systems work. And that is a scary prospect.

Four-month-dormant thread locked.

-- Tom Sloper -- sloperama.com

This topic is closed to new replies.

Advertisement