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.)
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_.
Just because the industry is used to creating a piece of art with just a stamp book (and stamp books are the hot thing right now), doesn't mean its the only way to create art. If you truly think that "we've done it, we've come up with everything we need to make games using these engines!" you lack serious creativity! If you want to LEAD the industry and not just follow it, you're going to have to step out of that comfort zone.
Not every game needs to be ANOTHER open world adventure game with crafting, an overhead camera, dialogue scenes, and click and hold menu buttons.
In the end, creating games at lower levels might inspire you to actually create something unique.
The same problem occurs in the music industry as well. Why even compose music when garage band offers audio clips you can just re-organize and loop in cool ways? Why use mics to record sound when there are plenty of already professionally recorded midi plugins for you to use?
My answer to you is creativity. Try doing something more natural and you might just create something fascinating, something nobody expected, something actually unique. Not only that, but you will be able to more fluently communicate your ideas to your audience, tweaking things exactly as you mean them to be. Not limiting yourself to the buttons and inputs in some interface.
There's always tradeoffs. These generic tools are made generic to reach the biggest audiences. But by being generic, they sacrifice the ability to be more specific, or else they become so much more abstract that they are harder to use than just writing something yourself.
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.
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.
> (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.
> 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.
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.
I'm not advocating for the average aspiring game developer to create a game project actually from scratch—even though, as you say, rendering, collision detection, etc. is in theory "easy" because it's such well-trodden territory. it's definitely useful to go down that route as well, but, still you get plenty of benefit from doing things in a more low-level way than you're used to, coming from something like Unity.
rarely if ever are video games created by someone having an idea, then typing some things into the computer to make that idea manifest itself in the form of an executable, and that's the whole process. the special thing about game development is that you flesh out the design of the game by actually working on it. you play around with things, explore the conceptual space of what you've created, and see what direction to take things in next. if you've only ever made games with Unity, then you only know how to think about problems within the conceptual schema of the way Unity does things (or worse: the way you ended up learning to use Unity so as to make Unity's annoyances maximally get out of the way of making your game).
when you sit down to make a game "from scratch (using libraries)", you're forced to completely rethink just about every aspect of game development that you take for granted. you don't have GameObjects and Components and Prefabs and Scenes—you have nothing, and you have to figure out how to make it into something. sure, you could just pull in some ECS library and try to continue living in that world, but there's so much benefit to be gained from making a genuine effort to not use such crutches—to figure out how to do things in a way that produces code that is reasonably efficient (not micro-optimized—just broadly "ok", efficiency-wise, is good enough for small projects running on modern computers).
you start to make observations like, woah: you don't need garbage collection/RAII/etc. at all, because, most of what you're doing that would require garbage collection/RAII/etc. is stuff that happens each frame, so you can just use a bump/arena temporary allocator that resets at the end of the frame, and, bam, that's 98% of what you were using GC/RAII for in the first place. the rest is either stuff you want to keep around for the entire duration of the executable's run, or stuff that's like per-level or per-map, that you unload and swap out when you transition between levels/maps. when you see things put into these terms, video game memory management doesn't seem all that scary, does it?
but if you've never tried to make a game "from scratch (with libraries)" on your own before, you might never encounter this. you might forever be tethered to the idea that video game logic can basically only be programmed using some kind of extremely high-level organizing principle/abstraction, like Unity's Scenes/Prefabs/GameObjects/Components, or Godot's Nodes. even if you continue using Unity or Godot (or whatever), you one day might want your game to do something complicated, and the only tool you have is a Node-hammer, so everything looks like a Node-nail, so you never consider the fundamental reality that really what you want is probably some combination of structs, arrays, and pointers, in order to make computers execute the vision of the game design idea you had in your head. and learning to be able to think about things in this way might even empower you to have the freedom to not just implement the idea you had in your head, but even do something crazier and more complex and cool, because you thought of how you could do it in the process of implementing the other idea you had!
"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.
> 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.
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".
if a sarcastic, defensive metaphor is what you were looking for, you could've spent a few more minutes coming up with a more logically-sound one. or you could've just engaged with my points directly, without the sarcasm.
if you can ONLY make art with Photoshop and completely lack any ability whatsoever to draw/paint/etc. without it, then yeah, you might not be an artist, but rather, a Photoshop-user.
hopefully we agree at least that LLM users are not artists, right? just because one uses a tool and art comes out the other end does not make one an artist.
An artist starts with PS, they master it can can make beautiful art with it. Then they need to use another product, or work traditionally - there'll be another learning curve but a lot of what they already learned can be reapplied. They're still an artist, even if they exclusively use PS & don't understand the minutiae of traditional art/techniques to smear charcoal until they decide to try it.
A game dev starts with Unity, same thing. They're still a game developer even if they only know how to use Unity - a lot of their knowledge is applicable to game development in general. If they switch to Unreal there'll be a learning curve, but not as steep as when they first started.
The same logic could be applied to cooking: we don't refuse to call someone a chef because they specialise in Asian cuisine, they're still a chef. A physics major is as much a scientist as a chemistry major is.
And as to your last point, it's pretty baity but maybe you have a very narrow definition of art? What is art? Is taping a banana to a wall art? If so then the person who did it is an artist. Personally, though I think you definitely disagree with it, I think using an LLM does make someone an artist as they're using a tool to produce something with aligns with their vision - if they just pressed a button without any input at all, I'm not sure I'd call that art unless it's something performative. But otherwise I put LLM users into the same category as people using PS tools - there's plenty going on under the hood, but the artist is still feeding it with input.
Let's say an artist uses a coloured pencil for some traditional art, are they now not an artist because they don't understand the chemical composition of the pencil that the company worked on so that it leaves a mark just-so? The pencil is a tool that the artist inputs into, but the artist doesn't have to understand the workings of the pencil from an atomic or quantum level to be considered an artist.
I guess I don't understand this strong desire to refer to oneself as a "game developer" completely regardless of one's level of knowledge or experience. I started off making games with RPG Maker 2000 and then later Game Maker when I was in middle school. I was most certainly developing games, but I would not have referred to myself as a "game developer", because I knew that I was using high-level tools to develop games, and I knew that I didn't know the first thing about Actual Game Development, really. later on, in high school, when I tried to use C# and libcairo to make a vector-graphics video game, I was confused as to why the game would run fine at 720p, but chug at 1080p. turns out I didn't know the first thing about what I was doing, and was doing all rendering on the CPU. embarrassing! but definitely the work of someone who was an aspiring game developer, but whom certainly would not consider himself to be a "game developer", unqualified, if asked.
why does the title matter so much to you? and why go to all these lengths to justify not learning the tiniest bit more about the craft of which you claim the title of craftsman, especially when I've gone the lengths I have to lay out exactly how straightforward it would be, and exactly what you have to gain from it?
this insistence over titles and outright refusal to learn basic principles is the sort of thing that makes me think that independent game development has become more of a fashion than a craft taken seriously.
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
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.
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.)