(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)
> perhaps i do need to be making an engine from scratch to keep myself interested
you're not the only one. jonathan blow has made tons of money selling games and also needs to write a whole programming language for 100h to keep him interested enough to yield 1h of content.
i can't really say much about the people who say don't program game engines (or whatever thing they don't like) in terms of opportunity costs (a generous name for this category of complaining), other than they would be bad at both making art and making money.
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.
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.
What's doomcoding? (It's not mentioned in the article and it doesn't appear to be a related term when I google it.) It sounds negative ("doom" + "we should limit ourselves" from it) but everything you said in the context before that sounds good.
I don't think I agree with this. Doomscrolling has a negative connotation - of wasting your time and being unhealthy for the mind. I don't see coding the same way. Sometimes, I code to finish a project and it's a major milestone and I feel accomplished. Other times, I just code something because it sounds like I'd enjoy it and it's fun. I feel fulfilled nonetheless, even if it goes nowhere. I wouldn't equate it to doomscrolling.
Yes coding itself is not like doomscrolling. I wanted to use that term because I lost so much time bu trying to reinvent stuff.
I wanted to make a game, and had an idea, but then I thought "why not making a game framework so I make my game". It was fun to build a game framework by mixing PixiJS, Rapier2D, ECS, writing my own loop logic and state management but then I lost the motivation. I just coded a framework for pleasure but at the start my point was making a game.
The desire to build something can cause our idea to be dropped.
I have worked briefly in the game industry long ago (not in engine teams though) and ended up writing a few engines for myself after leaving, a couple quite complete.
It’s just a hobby like another. I have zero interest in writing a full game on top of it, or even publishing it.
But do you know who NEVER gives me grief about it? People I know who work at Unity or [previous employer] writing AAA engines.
My last monstrosity is a Rust one with zero dependencies other than the std-lib/OS, Metal/DX12/Vulkan, its own physics engine, spatial audio, vm for scripting and other stuff. I will probably do nothing with it other than having updated my skills in a lot of areas.
I think we have to try these things at least once. My own attempt to write a javascript framework ended with me realising that I needed to put more effort into planning and research, which was a valuable lesson for me.
Yes building tools from scratch is a great way to learn. In my carrier a rewrote bunch of front-end frameworks, but then instead of rewriting everything from scratch I decided to simplify existing structures.
Once I tried to create my own front-end framework from scratch. I created signal library, mounting/unmouting, context etc but never able to write v-dom diffing or using existing vdom libraries.
Then I decided just implement my API on top of Preact. Preact did vdom-diffing for me and mounting/unmounting which was enough for my need.
The final project looked nothing like Preact, it even had it's own context system, data loading, signals, setup + render and context which just hooks itself into Preact Context but taught me a lot about how a front-end framework work.
Right, I think the usual point here that if your goal is to make a game, then this is usually the painful route and conveniently one that up-fronts the likely more exciting and comfortable part for a software engineer, namely the software engineering. It also tends to defer the very important business of learning rather quickly whether our idea even leads to a fun game in the first place
That said, it's still a worthwhile exercise that one can learn a lot from.
Balance is required for everything. There was a youtuber called Randy, he tried to build everything from scratch using C and it took him 6-7 years to finally release a game. Meanwhile I watched a youtuber who just made games from fake-ads in Unity and marketed it well and earned bunch of money.
Do we want money or do we want to get the pleasure of being an engineer and make money as a side quest?
There was a video of tsoding about why he doesn't have a job, he says "when I have enough money for my needs I just go into coding instead of working". I like his vision. He likes coding for the sake of programming and earns money as a side quest.
There is another angle: what if you want to express yourself, but, say, Unity is too limiting? Existing game engines were made to express existing ideas and while there is some stretch they do have hard limits.
Speak for yourself dude. I programmed a game engine in Java in 2011 right after I graduated college, and it powers a game that I launched on Steam in 2015. https://github.com/FourSeventy/sylver_engine
The first time i tried to make a game engine i didn't knew how to make a game engine and failed. The second time, same thing. But eventually i did manage to make a game engine. I even got to work professionally into making game engines for years. Nowadays i can make a game engine just fine.
Sure, trying to make a thing you don't know how to make will most likely end up with you not making it, but that is the case for pretty much everything.
(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)
[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
> perhaps i do need to be making an engine from scratch to keep myself interested
you're not the only one. jonathan blow has made tons of money selling games and also needs to write a whole programming language for 100h to keep him interested enough to yield 1h of content.
i can't really say much about the people who say don't program game engines (or whatever thing they don't like) in terms of opportunity costs (a generous name for this category of complaining), other than they would be bad at both making art and making money.
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.
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.
What's doomcoding? (It's not mentioned in the article and it doesn't appear to be a related term when I google it.) It sounds negative ("doom" + "we should limit ourselves" from it) but everything you said in the context before that sounds good.
Coding for pleasure I mean. We start a project and then get bored. Like Doomscrolling, for pleasure.
I don't think I agree with this. Doomscrolling has a negative connotation - of wasting your time and being unhealthy for the mind. I don't see coding the same way. Sometimes, I code to finish a project and it's a major milestone and I feel accomplished. Other times, I just code something because it sounds like I'd enjoy it and it's fun. I feel fulfilled nonetheless, even if it goes nowhere. I wouldn't equate it to doomscrolling.
Yes coding itself is not like doomscrolling. I wanted to use that term because I lost so much time bu trying to reinvent stuff.
I wanted to make a game, and had an idea, but then I thought "why not making a game framework so I make my game". It was fun to build a game framework by mixing PixiJS, Rapier2D, ECS, writing my own loop logic and state management but then I lost the motivation. I just coded a framework for pleasure but at the start my point was making a game.
The desire to build something can cause our idea to be dropped.
"Pridecoding"?
Maybe just “coding”?
"Hobbyhacking"?
I dunno if I agree it's doomcoding.
I have worked briefly in the game industry long ago (not in engine teams though) and ended up writing a few engines for myself after leaving, a couple quite complete.
It’s just a hobby like another. I have zero interest in writing a full game on top of it, or even publishing it.
But do you know who NEVER gives me grief about it? People I know who work at Unity or [previous employer] writing AAA engines.
My last monstrosity is a Rust one with zero dependencies other than the std-lib/OS, Metal/DX12/Vulkan, its own physics engine, spatial audio, vm for scripting and other stuff. I will probably do nothing with it other than having updated my skills in a lot of areas.
I think we have to try these things at least once. My own attempt to write a javascript framework ended with me realising that I needed to put more effort into planning and research, which was a valuable lesson for me.
Yes building tools from scratch is a great way to learn. In my carrier a rewrote bunch of front-end frameworks, but then instead of rewriting everything from scratch I decided to simplify existing structures.
Once I tried to create my own front-end framework from scratch. I created signal library, mounting/unmouting, context etc but never able to write v-dom diffing or using existing vdom libraries.
Then I decided just implement my API on top of Preact. Preact did vdom-diffing for me and mounting/unmounting which was enough for my need.
The final project looked nothing like Preact, it even had it's own context system, data loading, signals, setup + render and context which just hooks itself into Preact Context but taught me a lot about how a front-end framework work.
Right, I think the usual point here that if your goal is to make a game, then this is usually the painful route and conveniently one that up-fronts the likely more exciting and comfortable part for a software engineer, namely the software engineering. It also tends to defer the very important business of learning rather quickly whether our idea even leads to a fun game in the first place
That said, it's still a worthwhile exercise that one can learn a lot from.
Balance is required for everything. There was a youtuber called Randy, he tried to build everything from scratch using C and it took him 6-7 years to finally release a game. Meanwhile I watched a youtuber who just made games from fake-ads in Unity and marketed it well and earned bunch of money.
Do we want money or do we want to get the pleasure of being an engineer and make money as a side quest?
There was a video of tsoding about why he doesn't have a job, he says "when I have enough money for my needs I just go into coding instead of working". I like his vision. He likes coding for the sake of programming and earns money as a side quest.
There is another angle: what if you want to express yourself, but, say, Unity is too limiting? Existing game engines were made to express existing ideas and while there is some stretch they do have hard limits.
It helps to just write games and then over time an engine will emerge from the common code you carry across projects.
Starting from a checklist of features for a game engine almost always ends in wasted effort
Exactly.
Making game engine is the fun part, making actual game with it is the boring part.
Edit: Nevermind. Making a game engine is simple and easy. Anyone can do it.
Speak for yourself dude. I programmed a game engine in Java in 2011 right after I graduated college, and it powers a game that I launched on Steam in 2015. https://github.com/FourSeventy/sylver_engine
Yes, you're right. It's trivial to make a game engine. Anyone can do it. Even you!
The first time i tried to make a game engine i didn't knew how to make a game engine and failed. The second time, same thing. But eventually i did manage to make a game engine. I even got to work professionally into making game engines for years. Nowadays i can make a game engine just fine.
Sure, trying to make a thing you don't know how to make will most likely end up with you not making it, but that is the case for pretty much everything.
I don't think everybody thinks they can make game engine, nor do I think nobody has ever shipped a single game in their life