7 ms·

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 tod

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. For anyone interested: https://github.com/zinc-framework https://github.com/zinc-framework

adamrezich 2y ago
After trying to evangelize this exact mindset to people in the wake of the recent Godot drama, I've given up (or not, judging by my posts here…). Most people aren't willing to even investigate how easy it is to make “a game engine”, because the term “game engine” has been mythologized (due to Unity, Godot, etc.) into being this thing that's for all practical purposes impossible for the average programmer to build. “As a solo developer, either you work on building an engine, or you work on building a game, but if you're going to do the former, then you'll never complete the latter,” they say (in this very comments section, even). Well, sure… if by “game engine” you mean “general-purpose super-generic game engine,” and not “the smallest set of things absolutely necessary to transmute the idea I have in my head into playable form on this supercomputer I'm sitting in front of.” I don't really get it—I started programming games by learning Game Maker in the early 00s. By the time I was ready to move onto something more like “real game development” (C#/XNA), I was more than eager to structure things more according to how I wanted for whatever given project I was working on, rather than trying to cram my ideas into a somebody-else's-engine-shaped hole. But the freely-downloadable general-purpose game engines available these days, with their innumerable layers of wholly-unnecessary overly-generalized one-size-fits-all abstractions have gotten most people who use them to never even consider even imagining doing things in any way other than the way they're now used to doing them, using their tool of choice. They're more than happy to settle with thinking about game design purely in terms of whatever high-level primitives are exposed by their preferred engine, rather than even consider even imagining what it would be like to have complete control over how their game logic is organized and executed. Why simply define structs and make arrays of struct instances and iterate over them, when you could make a byzantine web of Nodes/GameObjects in the engine-provided scene graph? I guess that's how indie “game developers” these days have been trained to think. And it's crazy because compared to only a couple short decades ago, there's more information and resources available out there on the Web for free, that anyone can read and use to make building something “from scratch” (where “from scratch” means “using open-source libraries to do the parts you don't want to learn more about for the time being, such as rendering”) easier than it ever has been before! You can use something like SDL or Raylib to “sketch out” a gameplay prototype in shockingly few lines of code, then refactor everything so that all library calls are wrapped in function calls more suited to your use case, and then, later, if you want, you can replace those library calls with your own code! It's not difficult to do at all, but I think there's just some level of comfort people take in having a GUI editor for their “game engine” that they can open a blank project in and start clicking around to make things happen on the screen, compared to staring at a blank source code file and figuring out where to go from there. The ever-decreasing baseline level of curiosity and hacker-thinking in younger programmers continues to both baffle and depress me.
- alstonite 2y ago
  I pretty wholeheartedly disagree with this entire sentiment. For some people making a game engine isn't a monumental task, but implying that it's easy seems like an out-of-touch sentiment. There are many people who love making games but who aren't software devs that are enabled to make whatever they dream up via by the plug and play nature of game engines.
  - adamrezich 2y ago
    Have you ever tried to “make your own game engine” such that you can opine on this from a place of experience? General-purpose game engines like Unity and Godot are “plug-and-play” for only a small percentage of your game's development cycle—at some point, unless you're making an extremely trivial game, you're going to end up “fighting the engine” to make it do the thing you want it to do at some point or another—typically much more than once. If you weren't relying on someone else's underlying game engine substrate to build your game upon, then you would never encounter something like this. It would be entirely upon you to restructure your own underlying game engine substrate that you've built in order to build your game upon. You would know what each part of the machinery is doing, because you built it—you wouldn't have to guess and check and dive deep into documentation and forum threads and Discord channels just to try to figure out the optimal way to beat the engine into submission to do the thing you're trying to make it do. Have you seen the Raylib examples[0], such as the “2D platformer camera” example [1] (playable from the examples webpage)? It's really not a lot of code at all to get a basic playable game going—then from there, you just make more structs, store struct instances in arrays, and loop through the arrays to do 99% of the things you want a “game engine” to do that aren't covered by Raylib library functions. If you made a 2D platformer by starting from that example instead of using something like Unity or Godot, and do as I said above and wrap all Raylib library function calls in your own functions, then, in the absolute worst case, tomorrow you wake up and find out that Raylib has, for some reason, gone all “Our Machinery”[2] and deleted its public source repositories and informed you that you're legally obligated to delete all Raylib code on your machine. Not a problem—just switch to SDL or SFML or bgfx (for just the graphics) or something similar, spend a couple hours replacing the library function calls in your code, and you're good to go! You maintain complete ownership over the vast bulk of your game's code, because you wrote it yourself, except for a few library calls which can be easily replaced with something else. This is a much better situation to be in, compared to e.g. the Unity fiasco of last year! > There are many people who love making games but who aren't software devs This idea still baffles me—why do people try to make video games while abstaining from learning anything at all about software development? Like there's nothing wrong with using higher-level tools as a means of learning the very basics of the craft—that's how I started out, too. But wanting to learn a high-level tool and then stopping there and learning nothing more is like wanting to be an artist but never learning any art fundamentals and using an AI generator instead.[3] Video game development as a whole is extremely difficult, and a craft that should either be taken remotely seriously (especially if you wish to self-describe as a “game developer”!!), or taken extremely casually. If you want to take it extremely casually, then by all means continue to refrain from engaging with even baseline software development knowledge and principles. But if you want to take it seriously, because, for example, you wish to sell the software you've made to other people so they can run it on their computers, then really, making a “game engine” is the least of your concerns as a game developer. Actually figuring out the game's design is much more difficult and time-consuming! [0] https://www.raylib.com/examples.html https://www.raylib.com/examples.html [1] https://github.com/raysan5/raylib/blob/master/examples/core/core_2d_camera_platformer.c https://github.com/raysan5/raylib/blob/master/examples/core/... [2] https://old.reddit.com/r/gamedev/comments/wd4qoh/our_machinery_extensible_engine_made_in_c_just/ https://old.reddit.com/r/gamedev/comments/wd4qoh/our_machine... [3] Surely we all agree that someone whose idea of “creating art” is “learning how to best write a prompt for an AI art generator”, self-describing as an “artist”, weakens the term and is offensive to those who put untold amounts of time and effort into truly learning their craft—why should game development be any different?
samiv 2y 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." Yeah the really compelling thing to me is the knowledge building. For example what I do with my own project is that I take a look at some demo or example, let's say in Gamemaker or GDevelop and I ask myself a few questions: a) how is the sausage made? b) can I make the sausage and what are my ingredients? c) if I can't make the sausage yet, what do I need in order to make the sausage? For me this has been really the best way to build rather "deep" knowledge in this domain, as in knowing how something works under the hood (or how I think it works or at least how my version of it works) vs. knowing how to use it in Gamemaker / GDevelop. Ps. your github could use some screenshots I think
- kkukshtel 2y ago
  It has been crazy to build an engine for this exact reason. You quickly see what you take for granted and what requires work to implement but "appears" effortless. Things that seem so obvious and core you quickly find don't come for free. A simple example was that yesterday I was trying to debug why my MouseDown event wasn't firing every frame and was just firing once like MousePressed. After some digging in I realized that MouseDown isn't actually a primitive mouse event type in my platform wrapper code (Sokol). You get Up/Down. Doing this 1-to-1 wouldn't give people what they usually want (a MouseDown event that fires every frame), so you've got to figure out how to implement that yourself. As for the Github, it's all a work in progress! I'm actively working on the engine but it isn't really "released" yet. I've got a very active dev branch and some docs I'm working on before I do a proper "reveal". As for screenshots - what kind of stuff would you want to see? It's just a 2D engine so it's not like I have awesome graphics to show off. The point of it is that it's a code-only framework, there's no built-in editor or anything. I do want to have runnable embeds though of the demos!
FragmentShader 2y ago
> but when you create your own engine you are _fiercely_ aware of _everything_ it can and can't do The problem is that if you start gamedev by making engines, then you aren't aware of what you need to do. To give an example, if you make font rendering and looks blurry/pixelated, what now? Oh, and a simple 2D game takes 8 seconds to load, wonder why? Meanwhile, if you have ever made a Unity game, chances are you already know the keywords "SDF" and "Texture compression", because you tore down an already big engine for optimizing your game and accidentally learned about what features a game needs.
- sunrunner 2y ago
  > What now? > wonder why? What now is you have a fantastic opportunity to learn some topics in depth. Using Unity is also no guarantee that you'll come across those terms. And even if you do, if the Unity solution is to check the correct boxes you're exactly better off from a knowledge point of view. I'm not advocating for not using Unity, but I am advocating for learning, increasing the depth of your understanding, and just a general approach of curiosity and problem solving.
  - deleted 2y ago
    [deleted]
- saintfire 2y ago
  This was my experience. I dove into writing a niche game engine and stumbled over every hurdle that modern game engines solve. Been learning Godot lately and going back to writing an engine I'm confident I could trivally solve a lot of those hurdles. Additionally, if im trying to make a basic editor I can now see what is tenfold easier graphically (animations) and what I don't mind programming in.
  - kkukshtel 2y ago
    Writing an engine also has made more so much more aware of the implicit decisions of other engines and the "why" behind them. Largely I've come out of the process with much more respect for what they've done so far to get to where they're at.

adamrezich 2y ago

After trying to evangelize this exact mindset to people in the wake of the recent Godot drama, I've given up (or not, judging by my posts here…). Most people aren't willing to even investigate how easy it is to make “a game engine”, because the term “game engine” has been mythologized (due to Unity, Godot, etc.) into being this thing that's for all practical purposes impossible for the average programmer to build. “As a solo developer, either you work on building an engine, or you work on building a game, but if you're going to do the former, then you'll never complete the latter,” they say (in this very comments section, even). Well, sure… if by “game engine” you mean “general-purpose super-generic game engine,” and not “the smallest set of things absolutely necessary to transmute the idea I have in my head into playable form on this supercomputer I'm sitting in front of.” I don't really get it—I started programming games by learning Game Maker in the early 00s. By the time I was ready to move onto something more like “real game development” (C#/XNA), I was more than eager to structure things more according to how I wanted for whatever given project I was working on, rather than trying to cram my ideas into a somebody-else's-engine-shaped hole. But the freely-downloadable general-purpose game engines available these days, with their innumerable layers of wholly-unnecessary overly-generalized one-size-fits-all abstractions have gotten most people who use them to never even consider even imagining doing things in any way other than the way they're now used to doing them, using their tool of choice. They're more than happy to settle with thinking about game design purely in terms of whatever high-level primitives are exposed by their preferred engine, rather than even consider even imagining what it would be like to have complete control over how their game logic is organized and executed. Why simply define structs and make arrays of struct instances and iterate over them, when you could make a byzantine web of Nodes/GameObjects in the engine-provided scene graph? I guess that's how indie “game developers” these days have been trained to think. And it's crazy because compared to only a couple short decades ago, there's more information and resources available out there on the Web for free, that anyone can read and use to make building something “from scratch” (where “from scratch” means “using open-source libraries to do the parts you don't want to learn more about for the time being, such as rendering”) easier than it ever has been before! You can use something like SDL or Raylib to “sketch out” a gameplay prototype in shockingly few lines of code, then refactor everything so that all library calls are wrapped in function calls more suited to your use case, and then, later, if you want, you can replace those library calls with your own code! It's not difficult to do at all, but I think there's just some level of comfort people take in having a GUI editor for their “game engine” that they can open a blank project in and start clicking around to make things happen on the screen, compared to staring at a blank source code file and figuring out where to go from there. The ever-decreasing baseline level of curiosity and hacker-thinking in younger programmers continues to both baffle and depress me.

alstonite 2y ago
I pretty wholeheartedly disagree with this entire sentiment. For some people making a game engine isn't a monumental task, but implying that it's easy seems like an out-of-touch sentiment. There are many people who love making games but who aren't software devs that are enabled to make whatever they dream up via by the plug and play nature of game engines.
- adamrezich 2y ago
  Have you ever tried to “make your own game engine” such that you can opine on this from a place of experience? General-purpose game engines like Unity and Godot are “plug-and-play” for only a small percentage of your game's development cycle—at some point, unless you're making an extremely trivial game, you're going to end up “fighting the engine” to make it do the thing you want it to do at some point or another—typically much more than once. If you weren't relying on someone else's underlying game engine substrate to build your game upon, then you would never encounter something like this. It would be entirely upon you to restructure your own underlying game engine substrate that you've built in order to build your game upon. You would know what each part of the machinery is doing, because you built it—you wouldn't have to guess and check and dive deep into documentation and forum threads and Discord channels just to try to figure out the optimal way to beat the engine into submission to do the thing you're trying to make it do. Have you seen the Raylib examples[0], such as the “2D platformer camera” example [1] (playable from the examples webpage)? It's really not a lot of code at all to get a basic playable game going—then from there, you just make more structs, store struct instances in arrays, and loop through the arrays to do 99% of the things you want a “game engine” to do that aren't covered by Raylib library functions. If you made a 2D platformer by starting from that example instead of using something like Unity or Godot, and do as I said above and wrap all Raylib library function calls in your own functions, then, in the absolute worst case, tomorrow you wake up and find out that Raylib has, for some reason, gone all “Our Machinery”[2] and deleted its public source repositories and informed you that you're legally obligated to delete all Raylib code on your machine. Not a problem—just switch to SDL or SFML or bgfx (for just the graphics) or something similar, spend a couple hours replacing the library function calls in your code, and you're good to go! You maintain complete ownership over the vast bulk of your game's code, because you wrote it yourself, except for a few library calls which can be easily replaced with something else. This is a much better situation to be in, compared to e.g. the Unity fiasco of last year! > There are many people who love making games but who aren't software devs This idea still baffles me—why do people try to make video games while abstaining from learning anything at all about software development? Like there's nothing wrong with using higher-level tools as a means of learning the very basics of the craft—that's how I started out, too. But wanting to learn a high-level tool and then stopping there and learning nothing more is like wanting to be an artist but never learning any art fundamentals and using an AI generator instead.[3] Video game development as a whole is extremely difficult, and a craft that should either be taken remotely seriously (especially if you wish to self-describe as a “game developer”!!), or taken extremely casually. If you want to take it extremely casually, then by all means continue to refrain from engaging with even baseline software development knowledge and principles. But if you want to take it seriously, because, for example, you wish to sell the software you've made to other people so they can run it on their computers, then really, making a “game engine” is the least of your concerns as a game developer. Actually figuring out the game's design is much more difficult and time-consuming! [0] https://www.raylib.com/examples.html https://www.raylib.com/examples.html [1] https://github.com/raysan5/raylib/blob/master/examples/core/core_2d_camera_platformer.c https://github.com/raysan5/raylib/blob/master/examples/core/... [2] https://old.reddit.com/r/gamedev/comments/wd4qoh/our_machinery_extensible_engine_made_in_c_just/ https://old.reddit.com/r/gamedev/comments/wd4qoh/our_machine... [3] Surely we all agree that someone whose idea of “creating art” is “learning how to best write a prompt for an AI art generator”, self-describing as an “artist”, weakens the term and is offensive to those who put untold amounts of time and effort into truly learning their craft—why should game development be any different?

samiv 2y 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." Yeah the really compelling thing to me is the knowledge building. For example what I do with my own project is that I take a look at some demo or example, let's say in Gamemaker or GDevelop and I ask myself a few questions: a) how is the sausage made? b) can I make the sausage and what are my ingredients? c) if I can't make the sausage yet, what do I need in order to make the sausage? For me this has been really the best way to build rather "deep" knowledge in this domain, as in knowing how something works under the hood (or how I think it works or at least how my version of it works) vs. knowing how to use it in Gamemaker / GDevelop. Ps. your github could use some screenshots I think

kkukshtel 2y ago
It has been crazy to build an engine for this exact reason. You quickly see what you take for granted and what requires work to implement but "appears" effortless. Things that seem so obvious and core you quickly find don't come for free. A simple example was that yesterday I was trying to debug why my MouseDown event wasn't firing every frame and was just firing once like MousePressed. After some digging in I realized that MouseDown isn't actually a primitive mouse event type in my platform wrapper code (Sokol). You get Up/Down. Doing this 1-to-1 wouldn't give people what they usually want (a MouseDown event that fires every frame), so you've got to figure out how to implement that yourself. As for the Github, it's all a work in progress! I'm actively working on the engine but it isn't really "released" yet. I've got a very active dev branch and some docs I'm working on before I do a proper "reveal". As for screenshots - what kind of stuff would you want to see? It's just a 2D engine so it's not like I have awesome graphics to show off. The point of it is that it's a code-only framework, there's no built-in editor or anything. I do want to have runnable embeds though of the demos!

FragmentShader 2y ago

> but when you create your own engine you are _fiercely_ aware of _everything_ it can and can't do The problem is that if you start gamedev by making engines, then you aren't aware of what you need to do. To give an example, if you make font rendering and looks blurry/pixelated, what now? Oh, and a simple 2D game takes 8 seconds to load, wonder why? Meanwhile, if you have ever made a Unity game, chances are you already know the keywords "SDF" and "Texture compression", because you tore down an already big engine for optimizing your game and accidentally learned about what features a game needs.

sunrunner 2y ago
> What now? > wonder why? What now is you have a fantastic opportunity to learn some topics in depth. Using Unity is also no guarantee that you'll come across those terms. And even if you do, if the Unity solution is to check the correct boxes you're exactly better off from a knowledge point of view. I'm not advocating for not using Unity, but I am advocating for learning, increasing the depth of your understanding, and just a general approach of curiosity and problem solving.
- deleted 2y ago
  [deleted]
saintfire 2y ago
This was my experience. I dove into writing a niche game engine and stumbled over every hurdle that modern game engines solve. Been learning Godot lately and going back to writing an engine I'm confident I could trivally solve a lot of those hurdles. Additionally, if im trying to make a basic editor I can now see what is tenfold easier graphically (animations) and what I don't mind programming in.
- kkukshtel 2y ago
  Writing an engine also has made more so much more aware of the implicit decisions of other engines and the "why" behind them. Largely I've come out of the process with much more respect for what they've done so far to get to where they're at.