I highly recommend the 'interviews' part of this site [0]. Reading the honest opinions of professionals in this field helped me a huge amount when I was first digging into the internals of game engines and guided my thinking to understand some of the driving priorities.
For example - the role an engine plays in a content pipeline [1] and therefore the whole operation of a AAA studio may be something non-obvious to someone who hasn't working in the industry. These interviews give you enough to realise you may be missing something and point you in the right direction to read more.
IMHO putting graphics & input on the same line is underestimating the complexity. Going from metal to scene graph management can be complex. I remember when I started in OpenGL back in the day - it gave me a strong appreciation for why middle ware existed. Don’t get me started on input. :-)
Edit: e.g. good simple twin stick shooter needs at least draw call batching and the rest to draw millions of particles and hundreds of enemies. Then there is the issue of animation — and the rest. Art pipeline ? Textures or vertex colors ? Rendering engine is a pretty big deal. The rest IMHO is pretty simple in comparison...
pjmlp 1234 days ago [-]
Indeed, that is the main issue that Khronos API advocates always miss.
OpenGL, and now Vulkan, are pretty bare bones, and just a tiny part of what means to have a proper game engine, so basically everyone that bets on their "portability" ends up writing a middleware engine anyway.
Because not only one has to deal with everything a game engine requires, it also needs to handle extensions, possible code paths to work around driver bugs, and to handle the various levels of support for those extensions.
I have done my degree thesis in OpenGL, back when writing a particles engine was still big enough to be worthy of a thesis, instead of a checkbox on game engine middleware, so I am beyond that now.
However it kind of irritates me to see it is still the rite of passage for what differentiates boys from men when dealing with Khronos APIs.
maccard 1234 days ago [-]
> The rest IMHO is pretty simple in comparison...
I think you're way off base here. No arguments that rendering is _hard_, but the rest isn't simple at all. It depends on where you draw the line between rendering and <other system> but animation for example, can be just as difficult and really has nothing to do with the rendering part of a game engine.
Physics simulations (fluids, soft bodies/deformables, breakables) are also unsolved in a real time environment.
Networking is tough; games have strict latency requirements, and perform all sorts of tricks to minimize bandwidth usage.
Input (as you mentioned) is tough too, albeit solved for the most part by now.
It's also worth mentioning that this is all work needed for a game _engine_ you still need a game on top of it.
appstorelottery 1234 days ago [-]
> really has nothing to do with the rendering part of a game engine.
I disagree here, it depends on how you are going to implement animation. For example, if you're using shaders to manipulate vertexes - that's rendering engine land.
> Physics simulations (fluids, soft bodies/deformables, breakables) are also unsolved in a real time environment.
Yes - and again, depends on where you draw the line between physics and rendering engine if there are code-crossovers on the GPU. You could say architecturally, ok - this is the GPU engine in a very simple case.
> Networking is tough; games have strict latency requirements, and perform all sorts of tricks to minimize bandwidth usage.
Yes - totally agree with you here. This is a deep problem. For this kind of game you probably want a deterministic physics engine so everyone is seeing the same thing (running local physics simulations etc.).
> Input (as you mentioned) is tough too, albeit solved for the most part by now.
Agreed, but it's solved well by specialised 3rd party tools mostly. For example, in the Unity Engine control disconnects etc are still an issue in the base library. Rewired is one solution to this.
> It's also worth mentioning that this is all work needed for a game _engine_ you still need a game on top of it.
Yeah. Managing gameplay logic - again - how does this all come together.
Anyhow, I'm glad they are giving it a shot. It will be interesting to see how it all comes together.
I'd like to see a project actually where someone makes a twin stick shooter without any kind of engine at the lowest level we can get to right now without too much hassle (e.g. GLSL, direct to TCP/IP, maybe FGPA for server). That would be super cool.
EDIT: Just for clarity, I'm not trying to start an argument with you - I suppose we're drawing straws on how to delineate functionality. And further, I don't see a clear game design from this group to start with. If it's just simple shapes like Geometry wars then art pipeline becomes simple - if the physics part of things is simple as well (a little momentum and friction), and the net side of things isn't battle Royale requirements - then it's not rocket science. I guess my point was that GPU programming had a very steep learning curve for me, and I started way back in the dat on 3DFX hardware (I'm not super bright when it comes to paradigm shifts). I think one of the things I didn't see was their idea on what hardware they aim to target and what the game design was in more detail. Back in the day engines were written to satisfy game design - but the most complicated parts of the engine were on the GPU side. Anyhow - respect. You've obviously got some background here as well ;-)
wokwokwok 1235 days ago [-]
I find this very interesting, because I feel like it's one of those 'outcome' driven projects, where no real consideration is given to any kind of maintainability, and you quickly throw together a buggy prototype in a few months.
...and no one ever touches it again [1].
That was never the goal though, and as they point out in the retrospective [2]:
> We were asked whether the project would have benefit from a stricter testing phase to developing, with each code iteration requiring some testing, and we believe the answer is still no. While our engine could have used more testing, the project's mission was to learn, and we wouldn't have been able to learn as much by being more methodical.
> What the Isetta Engine allowed us to do was see the whole picture of a game engine, what it takes to build one, and how the engine development process works.
To be fair, it did that... but it's a pity they had to learn the hard way, by making something they poured their hearts and souls into and then... just, never touch again.
> We weren't being given explicit feedback about the engine we were developing from our faculty or others, and we were no longer spending even the majority of our time learning game engine development. At some point near the end, the project pivoted from its original goal, and we had to do something that was no longer learning. And it just became a slog.
I'm also working on an educational game engine 'from scratch', though for me this includes my own rendering engine. The linked article was just to an introdution, which made me think think this was a fluff submission with no real content, but the engine and project is from 2018 and quite well documented (perhaps the year should be included in the submission title).
Anyways, favorited so that I can examine further and utilize some of the lessons already learned.
sim_card_map 1234 days ago [-]
Creating a game engine from scratch that only runs/compiles on Windows...
Rendered at 21:49:39 GMT+0000 (Coordinated Universal Time) with Vercel.
For example - the role an engine plays in a content pipeline [1] and therefore the whole operation of a AAA studio may be something non-obvious to someone who hasn't working in the industry. These interviews give you enough to realise you may be missing something and point you in the right direction to read more.
[0] https://isetta.io/interviews/
[1] https://isetta.io/interviews/AmandineCoget-interview/#the-mo...
Edit: e.g. good simple twin stick shooter needs at least draw call batching and the rest to draw millions of particles and hundreds of enemies. Then there is the issue of animation — and the rest. Art pipeline ? Textures or vertex colors ? Rendering engine is a pretty big deal. The rest IMHO is pretty simple in comparison...
OpenGL, and now Vulkan, are pretty bare bones, and just a tiny part of what means to have a proper game engine, so basically everyone that bets on their "portability" ends up writing a middleware engine anyway.
Because not only one has to deal with everything a game engine requires, it also needs to handle extensions, possible code paths to work around driver bugs, and to handle the various levels of support for those extensions.
I have done my degree thesis in OpenGL, back when writing a particles engine was still big enough to be worthy of a thesis, instead of a checkbox on game engine middleware, so I am beyond that now.
However it kind of irritates me to see it is still the rite of passage for what differentiates boys from men when dealing with Khronos APIs.
I think you're way off base here. No arguments that rendering is _hard_, but the rest isn't simple at all. It depends on where you draw the line between rendering and <other system> but animation for example, can be just as difficult and really has nothing to do with the rendering part of a game engine.
Physics simulations (fluids, soft bodies/deformables, breakables) are also unsolved in a real time environment.
Networking is tough; games have strict latency requirements, and perform all sorts of tricks to minimize bandwidth usage.
Input (as you mentioned) is tough too, albeit solved for the most part by now.
It's also worth mentioning that this is all work needed for a game _engine_ you still need a game on top of it.
I disagree here, it depends on how you are going to implement animation. For example, if you're using shaders to manipulate vertexes - that's rendering engine land.
> Physics simulations (fluids, soft bodies/deformables, breakables) are also unsolved in a real time environment.
Yes - and again, depends on where you draw the line between physics and rendering engine if there are code-crossovers on the GPU. You could say architecturally, ok - this is the GPU engine in a very simple case.
> Networking is tough; games have strict latency requirements, and perform all sorts of tricks to minimize bandwidth usage.
Yes - totally agree with you here. This is a deep problem. For this kind of game you probably want a deterministic physics engine so everyone is seeing the same thing (running local physics simulations etc.).
> Input (as you mentioned) is tough too, albeit solved for the most part by now.
Agreed, but it's solved well by specialised 3rd party tools mostly. For example, in the Unity Engine control disconnects etc are still an issue in the base library. Rewired is one solution to this.
> It's also worth mentioning that this is all work needed for a game _engine_ you still need a game on top of it.
Yeah. Managing gameplay logic - again - how does this all come together.
Anyhow, I'm glad they are giving it a shot. It will be interesting to see how it all comes together.
I'd like to see a project actually where someone makes a twin stick shooter without any kind of engine at the lowest level we can get to right now without too much hassle (e.g. GLSL, direct to TCP/IP, maybe FGPA for server). That would be super cool.
EDIT: Just for clarity, I'm not trying to start an argument with you - I suppose we're drawing straws on how to delineate functionality. And further, I don't see a clear game design from this group to start with. If it's just simple shapes like Geometry wars then art pipeline becomes simple - if the physics part of things is simple as well (a little momentum and friction), and the net side of things isn't battle Royale requirements - then it's not rocket science. I guess my point was that GPU programming had a very steep learning curve for me, and I started way back in the dat on 3DFX hardware (I'm not super bright when it comes to paradigm shifts). I think one of the things I didn't see was their idea on what hardware they aim to target and what the game design was in more detail. Back in the day engines were written to satisfy game design - but the most complicated parts of the engine were on the GPU side. Anyhow - respect. You've obviously got some background here as well ;-)
...and no one ever touches it again [1].
That was never the goal though, and as they point out in the retrospective [2]:
> We were asked whether the project would have benefit from a stricter testing phase to developing, with each code iteration requiring some testing, and we believe the answer is still no. While our engine could have used more testing, the project's mission was to learn, and we wouldn't have been able to learn as much by being more methodical.
> What the Isetta Engine allowed us to do was see the whole picture of a game engine, what it takes to build one, and how the engine development process works.
To be fair, it did that... but it's a pity they had to learn the hard way, by making something they poured their hearts and souls into and then... just, never touch again.
> We weren't being given explicit feedback about the engine we were developing from our faculty or others, and we were no longer spending even the majority of our time learning game engine development. At some point near the end, the project pivoted from its original goal, and we had to do something that was no longer learning. And it just became a slog.
[1] - https://github.com/Isetta-Team/Isetta-Engine/commits/master
[2] - https://isetta.io/engine_postmortem/SoftwareDevelopment
Anyways, favorited so that I can examine further and utilize some of the lessons already learned.