[alstonite]

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.

[kitd]

I'm not a game dev, but I had a lot of fun making an ECS system by following ideas in an article I found (and which I have now annoyingly lost).

It's a very educational exercise that any dev would benefit from, game dev or not.

[adamrezich]

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

[1] https://github.com/raysan5/raylib/blob/master/examples/core/...

[2] 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?

[_gabe_]

You seem to be very intent on insisting that anyone can make a game engine (which I mostly agree with). But, it’s not easy, even when you use a pre-existing framework like Raylib. I’ve used frameworks like Monogame, I’ve used bare metal C++ and OpenGL, I’ve used the HTML canvas and JavaScript, I’ve built physics engines and used physics engines like Box2D or Havok. What I’m trying to say is I’ve done a lot of game engine-y stuff at various levels of the stack.

I’ve _also_ used Godot, Unity and Unreal. There’s a tremendous difference. I just started learning Godot a week ago and I already have the core game loop practically done in a new RPG. Sure I could’ve done the same thing using C++ and OpenGL (or Raylib or something), but I would be missing out on a lot of useful things that _just work_. Godot’s BBCode text labels are amazing and give my dialogue boxes a whole bunch of character out of the box. The tilemap editor allows me to just build my levels without having to build an editor first. The lighting system can add a ton of visual polish with very little effort on my part.

I’ve also dabbled in VR games with Unreal. And I’ve tried making some simple 3D games in Unity. Is this all possible without those engines? Yea. Would I have been able to experiment with the kinds of tech I got to play with if I made it all myself from scratch? I doubt it (not because I couldn’t do it, I just don’t have the time).

Another thing to consider is porting your game to different platforms! There’s a whole lot of variability in what kind of support you’ll get for that with something you made yourself or a framework like Raylib.

Anyways, from someone who has experienced both sides of the coin, you’ll end up fighting with the engine either way ;) There’s nothing wrong with using a general purpose engine.

[adamrezich]

Would you not say that learning how one could possibly make a game without using someone else's engine that does everything for you made you a better game developer, even if you end up choosing to use one?

[_gabe_]

That’s completely besides the point. I agree that working on an engine can be very fulfilling and round you out as a developer. But it’s not easy and I wouldn’t recommend that somebody who just wants to make a game go down that path. I’m pretty sure some of my favorite games like Hollow Knight would have never been made if they decided to just build the engine as well.

[adamrezich]

What is it specifically about Hollow Knight that makes you think it never would've been made without using someone else's engine? I didn't get too far into it myself but in terms of gameplay systems it seemed like a very standard 2D metroidvania platformer, except with a fantastic visual style.

Compare and contrast Salt & Sanctuary, which was uses FNA (which is a library, not an engine).

[_gabe_]

The fact that it’s a game that was developed by people that were self-proclaimed “non-coders”[0] using a plug n’ play game engine Stencyl (a no code engine) and then later switching to Unity. It seems to me the plug n’ play nature enabled them to gain traction with a prototype that led to the full fledged game.

This one quote on page 2 from the developers really hammers home this point:

> Those limitations aside, working in Stencyl has been fantastic. Ideas come together really easily and the tools are all intuitive. We definitely couldn't have come so far in such a short amount of time without it.

[0]: https://community.stencyl.com/index.php?topic=36539.0

[jsnell]

Because the people writing the game did not have infinite time and budget, and spent their resources on making the game rather than the engine. That allowed them to a) finish the game at all, b) make a game of bigger scope and higher quality. Maybe (just maybe!) they could have finished a game when rolling their own. But it would not have been the Hollow Knight we know.

It's great that you're enthusiastic about writing your own engine. I'm kind of in the same boat: I'm opinionated on software engineering and architecture, and my opinions don't line up with any of the existing engines. So I roll my own. But it's not actually an efficient use of my time, and as a result I don't write as many games as I'd prefer to, and the projects often end up down-scoped from the original vision just to finish them. It's a suboptimal way to work, but it's the one I have to use since any time I try using an engine I give up in disgust and get nothing done.

What's not so great is that you're ignoring the very obvious upsides of using an engine, pretending it's only downsides, and pushing your personal preference on other people as the obviously correct way to do things. Your bafflement on why anyone would use an engine is showing a distinct lack of empathy. Not everyone thinks like you, or has your priorities. You want to write a toolset and demonstrate your mastery of that toolset; some others just want to make a game. And you have no business telling them that their goal is invalid and they should instead copy your priorities.

[johnnyanmac]

>That’s completely besides the point.

I think it's a worthwhile thing to consider instead of dismmiss.

>But it’s not easy and I wouldn’t recommend that somebody who just wants to make a game go down that path.

Nothing is easy in game development. You can focus on whatever sector you choose, but don't expect an easy ride. That's why my honest first step to "how do I become a game programmer" is to fire up a terminal and write a Hello World in C or C#. I always approached concepts bottom-up, personally.

>I’m pretty sure some of my favorite games like Hollow Knight would have never been made if they decided to just build the engine as well.

Well, it sure is helping with Silksong, that's for sure.

But as a fun fact: Hungry Knight was made in Flash. I'm sure the devs would have found a way if they were determined enough if they didn't choose Unity. It could have been done in Game Maker or Construct or even good ol' Monogame (I believe Celeste used that).

[_gabe_]

I didn’t dismiss the point. My next sentence that you left out of that quote addresses it ;)

I also learn concepts bottom up, but thank God everyone isn’t like me. I’m just glad prebuilt tools like the game engines we have today exist so we can have artists creating awesome games.

Heck, even half life likely wouldn’t exist if Carmack hadn’t written the Quake engine and shared it with the Valve developers![0] Think of all the amazing games that have since been released by Valve that might never have been unless they had the kickstart that they got.

[0]: https://en.m.wikipedia.org/wiki/GoldSrc#:~:text=GoldSrc%20(p....

[MattRix]

The idea that people who use game engines are at all equivalent to AI art prompters is ridiculous. What you’re doing is being like a painter who says “real painters mix their own pigments”. It’s unnecessary gatekeeping.

[CaptainFever]

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.

[krapp]

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.

[MattRix]

You aren’t disagreeing with me.

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.

[adamrezich]

Some gates need to be kept!

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.

[MattRix]

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.

[adamrezich]

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.

[johnnyanmac]

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.

[d0100]

I program daily

At night I don't want to slog away implementing Foo and extending Bar

Unity is already a lot of programming to do any simple game mechanic, and you still have animation, modeling, art, lighting, shaders, sound...

I can't wait for AI to get to a point where I can tell it to "get look and feel from X game, mechanics from Y MOBA, multiplayer server" and get code good enough for an MVP

Games are for playing, code is an unfortunate side effect

[turtledragonfly]

> Games are for playing, code is an unfortunate side effect

Boo, hiss!

(I respect your opinion, though :)

[raincole]

> 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

It's more like an artist never learning the chemistry that makes pigments and watercolor work.

Sorry, comparing scripting in Unity/Godot and prompting in Stable Diffusion is just ridiculous.