7 ms·

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 s

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...

maccard 6y 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 6y 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 ;-)
pjmlp 6y 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 6y 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 6y 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 ;-)

pjmlp 6y 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.