I would call both gatekeeping. All forms of creation; using AI, CSP or paint to make art, or using ChatGPT, a game engine or no game engine to make games, are all valid, with different restrictions and advantages.
Sometimes gatekeeping is necessary. None of the AI driven "make a game with a prompt" projects I've seen posted here (which would be the AI equivalent of a "game engine") have been capable of making a game worth playing, despite technically being "games", so I'll have to disagree with you on at least that point for now.
I specifically said complaining about game devs who use engines is unnecessary gatekeeping. On the other hand, complaining about artists (or game devs!) who exclusively use AI seems like a valid use of gatekeeping to me.
If you meet someone at a party who self-describes as a carpenter, and you say, “oh that's awesome, I've been trying to add onto my deck by myself with no prior knowledge of carpentry and I'm running into trouble, can you give me some pointers?” and he replies, “oh I don't actually know anything at all about carpentry, I've never done carpentry before, I just design mass-produced wooden products in CAD software”, then you'd probably ask, “okay, well why do you self-describe as a carpenter, then?”
If the term used to describe a craftsman of a given craft grows to include people who don't actually know anything about said craft other than engaging with higher-level abstractions over core practices of said craft, then what value does the term continue to have?
The idea that “gatekeeping” is always a bad word (for ill-defined wishy-washy reasons) is asinine, and the sooner we recognize this, the better.
I didn’t say gatekeeping was always a bad word, in fact I think some gatekeeping is often justified when it comes to AI art.
As far as the carpenter stuff, I feel like your metaphor is once again going much too far. Someone can be a carpenter whether they buy their wood at home depot or grow the trees themselves… but it would be foolish to say that the person who buys the wood pre-grown is not a real carpenter.
We are talking about game developers, not engine developers. If someone wants to be a game dev, they have to have developed the game, but not the underlying engine. I don’t see how this is controversial.
It's only “controversial” because you're thinking in framing terms that don't necessarily reflect reality—“making a game” and “making a game engine” don't need to be distinct, disparate things.
When Ska Studios (a husband and wife) made Salt and Sanctuary, they just made a game using a library, and a framework that they've evolved over many years of using XNA and then later FNA (both libraries, not engines!), to make their games. They don't “do engine programming” and then “do game programming” as separate acts done by separate people of separate disciplines—they're one and the same!
The whole point I've been getting at in my posts here is that “game engine programming and game development are necessarily distinct, practically unrelated disciplines” is a false premise that people have recently come to believe, and one that I believe deserves significant pushback.
My carpenter metaphor was just fine, you're the one making it more convoluted—when has “carpenter” ever been defined to include “one who grows his own lumber” in its definition, at any point in human history? That was never the case—“carpentry” is the practice of crafting things out of wood, and a “carpenter” is one who engages in and has knowledge of the practice of “carpentry”.
Thus, one who uses CAD software to design products that a factory will mass-produce using wood as a material could be technically referred to as a “carpenter”, because “crafting things out of wood” is, in an abstract sense, what they are doing. But it's clearly disingenuous for such a person, who lacks any knowledge or experience in “traditional” “carpentry”, to self-describe as such, precisely because he lacks the domain knowledge and experience that is expected of someone of such a self-description.
But if an actual carpenter, with actual carpentry knowledge and experience, then goes on to design mass-produced wooden products with CAD software, and he self-describes as a “carpenter” when you meet him at a party, you may think his self-description is a bit odd given what he does for a living—but at least he will in fact be able to give you some pointers about building your deck—thus proving his self-description to be meaningful on some level.
Well again, this is the problem with how far you’ve stretched the carpentry comparison. You said it was disingenuous for the CAD user to call themselves a carpenter… and as far as I understand, the CAD user is your equivalent of a game dev who only uses engines.
If your argument is just that sometimes game devs can also make the engine at the same time as making the game, then yeah I agree with that… but I think your earlier posts were saying a lot more than that (such as implying that engine users aren’t really game developers and are basically equivalent to AI art prompters).
Also it’s a little funny you bring up the example of an XNA/FNA game, because that’s already a relatively high level framework, the kind of code those devs would use is really quite similar to using an engine, especially another C# engine like Unity.
If you use someone else's high-level game engine to make a game (metaphor: use CAD software to design mass-produced wooden products), but you could write a simple game yourself “from scratch (with libraries)” (you have carpentry experience), then you're a game developer (carpenter). If not, then you're not, you're a proficient tool-user, with no domain knowledge outside of how to use said tool.
> Also it’s a little funny you bring up the example of an XNA/FNA game, because that’s already a relatively high level framework, the kind of code those devs would use is really quite similar to using an engine, especially another C# engine like Unity.
This is untrue and you know it. XNA/FNA does not have a GUI editor, a scene graph, a physics engine, an entity/component system, and many other things that Unity et al. have. When you use XNA/FNA(/MonoGame), you have to figure out how to structure your game logic yourself. The structure you think in terms of is by and large something that you've written yourself, as opposed to with something like Unity, where a complete structure is provided for you, and you learn to think in terms of the primitives it exposes to you (GameObjects, Components, Prefabs, Scenes).
Ok I think we’ve come to the root of the problem. You don’t realize how much software development people who use engines still have to do! Just because there are things like GameObjects and Components does not mean you don’t have to think about the game logic or structure. There are tons of ways to approach things, those are still just a relatively low level framework.
And just so you don’t think I’m making stuff up, I wrote a framework for Unity that acts much like XNA or some other 2D scene graph. It’s 100% code based and essentially doesn’t use Unity at all except as a publishing tool. It’s called Futile and it was used in popular games like Rain World and Mini Metro, as well as many of my own games.
However, I also have made games “the Unity way”, with GameObjects and Components etc. These two different approaches to making games are not nearly as different as you claim. I still have to think a lot about game architecture and system design even when using all of Unity’s built-in foundational stuff.
Yes, I do realize how much work people need to do to make games within arbitrary frameworks provided by game engines, and alluded to such in previous posts.
XNA never had a scene graph though, I don't know where you got that idea from. XNA and its descendants give you a basic game loop, and then it's entirely up to you how you structure your game logic from there.
There's nothing wrong with using someone else's structural backbone, like the library you made that you mentioned -- but everyone who wants to self-describe as a “game developer” should try to do this themselves, without such a thing, at least once.
Video games are computer applications, and computer applications consist of data, and functions that operate on said data. When you learn to think in these terms, stuff that seemed complicated before becomes very simple to reason about, and also very easy to write code for. Sometimes, a more generalized scene graph-type system is the best fit for what you're trying to do. Oftentimes though, it's not, and you're unwittingly contorting your thinking about the problem space to fit the shape of the predefined structure you've chosen to use.
One example of this is how Game Maker (in the old versions—I don't know much about the newer GameMaker Studio) is structured. You define “Objects”, and each Object has, in addition to many other properties, “Events”, each of which can have one or more “Actions”. You also define “Rooms” (scenes), with a 2D GUI editor that lets you place instances of Objects within the Room. The first Room in the Room list is where your gameplay begins.
When you first start using Game Maker, you make a Room for each level in your game, you define Objects, and you place instances of Objects in your Rooms. You define logic with Events within Objects -- init stuff goes in the “Create” event, and update stuff goes in the “Step” event. You drag and drop Actions into Events in your Objects to define gameplay logic.
This is all well and good, but eventually you grow out of using any Action except “Execute code”, which lets you type GML code in an integrated editor. Eventually, you learn that it's a good idea to keep your “controller” logic in a single instance of a single Object—separate from your player character Object—called “objController” by convention. You put a single instance of objController at (0,0) in your first Room, and mark the “Persistent” checkbox in objController so it persists across Room transitions.
At this point, you're “fighting the engine”. The engine does not provide a first-class means of defining “controller logic”, so your only means of doing something like this is as I described above: defining an entire Object type—which contains tons of properties and functionality that you'll never use for this Object—just to allow you to define some code that gets run every frame. As an advanced Game Maker user, you get used to it, but you wish that this common pattern was given first-class support, so you didn't feel like you were “fighting the engine” to do something so obviously common.
As you become an even more advanced Game Maker user, depending on the type of game you're making, you might end up eschewing most if not all of the structural features of the engine, just so it “gets out of your way” and lets you write the code you want to write to make the game you want to make. You might end up as I did—having only a single Room, containing only a single objController instance, and then handling everything else yourself from there.
When I reached this point as a teen, had Raylib or XNA existed and had somebody shown it to me, I would've said, holy crap, this is exactly what I'm looking for. (XNA did come about shortly thereafter, and it's where I ended up going after outgrowing Game Maker.) I just want to draw sprites and text and simple geometric shapes to the screen, and I don't really care about learning low-level graphics stuff to learn how to do that myself, so if you can handle that for me, that's great—but I can handle managing all of the game's data in structs and arrays myself just fine though.
But apparently this is not the case for many modern game engine users. They learn to “think in terms of” whatever primitives the engine provides them with, and then decide that that's good enough, they don't need to learn anything else. They're already thinking in Scenes/Prefabs/GameObjects/Components—why stop now?
I firmly believe this is huge mistake, because it's such a self-limiting way of thinking about game development, and it causes you to become entrenched in your limited way of thinking about gameplay logic. But before last year's Unity debacle, my views were very unpopular, because, what's wrong with just using Unity, man? Well, now we know: it's not a great idea to invest one's entire way of thinking about game development and one's entire business prospects so heavily in someone else's platform, when they can decide to fuck you at any point in time, causing you to suddenly realize how dependent you were on said platform.
Some of the upvotes I've been getting in this thread are somewhat encouraging—maybe people are starting to come around to my way of thinking? (Not that I have a monopoly on such thinking, by any means, of course.) But many of the comments are incredibly discouraging—people really like to tie their entire identity to the specific-engine-specific way of thinking about game design and development, apparently, even when pitfalls of doing so are clearly outlined, and it's blatantly demonstrated how easy it is to begin to think outside of that box.
I think you’re getting consumed with HOW the game is made rather than WHAT is actually getting made. There are tons of super creative and unique games being made with engines like Unity all the time (or even with Game Maker, for example check out my cousin’s game Fight Knight).
The idea that the constraints of an engine are some big problem is absurd. Constraints are a good thing, they breed creativity. There’s a reason every game jam has a theme and a tight time limit, yet result in some of the most unique game concepts.
I completely agree that constraints can breed creativity—but so can trying to do things a different way than you're used to. If you've only ever made games with very generalized data structures organizing your game logic for you in some predefined way, then PICO-8 can give you the best of both worlds!
There's plenty of games made with Unity and other engines that I enjoy—I'm currently playing a Godot game and it's great.
But if nobody pushes back on the current status quo rhetoric, then many people will a.) continue to have extremely incorrect misconceptions about what necessarily constitutes a “game engine”, and how difficult it is to make one, b.) not be encouraged to try to learn something new that has more general applicability outside of the domain of their preferred tool, and c.) continue to find themselves in situations like Unity developers did last year, or like what some Godot developers are experiencing right now—feeling trapped, with no immediately-viable path forward.
In this past year, I've built my own “engine” that runs a networked open-world game that loads world chunks in and out of memory as players move around the world—but unlike other games like this that I've seen, certain types of NPCs can also freely move around the world, even when there's no players nearby. This was not trivial, but it would've been at least an order of magnitude more difficult, and much less performant (even though I haven't done any optimization work on it yet!) if I was using someone else's engine, shoehorning my approach to solving the problems that this design I wanted to make presents, into said engine's way of doing things—instead of just defining structs and functions that do what I want them to do and writing the whole system myself. It wasn't trivial, but it was MUCH easier than I would've imagined before trying it myself, given that I'm using a library for rendering, and another for network sockets.
So constraints can certainly breed creativity, but if these constraints are left unchallenged for long enough, then you're just limiting your potential for what you can do.
It'll vary for now, but AI isn't quite in that league. It's in the same theory space where I'm sure you CAN make a decently enjoyable NFT game. BUt the concept is unproven as of now and if we're being honest: the scene is full of a lot of grifters.
That isn't' a dismisal nor comparison of AI to other tools. But we don't live in a vacuum, sadly. curent cultural and political issues will affect the reputation of the tools in question.
