I believe the instinct to develop a game engine or framework comes down from loving programming and being passionate about mastering a tool. We humans love mastering something and we love masters, when we build something from scratch we own it, we are master of it and we lead the decision. That's so comforting and pleasurable, and the reward we see at the end of the path motivates us. But on the process it's too hard.
Nowadays I have the urge to combine a physics engine, rendering engine, ecs engine to develop my own game which I guess I'll quit in the middle.
As developers I believe we should limit ourselves from doomcoding.
For me, the interest in engine-making is to give myself a toolkit that is suited for the kinds of games I want to make, rather than an engine that is trying to be everything to everyone. Also to avoid the Unreal Engine monoculture.
(Considering the linked section) that is more or less how Petra Engine[0] came to be - making a gamejam game[1] for MSDOS over a few weeks. Though while i did make it for that specific game, i always had in mind that i may want to use it for other games in the future too so i tried to make it more "generic" and keep the engine and game bits separate while avoiding too many game-specific stuff (didn't fully manage it though - in the end i've been removing PAP-specific things and a bunch of hardcoded stuff over the years whenever i feel like using it).
That said, despite making a bunch of demos[2][3][4][5] since 2021 when i made the game, i never made any game using it after that as i always lose interest - perhaps i do need to be making an engine from scratch to keep myself interested :-P.
[0] http://runtimeterror.com/tech/petra/ (note the version is very old and i've made a lot of improvements since then - this includes the Codeberg repository which i'll move somewhere else at some point)
Reading the article show it talk about something else that build a "game engine" from scratch, what it says instead is *build a "engine"* to make the kind of games you will do over and over" that is more practical and attainable.
From developers this is how in-house frameworks work, that are mostly reusing other frameworks and libraries and create a sort of pseudo DSL.
I guess the really hard part about game engineers isn't writing them, it's making them portable to more than platform, which is the really boring, tedious, expensive part. this is why I'll never write a game engine.
I want to differentiate between "game engine" and "framework" here, even knowing the distinction is subjective.
To me a game engine includes UI elements that package the entire process of game development into a coherent application. Sprite editors, code editors, asset management, physics, all in a neat package. Bonus points I guess for coming up with a quirky bespoke internal scripting language that only gets used with that engine. You can wind up with a utility library that makes writing games easier but to me that still isn't a "game engine" per se.
And I think that's the really difficult part. Everyone probably just uses DearImGUI anyway but that's still an entire layer of abstraction and difficulty on top of writing the game utility code itself, and it encompasses things most developers won't find fun or interesting or even may not know how to do. How do you support multiple platforms? How do you deal with data files? How do you import and export a project? Handle input? Sound? You got a triangle on screen? Great! Now you have to implement the rest of the universe - textures, lighting, UV mapping, shaders, models, skeletons, rigging, animations. Now do physics. Every single aspect of engine design is an entire discipline unto itself.
Of course it also matters how specifically tailored and non-general you want to make an engine. Engines exist just for making RPGs or visual novels. But even then, to me, it isn't an "engine" unless it's packaged into a GUI with coherent design principles.
12 comments
[ 1.5 ms ] story [ 14.4 ms ] threadNowadays I have the urge to combine a physics engine, rendering engine, ecs engine to develop my own game which I guess I'll quit in the middle.
As developers I believe we should limit ourselves from doomcoding.
That said, despite making a bunch of demos[2][3][4][5] since 2021 when i made the game, i never made any game using it after that as i always lose interest - perhaps i do need to be making an engine from scratch to keep myself interested :-P.
[0] http://runtimeterror.com/tech/petra/ (note the version is very old and i've made a lot of improvements since then - this includes the Codeberg repository which i'll move somewhere else at some point)
[1] https://bad-sector.itch.io/post-apocalyptic-petra
[2] http://runtimeterror.com/pages/iv/images/44d7537fb719e00fdcd...
[3] http://runtimeterror.com/pages/iv/images/d22ff83dd5e5109e02e...
[4] http://runtimeterror.com/pages/iv/images/1da6a4bce430a8d8507...
[5] https://www.youtube.com/watch?v=zx9KmkTLcB0
It helps you build a full ray tracer / 3D engine only guided with tests, really powerful to learn test driven development.
What s cool is that just being driven with tests still allows you to do it in any language you want.
Plus you ll learn a quintillion of stuff about mathematics. This is really the kind of project that makes you go to a real senior SWE
From developers this is how in-house frameworks work, that are mostly reusing other frameworks and libraries and create a sort of pseudo DSL.
[1] Why D Programming Language?
https://www.youtube.com/watch?v=teWQbYvPBTg
[2] Art of Reflection:
https://store.steampowered.com/app/2290770/The_Art_of_Reflec...
To me a game engine includes UI elements that package the entire process of game development into a coherent application. Sprite editors, code editors, asset management, physics, all in a neat package. Bonus points I guess for coming up with a quirky bespoke internal scripting language that only gets used with that engine. You can wind up with a utility library that makes writing games easier but to me that still isn't a "game engine" per se.
And I think that's the really difficult part. Everyone probably just uses DearImGUI anyway but that's still an entire layer of abstraction and difficulty on top of writing the game utility code itself, and it encompasses things most developers won't find fun or interesting or even may not know how to do. How do you support multiple platforms? How do you deal with data files? How do you import and export a project? Handle input? Sound? You got a triangle on screen? Great! Now you have to implement the rest of the universe - textures, lighting, UV mapping, shaders, models, skeletons, rigging, animations. Now do physics. Every single aspect of engine design is an entire discipline unto itself.
Of course it also matters how specifically tailored and non-general you want to make an engine. Engines exist just for making RPGs or visual novels. But even then, to me, it isn't an "engine" unless it's packaged into a GUI with coherent design principles.