Isetta: Writing a Game Engine from Scratch
isetta.io
isetta.io
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...
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 ;-)
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.
...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.