> 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 ;-)
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 ;-)