I think the best advice for making your own game is: do what you're most excited to do. Do you spend time thinking about making your own game engine? Then start making it. Be willing to change course later if it's too hard, your time will not be wasted.
I got into gamedev by messing around with making my own engine, mostly focusing on low level graphics APIs, and that knowledge transferred well when I switched to a professional game engine. I knew about shaders and such and knew I was somewhat prepared to alter the engine I was using if needed.
Or, the other way, if you start making a game in an engine and you hate it, your efforts are not wasted. The truth is like 10 or 20 thousand lines of game logic can make a lot of games, and that's really not much code to port to your own game engine compared to the rest of the engine. All the art and other assets can be ported too. Plus, if you know a professional game engine you can use it for tooling or get some good architecture ideas to use in your own engine.
So, just get moving with whatever excites you most and be willing to change course.
I think maybe opposed to some of the other opinions here, making your own engine is much easier than you think and has a lot of potential upside.
On a walk today I was thinking about something specific that I think is under-discussed. Yes people bikeshed etc. but when you create your own engine you are _fiercely_ aware of _everything_ it can and can't do. As part of this, it's very easy to feel fully in command of your own toolset, and as such able to exhibit mastery over that toolset.
Granted, the scope of possibility when you start out building your own tool is narrow, but in some ways that acts as an easier onboarding to expertise instead of getting dumped into something as powerful as Unity/Unreal/Godot with little orientation and lots of edges you don't know about. In using some super-general you have to carve out your own path through its features, which is cognitive load (and time!) you don't need to worry about when you create your own.
For similar reasons I'm _also_ making my own engine. It's 2D-only engine that uses lots of modern C# features to make for rapid programming of 2D games. For the game I'm making with it to start, I'm using literally every feature of the engine, which is something I don't think I'd ever be able to say for something more general purpose.
Am I the only one who thinks the word "engine" is overused?
I've always assumed that "make a game, or make an engine" meant: if you decide to not use an engine when making your game, don't abstract it and also make an engine.
In other words, don't overengineer your game and build a generic engine when you don't need to.
Have I interpreted this wrong all these years? Or did the phrase morph because everyone thinks everything is too hard to program yourself these days?
Congrats! Game engines seem like such a gratifying pursuit that flexes every aspect of one’s skills. I just started reading Game Engine Archicture; if I can ever make the time I really want to take a crack at an engine.
Buttons840 ·74 days ago
I got into gamedev by messing around with making my own engine, mostly focusing on low level graphics APIs, and that knowledge transferred well when I switched to a professional game engine. I knew about shaders and such and knew I was somewhat prepared to alter the engine I was using if needed.
Or, the other way, if you start making a game in an engine and you hate it, your efforts are not wasted. The truth is like 10 or 20 thousand lines of game logic can make a lot of games, and that's really not much code to port to your own game engine compared to the rest of the engine. All the art and other assets can be ported too. Plus, if you know a professional game engine you can use it for tooling or get some good architecture ideas to use in your own engine.
So, just get moving with whatever excites you most and be willing to change course.
Show replies
kkukshtel ·74 days ago
On a walk today I was thinking about something specific that I think is under-discussed. Yes people bikeshed etc. but when you create your own engine you are _fiercely_ aware of _everything_ it can and can't do. As part of this, it's very easy to feel fully in command of your own toolset, and as such able to exhibit mastery over that toolset.
Granted, the scope of possibility when you start out building your own tool is narrow, but in some ways that acts as an easier onboarding to expertise instead of getting dumped into something as powerful as Unity/Unreal/Godot with little orientation and lots of edges you don't know about. In using some super-general you have to carve out your own path through its features, which is cognitive load (and time!) you don't need to worry about when you create your own.
For similar reasons I'm _also_ making my own engine. It's 2D-only engine that uses lots of modern C# features to make for rapid programming of 2D games. For the game I'm making with it to start, I'm using literally every feature of the engine, which is something I don't think I'd ever be able to say for something more general purpose.
For anyone interested: https://github.com/zinc-framework
Show replies
bcrosby95 ·74 days ago
I've always assumed that "make a game, or make an engine" meant: if you decide to not use an engine when making your game, don't abstract it and also make an engine.
In other words, don't overengineer your game and build a generic engine when you don't need to.
Have I interpreted this wrong all these years? Or did the phrase morph because everyone thinks everything is too hard to program yourself these days?
Show replies
braden-lk ·74 days ago
Show replies
slmjkdbtl ·74 days ago
Show replies