2 comments

  • kyzcdev42 minutes ago
    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&#x27;s so comforting and pleasurable, and the reward we see at the end of the path motivates us. But on the process it&#x27;s too hard.<p>Nowadays I have the urge to combine a physics engine, rendering engine, ecs engine to develop my own game which I guess I&#x27;ll quit in the middle.<p>As developers I believe we should limit ourselves from doomcoding.
    • whstl16 minutes ago
      100% agree.<p>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.<p>It’s just a hobby like another. I have zero interest in writing a full game on top of it, or even publishing it.<p>But do you know who NEVER gives me grief about it? People I know who work at Unity or [previous employer] writing AAA engines.<p>My last monstrosity is a Rust one with zero dependencies other than the std-lib&#x2F;OS, Metal&#x2F;DX12&#x2F;Vulkan, its own physics engine, spatial audio, vm for scripting and other stuff.
    • daledavies35 minutes ago
      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.
      • kyzcdev23 minutes ago
        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.<p>Once I tried to create my own front-end framework from scratch. I created signal library, mounting&#x2F;unmouting, context etc but never able to write v-dom diffing or using existing vdom libraries.<p>Then I decided just implement my API on top of Preact. Preact did vdom-diffing for me and mounting&#x2F;unmounting which was enough for my need.<p>The final project looked nothing like Preact, it even had it&#x27;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.
      • vector_spaces19 minutes ago
        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<p>That said, it&#x27;s still a worthwhile exercise that one can learn a lot from.
    • indy17 minutes ago
      It helps to just write games and then over time an engine will emerge from the common code you carry across projects.<p>Starting from a checklist of features for a game engine almost always ends in wasted effort
  • dvh6 minutes ago
    Making game engine is the fun part, making actual game with it is the boring part.