Making game engines is a waste of time – I probably won’t stop making them
benwiser.com
benwiser.com
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.
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.
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....
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:
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.
_______________________________________________________
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.
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.
Turns out there wasn't really a market for games on the Palm Pilot. Oh well.