4 ms·

On the other hand, porting to other platforms is probably never a no-op even when building on big 3rd party tech stacks. Many of the platform specifics will shi

On the other hand, porting to other platforms is probably never a no-op even when building on big 3rd party tech stacks. Many of the platform specifics will shine through to the high-level code. And personally I find it rewarding to learn how to properly layer the code in order to factor out platform concerns. Many of the differences between platforms will seem kind of dull and the different platform implementations will seem kind of repetitive, but it's not terrible either if you develop on one main platform and routinely port to a handful of other platforms. I suppose that graphics APIs are the biggest annoyance here because there is comparatively a lot of setup boilerplate required, and depending on your game, considerable math code will have to be in implementation-specific shader code. There are standalone 3D graphics libraries with backends for OpenGL/Direct3D/Vulkan/Metal, not sure how well they work.

blensor 5y ago
That right there is the crux: "And personally I find it rewarding to learn how to properly layer the code in order to factor out platform concerns." I like tech riddles and figuring out how to make stuff work, investors unfortunately do not. If you constantly have to defend why you can't just do X if everybody else can just because the stuff is only available on Unity and you have to write the underlying plugins yourself it get's old pretty quickly.
- jstimpfle 5y ago
  It is not a riddle. I see it as a general lesson in software architecture, that might help you just as well to factor the use of libraries, for example. > If you constantly have to defend why you can't just do X if everybody else can just because the stuff is only available on Unity and you have to write the underlying plugins yourself it get's old pretty quickly. Well this is a different point, not the one about platforms.
  - blensor 5y ago
    It actually is the one about platforms because Unity has established itself as the standard in game dev (and I am saying that as a Godot VR game developer who is trying to break through that) So "every" company that builds something in that space targets Unity first, Unreal second and after that maybe something like Godot. Most of the things can be implemented by developers not using Unity as well but while others are actually building the game, you are building the framework below it. That is a noble thing to do and will help the community in the long run but has zero advantage for shipping your game on time. The best example is Meta's OpenXR support. They released it on Unity first (as they do all their other features) and Unreal game developers were complaining that they can't use passthrough because Meta hasn't rolled out support for Unreal for several months. So while the Unity developers were already happily working on their projects, Unreal devs were waiting and not even having a timeline when it will be possible. In our case with Godot it's actually a question of, do we put in the time to port to Unity or do we put in the time to build support for all the things we need that are already available for Unity. And how often do we expect that situation to come up in the future

blensor 5y ago

That right there is the crux: "And personally I find it rewarding to learn how to properly layer the code in order to factor out platform concerns." I like tech riddles and figuring out how to make stuff work, investors unfortunately do not. If you constantly have to defend why you can't just do X if everybody else can just because the stuff is only available on Unity and you have to write the underlying plugins yourself it get's old pretty quickly.

jstimpfle 5y ago
It is not a riddle. I see it as a general lesson in software architecture, that might help you just as well to factor the use of libraries, for example. > If you constantly have to defend why you can't just do X if everybody else can just because the stuff is only available on Unity and you have to write the underlying plugins yourself it get's old pretty quickly. Well this is a different point, not the one about platforms.
- blensor 5y ago
  It actually is the one about platforms because Unity has established itself as the standard in game dev (and I am saying that as a Godot VR game developer who is trying to break through that) So "every" company that builds something in that space targets Unity first, Unreal second and after that maybe something like Godot. Most of the things can be implemented by developers not using Unity as well but while others are actually building the game, you are building the framework below it. That is a noble thing to do and will help the community in the long run but has zero advantage for shipping your game on time. The best example is Meta's OpenXR support. They released it on Unity first (as they do all their other features) and Unreal game developers were complaining that they can't use passthrough because Meta hasn't rolled out support for Unreal for several months. So while the Unity developers were already happily working on their projects, Unreal devs were waiting and not even having a timeline when it will be possible. In our case with Godot it's actually a question of, do we put in the time to port to Unity or do we put in the time to build support for all the things we need that are already available for Unity. And how often do we expect that situation to come up in the future