▲ 32 points
back
24 comments
There's plenty of material on those topics already. In fact, another big book about graphics was discussed on HN yesterday.
The areas where we need new books relate to multi-user games and scaling. How do you build a really big world? How do you manage terabytes, or even petabytes, of remotely stored content? How do you deal with client/server lag? How do you deal with content loading during fast motion? How do you do automated level of detail generation and impostoring? In worlds with user-generated content, how do you do quality control? How do you deal with overload due to excessively detailed content? How do you make a modern layered clothing system? How do you deal with too many players in the same area?
There is plenty of material on this topic already, and as other people pointed out the topics that you've mentioned would require some very specific experience that likely only a handful of people around the world have.
It's great to have a plethora of authors to choose from though, even when it comes to foundational material. For instance, I would have never learned as much as I have about programming language design and implementation if Bob Nystrom hadn't written crafting interpreters. There's plenty of material already about the foundations of programming language design, but he wrote the book anyways and I'm very glad he did.
I like going through foundational material in these types of books even if I'm already familiar with a lot of it. Most of the time I'll find a couple of nuggets of information that I never knew about before. So I agree that specialty books would be amazing, but I disagree about the notion that we don't need anymore books about the fundamentals.
There are a lot fewer people with this expertise, and of those, that can communicate it well and have the time to write a book I'm sure makes them a relatively small group of people. They probably mostly work in AAA studios, since only they have the scale and money to encounter and tackle these problems. I do wish more of them would, however.
Someone like Pat Wyatt comes to mind:
Networking falls outside the typical game engine. A game engine is largely rendering, physics, controls. The questions you are asking is largely design related and solved by existing networking state tools. Most of which is proprietary or require expertise in networking domain. Seems like your question is more of "How do I build an MMO" which is almost certainly a solution looking for a problem.
Networking falls outside the typical game engine.
The major game engines include networking.
* Unreal Engine, networking section, documentation.[1]
* Unity game engine, networking section, documentation.[2]
My own interest is in metaverse systems, with big, detailed, free-play worlds. Wrangling all that content presents a set of problems that are not well solved yet. Which is why the highly publicized metaverses look so much worse than a typical AAA title. They haven't solved content wrangling, so they have to limit content complexity so severely it looks like 1995. I'm plugging away on that problem. (Demo video: [3]). It seems to be quite solveable, but there's not much written on the subject and I'm having to re-invent too much.
[1] https://docs.unrealengine.com/5.0/en-US/networking-and-multi...
The "big ones" like Unity, Cryengine, Unreal etc. include many many things. They are absolutely huge compared to what a single game using them actually needs.
A game engine is just that: an engine for games to run on to seperate engine and gameplay programming.
If your team decides to create singleplayer game(s), and your own engine as a platform for it, then building full networking and netcode into that would be out of scope. That would still be a game engine nonetheless.
Can the term game engine include networking? Absolutely. Does game engine inherently imply networking? No, I don't think so.
> A game engine is largely rendering, physics, controls.
If "controls" are an integral part of a game engine, then networking is as well. Networking is just another control/input device. You read bytes from your joystick driver, you read bytes from your network driver.
Building a robust input handling system that can handle a variety of input devices, high latencies, failures, recoveries, etc is absolutely an integral part of building a modern game engine.
Agreed, spending what appear to be 1000+ pages of "foundations" before covering networking (if at all) seems to be missing the point about what game engine development is in 202X.
Seems like a more germane title would be "foundations of real-time 3D physics simulation".
Huge fan of Eric. I've had several of his books on the shelf over the years. His old game engine (C4) was impressive and gave me something to aspire to. The architecture was well thought out. The math was on point. The performance was good.
I would echo other comments that these subjects have been written about ad nauseum. What we, the indy dev community, and engineers here would like to see is how to achieve Multiplayer scaling, solving state issues, sharing state. Network architectures beyond the lobby. Sound architectures beyond the 3D Listener with Doppler effect. Graphics architectures for polished rendering pipelines in PBR.
Math for games is great. Graphics for games is great. We need more meat though.
One of the books on my shelf right now is Game Engine Architecture 2nd ed by Jason Gregory (which is excellent, btw) that goes into the surface of this stuff.
I don't want a world where our only choices are Unity, Unreal, or some small engine. I don't want a world where one company owns the experience (Meta, VR). I don't want a world where every operating system has their own graphics framework (damn, MetalVulkanicDirectGL?).
I still have nothing but love for Eric and will probably buy these for the support. Sadly my interest in graphics programing died with Apple deprecating OpenGL and introducing Metal.
Metal is great. Of the current generation of modern low-overhead Gfx APIs I think Metal was the easiest to get started with, great documentation and examples. While it takes more specialized knowledge to get started compared to OpenGL, I think there are now several good cross platform libraries like bgfx and sokol to satisfy the need for a higher level cross platform library (including shader transpiling) that fill the need that OpenGL used to serve.
I'm glad OpenGL got deprecated across the industry, despite the patchwork of extensions it was based on a model of GPU + CPU capability from the 1990s and became obsolete.
Yeah, I’m currently a big bgfx fan.
I think not dropping support for certain specs is what killed OpenGL. 2/3s of it is bloat to support old immediate mode or older hardware.
A PureGL focused on buffers and shaders. Which is what Metal, Vulkan, DX12 is all about now.
SPIR-V might help standardize the shaders under the HLSL syntax but that’s a whole other mess.
5 - Animation
6 - AI
7 - Networking
8 - Networking (real-time synchronization)
9 - Networking (many users)
10 - Serialization and asset management
11 - GUI and settings
12 - Custom in-editor tools
13 - Optimization part 1
14 - Optimization part 2
15 - More rendering
16 - More AI
17 - ???
You have a lot more 200-page books to go. Also this is just game development, you also need design, publishing, promoting, legal, etc.
+ message passing, anti-cheat
Data/Metadata/logging/telemetry
You totally forgot audio. Sound effects, music, ambience etc.
Is there an ETA for Volume 3? Seems weird to post this on HN if there is nothing new since the 2nd volume was published in 2019.
I have the two books currently sitting next to me. They're very very in-depth and math focused (well that's sort of expected for the mathematics book at least) - you might want to also look at some more lightweight and "fun" tutorials for rendering and going in-depth with the rendering book in parallel.
This appears to be good for a game engine, but is there any good literature on game design?
There are many good books on game design. Here are a few that I own:
The Art of Game Design: A Book of Lenses, by Jesse Schell
Level Up! The Guide to Great Video Game Design, by Scott Rogers
A Theory of Fun for Game Design, by Raph Koster
Designing Games: A Guide to Engineering Experiences, by Tynan Sylvester
Game Feel: A Game Designers Guide yo Virtual Sensation, by Steve Swink
Designing Virtual Worlds, by Richard Bartle
Here are a few more that I haven’t read and don’t own, so don’t know anything about them:
Elements of Game Design, by Robert Zubek
Advanced Game Design: A Systems Approach, by Michael Sellers
Game Mechanics: Advanced Game Design, by Ernest Adams & Joris Dormans
The Ultimate Guide to Video Game Writing and Design, by Flint Dille & John Zuur Platten
I’m sure there are more. You have quite a few to choose from! If you plan on reading just one, I recommend the first one on my list.
Garfield, Elias, and Gutschera's Characteristics Of Games is a good foundation.
I second this! A lot of the popular game design books are pretty woo-woo but this one keeps things realistic.
I've lost count of how many times I've eagerly started a new game engine project - yet I still haven't learned how absolutely gargantuan that kind of project is.
Sounds like me. It’s been my recurring project, restarted every few years. My previous one got as far as a module system, multithreaded job system, basic event system, ECS and a usable editor based on Dear ImGUI but has very limited rendering, if you could call it that at all.
My latest iteration is actually making some strides and has most of the above plus Lua scripting, a scene system, notification events (x happened) as well as messages (events posted specifically to entities or groups of entities) and asynchronous resource loading. I am currently cleaning up the code and then I plan to add PhysX support. Rendering is still very basic though.
But that’s ok, it’s my for fun personal project, where I can tackle the challenges that are interesting or fun to me (I enjoy creating a cache efficient messaging system based on a paged stack allocator memory pool... these are things I absolutely don’t need but really enjoy writing).
Will I ever complete it or make a substantial game with it? Probably not.
But it keeps programming enjoyable (and helps me retain some c++ knowledge)
The hard part is the editor.
You can make a nice 3D renderer, learn shaders, bring in a physics library, make a bunch of models and textures, write a lighting system, add a system of animation, make an actor/AI system, create 2D UI helpers for menus/HUDs, work out a file format for storing and loading state...
...And then realize that it's very difficult to create a detailed world when you can't see it and manipulate it in realtime. D'oh.