I'm reminded of Jonathan Blow's talk, "Preventing the Collapse of Civilization" [1]. Are we going to end up with a generation of game developers who don't understand the internals of their game engines? The unreal engine 5 demo has really wowed everyone but could we maybe reach a point in the future where these amazing game engines are struggling to compete against really inefficient game code?
In C/C++, dependency management is not as convenient as in Rust. There's Conan, but you have to install it. Rust comes with Cargo.
So, in C++, there are more game engines developed using a minimal amount of dependencies, and in Rust, there are more game engines developed using more external dependencies.
As the majority of people transition to Rust, even the people working on "lower level" code will also forget what internals are about.
One reason why I’m not a fan of Unity. Game engines are leaky abstractions. You hit a point where you need to know how things in general work - even if you don’t know the implementation verbatim.
Most of anything to do with programming is a leaky abstraction so hiding source code from developers and saying “you don’t need to know that” is charming at best, idiotic at worst.
Net code issues, rendering equations and HSV knowledge, audio buffers and DSP, input controller and output display latency/VR, psychology, down to IEE754 optimizations. The more you know, the better for you.
I don’t see this as realistic. Particularly when engines like UE4 and probably 5 share their source code and have a layer writing in amongst the engine cruft. Further engines like Unity whilst they don’t provide source don’t really mean you can make anything other than the simplest games without understanding what’s going on under the hood to a reasonable degree. Less technically adept game developers can get a good head start but generally will need to lean on technical colleagues or contractors.
Game development as a craft also requires a lot of creative problem solving which lends the people seriously involved in it to naturally push and probe at the edges of their knowledge.
I have the same problem - love working on the game engine (I have several), but thankfully I found someone who loves designing games and drawing pixel art. Also, he doesn't know what "using RISC-V virtual machines with thin C++ binaries as a scripting language" means, so he can't complain about all the stupid shit I'm doing!
It’s a bit unfortunate that this issue is so contentious on game development forums.
Someone wants to make a game engine, or asks for help with some aspect of making a game engine, and someone will often reply by saying “you should just use Unity” or something similar. It may be well-intentioned and they may give good reasons why you should just use engine X instead of rolling your own, but here’s the big problem…
Before you help someone, you gotta understand what their motives are.
The next part is simple—if you’re under no illusions that you are not making money by making games, the kind of dollars/time input, salable product output efficiency ratio just stops being relevant. So some other factor is relevant, if you are a hobbyist.
>Someone wants to make a game engine, or asks for help with some aspect of making a game engine, and someone will often reply by saying “you should just use Unity” or something similar.
That's also a classic BS response in Stack Overflow and such.
Someone asks "How do I do X?"
And people will jump to comment "You shouldn't do X, etc" instead of answering the question (and if needed, adding a caveat that they don't recommend it).
Many times people very well know the drawbacks of X, that it's considered a bad practice, etc, and also how to do it "the right way", but want to do X anyway for some specific reason (hacking, working around some issue, etc).
Why? Holding people who are beginners asking questions based on wrong assumptions to the standards of experts who are trying to push the boundaries with complete domain knowledge seems like a wrong thing to optimize for.
Apologies, wasn't sure who you were talking about.
The point is they're not bad assumptions, they're a pretty good prior. If you swing the other way and assume people "know what they're doing" and take their word for it, you're going to give them and yourself a lot of grief in a majority of cases ("but how do I put the gasoline in the chainsaw to cut the chicken?").
I used to think the way you do, but as I spent more time on forums like Stack Overflow, I started to see the damage that this kind of behavior does to the community. I now see this behavior as an opportunity for a teachable moment to explain to people how to answer questions.
It’s one thing if you are on the DIY Stack Exchange and ask how to knock out a wall, and the best answer is, “That’s a load-bearing wall. You don’t knock it out.”
It’s another thing entirely when you ask innocuous questions like, “How do I tell what web browser and version my code is running in?” and some smartass answers, “You should be using feature detection.”
It’s really frustrating to ask a straightforward question and to get a response from five different people making invalid assumptions about what problem you’re trying to solve. It makes the community seem downright hostile! You may think that you’re addressing the underlying problems—but what you’re doing is telling people, “I don’t take your questions seriously; I know better than you.”
That might not be the message you want to send, but if you rely on assumptions then it will be the message that you do send.
> And people will jump to comment "You shouldn't do X, etc" instead of answering the question
While this can sometimes be annoying, this is actually one of my favourite things about Stack Overflow. Because it means you can ask a really naive question, and actually come away with knowledge of what best-practices for your high-level problem are.
That's because, for better or worse, there's usually no visible difference between a question asking "How do I do X?" from a kid at home making something for fun, and the same question from a professional on a mission-critical system.
The same question in different context may have completely different answers, yet StackOverflow is all about finding the "correct" answer, and closing "duplicate" questions.
As with nearly every other aspect of modern life, people are at the mercy of a system of rules whose rewards don't exactly align with the benefit of the people in it.
Also...where do you get game engine developers to work on those established projects if everyone is told not to bother?
I see variations of this with other fields as well. People disparage college operating systems and programming language classes, because "we have plenty of those already" or say that people should contribute to an established project of some kind instead of reinventing the wheel. But that's how you gain an understanding of how a piece of software works, or how you end up with a new thing that's better than the old one.
You get people from some adjacent field (some CAD/CAM people for the geometry bits, someone from Uber for the distributed system bits) to solve the hard technical problems and hire game programmers for more product development / API design type roles
Theres a problem with online forums. People glom their opinions together about solving a common problem (like making a game) into a big rolling ball. People who have a different goal but a similar problem become difficult to answer without tearing yourself out of your own commonly shared train of thought.
The perfect answerer would have expert knowledge and the free time and an omni-directional goal to serve all questioners. Those people aren't out there.
Butchering Eisenhower's famous quote about planning in times of war:
> In producing a skilled game developer, I have always found that their self-made engines are useless, but the development experience is indispensable.
My college has a senior project course every spring. The class is divided into groups of four to five members. Each group implements the same board game as a video game in a competition. The board game always is always deterministic with perfect information (i.e. chess or checkers).
Most team use Unity. Two years ago there was an unsuccessful attempt in Unreal, and three years ago an excellent game with web technologies (Electron + Angular).
I took this course last year and my team took a different approach. Our class's board game was Quoridor[1] and my group wrote a game engine[2] in Java leveraging OpenGL for graphics and Netty for socket abstractions.
The amount I learned that semester was incredible. Never before have I needed to know anything about graphics rendering, how to load fonts from a file and convert it into a texture format. I never needed to know about how to actually create a networked application, how to use genetic algorithms to tune AI weights, or put all of that together to create a game.
Our game sucked, but it was the most productive three months of my education and I learned more through that self-imposed struggle than my prior three years and a half years of classes. A game engine can touch any field in computer science and bring it into one application, and I think that's incredible.
I remember this urge, it took me once. I wrote a physics+animation engine for the Palm Pilot(!) and wrote a couple games in it - Lexicon and Combinoid. Moving sprites, collision, physics. Fun while it lasted.
Turns out there wasn't really a market for games on the Palm Pilot. Oh well.
The general case game engine, such as Unity, are one size fits all. It can make sense to make specialized game engines that optimize for a specific gameplay dynamic.
Today, building a custom game engine does not necessarily mean building everything from scratch.
A lot of very good open-source libs can be assembled to relatively quickly build a working engine tailored for the needs of the games you want to build.
SDL, bgfx or Diligent can be used a simple platform/rendering abstractions, many of the excellent stb libs can be used for resources loading, or Assimp if you need 3D assets, simple or complex physics engine are also available, same for audio and networking...
Most of what goes into a game engine is not those.
SDL is a similar level of abstraction to win32/x11/...
Bgfx/diligent have a similar level abstraction to d3d/opengl/...
(And if you are a solo engine-writer, you're not going to write more than one custom windowing/graphics target anyway, so those libs don't reduce the amount of work you have to do.)
A basic image loader for a format like bmp or netpbm is trivial.
Here are all the dependencies for my game engine right now:
- Assimp
- Freetype
- SDL
- Linear algebra library
- Intel intrinsics library (transitive dependency of the
math library)
- S7 scheme
- stb-image
- Toml parser
- Audio library
I estimate it would take under a week to replace all those except freetype and assimp, and freetype could be replaced with bitmapped fonts. Making an engine is as much (or as little) work as it's ever been because, similarly to a web browser or an OS, the challenge is designing and implementing application infrastructure.
More interesting, IMO, is to look at the ways that general-purpose engines have allowed people to avoid building engines in the first place. Something like unity is a toolbox to let you build any game you would want without needing to write thousands of lines of infrastructure code. Even lighter-weight toolkits like love,fna,raylib are general enough to be usable for a broad variety of games, while still providing enough specific functionality that you can just start writing your game.
It's unfortunate that everything has gone high-level (Unity/Unreal) or ultra low-level (Vulkan/Metal/DX12).
In the 2000s hobbyists were doing stuff in the middle level, because you had to stitch together your window management, GL/DX code, physics libraries, sound libraries, net code, input code, yourself.
I don't know that you always want to do that, but everybody ought to do it at least once.
It's not a waste of time. For effectively using off the shelf game engines, you need to have a good understanding of what's going on under the hood. And the best way to learn that is by building your own toy engine.
I'm currently making a game engine myself and it has been both challenging and fulfilling.
I don't expect people to use what I've made, but as long as I learn from it, it is not going to be a waste of time.
Each step on making the engine has been full of important lessons:
* With OpenGL I learned about graphics and how they are rendered on a screen. Knowledge on this has helped with optimizations on my other projects made with Unity
* Adding Lisp scripting has renewed my love of Lisp and has made me realize the importance of scripting on game engines
* Implementing cross platform has made me realize just how difficult this is and why most people jsut go with Unity because it's offered out of the box.
* Designing APIs and functions is not trivial. Each game engine has a different way of doing things and it is mostly dictated by their technology stack.
I'm working on this mostly for learning purposes and I've been logging my journey every step of the way. If anyone is intetested in checking it out, or give suggestions or critiques, here's the link:
I love this mindset. I think as engineers we often get discouraged when we feel like our own implementation of something could never be as good as what's already out there (at least, I do). But the question that should be asked is: "Would it make me happy to do it myself?" If so, then who cares! Hobby projects are about making yourself happy. There's nothing wrong with doing something purely for fun.
If you really want to make a game that doesn't give the user a feeling that they've played it before you do need to make your own engine.
You can tell in seconds that a game feels and renders like another game using the same engine. Sometimes the quirks and unique characteristics of a custom engine are what give a game its charm and X factor.
39 comments
[ 3.8 ms ] story [ 101 ms ] thread[1] https://www.youtube.com/watch?v=pW-SOdj4Kkk
So, in C++, there are more game engines developed using a minimal amount of dependencies, and in Rust, there are more game engines developed using more external dependencies.
As the majority of people transition to Rust, even the people working on "lower level" code will also forget what internals are about.
Most of anything to do with programming is a leaky abstraction so hiding source code from developers and saying “you don’t need to know that” is charming at best, idiotic at worst.
Net code issues, rendering equations and HSV knowledge, audio buffers and DSP, input controller and output display latency/VR, psychology, down to IEE754 optimizations. The more you know, the better for you.
Game development as a craft also requires a lot of creative problem solving which lends the people seriously involved in it to naturally push and probe at the edges of their knowledge.
I still think a JASS-like code editor would have been better than blueprints for giving news a mental framework for transitioning into C++.
Looked like this:
http://world-editor-tutorials.thehelper.net/dialog/dodialog....
Someone wants to make a game engine, or asks for help with some aspect of making a game engine, and someone will often reply by saying “you should just use Unity” or something similar. It may be well-intentioned and they may give good reasons why you should just use engine X instead of rolling your own, but here’s the big problem…
Before you help someone, you gotta understand what their motives are.
The next part is simple—if you’re under no illusions that you are not making money by making games, the kind of dollars/time input, salable product output efficiency ratio just stops being relevant. So some other factor is relevant, if you are a hobbyist.
That's also a classic BS response in Stack Overflow and such.
Someone asks "How do I do X?"
And people will jump to comment "You shouldn't do X, etc" instead of answering the question (and if needed, adding a caveat that they don't recommend it).
Many times people very well know the drawbacks of X, that it's considered a bad practice, etc, and also how to do it "the right way", but want to do X anyway for some specific reason (hacking, working around some issue, etc).
https://en.wikipedia.org/wiki/XY_problem
So it's not so much of a "BS response" as a rational first response, even if frustrating for people who don't fall in that category.
These are people who make bad assumptions when they answer questions.
The point is they're not bad assumptions, they're a pretty good prior. If you swing the other way and assume people "know what they're doing" and take their word for it, you're going to give them and yourself a lot of grief in a majority of cases ("but how do I put the gasoline in the chainsaw to cut the chicken?").
It’s one thing if you are on the DIY Stack Exchange and ask how to knock out a wall, and the best answer is, “That’s a load-bearing wall. You don’t knock it out.”
It’s another thing entirely when you ask innocuous questions like, “How do I tell what web browser and version my code is running in?” and some smartass answers, “You should be using feature detection.”
It’s really frustrating to ask a straightforward question and to get a response from five different people making invalid assumptions about what problem you’re trying to solve. It makes the community seem downright hostile! You may think that you’re addressing the underlying problems—but what you’re doing is telling people, “I don’t take your questions seriously; I know better than you.”
That might not be the message you want to send, but if you rely on assumptions then it will be the message that you do send.
While this can sometimes be annoying, this is actually one of my favourite things about Stack Overflow. Because it means you can ask a really naive question, and actually come away with knowledge of what best-practices for your high-level problem are.
The same question in different context may have completely different answers, yet StackOverflow is all about finding the "correct" answer, and closing "duplicate" questions.
As with nearly every other aspect of modern life, people are at the mercy of a system of rules whose rewards don't exactly align with the benefit of the people in it.
I see variations of this with other fields as well. People disparage college operating systems and programming language classes, because "we have plenty of those already" or say that people should contribute to an established project of some kind instead of reinventing the wheel. But that's how you gain an understanding of how a piece of software works, or how you end up with a new thing that's better than the old one.
Though i do not think any of them is interested in working in games nowadays.
The perfect answerer would have expert knowledge and the free time and an omni-directional goal to serve all questioners. Those people aren't out there.
> In producing a skilled game developer, I have always found that their self-made engines are useless, but the development experience is indispensable.
Most team use Unity. Two years ago there was an unsuccessful attempt in Unreal, and three years ago an excellent game with web technologies (Electron + Angular).
I took this course last year and my team took a different approach. Our class's board game was Quoridor[1] and my group wrote a game engine[2] in Java leveraging OpenGL for graphics and Netty for socket abstractions.
The amount I learned that semester was incredible. Never before have I needed to know anything about graphics rendering, how to load fonts from a file and convert it into a texture format. I never needed to know about how to actually create a networked application, how to use genetic algorithms to tune AI weights, or put all of that together to create a game.
Our game sucked, but it was the most productive three months of my education and I learned more through that self-imposed struggle than my prior three years and a half years of classes. A game engine can touch any field in computer science and bring it into one application, and I think that's incredible.
[1] https://en.wikipedia.org/wiki/Quoridor
[2] https://github.com/harding-capstone
Turns out there wasn't really a market for games on the Palm Pilot. Oh well.
It seems like game engines should go the way of linux. No one would really consider making a new commercial os these days.
I don't think it's at the polish of Unreal or Unity, but it's probably the closest attempt for open source.
Also, with FPGAs, maybe we should see more OS HW level experimentation.
A lot of very good open-source libs can be assembled to relatively quickly build a working engine tailored for the needs of the games you want to build.
SDL, bgfx or Diligent can be used a simple platform/rendering abstractions, many of the excellent stb libs can be used for resources loading, or Assimp if you need 3D assets, simple or complex physics engine are also available, same for audio and networking...
SDL is a similar level of abstraction to win32/x11/...
Bgfx/diligent have a similar level abstraction to d3d/opengl/...
(And if you are a solo engine-writer, you're not going to write more than one custom windowing/graphics target anyway, so those libs don't reduce the amount of work you have to do.)
A basic image loader for a format like bmp or netpbm is trivial.
Here are all the dependencies for my game engine right now:
- Assimp
- Freetype
- SDL
- Linear algebra library
- Intel intrinsics library (transitive dependency of the math library)
- S7 scheme
- stb-image
- Toml parser
- Audio library
I estimate it would take under a week to replace all those except freetype and assimp, and freetype could be replaced with bitmapped fonts. Making an engine is as much (or as little) work as it's ever been because, similarly to a web browser or an OS, the challenge is designing and implementing application infrastructure.
More interesting, IMO, is to look at the ways that general-purpose engines have allowed people to avoid building engines in the first place. Something like unity is a toolbox to let you build any game you would want without needing to write thousands of lines of infrastructure code. Even lighter-weight toolkits like love,fna,raylib are general enough to be usable for a broad variety of games, while still providing enough specific functionality that you can just start writing your game.In the 2000s hobbyists were doing stuff in the middle level, because you had to stitch together your window management, GL/DX code, physics libraries, sound libraries, net code, input code, yourself.
I don't know that you always want to do that, but everybody ought to do it at least once.
I don't expect people to use what I've made, but as long as I learn from it, it is not going to be a waste of time.
Each step on making the engine has been full of important lessons:
* With OpenGL I learned about graphics and how they are rendered on a screen. Knowledge on this has helped with optimizations on my other projects made with Unity
* Adding Lisp scripting has renewed my love of Lisp and has made me realize the importance of scripting on game engines
* Implementing cross platform has made me realize just how difficult this is and why most people jsut go with Unity because it's offered out of the box.
* Designing APIs and functions is not trivial. Each game engine has a different way of doing things and it is mostly dictated by their technology stack.
I'm working on this mostly for learning purposes and I've been logging my journey every step of the way. If anyone is intetested in checking it out, or give suggestions or critiques, here's the link:
https://github.com/accidentalrebel/Rebel-Game-Engine
You can tell in seconds that a game feels and renders like another game using the same engine. Sometimes the quirks and unique characteristics of a custom engine are what give a game its charm and X factor.