3 ms·

These days, if you're making a game, even a fairly small indie game, you usually want it to run on as many platforms as possible. Even for a 2D game, there's b

These days, if you're making a game, even a fairly small indie game, you usually want it to run on as many platforms as possible. Even for a 2D game, there's big advantages to using a ready-made engine that natively supports many platforms, from mobile to high-end consoles (across OpenGL, D3D, Metal, and proprietary console rendering APIs). If you're building a game engine as a fun/learning project, that's cool. But if your goal is to make a game, pick a ready-made engine as a starting point. Whichever you choose, you'll probably end up both loving it and hating it, but you'll get a heck of a lot more game-making done than if you go down the 'build your own engine' route.

ratww 5y ago
You're repeating advice for people with zero experience in making games, which is fine. But it doesn't have much to do with this discussion. Casey Muratori is not teaching people how to make an indie game or an AAA. He's teaching how to make almost everything in a video game from scratch. He speaks constantly of how he's not a game-code programmer, let alone a game designer. Pretty much everyone watching it knows what they're in for, because he talks about it all the time. Those ready-made engines you're talking about have to be made by someone. Not to mention that anything beyond "basic indie game" requires someone who knows deeply how a game works. And those people are who Casey is currently educating. Someone doing Unity/Unreal for several years won't learn those things Casey is teaching unless they really dive into deeper material, and Casey is providing exactly this kind of material. This industry doesn't need more people with Junior-level experience even though they've been working at it for 20 years. Maybe this kind of education not you, and that's fine, but just because something is being taught on the internet, doesn't automatically mean you and everyone have to learn it. You gotta learn to live with it.
jstimpfle 5y ago
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

ratww 5y ago

You're repeating advice for people with zero experience in making games, which is fine. But it doesn't have much to do with this discussion. Casey Muratori is not teaching people how to make an indie game or an AAA. He's teaching how to make almost everything in a video game from scratch. He speaks constantly of how he's not a game-code programmer, let alone a game designer. Pretty much everyone watching it knows what they're in for, because he talks about it all the time. Those ready-made engines you're talking about have to be made by someone. Not to mention that anything beyond "basic indie game" requires someone who knows deeply how a game works. And those people are who Casey is currently educating. Someone doing Unity/Unreal for several years won't learn those things Casey is teaching unless they really dive into deeper material, and Casey is providing exactly this kind of material. This industry doesn't need more people with Junior-level experience even though they've been working at it for 20 years. Maybe this kind of education not you, and that's fine, but just because something is being taught on the internet, doesn't automatically mean you and everyone have to learn it. You gotta learn to live with it.

jstimpfle 5y ago

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