4 ms·

A massive selling point for Godot, is its relative simplicity, general purpose design, and unopinionated approach to development inside of it. Unlike many open

A massive selling point for Godot, is its relative simplicity, general purpose design, and unopinionated approach to development inside of it. Unlike many open source engines that have failed, Godot (esp. Since 3.x) tends to provide you with minimal abstractions, and focus its development efforts on polishing core features which more complex features can be built on top of. It offers a smaller core feature set than an engine like Unreal, but polishes what's there so well that it can compete on a commercial level I personally believe much of its success is owed in large part to this kind of prioritization on fit and finish. Its networking api is minimal, and easy to use. It helps you negotiate your initial connection, and then gets out of your way, so you can spend your time thinking about the information coming through the pipe. A more opinionated system might be faster to get up and going, but would likely get in your way for more complex projects. Much of godot's functionality is implemented in modules, which the engine can be optionally compiled without, and are easily added in by other developers. On top of this, the engine has a plug-in ecosystem like Unity has, which allows functionality extension on a per-project basis. This means that more opinionated networking features can be trivially appended to the engine's core feature set by the community, and shared or sold as developers see fit. Imo, this is a win. Developers don't have to work around, bypass, or ship with a clunky networking model that seemed like a good idea at the time, and Godot devs don't have to maintain the potentially sprawling implementation of a feature that could very well get in somebody's way. Wrt gdscript, it's something that existed in the engine before it was open-sourced, is tightly integrated into the engine's systems, and is easy to bind new code and methods to. I don't think that the core vm has been touched too much since it was released, and it's fairly easy to ignore if you want to use C#, or C++ instead. Godot exists in a space between something like Unreal, and older frameworks like XNA. It's small enough that a single person can wrap their head around it, offers a baseline set of tools, with a modern renderer (4.0 will have a more modern renderer). It's beginner friendly, but it rarely gets in the way of experienced devs as a result.

andrewmcwatters 6y ago
> Its networking api is minimal, and easy to use. It helps you negotiate your initial connection, and then gets out of your way, so you can spend your time thinking about the information coming through the pipe. This doesn't mean anything at all if you've actually built a game before. You can do this with ENet alone, which means they haven't done anything for you. > A more opinionated system might be faster to get up and going, but would likely get in your way for more complex projects. There's effectively no difference in its multiplayer offering and a GitHub project with under 100 stars and a month's development work binding rendering APIs to a popular programming language. You literally have to do everything yourself. > Much of godot's functionality is implemented in modules, which the engine can be optionally compiled without, and are easily added in by other developers. On top of this, the engine has a plug-in ecosystem like Unity has, which allows functionality extension on a per-project basis. None of this means anything at all. You're just saying people have to create their own work, but hey, since it's in a "module" that makes it good! > Imo, this is a win. Developers don't have to work around, bypass, or ship with a clunky networking model that seemed like a good idea at the time, and Godot devs don't have to maintain the potentially sprawling implementation of a feature that could very well get in somebody's way. Yeah you're right, and the end result is basically no one does multiplayer or does it well, because most people using Godot don't know what they're doing to begin with. It's easy to not get in somebody's way when you do nothing at all, isn't it? > Wrt gdscript, it's something that existed in the engine before it was open-sourced, is tightly integrated into the engine's systems, and is easy to bind new code and methods to. As far as I know, they spent Mozilla funds to continue developing it versus features actual game developers care about. I don't really see a difference between what it offers in terms of meaningful features, and what someone experienced could throw themselves in 3-6 months time.
- crocodiletears 6y ago
  > This doesn't mean anything at all if you've actually built a game before. You can do this with ENet alone, which means they haven't done anything for you. They've integrated it into the engine, tested it across multiple platforms, exposed its methods via the language bindings interface, and abstracted away memory management if you don't want to think about it. They've also written a simple protocol that allows for remote procedure calls on the scene-tree that abstracts away the lower-level networking components. That's not nothing. > There's effectively no difference in its multiplayer offering and a GitHub project with under 100 stars and a month's development work binding rendering APIs to a popular programming language. You literally have to do everything yourself. The difference is every other feature of the engine. > None of this means anything at all. You're just saying people have to create their own work, but hey, since it's in a "module" that makes it good! I'm saying that the engine allows anyone who wants a feature to add it without requiring low-level development efforts, or getting the devs to accept a feature commit to make it generally available. This doesn't excuse every missing feature in the engine by a long-shot. But it does mean that the engine, and its development team can focus on getting the boring things right, and can reasonably expect their community to fill in the blanks over time. > Yeah you're right, and the end result is basically no one does multiplayer or does it well, because most people using Godot don't know what they're doing to begin with. It's easy to not get in somebody's way when you do nothing at all, isn't it? Most people using any game engine don't know what they're doing. And once again, I think you're exaggerating when you say, 'nothing at all'. Minimal? Yes. > As far as I know, they spent Mozilla funds to continue developing it versus features actual game developers care about. Per their blog posts, the 2019 Mozilla grant was used to fund the following things game developers don't care about: 1. Godot's Browser support 2. Improving Networking documentation, and debugging features, refactoring their TCP/UDP layer, implementing DTLS over UDP 3. Assets for showcase and benchmarking demos https://godotengine.org/article/godot-engine-awarded-50000-mozilla-open-source-support-program https://godotengine.org/article/godot-engine-awarded-50000-m... > I don't really see a difference between what it offers in terms of meaningful features, and what someone experienced could throw themselves in 3-6 months time. At the very least, 3-6 months of development time. Some of which could likely be used to implement a networking protocol. But more seriously, you get a solid, well-documented, increasingly refined engine with a permissive license that's actively being tested and maintained across multiple platforms and hardware configurations. The engine has several dedicated developers working full-time that you don't have to pay for, who are often happy to answer any questions you may have, and a large community to provide free support whenever they're unavailable or unwilling to help. You also have a young but growing plug-in ecosystem whose developers seem to love sharing their source code. Most of the features that are there are fairly mature, and are actively being battle-tested by novice and dumb developers with a gift for finding edge cases and breaking things. An experienced developer could certainly approximate Godot's feature set in six months. Of that, I have no doubt. But I really think you're underestimating the team, and what it's achieved.

andrewmcwatters 6y ago

> Its networking api is minimal, and easy to use. It helps you negotiate your initial connection, and then gets out of your way, so you can spend your time thinking about the information coming through the pipe. This doesn't mean anything at all if you've actually built a game before. You can do this with ENet alone, which means they haven't done anything for you. > A more opinionated system might be faster to get up and going, but would likely get in your way for more complex projects. There's effectively no difference in its multiplayer offering and a GitHub project with under 100 stars and a month's development work binding rendering APIs to a popular programming language. You literally have to do everything yourself. > Much of godot's functionality is implemented in modules, which the engine can be optionally compiled without, and are easily added in by other developers. On top of this, the engine has a plug-in ecosystem like Unity has, which allows functionality extension on a per-project basis. None of this means anything at all. You're just saying people have to create their own work, but hey, since it's in a "module" that makes it good! > Imo, this is a win. Developers don't have to work around, bypass, or ship with a clunky networking model that seemed like a good idea at the time, and Godot devs don't have to maintain the potentially sprawling implementation of a feature that could very well get in somebody's way. Yeah you're right, and the end result is basically no one does multiplayer or does it well, because most people using Godot don't know what they're doing to begin with. It's easy to not get in somebody's way when you do nothing at all, isn't it? > Wrt gdscript, it's something that existed in the engine before it was open-sourced, is tightly integrated into the engine's systems, and is easy to bind new code and methods to. As far as I know, they spent Mozilla funds to continue developing it versus features actual game developers care about. I don't really see a difference between what it offers in terms of meaningful features, and what someone experienced could throw themselves in 3-6 months time.

crocodiletears 6y ago
> This doesn't mean anything at all if you've actually built a game before. You can do this with ENet alone, which means they haven't done anything for you. They've integrated it into the engine, tested it across multiple platforms, exposed its methods via the language bindings interface, and abstracted away memory management if you don't want to think about it. They've also written a simple protocol that allows for remote procedure calls on the scene-tree that abstracts away the lower-level networking components. That's not nothing. > There's effectively no difference in its multiplayer offering and a GitHub project with under 100 stars and a month's development work binding rendering APIs to a popular programming language. You literally have to do everything yourself. The difference is every other feature of the engine. > None of this means anything at all. You're just saying people have to create their own work, but hey, since it's in a "module" that makes it good! I'm saying that the engine allows anyone who wants a feature to add it without requiring low-level development efforts, or getting the devs to accept a feature commit to make it generally available. This doesn't excuse every missing feature in the engine by a long-shot. But it does mean that the engine, and its development team can focus on getting the boring things right, and can reasonably expect their community to fill in the blanks over time. > Yeah you're right, and the end result is basically no one does multiplayer or does it well, because most people using Godot don't know what they're doing to begin with. It's easy to not get in somebody's way when you do nothing at all, isn't it? Most people using any game engine don't know what they're doing. And once again, I think you're exaggerating when you say, 'nothing at all'. Minimal? Yes. > As far as I know, they spent Mozilla funds to continue developing it versus features actual game developers care about. Per their blog posts, the 2019 Mozilla grant was used to fund the following things game developers don't care about: 1. Godot's Browser support 2. Improving Networking documentation, and debugging features, refactoring their TCP/UDP layer, implementing DTLS over UDP 3. Assets for showcase and benchmarking demos https://godotengine.org/article/godot-engine-awarded-50000-mozilla-open-source-support-program https://godotengine.org/article/godot-engine-awarded-50000-m... > I don't really see a difference between what it offers in terms of meaningful features, and what someone experienced could throw themselves in 3-6 months time. At the very least, 3-6 months of development time. Some of which could likely be used to implement a networking protocol. But more seriously, you get a solid, well-documented, increasingly refined engine with a permissive license that's actively being tested and maintained across multiple platforms and hardware configurations. The engine has several dedicated developers working full-time that you don't have to pay for, who are often happy to answer any questions you may have, and a large community to provide free support whenever they're unavailable or unwilling to help. You also have a young but growing plug-in ecosystem whose developers seem to love sharing their source code. Most of the features that are there are fairly mature, and are actively being battle-tested by novice and dumb developers with a gift for finding edge cases and breaking things. An experienced developer could certainly approximate Godot's feature set in six months. Of that, I have no doubt. But I really think you're underestimating the team, and what it's achieved.