12 ms·
How does a game engine work? an overview (2016)
- rubyist5eva 5y agoWhat makes a game engine different than a framework, ie. Unreal is a game engine whereas Ruby on Rails is a framework (web app engine?)
- ratww 5y agoGreat 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.
- rubyist5eva 5y agoThank you for the thorough response.
- rsp1984 5y ago> 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.
- fulafel 5y agoVery true. In the end, WebGL finally did it... mostly.
- kaetemi 5y agoAnd sound? :)
- Agentlien 5y agoIt's amazing how often people forget about audio despite what a huge impact it has on us. When I worked in AAA we would get periodical reminders not to mute the game when playing. People still did.
- cyber_kinetist 5y agoThe 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_sound.h 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 https://github.com/mackron/miniaudio/issues/196)
- gmueckl 5y agoSomehow, 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).
- 5y ago
- rohithkp 5y agoA 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. [1]: https://github.com/UQdeco2800/2021-ext-studio-2 https://github.com/UQdeco2800/2021-ext-studio-2 [2]: https://github.com/UQdeco2800/2021-ext-studio-2/wiki/Getting-Started https://github.com/UQdeco2800/2021-ext-studio-2/wiki/Getting...
- Agentlien 5y agoI'm not really impressed with this article. 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.
- LadyCailin 5y agoI 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.
- midnightclubbed 5y agoAbsolutely 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.
- DeathArrow 5y ago>A game engine consists of three smaller engines: >Math Engine >Rendering Engine >Physics Engine 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.
- chuckSu 5y agoHater alert!
- deleted 5y ago[deleted]
- jedimastert 5y agoI 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.
- mysterydip 5y agoIt 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.
- 5y ago
- sushsjsuauahab 5y agoItt: purists one up each other on how things are supposed to be.
- openthegates 5y agoI'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.
- Agentlien 5y agoI don't see this as gatekeeping. 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/ 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.
- tomnipotent 5y ago> in a surprisingly authoritative tone 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.
- DeathArrow 5y agoI worked 7 years as a game developer. And while I've written some parts of some renderers, one thing I didn't: attempt to implement a game engine.
- Svoka 5y agoDid 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.
- bullen 5y agoI have made 1 game engine: http://aeonalpha.com http://aeonalpha.com And I'm working on my second: http://ahoy.rupy.se 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-redistribution-of-the-clexe-compiler/975508 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?)
- guerrilla 5y agoI don't think I understand your problem well enough, but just in case, would using dlopen with gcc or LLVM instead help?
- srgpqt 5y agoPerhaps you could include the zig compiler instead, and use “zig cc” to compile C/C++ with it.
- deleted 5y ago[deleted]
- flohofwoe 5y agoDid 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: https://github.com/ziglang/zig-pypi https://github.com/ziglang/zig-pypi
- codingclaws 5y agoWhen 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: https://gafferongames.com/post/fix_your_timestep/ https://gafferongames.com/post/fix_your_timestep/
- kristov 5y agoBeen 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.
- dagmx 5y agoECS 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..
- meheleventyone 5y agoAn ECS and a scene graph aren’t really mutually exclusive nor do you need an ECS to do instanced rendering.
- mkotowski 5y ago> A game engine consists of three smaller engines […] Compare with a far more detailed Figure 1.15 [0] from “Game Engine Architecture”. [0]: https://www.gameenginebook.com/figures.html https://www.gameenginebook.com/figures.html