I got into gamedev by messing around with making my own engine, mostly focusing on low level graphics APIs, and that knowledge transferred well when I switched to a professional game engine. I knew about shaders and such and knew I was somewhat prepared to alter the engine I was using if needed.
Or, the other way, if you start making a game in an engine and you hate it, your efforts are not wasted. The truth is like 10 or 20 thousand lines of game logic can make a lot of games, and that's really not much code to port to your own game engine compared to the rest of the engine. All the art and other assets can be ported too. Plus, if you know a professional game engine you can use it for tooling or get some good architecture ideas to use in your own engine.
So, just get moving with whatever excites you most and be willing to change course.
Making a game engine is a very concrete task, in that you can map out the steps and many of them are well-defined.
On the other hand “make a good game” kinda isn’t. Which I think is a big reason why coders gravitate towards the “start making an engine” route and then fall down it :)
The developers I admire and look up to a lot are the artists that fell into programming. I think they’re the best when it comes to being a successful lone / indie dev for games. Everyone notices art, but you don’t notice programming unless it goes wrong or you know the tech behind what you’re looking at.
The highly automating/efficient mindset of programmers is great but even small games are big pieces of art that require a lot of diligent labor that you must expect and respect.
And of course, your point is that no one sees programming in a screenshot or trailer.
That said, some of the most fun mechanics are born out of happy accidents involving interactions that weren't fully considered so it's definitely not a constant
For the vast majority of games they are very wide. Including technical platformers, which will have very finetuned movement systems, but they must be accompanied by a lot of equally finetuned levels. Another way of seeing it is that content is the "space" which your systems are expressed in, and more expressive systems require more space. A complex combat system will demand more enemy characters for its complexity to be relevant.
But I was only speaking in terms of programmers' understanding the nature of game production, rather than their actual contribution to the game. Of course there are very programming forward games, and entire genres driven first and foremost by innovative gameplay code. But even in those games and genres the programmer must understand that on top of the unique features that are being programmed, most of the important work will still be content creation. It's the nature of the beast. I'm a programmer who had to learn this the hard way. It's nothing like a software startup. It's more like a movie production with a software project inside.
Now, reading kanji... that's where the pain begins.
Reading kanji is easy, the problem is looking them up. Jisho has a terrible kanji recognition engine. The one from sljfaq.org works amazingly well, but it is not a dictionary so you have to ugh, copy every kanji by hand, making the process take forever for each word.
They're less than 50 each, plus a few diacritics. I did learn hiragana in 3 days, it's that easy. One just need motivation, and practice. People failing at it just don't put the work. Heck, I can read more thai letters than a relative who lives there for years and is "learning" the language because I sat and took a few hours to practice.
This doesn't sound right to me. Surely making an engine has thousands of different choices to make and thousands of rabbit holes to get lost in.
Making a game fun is a bit of a black art. A little more juice (screen shake/SFX/etc) can make the exact same experience otherwise a lot more fun. An interesting recent example of this for me is playing Witchfire, a 1st person single player extraction shooter that just came to steam in early access. One of the bolt action guns once you level it up makes a bell sound with every headshot that makes it feel incredibly epic, along with the benefits headshots give for that gun.
There's pretty much no rules when it comes to making a game. Versus with an engine, you at least have some requirements and guidelines. It's gotta render stuff, do physics, etc. With a game you could literally do anything, and 99.99% of all stuff you can do probably sucks and isn't fun. So you have to really be willing to throw ideas away.
To me it means playing with tech without making anything that’s useful. You can’t make any design tradeoffs without a game in mind.
Every engine I’ve seen written in isolation gets immediately gutted as soon as it needs to make something work.
First you hack through all your abstractions to get the critical path up and then you essentially write each feature again.
I envy the creator of Stardew Valley; he programmed, designed, wrote, and composed the entire game by himself over his 5 years of development.
I intuitively want to agree, but on the other hand I've also seen many, many hobby/indie/etc projects deadlock when they switched engines. Or even engine versions (Unreal 4 -> 5).
A well- and hand-written game is easily portable, see the original Doom, where separation between core logic and side effects, such as drawing in a screen, is clear. Actually, this is a good architectural model for all types of software.
https://www.reddit.com/r/gamedev/comments/16lphwe/caves_of_q...
It can be as easy as copy/pasting your code or so annoying that a fresh re-write is faster.
Analogies: I want to write a novel so I'll first build a typewriter. I want to film a movie so I'll first build a camera and digital editing software. I want to cook food so I'll first build a stove, pots, pans, and knives.
In all those other examples it hopefully clear, you just buy the tools you need and then make the thing the tools allow you to make. At this point, the same is true in games.
If you like making a game engine than make one. Just like if you like making knives or cameras then make them. But, making a knife is not cooking, making a camera is not making a movie, and making a game-engine is not making a game.
I also want to add, making a game-engine is easy compared to making a game. Why? Because all the things to you need are well known. You need a 2d renderer (UI), a 3d renderer (assuming you need 3d), image loaders, model loaders, sound players, music players, keyboard input, joypad input, entity systems. Etc. You build them and it seems like you're making progress and if your goal is to make a game-engine, then you are making progress. But, if your goal is to make game, you're mostly likely fooling yourself that you're making progress. Again, back to the analogies, if you're making a knife, you aren't making progress on cooking, your making progress on making a knife. If your making a camera, you aren't making progress on making a movie, you're making progress on making a camera.
What makes making a game harder than a game-engine is the list things to do for a game is unknown.
There are some games that are just not possible using someone else's engine. Consider Factorio, non-Euclidean geometry, the early MMOs, or anything else which pushes the boundaries of what's possible. On the other hand...are you really making a game like that? Similarly, there are good reasons why you'd want to grow your own herbs, and the deep knowledge of growing conditions really does add to your ability to understand why your parsley is bitter this year, but for most restaurants it wouldn't pay off.
If you have a gear hobbing machine, you can only make standardized gears and the only thing you can influence is the size of the gear.
That's also a benfit for if you want to break into the industry. There's a ton of gameplay positions, but a lot less people who want to work with the tooling or the tech art or sound engineering. So that's another thing to keep in mind if you are choosing a direction.
I say no matter what you choose though, you stick with it. chasing two rabbits and all that.
Just start on your games. What feature does it need next? Ok now write that.
You don’t need an FBX skeleton parser. You need a header with vertices in it.
This give you very high velocity iteration, without the engine imposing creative constraints.
The final product is tight, efficient, and will last forever.
Quake and perhaps doom popularized selling game technology and even quake engine was tailor made for the game, not general purpose.
> The term "game engine" arose in the mid-1990s, especially in connection with 3D games such as first-person shooters with a first-person shooter engine.
> Such was the popularity of Id Software's Doom and Quake games that, rather than work from scratch, other developers licensed the core portions of the software
Want to correct any of your comments? Or make any other personal accusations?
Also in the Adventure Game space:
https://en.wikipedia.org/wiki/SCUMM
The oriignal MUD was an engine, and there are hundreds of derivatives of MUD that are also engines, I recommend Richard Bartle's book for a really good history of it, I think it's free online.
https://en.wikipedia.org/wiki/Multi-user_dungeon#Wider_acces...
https://mud.co.uk/richard/DesigningVirtualWorlds.pdf
Bartle's own words:
> MUD was programmed in MACRO-10 assembler on a DecSystem-10 mainframe at Essex University, England, in the fall of 1978. Its author was a talented Computer Science undergraduate, Roy Trubshaw. Version I was a simple test program to establish the basic principles by which a shared world could be maintained. When it worked, Roy immediately started on version II, a text-based virtual world that would be instantly recognizable as such even today. It was also written in MACRO-10, a decision that led to its becoming increasingly unwieldy as more and more features were added. Because of this, in the fall of 1979 Roy made the decision to begin work on version III of the game. He split it in two: The game engine was written in BCPL (the fore-runner of C); the game world was written in a language of his own devising, MUDDL (Multi-User Dungeon Definition Language). The idea was that multiple worlds could be constructed in UDDL but would run on the same, unmodified engine (which was effectively an interpreter).
Not only is it clearly the same content generation process as modern engines, he even called it an engine. (this book is from 2005 IIRC but I think it's mostly a moot point what they're named)
PLATO: > There had been graphical virtual worlds before. The seminal PLATO (Programmed Logic for Automatic Teaching Operations) system went live at the University of Illinois way back in 1961, and many games were written to take advantage of both its network connectivity and graphics- capable plasma display units. Some of these laid down principles that would greatly influence the development of later computer games; some came close to being virtual worlds; some actually were virtual worlds. Orthanc, by Paul Resch, Larry Kemp, and Eric Hagstrom, was an overhead-view graphical game that, although not implementing a shared world, nevertheless allowed communication between individual players. It was written as early as 1973. Jim Schwaiger’s 1977 game Oubliette (inspired by Dungeons & Dragons and Chuck Miller’s earlier multiplayer game, Mines of Moria) had a first-person point of view and used line graphics to render the scene ahead. It had persistent characters, but was not a persistent world. Also, the interaction it allowed between characters was very limited; it was almost there, but not quite. In late 1979, the first ever fully-functional graphical virtual world was released: Avatar. Written by a group of students to out-do Oubliette, it was to become the most successful PLATO game ever—it accounted for 6% of all the hours spent on the system between September 1978 and May 198517. Again using a Fantasy setting, it introduced the concept of spawning to repopulate areas automatically after players killed all the monsters.
Graphics programming was already hard to hire into, and I'm not even convinced there's more than a few dozen legitimate positions out there in these times.
Good ole days of AS3, still ahead of their time.
Really wish there was an AS3 WASM or something
On a walk today I was thinking about something specific that I think is under-discussed. Yes people bikeshed etc. but when you create your own engine you are _fiercely_ aware of _everything_ it can and can't do. As part of this, it's very easy to feel fully in command of your own toolset, and as such able to exhibit mastery over that toolset.
Granted, the scope of possibility when you start out building your own tool is narrow, but in some ways that acts as an easier onboarding to expertise instead of getting dumped into something as powerful as Unity/Unreal/Godot with little orientation and lots of edges you don't know about. In using some super-general you have to carve out your own path through its features, which is cognitive load (and time!) you don't need to worry about when you create your own.
For similar reasons I'm _also_ making my own engine. It's 2D-only engine that uses lots of modern C# features to make for rapid programming of 2D games. For the game I'm making with it to start, I'm using literally every feature of the engine, which is something I don't think I'd ever be able to say for something more general purpose.
For anyone interested: https://github.com/zinc-framework
The problem is that if you start gamedev by making engines, then you aren't aware of what you need to do.
To give an example, if you make font rendering and looks blurry/pixelated, what now? Oh, and a simple 2D game takes 8 seconds to load, wonder why?
Meanwhile, if you have ever made a Unity game, chances are you already know the keywords "SDF" and "Texture compression", because you tore down an already big engine for optimizing your game and accidentally learned about what features a game needs.
What now is you have a fantastic opportunity to learn some topics in depth. Using Unity is also no guarantee that you'll come across those terms. And even if you do, if the Unity solution is to check the correct boxes you're exactly better off from a knowledge point of view.
I'm not advocating for not using Unity, but I am advocating for learning, increasing the depth of your understanding, and just a general approach of curiosity and problem solving.
I dove into writing a niche game engine and stumbled over every hurdle that modern game engines solve.
Been learning Godot lately and going back to writing an engine I'm confident I could trivally solve a lot of those hurdles.
Additionally, if im trying to make a basic editor I can now see what is tenfold easier graphically (animations) and what I don't mind programming in.
“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.
It's a very educational exercise that any dev would benefit from, game dev or not.
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?
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.
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).
Compare and contrast Salt & Sanctuary, which was uses FNA (which is a library, not an engine).
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.
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.
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.
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.
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.
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.
I thought the last paragraph of my previous post made it pretty clear that I rather specifically don't think that.
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.
> 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).
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.
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.
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.
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.
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.
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
Boo, hiss!
(I respect your opinion, though :)
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.
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.
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.
Yeah the really compelling thing to me is the knowledge building. For example what I do with my own project is that I take a look at some demo or example, let's say in Gamemaker or GDevelop and I ask myself a few questions:
a) how is the sausage made?
b) can I make the sausage and what are my ingredients?
c) if I can't make the sausage yet, what do I need in order to make the sausage?
Ps. your github could use some screenshots I think
A simple example was that yesterday I was trying to debug why my MouseDown event wasn't firing every frame and was just firing once like MousePressed. After some digging in I realized that MouseDown isn't actually a primitive mouse event type in my platform wrapper code (Sokol). You get Up/Down. Doing this 1-to-1 wouldn't give people what they usually want (a MouseDown event that fires every frame), so you've got to figure out how to implement that yourself.
As for the Github, it's all a work in progress! I'm actively working on the engine but it isn't really "released" yet. I've got a very active dev branch and some docs I'm working on before I do a proper "reveal".
As for screenshots - what kind of stuff would you want to see? It's just a 2D engine so it's not like I have awesome graphics to show off. The point of it is that it's a code-only framework, there's no built-in editor or anything. I do want to have runnable embeds though of the demos!
I've always assumed that "make a game, or make an engine" meant: if you decide to not use an engine when making your game, don't abstract it and also make an engine.
In other words, don't overengineer your game and build a generic engine when you don't need to.
Have I interpreted this wrong all these years? Or did the phrase morph because everyone thinks everything is too hard to program yourself these days?
Exactly this. Do the minimal thing correct for your situation (your own rendering if desired/required or integrating a third party solution, free or otherwise) and don't spend a year on stable rigid body simulations in a completely general-purpose and reusable tool (that is only reusable for you because it's almost a guarantee it won't be general purpose enough or documented well enough for anyone else) if you don't need the objects to behave with some level of physical realism.
Smaller personal and hobbyist projects have the freedom to make a lot more choices around 'how' they get to their end goal, and I think they should use that opportunity. If you're genuinely intending to make the next indie hit, the actual tech is not likely to be the most difficult thing for success, whether you use Unity or your own tools.
> because everyone thinks everything is too hard to program yourself these days?
Without getting too cynical, it seems like there's a culture of ignorance in some places where large long-lived software projects created by other people over time are treated as black boxes, impossible to understand, and not for the likes of mere mortals to even attempt to comprehend.
Unreal exists because studios want to be able to hire hundreds of contract artists on a short schedule. These non-technical contributors need to be able to import whatever permutations of data they spit out of Maya, without conflict, and have it work efficiently on all platforms.
Solving that problem sucks and is complex which is why people pay for their product.
But anything you make yourself or with a few friends doesn’t have that problem.
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.
Source: me
Anyone that wants to build an engine (or a CMS, or whatever) with the goal of making a game should try making one or more games with one or more existing engines first, if only to get a better idea of features and shortcomings. And if they really want to make games, or just the engine.
* Be resources efficient (memory and cpu usage)
* Has primary 3D support
* stable
* Supports old devices (ideally embedded systems too)
* And of course be FOSS
I'm focusing on mobile, as you know mobile devices are very sensible to heating so the 1st option is a must, Godot isn't resource efficient, it heats very easily when I play one of the sample games. Regarding the second option, whilst Godot still supports gles2(which is the most widely supported api yet across old devices) it's further being pushed as second-citizent over Vulkan and looking through github no other engine checks my boxes...
If someone could direct me to an engine that checks all the boxes above I would happily try it out.
Solution: make a new engine
Result: I want an engine that does x, y and z but none of the 5 can do that
but hey, your engine doesn't need to be a competeing "standard" if you do want to make a new engine.
the main up/downside is that it's a C# engine. So it won't necessarily be as hyper-optimal as c++ without some discipline on what parts of the language you use (hint: avoid LINQ at all costs in the hot loop, and look at the newer ways in C# on how to utilize unmanaged collections).
Regarding the asset prefetching, you mention that they are loaded lazily. Maybe I'm misunderstanding but to me prefetching and lazy loading are the opposite (i.e. you would prefetch during a loading screen in order to avoid loading things on demand since it could affect the game loop). Could you elaborate?
There’s also a mechanism to collect and remove unused assets from memory.
I've been cranking on a 2D engine for over 4 years and have put thousands of hours of work into it.
My summary:
If you want to write a game, just write a game. Don't start with your own engine since this will suck all your time and you'll end up spending 90% on engine and very little getting the game game done. Especially so in the beginning when you have no features and doing anything in the game requires engine work.
If you choose to create your own engine it's a compelling and fantastic domain where problems come in all shapes and sizes and you can and get to work with physics, maths, linear algebra, audio, rendering, graphics APIs, system level programming, most likely native programming AND scripting, game content, technical art etc.
But finally the real work is not the engine but the tooling and the editor around the engine.
If (when) you rely on free assets from (for example opengameart) you can expect no consistency. Not just the art style but just the technical part too, like your models are all inconsistent in shapes and sizes and axis, 2D content such as textures are by default without any meta data etc. So you really need to create a ton of tooling so that you can have sensible workflows and you can extract and consume the usable and interesting parts of any content package easily.
This inevitably leads to the concept of "editor" which easily comes with a ton of work by itself that has nothing to do with game or game engine per se. For example the concept of "Project", windows, resource management, basic editing functionality for creating content, undo/redo/ etc. A lot of this is not really related to the game or the engine in anyway but you really sort of "must have it" if you want to create something that is actually usable.
The feature creep is real! But once you get the over a lot of the boiler plate and you can actually use your own editor to stuff content into your own engine and have it running it's really a nice feeling even if nobody else cares!
On the technical side my advice is really to be able to do first principles type of thinking. It's of utmost importance to be able to break things apart into self contained features and pieces that the game can then combine to create bigger constructs.
If you can have your materials scroll textures vertically, when you combine that with shapes that are layered and place textures onto those shapes that scroll at various multiples of your "characters" speed then you've just created "parallax scrolling" essentially.
-----
But I'd say there's a middle ground between using an existing engine and making your own general-purpose engine from scratch. I've been making a 2D RTS using C++/SDL, and it's taken me longer to write it this way than if I had used an existing engine, but in only a few months I've reached the point where I have a prototype and have had multiple playtests and am iterating the prototype based on feedback from those playtests.
So, while the advice "make games, not game engines" is still definitely true, it doesn't mean that if you code "from scratch" that your game will necessarily be a long 4-year engine project (unless you want it to be!). The trick is to keep the code specific to the game you're working on and to avoid the urge to abstract everything / make everything general-purpose.
I personally I'm not capable of executing this strategy because my mind is always thinking in terms of abstractions and how to make things so re-usable in another context/project when the time comes. For better or worse this means that for me any "game from scratch" project will immediately turn into "engine + game from scratch" project :)
I say that as someone who keeps working as mostly C++ contributor into internal game engines for various projects.
I would want people to look forward and make works of art that expand what we thought was possible more instead of 'learning low level programming'.
This type of project is small enough to plan all the elements before you start (which helps to stick to the design and therefore to avoid feature creep). Yet, it is still complex enough to provide entertainment and challenge.
This approach also has the advantage – at least it is an advantage in the case of side projects – that you can see the results of your work quite quickly.
I'm working on such a project myself, and it is a great experience. Although to tell the truth, it is more of a "game creation kit" than an engine.
No disrespect or put downs of anyone trying to do their own thing, but Godot is a really great engine and is open source. It's kind of miracle that we live in a world where there is a viable open source engine for commercial grade 2d games and the whole thing is MIT licensed.
For instance, I find you can get massive mileage by declaring “(almost) everything is instanced”, then you batch it, forget it, move on. There are similar shortcuts to be made with physics and so on.
The close to ideal engine, in terms of approaches to problems, was LittleBigPlanet. That was a small team that were really good, but crucially they had the right way to frame the problems so as to constrain the emergent complexity of the result.
Yes I agree, writing a specific functionality in the engine does allow for more optimal performance but the tradeoff is that it's more brittle and more complicated to write and maintain.
My personal approach has been to do the first principles and avoid writing use-case specific features in the engine as much as possible but provide more fundamental functionality that the game then combines to create the desired effect.
That being said I've still had to do some concessions and move stuff like simple constant velocity game object integration to the engine side simply because the perf difference between native code doing that vs Lua code are just too massive.
Some typical ways to divide this though is
Some org has "engine" team and "game" team. Engine team implements features in the engine itself and game team implements game specific features using the embedded scripting language.
Engine features are game agnostic and game features are specific to games and are scripted / built-on top of the engine features.
But sometimes things get muddled as general purpose engines are used in games that require specific features in the engine itself. Typically the decision is then made by a) what kind of feature and how does it fit in the architecture of the engine b) what are the performance requirements c) who is willing to do the work and maintain it
I haven’t found much information on how to write a game in this style with existing engines. Any advice or resources you would point a noob too? I am a software engineer but not a game programmer.
It doesn’t have to be so good as a real slot machine (regulations and such) but I do want to follow the rules as best I can. I may not use a real hardware RNG.
local engine = EngineFactory.new()
Examples of what I expect:
local engine = Engine.new()
local factory = EngineFactory.new()
local engine = factory:build_engine()My next step is to work on collision and physics; maybe I’ll use something like Box2D.
Putting aside the politics and all, focusing on the tech- one thing I came across when trying to do my own collision detection was the idea of using the GPU and occlusion queries for pixel-perfect results.
I didn't come up with the technique, but it's super cool, and since you're not taxing the GPU with tons of 3d triangles, it's perhaps a bit more free to do stuff like that.
Nowadays, it’s very rare for a user to download and run a binary.
The interesting part of the collision detection code is here: https://github.com/dakom/not-a-game/blob/main/src/collision/...
Honestly more people should try it before they knock it. Programming a game from scratch is not rocket science. It takes some work to get to finished game but sometimes the journey is what people care about and want to master. No need to always be optimizing for the end result.
I make stuff with wood. I don’t use power tools. I use hand tools. Because I like doing it that way.
Hope your kid has fun playing the game!
Do you have any examples of good debugging features?
This is very reasonable advice. Those tools are software behemoths, by design, because they have to account for all possible use cases and give people a way of opting in to any possible combination of provided features, along with providing various abstractions (scene hierarchy, gameplay scripting, graphics API abstraction, materials, VFX, animation state trees, etc., the list is seemingly endless) as they need to support making essentially any kind of game.
And not only are they software behemoths, they also represent a huge amount of mindshare in the form of documentation, support, community, customer-provided content, (marketplace assets) and so on.
If you're making a game and you know what your requirements are up front, it's possible you just don't need most of what the engine provides.
If you don't need to support multiple graphics APIs, you can get away with just using the specific API yourself (and then you don't need a different shading language). If you don't need complex VFX you might not need a VFX graph. If your rendering code is closer to your gameplay code you don't need a separate gameplay scripting system, you could actually write your gameplay code in the same language and build them together. Don't need rigid body simulation? Great! Throw that away. Don't need RVTs? Goodbye. And so on.
That doesn't mean throwing away some engine-like structure, you'll almost certainly still end up with some representation of a scene, but if your requirements are minimal you can get away without most of what's in the above tools.
And there's always the middle ground (that seems to get forgotten). Open source rendering libraries such as Ogre integrated into your own program, such that your game stops being a completely isolated component that sits on top of the engine and is regular code integrated with rendering (and so on), while being a more cohesive whole.
Of course, if you need the features in Unity or Unreal and you don't have five years to burn then maybe you should just use them after all.
Working on your own engine gives you a level of understanding that cannot otherwise be obtained. It's like writing your own OS. This is very much a worthwhile endeavour. People should be encouraged to write their own crap, even if they don't end up using it on the job or whatever (whoever the fuck said this was the only metric for deciding what to work on?) because of the level of insight it provides.
Generic engines like UE5 and Unity break down both in terms of functionality and performance the moment you do something they are not intended to do. They are also an overkill for a project of the scale shared here. From an engineering perspective, it's absolutely ridiculous to use an engine for this project.
So please stop parroting this nonsense. Use your goddamn brain to form opinions. There isn't an off-the-shelf engine for that.