7 ms·

I'd recommend trying to make a game "from scratch", using only libraries, instead of an "engine", if you haven't done it before, and have only used fully-featur

I'd recommend trying to make a game "from scratch", using only libraries, instead of an "engine", if you haven't done it before, and have only used fully-featured game engines. it's good to learn how to solve problems using structs and pointers and memory, instead of thinking only in high-level primitives like Entities and Components and Prefabs and Scenes and Nodes. not only will you level up your knowledge of how computers work, but you might be surprised at how much easier it can be to structure your code and reason about it. spend a weekend making a simple 2D platformer with something like C and SDL. include support for multiple levels, a title screen, and maybe a pause screen. if you've never done this before, you might be shocked at how easy it is. you don't need a scene graph. you don't need a component system. you don't need garbage collection. if you're used to having all of these things by default, it's the only paradigm you'll ever know how to work within. once you've done this, feel free to return to using full-featured engines if you wish—but you may start to see the value in doing more things yourself, instead of trying to fit your ideas into complex, overly-generic, overengineered systems and abstractions you yourself didn't design. this is all assuming, of course, that your goal is, at least in part, to be able to honestly call yourself a "game developer" in general, as opposed to merely an expert user of a specific piece of software. if instead your goal is to just make something you want to make, without care for improving your knowledge and skills and craft, then by all means jump from one full-featured engine to the next, replacing your mental schema for "how games are made" with the high-level abstractions and systems of one complex piece of software with that of another. (if any downvoters could explain why they find this post to be disagreeable, I'd love to hear it.)

vunderba 3y ago
"this is all assuming, of course, that your goal is, at least in part, to be able to honestly call yourself a "game developer" in general" This is some Wagnerian level of gatekeeping snobbery right here. A game developer.... develops games by definition. They don't develop engines, they don't develop rigid body collision systems, they don't develop 3D renderers, they develop (aka make) games. If you find a suitable tool to facilitate the creation of your vision, you'd be a fool not to avail yourself of it.
- adamrezich 3y ago
  > They don't develop engines, they don't develop rigid body collision systems, they don't develop 3D renderers, note how I never suggested doing any of those things in the post-Unity pre-Godot weekend project I suggested—except for the "engine". if you call yourself a "game developer" in general—as opposed to an expert user of a specific piece of game development software—then you should intuitively understand the level of effort it would take to create an "engine", using C and SDL (or something like those—Zig and raylib, Jai and Simp, whatever), specifically for creating a simple single-threaded 2D platformer, with multiple levels and a title screen, in a weekend's time—it's far from rocket science. some arrays of structs, some functions that loop through those arrays to simulate and render stuff (as colored squares), some code that handles input and makes it change some variables in a struct, and it all runs in an infinite loop that breaks when the player presses Esc (optionally with a frame limiter). then from there you can add an "asset system" (arrays of structs, plus an ID enum and a load function, for textures and sounds), and a "scene" system ("TITLE_SCREEN, GAME, ..." enum, switches that branch on that, and a current level integer). (stretch goal: particles.) there's a tiny bit more to it than this, but that's most of it. for someone who calls themselves a game developer as opposed to an expert user of certain software, this should all be completely straightforward to write in a weekend, because these lower-level constructs—underpinnings to higher-level abstractions found in general-purpose game engines like Unity and Godot—arise naturally from thinking about the things the computer needs to do (functions) and keep track of (structs, arrays of structs, pointers) to make your gameplay come alive, more generally, unbound by tool-specific mental schemas. I'm not suggesting one write a game in assembly, but merely something a bit closer to that than GameObjects and Components or Nodes. proving to yourself that you don't need such abstractions to make a game is empowering, and causes "game engines" to be somewhat demystified for you, unlocking a breadth of new knowledge, understanding, and possibly even inspiration—if you've only ever thought about game development in terms of the high-level abstractions specific to a general-purpose game engine.
  - fennecfoxy 3y ago
    Ah damn bruh, I guess my artist friends aren't really artists since they don't know how to program photoshop from scratch. I'll let 'em know that they're just "expert users of certain software".
johnnyanmac 3y ago
>(if any downvoters could explain why they find this post to be disagreeable, I'd love to hear it.) https://aas.sh/blog/make-games-not-engines/ https://aas.sh/blog/make-games-not-engines/ I post this as someone who in fact is an engine developer, To my chagrin, most people don't want to actually work on engines. >this is all assuming, of course, that your goal is, at least in part, to be able to honestly call yourself a "game developer" in general, as opposed to merely an expert user of a specific piece of software. this gatekeeping doesn't help much either. there are multiple successes made on GameMaker from people who barely know more than the rudimentary sctipting/programming basics. I don't think many would argue with them being "game developers", even if they wouldn't necessarily get jobs at Naughty Dog or Blizzard. There's a lot about proper game design to learn that you can pick up without ever touching a line of code. Or even a computer if you want to go super old school. I'd only recommend your path to current computer science students hoping to work in industry after graduation, not someone who wants to ship an actual full game
- adamrezich 3y ago
  look at all the comments in this thread acting as though making a single-threaded 2D platformer "from scratch (with libraries)" in C (or similar) is some herculean task, when you and I know how simple and straightforward it is. specifically, those saying, "you mean, make my own engine?!", showing a complete lack of understanding of basic principles. I haven't kept up with GameMaker: Studio, but if it's still anything like Game Maker 8, then it should be very straightforward for any seasoned GameMaker user to spend a weekend or two making the 2D platformer example I outlined, in C or similar. GameMaker (or, at least, Game Maker) does lots of things the dead-simple way: resource IDs are just integer constants. when you draw_sprite(x, y, sprPlayer), sprPlayer is just 4, or whatever. this is a pretty decent simple API that could be replicated easily! GameMaker users who try this project out will discover how much easier it is to have most or all of your game's logic in once place, instead of split up into various Events in various Objects. they'll discover how, when you're doing things the simple straightforward way, you don't need to make an "objController" with a Code action in a Step event and a Persistent flag, and remember to stick an instance of it in your first level, just to get some logic to run every frame of every level of your game. you just write the code in your simulate()/update() function! it's that easy! after working on this project, the GameMaker user who has never tried anything like the project before can still go back to GameMaker and continue to use it if they find it to be a useful tool in rapidly developing the kinds of games they want to create—but they'll have gained immense experience, knowledge, empowerment, and possibly inspiration from having gone outside their box and having experienced a different, simpler way of doing things. maybe they'll reconsider if they need GameMaker for their next project—maybe they'll be better off owning more of their own code, if all they're using GameMaker for is easily replicated without it.
fennecfoxy 3y ago
Just more gatekeeping and elitism. Same reason that "C" devs sneeze on Javascript devs and for some reason act like JS devs "aren't smart enough to write C" as if that's the real reason. Bruh, write a game from scratch including engine? Why don't you write your own network stack and display drivers from scratch while you're at it? Hell, you won't truly know how the graphics are rendered until you build your own DirectX/OGL clone. There's a reason we do the work; so that other people can use it and build upon it. Everyone starting from scratch again is only a learning exercise _if that's what they trying to learn_.
- adamrezich 3y ago
  some gates need to be kept. if you use an LLM to generate a game for you, are you still a "game developer"? where does one draw the line? it's has to be somewhere, and "understands what a 'game engine' necessarily entails such that 'making a simple single-threaded 2D platformer "from scratch (using libraries)" in C or equivalent' isn't a scary thing, but rather very, very simple and straightforward" seems about as good of a bar as any—and it's a very, very low bar, one that anyone who is offended that they don't meet this criteria, should be able to achieve in two weekends, tops. then you can go back to using whatever general-purpose engine you want, secure in your improved knowledge about how games can made without using one. you seem to think that my 2D platformer example is some outrageously difficult task, too scary for you to make, which is exactly what I'm talking about—you should intuitively understand how little I'm actually asking for here, instead of being outraged at my suggestion.
- jcabreu 3y ago
  With that mindset, I'm really curious on how you view the industry trend in AI tools. Obviously its hit the art industry sooner, but there's more and more tools for game developers coming out now too. If you think the way you do about game engines and javascript, then if someone uses AI to generate a game by typing a paragraph about their game, do you really still see them as a game developer? Maybe that term isn't as important to you, but I'm willing to bet you would agree that artists would find it highly offensive if people who generate art using AI call themselves artists with as much authority as those who have disciplined themselves in the field for countless years. And that's avoiding the fact that with higher and higher level abstractions that people know what's even going on at all. Bro, have you tried debugging modern javascript frameworks? What a nightmare...The call stack dump alone is like 3 full pages of shit that nobody knows how it works, all built on shit that also nobody knows how it works. Absolute nightmare. Oh, but don't worry! Someone will build yet another stack of technology on top of that to give it a Band-Aid! Yikes.
nicce 3y ago
> (if any downvoters could explain why they find this post to be disagreeable, I'd love to hear it.) Making it from scratch takes enormous amount of (expensive) more to make any graphically competitive game. Sure, you can make 2D games even with vector graphics, but when you need anything more realistic without making every asset or 3d animations with collision checks manually yourself, you are in trouble and never deliver your game without AAA budget. There is a reason why game engines exists. They solve very difficult problems, in tested, reusable scenarios, providing cross-platform support out of the box. If your libraries calculate collisions, velocities etc. all or even add ray tracing, they are already engines.
- adamrezich 3y ago
  > There is a reason why game engines exists. They solve very difficult problems, in tested, reusable scenarios, providing cross-platform support out of the box. If your libraries calculate collisions, velocities etc. all or even add ray tracing, they are already engines. it seems that people these days don't really understand what necessarily constitutes a "game engine". this is why I am advocating for people to make small weekend game projects using languages and libraries that are lower-level than what they are used to working with. instead of trying to build the game you've always wanted to make, try making a weekend platformer project like I outlined above—I cannot understate how useful this to making you a better game developer, even if you do end up continuing to use a general-purpose engine that someone else made. demystifying these concepts and seeing for yourself, in a hands-on way, that you don't need almost any of what these big general-purpose engines give you, to make a playable video game, is incredibly empowering, and has zero chance of making you a worse game developer, at any rate.
- Cloudef 3y ago
  Writing rendering and collision code honestly is pretty easy compared to coding a game. Difference is that rendering, collision, etc shenigans is "solved problem", theres lots of papers. Game is the creative part, and there is no solution.
  - adamrezich 3y ago

vunderba 3y ago

"this is all assuming, of course, that your goal is, at least in part, to be able to honestly call yourself a "game developer" in general" This is some Wagnerian level of gatekeeping snobbery right here. A game developer.... develops games by definition. They don't develop engines, they don't develop rigid body collision systems, they don't develop 3D renderers, they develop (aka make) games. If you find a suitable tool to facilitate the creation of your vision, you'd be a fool not to avail yourself of it.

adamrezich 3y ago
> They don't develop engines, they don't develop rigid body collision systems, they don't develop 3D renderers, note how I never suggested doing any of those things in the post-Unity pre-Godot weekend project I suggested—except for the "engine". if you call yourself a "game developer" in general—as opposed to an expert user of a specific piece of game development software—then you should intuitively understand the level of effort it would take to create an "engine", using C and SDL (or something like those—Zig and raylib, Jai and Simp, whatever), specifically for creating a simple single-threaded 2D platformer, with multiple levels and a title screen, in a weekend's time—it's far from rocket science. some arrays of structs, some functions that loop through those arrays to simulate and render stuff (as colored squares), some code that handles input and makes it change some variables in a struct, and it all runs in an infinite loop that breaks when the player presses Esc (optionally with a frame limiter). then from there you can add an "asset system" (arrays of structs, plus an ID enum and a load function, for textures and sounds), and a "scene" system ("TITLE_SCREEN, GAME, ..." enum, switches that branch on that, and a current level integer). (stretch goal: particles.) there's a tiny bit more to it than this, but that's most of it. for someone who calls themselves a game developer as opposed to an expert user of certain software, this should all be completely straightforward to write in a weekend, because these lower-level constructs—underpinnings to higher-level abstractions found in general-purpose game engines like Unity and Godot—arise naturally from thinking about the things the computer needs to do (functions) and keep track of (structs, arrays of structs, pointers) to make your gameplay come alive, more generally, unbound by tool-specific mental schemas. I'm not suggesting one write a game in assembly, but merely something a bit closer to that than GameObjects and Components or Nodes. proving to yourself that you don't need such abstractions to make a game is empowering, and causes "game engines" to be somewhat demystified for you, unlocking a breadth of new knowledge, understanding, and possibly even inspiration—if you've only ever thought about game development in terms of the high-level abstractions specific to a general-purpose game engine.
- fennecfoxy 3y ago
  Ah damn bruh, I guess my artist friends aren't really artists since they don't know how to program photoshop from scratch. I'll let 'em know that they're just "expert users of certain software".

johnnyanmac 3y ago

>(if any downvoters could explain why they find this post to be disagreeable, I'd love to hear it.) https://aas.sh/blog/make-games-not-engines/ https://aas.sh/blog/make-games-not-engines/ I post this as someone who in fact is an engine developer, To my chagrin, most people don't want to actually work on engines. >this is all assuming, of course, that your goal is, at least in part, to be able to honestly call yourself a "game developer" in general, as opposed to merely an expert user of a specific piece of software. this gatekeeping doesn't help much either. there are multiple successes made on GameMaker from people who barely know more than the rudimentary sctipting/programming basics. I don't think many would argue with them being "game developers", even if they wouldn't necessarily get jobs at Naughty Dog or Blizzard. There's a lot about proper game design to learn that you can pick up without ever touching a line of code. Or even a computer if you want to go super old school. I'd only recommend your path to current computer science students hoping to work in industry after graduation, not someone who wants to ship an actual full game

adamrezich 3y ago
look at all the comments in this thread acting as though making a single-threaded 2D platformer "from scratch (with libraries)" in C (or similar) is some herculean task, when you and I know how simple and straightforward it is. specifically, those saying, "you mean, make my own engine?!", showing a complete lack of understanding of basic principles. I haven't kept up with GameMaker: Studio, but if it's still anything like Game Maker 8, then it should be very straightforward for any seasoned GameMaker user to spend a weekend or two making the 2D platformer example I outlined, in C or similar. GameMaker (or, at least, Game Maker) does lots of things the dead-simple way: resource IDs are just integer constants. when you draw_sprite(x, y, sprPlayer), sprPlayer is just 4, or whatever. this is a pretty decent simple API that could be replicated easily! GameMaker users who try this project out will discover how much easier it is to have most or all of your game's logic in once place, instead of split up into various Events in various Objects. they'll discover how, when you're doing things the simple straightforward way, you don't need to make an "objController" with a Code action in a Step event and a Persistent flag, and remember to stick an instance of it in your first level, just to get some logic to run every frame of every level of your game. you just write the code in your simulate()/update() function! it's that easy! after working on this project, the GameMaker user who has never tried anything like the project before can still go back to GameMaker and continue to use it if they find it to be a useful tool in rapidly developing the kinds of games they want to create—but they'll have gained immense experience, knowledge, empowerment, and possibly inspiration from having gone outside their box and having experienced a different, simpler way of doing things. maybe they'll reconsider if they need GameMaker for their next project—maybe they'll be better off owning more of their own code, if all they're using GameMaker for is easily replicated without it.

fennecfoxy 3y ago

Just more gatekeeping and elitism. Same reason that "C" devs sneeze on Javascript devs and for some reason act like JS devs "aren't smart enough to write C" as if that's the real reason. Bruh, write a game from scratch including engine? Why don't you write your own network stack and display drivers from scratch while you're at it? Hell, you won't truly know how the graphics are rendered until you build your own DirectX/OGL clone. There's a reason we do the work; so that other people can use it and build upon it. Everyone starting from scratch again is only a learning exercise _if that's what they trying to learn_.

adamrezich 3y ago
some gates need to be kept. if you use an LLM to generate a game for you, are you still a "game developer"? where does one draw the line? it's has to be somewhere, and "understands what a 'game engine' necessarily entails such that 'making a simple single-threaded 2D platformer "from scratch (using libraries)" in C or equivalent' isn't a scary thing, but rather very, very simple and straightforward" seems about as good of a bar as any—and it's a very, very low bar, one that anyone who is offended that they don't meet this criteria, should be able to achieve in two weekends, tops. then you can go back to using whatever general-purpose engine you want, secure in your improved knowledge about how games can made without using one. you seem to think that my 2D platformer example is some outrageously difficult task, too scary for you to make, which is exactly what I'm talking about—you should intuitively understand how little I'm actually asking for here, instead of being outraged at my suggestion.
jcabreu 3y ago
With that mindset, I'm really curious on how you view the industry trend in AI tools. Obviously its hit the art industry sooner, but there's more and more tools for game developers coming out now too. If you think the way you do about game engines and javascript, then if someone uses AI to generate a game by typing a paragraph about their game, do you really still see them as a game developer? Maybe that term isn't as important to you, but I'm willing to bet you would agree that artists would find it highly offensive if people who generate art using AI call themselves artists with as much authority as those who have disciplined themselves in the field for countless years. And that's avoiding the fact that with higher and higher level abstractions that people know what's even going on at all. Bro, have you tried debugging modern javascript frameworks? What a nightmare...The call stack dump alone is like 3 full pages of shit that nobody knows how it works, all built on shit that also nobody knows how it works. Absolute nightmare. Oh, but don't worry! Someone will build yet another stack of technology on top of that to give it a Band-Aid! Yikes.

nicce 3y ago

> (if any downvoters could explain why they find this post to be disagreeable, I'd love to hear it.) Making it from scratch takes enormous amount of (expensive) more to make any graphically competitive game. Sure, you can make 2D games even with vector graphics, but when you need anything more realistic without making every asset or 3d animations with collision checks manually yourself, you are in trouble and never deliver your game without AAA budget. There is a reason why game engines exists. They solve very difficult problems, in tested, reusable scenarios, providing cross-platform support out of the box. If your libraries calculate collisions, velocities etc. all or even add ray tracing, they are already engines.

adamrezich 3y ago
> There is a reason why game engines exists. They solve very difficult problems, in tested, reusable scenarios, providing cross-platform support out of the box. If your libraries calculate collisions, velocities etc. all or even add ray tracing, they are already engines. it seems that people these days don't really understand what necessarily constitutes a "game engine". this is why I am advocating for people to make small weekend game projects using languages and libraries that are lower-level than what they are used to working with. instead of trying to build the game you've always wanted to make, try making a weekend platformer project like I outlined above—I cannot understate how useful this to making you a better game developer, even if you do end up continuing to use a general-purpose engine that someone else made. demystifying these concepts and seeing for yourself, in a hands-on way, that you don't need almost any of what these big general-purpose engines give you, to make a playable video game, is incredibly empowering, and has zero chance of making you a worse game developer, at any rate.
Cloudef 3y ago
Writing rendering and collision code honestly is pretty easy compared to coding a game. Difference is that rendering, collision, etc shenigans is "solved problem", theres lots of papers. Game is the creative part, and there is no solution.
- adamrezich 3y ago