Right now I'm struggling with the fact that I'm not allowed to redistribute cl.exe compiler (I tried real hard: https://developercommunity.visualstudio.com/t/allow-redistri...) so people have to download the whole VS package and extract the necessary files (takes about 2 hours) to get automatic integrated recompile and hotdeploy in my engine.
So I'm looking at going full tinycc and dropping VS all together on Windows. But then seen how they are deprecating my pretty new and probably good forever Skylake on Windows 11 I'm thinking it's over and I should just switch to Jetson Nano but then I'm owned by Nvidia... (Raspberry 4 driver has HALF_FLOAT issues still and well Broadcom... + CPU/GPU balance is off) so I'm kinda loosing hope for humanity at this point!
Risc-V is not progressing hard and fast enough to make it in time!
Edit: Zig, Go, Rust and WASM are not solutions, they are fragmentations. Only C(+) on client and JavaSE (VM and GC) on server makes sense. (Gotta burn that karma somehow right?)
Did you consider the Zig toolchain? It's also a full C/C++ compiler toolchain (via Clang), and comes with enough Windows headers (from the MingW project) to build DirectX games out of the box.
For instance here is Zig as Python package to provide a simple cross-compilation solution for other Python packages that need to build native DLLs:
I'm glad the author learned some things and enjoyed it. Writing your own game engine is a good exercise and I highly recommend it.
But this feels very much like a breakdown of one specific rudimentary engine disguised as an overview of game engines in general.
The biggest thing that bothered me is that there is a huge portion of the engine missing here. He mentions physics, graphics, math (which I see more as a set of helper libraries, not an engine component), but nothing really about game logic, audio, or input.
Every engine I've worked with (or written) has had a lot of its architecture dedicated to these. He does mention entities but nothing about them. I'm a graphics programmer myself but even so this seems the most central system to me. It drives everything that happens. What do the objects represent, how do they behave, how do they interact beyond bouncing off each other.
Without these systems your game engine is nothing but a silent physics simulation without any player input.
Absolutely agree. Explaining what goes into a game 'engine' is a great thing but this article misses on every front.
Calling the math library a 'math engine' more than bothered me, it is just plain wrong. It's just a few data type classes/structs and the associated templates and code to manipulate them. For an OpenGL game engine #include "glm.h" is going to do pretty much everything you would want in a battle-tested way.
There is so much in here that is inaccurate, misleading and just plain wrong: "To render a pixel on a screen you need to communicate with the GPU. To do so, you need a medium. This medium is called OpenGL."
What about WebGL, Vulkan, DX, Metal? What is a medium?
"Scenegraphs are generic trees and they provide a fast way to traverse game entities. You may want to use C++ vector containers instead. This is all right. The problem is that they are too slow to traverse. Thus, if you can, use scenegraphs instead."
How is a vector too slow to traverse? If I want to traverse linearly it is pretty much the fastest container. How is the scenography ordered? Is it ordered by an object/transform hierarchy, is it ordered for rendering speed, is it ordered by locality for culling/streaming, all of these?
Why is he inventing terms like the 'engine loop' where most people use 'game loop'?
And yeah, so many missing systems. Even the description of the physics 'engine' misses collision detection.
So great that the author learnt about game engines, but dangerous for them to then present such an incomplete article with such an air of authority.
I stopped reading when I noticed that every image had a copyright tag on it. This blog isn’t primarily for teaching people things, it’s for something else, if nothing else, the author’s ego.
> The first prototypes of the engine were failures. I couldn't even get OpenGL to work right.
As someone who's worked with OpenGL since ~ 20 years (and professionally for the last 12 years) I can ascertain that in fact nobody ever gets OpenGL to work right across different platforms. Everybody just puts in enough workarounds and #ifdefs s.t. it appears that it's "write once, run anywhere", where in reality what you write for one set of hardware will almost certainly fail on another (the definition of "fail" here is pretty broad: crashes, weird slowdowns that don't make any sense, memory leaks in the driver, outright non-compliance with the standard, etc..).
The reason is that most vendor's OpenGL implementations are broken in one way or another, particularly on mobile. Vendors treat their drivers like another box to check s.t. they can claim OpenGL compatibility but in reality it's what makes or brakes real world performance (web browsers, games, 2d graphics, etc..). It's astonishing.
Why do people keep repeating this? A game engine is a monstrous piece of software from which the renderer or the physics is just a tiny part.
Ogre is not a game engine. Unreal, Unity, CryEngine, Frosbite are game engines.
Even implementing a quality renderer is quite an undertaking. Knowing some OpenGL and some basic math is far from being enough. You have to know the graphic pipeline, the GPUs, the CPUs by heart. And be up to date with new techniques employed in graphics, where new things are being discovered daily. You have to read last papers published by Nvidia, AMD and Intel.
I saw many people dabbling with graphics that "built" game engines, when in reality they implemented some toy renderers.
I would be cautious about someone who hardly knows OpenGL teaching others about game engines.
It is like someone learns a few Javascript keywords and starts teaching others compilers.
> Ogre is not a game engine. Unreal, Unity, CryEngine, Frosbite are game engines.
Including the editor tools and asset pipeline into the term "game engine" has only really become fashionable after Unity became so incredible popular, from that moment on, Unity and 'game engine' became synomymous and everybody else (including Unreal) copied the Unity workflow model. Most of the team works in the integrated editor tool in Unity most of the time, thus the editor tool has become synonymous with "engine" but it is actually the "factory line". But this integrated game development model isn't the only possible model just because it has become so popular.
It's just as well possible to create a mainly "programmer driven" game engine where tools are only used to provide the asset data, but the actual game is fully built in code (IMHO it would be much less confusing if the term 'engine' would only be used for the runtime parts that actually 'drive' the game).
That's not the point. You've got code responsible for audio, asset loading and streaming (which tends to be ad-hoc in "engines" that focus on rendering), UI, state loading and saving, visibility query DB, nav meshes, and a lot of system and gameplay logic further divided into unique modules (character management, damage management, etc.) Yes, editor is a must these days (and has been for over 20 years) but that's not the point DeathArrow was making.
What if your game embeds all assets in the executable as runtime structures instead of loading files? What if savegames are just checkpoints instead of serialized game state? What if you render so little data that you don't need complex visibility checks, etc etc etc...
Simple 2D games don't need all the runtime components that a triple-A game needs, yet a game engine for 2D games is just as much a game engine as an engine used for triple-A games.
This is a good time to point out we're really arguing over the definition of a word here, and can probably agree on a lot of facts and observations, even if we don't agree on what the definition of "game engine" should be.
Exactly, the deeper you dig, the more the "engine" just disolves into lines of code. Where does the engine HAL end and where do operating system services begin? Is libcurl considered part of the engine? Maybe if it's linked to the engine code? But what if the curl libs are part of the OS installation?
And on the opposite end, if the Unity editor is considered part of the engine, why not Visual Studio, Photoshop and Maya/3dsMax/Blender too?
In the end, the engine is just that fuzzy layer between the high level gameplay code and the operating system (going with my own preference that "engine" should only be used for the runtime parts).
Engines are essentially loops. There are many examples of engines in software and hardware. Processors, virtual machines, emulators: they are execution engines looping over instructions that they decode and execute. Game engines are the same: they loop over user input, logic and audivisual output. Every game will have this loop deep inside, no matter how it was programmed. It is essential to their operation.
Modern game engines are generalizations of that loop. People took the common functionality from successful games and separated it from the game-specific code.
It really depends on the games you are making. Not every game needs nav meshes for example.
For things like audio and asset loading, you can get really far building on top of a library like SDL2 or GLFW as a cross-platform system interface, and using some single-header libraries for things like loading models or playing audio samples. There are also great physics libraries out there like Chipmunk or Bullet which neatly encapsulate most of the "hard stuff" in building a game engine.
For something like a 2D platformer for example, it's perfectly reasonable and easier than ever for a solo developer to take on building a small custom engine.
Honestly Unity is now mainstream, but I hate it. It is not the game engine, it is a game engine. One of many ways of doing thingи, and very from what I find ideal for my workflows.
In many ways game development seems decades behind other types of software development in terms of workflows. Virtually every other discipline in CS has moved towards loosely-coupled, composable components, but game development is still mostly happening against proprietary monoliths.
Is it really because game development is "decades behind", or just because games are among the few pieces of software still developed against hard performance constraints?
Loosely-coupled composable components may be great for producing software quickly, but the approach is basically antithetical to performance.
I don't think that's true. If anything a tightly-coupled monolith can hurt performance.
For instance have you ever read through the movement code in Unreal? There are a million branching cases for every kind of movement: on particular slopes, swimming, flying etc. If your game doesn't have underwater motion, you're still executing those branches just because other games might need it.
General purpose game engines are by necessity not optimized for performance. They're optimized for being able to support every arbitrary type of game.
Many game devs, myself included, would argue that loosely coupled code makes for messier and less performant code in most situations. It certainly becomes harder to reason about code once the execution flows through dozens of different functions (often in different files) rather than through a single monolithic function. This is somewhat obvious when you think about it, yet people still insist on breaking long but perfectly readable functions into tons of tiny parts for some reason.
In many game dev circles there has also been a strong push towards “Data Oriented Design” where the focus is on manipulating the memory as directly as possible, rather than creating abstractions. See this talk by Mike Acton: https://youtu.be/rX0ItVEVjHc
A general purpose game engine is more like a web browser than other software projects. And perhaps one of the few projects outside of an OS with more complexity. An engine is intended to be a place to run arbitrary software, across multiple platforms and also an environment to build it on. There is still a whole bunch of reusable components built on top as there is with the web.
It's in imperfect analogy. You could argue there's nothing less tightly coupled than web dev. There you choose whatever tools you want as long as you can get it into HTML/CSS/JS at the end of the day.
With engine-based gamedev, you buy into a monolith and that will dictate basically everything about how the project has to be built.
Standards are lovely if everyone follows and supports them but even the three main web engines don’t. And even when they’re similar enough there are significant differences in important characteristics like JS performance.
Likewise one of the things thats most fiddly and annoying in game engines is dealing with implementation of things like OpenGL that are based on standards but not actually implemented to spec across OSes and hardware.
I agree on the dangers of relying on closed-source, proprietary software but if we wanted to avoid that we could just point to Godot as our monolithic example de jour instead.
Web dev is not tightly coupled, but browser dev is, and when you do web dev you're essentially buying into a set of monoliths that have finally after 30 years come together by committee just enough so that you only have to conform to one single way of doing web dev. Javascript has quite seriously sucked for a long time and only recently got a bit better, and HTML and CSS are still trash, so don't talk to me about "dictate basically everything" as if that's not the case there, too.
Unity is the equivalent of a browser, not an app or even app framework. It just lives in a world where the competitors haven't done the committee thing to ensure interop (and never will).
Web is a standards-based, implementation independent platform. That is completely, categorically different from Unity, which is a proprietary tool for making applications.
Unity isn't the browser, it's web-flow or square-space. Except it doesn't give you artifacts which are interoperable with other tools at the end.
Game engines inevitably become monoliths because you need that level of integration between components. If you examine a modern game, you'll generally find about 3 different layers in the runtime:
- individual subsystems: aside from things like animation and graphics, many engines use externally developed libraries for sybsystems (e.g. retour for navigation or bullet for physics)
- integration layer: this comes across as a mundane glue layer between game code and the subsystems, but it is much more than that. This layer takes care of a lot of things. For example, it's often responsible that the right resources are loaded at the right time across all subsystems, makes triggers work (physics collision handler to trigger events/changes in other subsystems), makes it possible that animation timelines can act across other subsystems, triggering sounds, starting animations, altering object states, and many more things... This layer is also ultimately responsible for keeping the real time guarantees across all subsystems with all the tweaking that entails.
- game logic using the facilities provided by the integration layer
When you look at the evolution of game engines, the first ones were monoliths that had to do everything themselves because no reusable components existed (e.g. Doom, Quake). A few years later, reusable components started to appear (mostly physics and audio engines IIRC) and for a short time there were a lot of mostly proprietary engines integrating these components. But with games becoming more complex and more demanding, these integration layers also became more and more complex and became a huge investment. That's when the well integrated monoliths won.
I disagree. I don't think there's anything inherently "tightly-couply" in engines, nor the systems are as coupled as tightly as you describe.
In modern engines, the allocation and management of resources is often delegated to an individual subsystem. The fact there are no famous libraries (as famous as Bullet, Retour or BGFX) that do it is no indictment it's not decoupled in practice, it's just not a very sexy area. And even in commercial engines, this subsystem is not as smart (and complex) as one would wish.
The triggering parts you mention are handled by Components, in most popular engines. Even without using ECS or something fancy, Unity-style components are already as decoupled as it gets. Sure one component might need to know about others, but that's the nature of the programming and it's already pretty decoupled.
Even the editors like Unity are as decoupled as it gets, using reflection instead of knowing the internals of the Components in the integration layer.
The fact that most engines only come in big monolithic packages is just a reflection of current development culture, with lack of collaboration between engine writers and lack of standard patterns or formats. Virtually every single standard present in video game engines (models, video, audio, code, serialisation, APIs) come from the outside. It's a young field.
But I could perfectly envision a reality where the popular libraries offer components (or whatever) ready to be included into third-party editors, for example. Imagine VST plugins in a DAW, for example. Maybe even a standard map/level format too.
But this is not where the money is: Unity and Unreal breaking it and creating an open ecosystem of Components would be amazing, but would also open the floodgates for competition. Their "strength" is in being a single package that looks monolithic from the outside. With a plugin-is system one could create a new editor without creating the other parts, or a new renderer without creating an editor. I could see Godot doing it, maybe, but that's probably not a priority.
For instance, renderers (esp. back-ends) and physics engines are already largely subsystems which are fairly separate from the rest of the game logic.
I can imagine a world where you start with a package manager, and maybe you choose one overarching framework/ecosystem which will serve as a middleware for combining nav meshes and animations etc. in the same world space, handling events etc. the same way you might choose a framework for building a web-server from several popular options.
There's no reason you need an extremely heavy-weight closed-source black-box system to serve as the foundational layer.
This sounds nice on paper. There's just one problem: you mention one overarching framework. That's the game engine. And no matter how you slice it, it's going to be a beast.
Not exactly - I think you can have one of many frameworks serving that glue/structure role, and not all games would need it.
I also think you're over-estimating how much of a "beast" you need as a minimal structure for building a game around. I have built a lot of hobby games, and if you're not trying to make an AAA game, you can get really far with a simple game loop, and a few single-header libraries for things like audio and asset loading.
That would be one of the advantages of a more modular approach: you could choose a right-size solution rather than working from the assumption that you need this hugely complex monolith to build off of, and potentially not needing a lot of that complexity.
> I also think you're over-estimating how much of a "beast" you need as a minimal structure for building a game around. I have built a lot of hobby games, and if you're not trying to make an AAA game, you can get really far with a simple game loop
It’s an organization/people problem. Eventually if your tiny hobby game engine gets big enough people start trying to use it to make the equivalent of AAA games. Then either those users (or your investors if you’ve gone that route like Unity did), start pushing you to support those edge cases.
Eventually your elegant modular code is dwarfed by the all the edge case handling that got crammed into the framework—either because it was so performance critical that it had to live there or (the more likely case) because it was much faster to hamjam it in than spend time thinking about how best to architect it.
Idk I think you are describing a way a modular approach can fail, but I'm fairly confident you could find a way to modularize game development to a much greater degree than is currently achieved.
I think you could, but I just don’t know how long it would last. The real benefit of microservices in most cases is that the network acts as an externally enforced boundary layer.
There’s no reason the vast majority of time that you need to pay the overhead of using network calls to enforce your boundaries. Yet time an again you see companies willing to pay the microservices tax because it’s just so hard organizationally to enforce modular boundaries over time.
You can have almost all of those benefits without using network calls as your boundary. Nearly every benefit you listed is a consequence of having enforced boundaries, not of microservices specifically.
Microservices do provide technical benefits for a small monitory of companies, but for the rest of us it’s almost entirely a solution to organizational/human problems.
An npm like ecosystem sounds absolutely horrible. It’s also not what I thought you were talking about.
Many (most?) software engineers (most?) cringe at the state of the npm ecosystem—even if they hold their nose and participate in it. I definitely wouldn’t consider that an improvement to the state of game dev software engineering practices.
I think there are some problems with package managers, and with the culture around NPM in particular, but I think almost everyone would agree that simple and standardized code reuse has been a massive boon to software engineering as a whole.
Do you dislike cargo as well or just npm for some reason?
It's more a question about degree. I don't mind an app having a few well vetted external dependencies. When it becomes common and accepted for a small application to contain thousands of 3rd party dependencies, I think we've gone way too far.
I've worked in languages that had large standard libraries where it was common to only include a few large commercial external dependencies, and I've worked with javascript and ruby on the other end of the spectrum.
I don't think one style has a clear productivity advantage over the other. Other than maybe at the very lowest levels of beginning software engineers (even then I'm unsure because of the decision paralysis common for beginners in these ecosystems).
As to the original point, however, Unity and other engines already have package managers and asset/code stores. What you're essentially asking for is for Unity to remove many of the features they already include and pull them out into packages. Now you're running up against many of the organizational issues I've already talked about. Not saying it's impossible, in my experience it's just not likely to work out long term.
> Virtually every other discipline in CS has moved towards loosely-coupled, composable components, but game development is still mostly happening against proprietary monoliths.
I'd argue that's because game development is not a CS discipline. Game tech / engine is, but games need more man-hours in artistic disciplines like modeling, animation, level-design, story-telling etc. than they need for cs.
There is a lot of 'game middleware' out there for the CS part of the equation. Game engines themselves are not monoliths, using 20+ middleware components is common.
The game design part is done using a monolithic interface to the technology (the engine), but that's because that job is not 'programming'.
There's artists building the game experience and CS people building the game technology.
The latter do use and reuse smaller software components to build the level editors, scripting interfaces, particle physics, path-finding, illumination, etc. The engine. This job is very much like other fields of software development, not actually behind.
The first might write code (e.g. scripting), but they are generally doing so in a restricted 'monolithic' environment provided to make their job easier. They do not have to build the technology, they can just direct it, if that makes sense. Their job isn't typical software development, more content development, thus it seems a bit alien, behind from a software developer's perspective.
Game Design and programming are two completely different sets of abilities.
Programmers can design a game, and game designers can do some programming, of course. But in modern days, the core way that both professionals interact with engine editors is completely different.
Game Design in general is closer to art or being director than to programming.
I like to call the Unity approach a "Photoshop for games" (which can be a good or a bad thing, depending on perspective and requirements).
It's essentially a game-maker UI tool with some support for scripting/coding. The runtime that's dangling off the end of the asset pipeline and editor is much less important (even if this hurts the pride of hardcore engine coders) ;)
PS: a standalone "bring your own engine" hackable Unity editor would be great, but I guess that doesn't quit fit into Unity's business model
> PS: a standalone "bring your own engine" hackable Unity editor would be great, but I guess that doesn't quit fit into Unity's business model
I’ve been thinking about this a lot as I want to write more standalone games with minimalist runtimes but also don’t want to give up the QoL you get with a decent scene editor with runtime inspection and “fiddling”.
The most exciting thing happening in game development is the move towards ECS (Entity Component Systems). Hopefully with games like Overwatch using it (and other big names), it'll see an uptick in usage.
Unity is reworking their systems to use it by calling it "DOTS" (https://unity.com/dots), and this wouldn't be a HN post without mentioning rust so there is also bevy (https://bevyengine.org/) which is great.
ECS (or what's called "ECS" nowadays) is mainly useful if you need to deal with thousands of similar data items each frame. Not many games need that outside of specialized systems like particle systems.
What about a monolith ensures better performance optimization?
And won't general-purpose engines pay a penalty relative to single-purpose engines since they have to optimize for the "average case" game rather than exactly one target?
> And won't general-purpose engines pay a penalty relative to single-purpose engines since they have to optimize for the "average case" game rather than exactly one target?
Theoretically, yes. However so many man hours have been put into optimizing engines like Unreal that in reality the answer is no.
I don't agree with this. I mean, UE renderer is the subject of countless hours of effort and optimization. But for instance the startup time (or build time for that matter) of a UE game is quite long and it is fairly easy to beat in a bespoke engine.
That's one of the reasons looser coupling would be great. I would love to be able to use the UE renderer in the context of a different engine.
At its core a game engine is a render loop and a game logic loop. If you're using a 3rd party renderer, your "engine code" might fit in a single source file if you're making a game like asteroids or tic tac toe for example.
What you're talking about is a particular type of game engine: a tool with integrated editor, AAA 3D renderer, and which is general-puropose enough to support many different types of games built on top of it. That's a very very narrow way to define game engines, and imo it creates the wrong impression that games are this infinitely complex medium which it takes hundreds of people to work on at the most basic level.
I think the author's definition is also too narrow, but it's perfectly valid to get into game engine development through small toy engines which are built from the ground up by one person.
"Why do people keep repeating this? A game engine is a monstrous piece of software from which the renderer or the physics is just a tiny part."
Maybe it is also worth noting, that there is a difference between a AAA monstrous game engine - and a simple one for casual browser games and the like?
So there might be even value in an article from a beginner covering only the basics?
(but I do agree, that the teaching was in a style overly confident not warranted)
At the very least a bespoke engine will deal with state management, data loading and saving, audio, gameplay systems and probably AI. I'd even argue that these are more of a focus in indie games than rendering is.
I would argue it very much depends on the type of game you make.
You do not always need a sophisticated assets loading mechanism nor AI modules. Or you need them in a different way, than what the engine provides (mostly my experience).
My point is, "game engine" is not a static universal concept.
Not every game needs a physic engine, for example, nor even assets(I think there are engines for text only rpgs)
Sure, if you're making a text adventure in the command line, then the REPL is basically your default game engine. That's where your i/o, computation, control flow, asset management, etc is implemented/centralized.
"Game engine" outside of the context of making a game is just a runtime (and/or environment), and I agree it becomes a bit meaningless (as a prescriptive thing).
It's like saying a CPU needs to have vectorized operations, or even a hardware multiply, to be called a CPU. It's true that in many, if not most, cases those are essential components. However, I find it more useful to define "game engine" as "whatever takes care of the game, physics, and display logic implementation for a particular game".
> Many a better approach would be to ask whether every game needs a game engine?
So, by my definition every game _has_ a game engine. I think a more interesting question would be, "when does a game engine need to be considered as its own logical layer or compartment?"
I never did a text based game, but I would argue, that a good engine there could help a lot with structure. And there seem to be a lot engines, a short search suggested.
And maybe no, not every game needs its own engine, but after a while you could probably extract a game engine out of every game. Whether thats worth it, usually depends on the success of the game ..
Makes sense, but then "engine" is really just a different term for what you'd call "framework" in the rest of the IT industry. And you can find more or less the same debate about what makes a good framework, whether you need one at all, etc in non-game parts of IT.
However, I agree with the OP that there are certain low-level components that are common in most games and that you'd therefore expect when choosing an engine. I'd argue that you'll at the very least want to have a game loop (or engine loop), processing of player inputs, a renderer (even if it just renders 2D sprites), and probably audio output. That usually implies you have some sort of assets that have to be managed, even if those are just bitmaps and wav files.
All of this reminds me of the discussions about what makes a game, which are common in academic research about computer games. When one mentions "computer game", I'd argue, most of us immediately have a certain mental image, usually strongly influenced by AAA games. But technically, you could also just hand your player a folder of text files that they have to navigate through in "choose your own adventure" style - and you have a "computer game" without even having a program at all.
"argue that you'll at the very least want to have a game loop (or engine loop), processing of player inputs, a renderer (even if it just renders 2D sprites), and probably audio output. That usually implies you have some sort of assets that have to be managed,"
Yeah, I agree those are the features I would expect from a common game engine. Maybe with some DB as well.
Otherwise yes, a game engine is just a special framework in my opinion. And you always have to choose the right tool for the job.
"you could also just hand your player a folder of text files that they have to navigate through in "choose your own adventure" style - and you have a "computer game" without even having a program at all. "
And I think someone here recently just published that, as a game to learn bash..
That seems like an overly narrow stance on the subject. Not all games are AAA level and not all game engines need to be competing in the same category with UE4/5/CryEngine/Unity etc. trying to reach maximal "realism". Not all engines are 3D, not all engines need/want to have realistic physics models or state of the art graphics and rendering.
Is Box2D not a "real" physics engine but a toy physics engine because it's not simulating physics in 3 dimensions?
Games are games and there are a multitude of categories and multiple different dimensions how to judge any particular game or its engine. Saying that something is not a real game engine because it doesn't meet some random narrowly defined criteria is pointless.
Surely a game engine = code that supported writing & publishing a single game. Nothing more than that.
If an indie author finishes a game on their own steam, without using a popular decades-old engine, I want to hear how they've focused their perspective to make it work.
I think you're ignoring how small the definition of "game" truly is.
For example, you need exactly none of the things you just described you make Flappy Birds.
Hell, insisting that a game engine isn't a "real" engine unless it can render 3D graphics on a GPU ignores such a huge swatch of games it's hard to know where to even start.
Indeed, game engines are one of the prime destinations for game devs near the end of their career. Game engine companies are more relaxed and on average better paying than studio work since they are not tied to game releases and the related crunch.
Yet there also exists a sea of inexperienced programmers jumping straight into "engine dev". They have none of the critical production experience which drives quality engines. This flood of enthusistic yet unprepared engineers causes a bipartite population. With the majority of public articles or YouTube presentations coming from those least prepared to speak with knowledge.
If you want to become a game engine dev your first step should be joining a studio as a gameplay programmer. No one wants to use an engine written by someone who does not know how to make games.
The next frontier is "metaverse engines". A metaverse engine client is partly like an MMO game engine, and partly like a web browser. You've got a flood of incoming events and content to deal with, no idea what it all means until it arrives, and have to present the illusion of a coherent world to the user while the data is coming in. A big difference from MMOs is that worlds with user-created content don't get all the pre-computation and optimization that happens in, say, Unreal Engine's level building tools. It's the 3D equivalent of rendering un-optimized web pages.
A metaverse engine server (probably a whole farm of services) is somewhat like a MMO game server, except that it may have to deal with other similar servers. Possibly untrusted servers run by others, if you allow portals or teleporting or adjacent regions run by different grids. Hard problem. Improbable tried to build such a thing, as Spatial OS, but the end result was really expensive to run and all the games that used it went broke.
Both Tim Sweeney and John Carmack see many unsolved problems in this area. If this "metaverse" stuff survives the hype and the scams and turns out to be important, there's plenty of hard work ahead in this area.
> If you want to become a game engine dev your first step should be joining a studio as a gameplay programmer. No one wants to use an engine written by someone who does not know how to make games.
Plenty of engine companies and studios will hire juniors and mid-level engineers into engine teams. And it’s been that way for a long time. And whilst the engine will preferably be made whilst developing actual games using it you don’t need everyone on the team to have been a gameplay programmer. There’s almost too much specialisation required these days and a lot of engine engineers aren’t interested in or good enough at game design to do gameplay roles. What it does need is active feedback from game teams building serious projects.
I’d agree though if you want stability and much less chance of crunch pick a company with a stable income. Engine companies are good for this but there are plenty of others.
It doesn't have to be monstrous. One of the first 3D FPS game engines is idtech1, from DOOM. It's less than 400KB zipped. I don't think anyone would argue that it's not a game engine, considered state of the art at one time and ported to every system under the sun.
I agree with your points on a renderer is not an engine, though.
If we are using 1993 standards, you are right. 400KB is enough. But I'm afraid the public is using 2021 standards. Even a texture is more than 400KB. Maybe you can fit a sound into 400KB.
I think your comment, coupled with parent’s, perfectly summarizes the problem most of this thread hints at. There is such a wide range of use cases in each particular facet of the engine and those use cases are going to be handled differently depending on time/expertise/budget/etc. For your purpose audio is handled well by a single file’s worth of C code, but there are games whose runtime audio components are almost a DAWs worth of processing and procedural sound generation and then coupled with an in game modifiable equalizer/quantizer/localizer/etc. Both your option and the more complex one are doing the job they need to do, but they are specified according to the ‘games’ need, not some overarching ‘here-is-what-a-game-engine-has-to-do-for-audio’ general advice about game engines. Articles about game engine design and the comments they elicit always seem to devolve into a very narrow perspective about individual implementations of some component for a specific target. Hell, I don’t even know if there is a way to broadly discuss the concept of a game engine without first talking about the species of engine your discussing, there is just too much space to be specific about things if you don’t narrow your discussion surface from the outset.
Indeed, and the main reason why proprietary APIs are a non-issue on production engines, they are packed on the respective backend plugin and that is all.
One of more frequently recommended books is Jason Gregory’s ‘Game Engine Architecture’. Neither version I have is too deep in code specifics, but for standard AAA game development (Gregory was/is at Naughty Dog on their engine team) it is a pretty detailed look at the structure and options of game engines.
For a more code centric resource I would say you could check out the YouTube videos by The Cherno (former EA engine dev).
A college course[1] I recently took involved working with LibGDX and Box2d to build a game from scratch.
Rudimentary documentation, but the wiki[2] does a good job of breaking down how each component fits in, including MPC/NPC components, Game Screens, Areas, Animations, Texture Atlases, Sound, Collisions, Physics, etc, all of this using Entity-Component, Factory design patterns.
When I built a game engine, the most important thing I learned was to use the same dt every time for the physics. So, your physics update might run multiple times within a single game loop iteration and you need interpolation to deal with any leftover time. Glenn taught me this:
I'm honestly a bit baffled by the gatekeeping in this thread.
While it's perfectly valid to use one of the big engines, it's fine even for an indie dev to build their own engine on top of frameworks like MonoGame by e.g. implementing a simple ECS or other components they want to use in their dev workflow. Not every game is a AAA game in need of a cutting edge graphics pipeline.
Some of the most accomplished indie developers wrote their own engines from scratch or used low level frameworks to build them.
I am all for writing your own engine as a learning experience. Most programmers I have worked with have done so.
I am all for sharing your learning experiences in a blog post. A lot of really good blogs do this while being really honest with where they struggled and what they learned. See https://jvns.ca/ for a prime example.
My problem with this post is that it's a post by someone very inexperienced presenting a very shallow and narrow view of what a game engine is in a surprisingly authoritative tone.
If the article would have been "I made my first basic game engine, here's how it's structured" I would have felt differently about it. But this is presented as "this is how a game engine works" and it does not present an accurate image of that.
How exactly is he supposed to change his "tone" so you're less insulted by his "authority"? You do realize that English is clearly not his primary language.
I'm beyond vexed by the number of people slamming the author for his ego, while themselves posting ego-laden responses.
Did you make a game engine? I was in game development for 15 years, and making engines is always fun and worked out well for projects I worked on.
My advice would be not to try to make THE game engine. Making a game with its own engine usually works out OK, if team has expertise, of course.
Like Unity or Unreal, don't try to replicate those, creating generic 3D engine for every game. You don't need to. But it is easy to make 2.5D game with its own engine which would absolutely reck "big guys" in performance and simplicity of use.
Been looking at ECS architecture for game engines. As opposed to a scene graph you have big in memory tables of "things". This let's you say render all the leaves on all the trees in one OpenGL draw call. As opposed to traversing a scene graph and constantly switching contexts of what is being drawn.
ECS is more about shared components and batched processing of components, than it is about instanced rendering. You can instance render with or without an ECS quite easily, and an ECS doesn't negate a scene graph.
Often you'll have a scene graph and an ECS. The scenegraph consists of the entities. Otherwise it can get difficult to do a lot of world scale processing like loading in segments etc..
The verdict for indie developers (not using Unity/Unreal) seems: just bite the bullet and license FMOD (or Wwise or any of the popular proprietary audio engies).
I was actually searching for a good open-source audio library to use, and found out that my options aren't that good. SoLoud is a pain in the ass to install and integrate into an existing codebase, and OpenAL doesn't have any good implementations available (either proprietary or LGPL). I'm now just using a simple single-header audio library in cute_headers (https://github.com/RandyGaul/cute_headers/blob/master/cute_s...), but will probably switch to MiniAudio once the high-level API is finished (https://github.com/mackron/miniaudio/issues/196)
Somehow, it is completely counterintuitive to people that a coherent soundscape is important to establish a feeling of user presence in the rendered environment. Ambient sounds, footsteps, tiny impact noises etc. are essential to make a virtual world seem physical.
Partially I blame the focus that game marketing and game journalism puts on the quality of the game visuals. If your game's PR media package doesn't have good screenshots, you can pack up and go home. Maybe, the reason for that is that historically, games were marketed by getting articles about them placed in game journals and they could only present images. This has carried over to some extent to the web (screenshots are easier to make and easier on the server bandwidth than gameplay videos).
I think it’s just that humans are highly visual. You need to be able to see the thing you’re making to make it much more than you need to hear it. So sound is always an after thought and good sound also blends in to the whole.
Engine programmers are even more susceptible to this natural bias because there is a vanishingly small part of engine development that needs aural feedback. It always amazes me how many engine projects have fancy renderers but can’t do more than play one shot sound effects.
This audio bias extends into web video as well. The vast majority of videos get played without any audio.
On a side note, I've been going through games I've played that had excellent sound and some of them (e.g. the Half Life series) are among the better games of all times. The one prominent exception in my library would be Elite: Dangerous - it's a decent game overall, but not mind blowing. I believe that good audio is mostly correlated with the developer's attention to the complete experience and not just to a certain wow factor like stunning graphics or a particular gameplay gimmick.
Great question. I don't think there's a single answer for that, but I see Frameworks as being code-first tools, where developers are expected to do most of the work using code. Users are expected to write things together (views and controller), and more code is exposed to them.
In (most) engines, however, there are more assumptions baked in, and most things can be accomplished by configuration alone. Writing code is mostly an escape hatch or is required just in few places, instead of being the only way of interfacing with the engine. (Of course that doesn't apply for every engine).
I think a good comparison in the web world would be Hasura. It can do similar things that Rails also does (provide APIs), but in a more limited way, and code is not strictly necessary unless you're doing something that's not standard.
And I'm working on my second: http://ahoy.rupy.se
Right now I'm struggling with the fact that I'm not allowed to redistribute cl.exe compiler (I tried real hard: https://developercommunity.visualstudio.com/t/allow-redistri...) so people have to download the whole VS package and extract the necessary files (takes about 2 hours) to get automatic integrated recompile and hotdeploy in my engine.
So I'm looking at going full tinycc and dropping VS all together on Windows. But then seen how they are deprecating my pretty new and probably good forever Skylake on Windows 11 I'm thinking it's over and I should just switch to Jetson Nano but then I'm owned by Nvidia... (Raspberry 4 driver has HALF_FLOAT issues still and well Broadcom... + CPU/GPU balance is off) so I'm kinda loosing hope for humanity at this point!
Risc-V is not progressing hard and fast enough to make it in time!
Edit: Zig, Go, Rust and WASM are not solutions, they are fragmentations. Only C(+) on client and JavaSE (VM and GC) on server makes sense. (Gotta burn that karma somehow right?)