I find that when initially exploring a problem space, it's useful to consider functions as “verbs” to help me think through the solution, and that feels useful in helping me figure out a solution to my problem—I've isolated some_operation() into its own function, and it's easy to see at a glance whether or not some_operation() does the specific thing its name claims to do (and if so, how well).
But then after things have solidified somewhat, it's good practice to go back through your code and determine whether those “verbs” ended up being used more than once. Quite often, something that I thought would be repeated enough to justify being its own function, is actually only invoked in one specific place—so I go back and inline these functions as needed.
The less my code looks like a byzantine tangle of function invocations, and the more my code reads like a straightforward list of statements to execute in order, the better it makes me feel, because I know that I'm not unnecessarily hiding complexity, and I can get a better, more concrete feel for what my program's execution looks like.
“Game engine” is supposed to simply mean, the parts of the game code that aren't the main game logic—the stuff that handles asset loading, entity management, input detection, rendering, sound playback—that sort of thing. It could be used to refer to Unreal Engine… or it could just mean the simple, minimal homemade tech stack that you built your game upon. Or anything in-between.
But you hit the nail on the head—it's definitely one of those terms that has been warped and downright mythologized in recent years, with the rise of free-to-download general-purpose GUI-editor “game engines”, and their ensuing popularity.
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.
People like designing and making games, so they design and make games… Making the engine (or underlying framework, whatever) is just not necessary for that goal.
There are relatively few game designs (especially with indie scope!) where a custom engine is truly necessary.
For the tinker/hacker types, there are plenty of things to do at a “lower level” within the engine itself (note: I don’t necessarily mean modifying the source code). There are all kinds of different ways to structure things within the confines of the engine, and lots of other ways of building frameworks and GUI tools within the engine too.
I think it's also easy to conflate game development as one big thing. 100 people could say that they want to make games and all mean 100 very different things. I think for some people, like you mentioned, they ostensibly want to "make games" but also just like to tinker of engine-flavored tech, and that's totally okay.
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.
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!
[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?
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.
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?
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.
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).
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).
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.
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.
It's great that Hollow Knight got made, in short enough order at the time (2017) and it's great for them that they were able to port it to so many platforms with relative ease.
But the entire development team probably got a few gray hairs from the stress of last year's Unity debacle.
It is now no longer 2016–17. We have now seen firsthand the quite possible perils of building your game on someone else's engine.
It's like how Twitter used to provide very open API access for people to use to build all sorts of third-party apps. Overnight there was a huge explosion of these apps, and it was great for Twitter because it meant more people had more ways to engage with the platform. But when, after Twitter bought all the third-party apps they cared about and kept increasingly clamping down on API access more and more before finally pulling the plug on third-party app support entirely, what did that mean for everyone who built their entire business around using someone else's platform? They got fucked, hard.
When you see this pattern recur time and time again, you start to think, maybe it's not such a great idea to build a business atop someone else's platform. Maybe you're better off in the long run if you have complete ownership over your code.
Imagine if Unity pulled the trigger on their bullshit last year and went through with it. What would the Hollow Knight developers have to do? Scramble to reimplement their game in a new, Unity-free codebase, on every platform it's been released on, just to prevent paying Unity more than they already do? It doesn't sound like an enviable position to be in.
You have to look at the bigger picture and consider nth-order effects if you're trying to make a business out of game development. If you're doing it as a hobby, then it's fine, who cares—if you wake up one day to find that the platform you've been using for your hobby projects now wants to charge you to use it or whatever, then it's a bummer, but not a big deal, because you haven't invested your business into the platform, you're just partaking in a hobby.
Out-of-hand accusations of “lacking empathy” and the like when it comes to subject matters like this are inane, vapid, and really quite untoward. We're talking about concrete things here like the technology used to make video games and its relation to treating game development as a business—not feelings, or inclusivity, or whatever it is you're responding to with this verbiage.
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.
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.
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.
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 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, ever 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.
> 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.
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
Absolutely agree! It's totally doable, but it does require some desire/ability to dig under the hood little.
I think a lot of people conflate the game engine with a game editor, and don't realise how simple an engine can be if it only contains the features needed for one game.
I've shipped several games with my home made engine, and it was the best technical decision I ever made! No more relying on someone else to fix bugs!
The editor is part of it but I think the complete lack of where to even begin structuring one's game code in absence of some kind of formalized scene graph is a huge part of it as well. Scene graph editors make seeing “what exists in the game world right now” very visually apparent and easy to understand: “well, there's this root Node, and within that there's these different Nodes, and some of them have child Nodes which represent…” and so on and so forth. I recently replied to someone on X [0] who was starting from the Raylib 2D platformer example and asked, earnestly, “so I have this constant array of five rectangles representing platforms… how do I go from this to ‘defining my game's world’”?
It's just data. In its most basic form, a game world can be represented as just arrays of instances of structs, and then you loop over those arrays and call a function on each element to simulate the “entity” that struct instance represents, and then again to render it onto the screen. Sure, you eventually might want to do something more complex than that if the need arises, but most people would be surprised at just how far you can go doing only the simplest possible thing.
everyone will have a different engine. Some people will want to properly learn music theory and chord progressions and proper maintenance of a guitar. Others just want to learn 4 chords and use it to sing to their favorite pop song. Both are valid.
That's ultimately what one crowd wants. They want to deal wth minimum or no code, move around assets in a scene, and try to recreate a level in their head. General purpose engines abstracted the need to learn the code, which was never of interest to most people that just want to make a little game.
My only reservation is knowing when to pick the right tool for the right job. I wouldn't throw Photoshop at someone who just wanted to add some filter on a few pictures if some free phone app (probably a built-in one) worked for them. Likewise, I sure wouldn't tell someone who wanted to make a quick pixel art platformer to download Unreal Engine. Even Unity is a bit overkill. Flash used to be that "iMovie" of 2d games, and we never truly filled in that void when it died.
What? It's the opposite. Everyone and their dog is building their own game engine. Convincing people to actually make games with their engines is the hard part.
> Most likely Crypto influencers are Putin-proxies, as usual.
What proof do you have for this assertion? I find cryptocurrency influencers to be incredibly distasteful and lame, but I am unaware of any evidence that supports this theory.
So far, there was a trend, if you dig and look where far right money was coming from (Truth Social, Brexit, etc) it was invariably coming from proxies of Putin or useful idiots.
If you notice, Trump had started collecting large amounts of money from Crypto. At approximately the same time when normal channels to transfer money from Putin’s proxies dried up. This channel, on the other hand, is still wide open. A known vulnerability, easy to exploit.
A web framework doesn't need GC, it just needs some ability to express the idea that per-request code should get its own allocator, with knowledge of said allocator propagating down through function calls.
Jai solves this by having a "context", which includes an "allocator" member by default, whose default value is a standard heap allocator. You can override this allocator member to point to your own allocator, so it's easy and straightforward to have the main server procedure allocate a pool of memory, create a new context with a new allocator that uses this pool of memory, then "push" this context for the duration of the request resolution, then free (or mark for reuse) the memory pool afterward.
This is very interesting. I don't know if it was the intent, but Jon Blow doesn't plan to self-host the Jai compiler anytime soon, and I wonder if the rationale is at least in part due to things like this. It's interesting how he doesn't see self-hosting as any sort of immediate goal, quite unlike Rust and Zig.
I trust science completely, it's all we have. I don't trust the people doing the science.
In the same way that you can trust laws, but not most lawyers. Medicine, but not certain doctors. It's not the scientific method that's at fault, it's its abuse.
It's just a company that promised AGI would somehow come from developing LLM-based products, rapidly scrambling to keep up with other LLM-based products, to distract from the fact that it's becoming increasingly apparent that AGI is not coming anytime soon.
There's good reasons to expect time travel is physically impossible.
Your brain is an existential proof that general intelligence isn't impossible.
Figuring out the special sauce that makes a human brain able to learn so much so easily? Sure that's hard, but evolution did it blindly, and we can simulate evolution, so we've definitely got the tools to make AGI, we just don't have the tools to engineer it.
The comment is referring back to "not compensating for anything". Choosing to keep a balding head and not caring what other people think is a power move when having a full head of hair becomes trivial.
Drawing a moral equivalency to some random event in some random contemporary work of fiction as a means of moralizing isn't some kind of awesome megadunk “own” or anything—it's actually pretty lame.
reply