5 ms·

I find their prioritization of features also very weird. I can't start an empty project and get multiplayer out of the box, but my team's 7 year old (?) 2D gam

I find their prioritization of features also very weird. I can't start an empty project and get multiplayer out of the box, but my team's 7 year old (?) 2D game engine[1] can do this and have client-side prediction set up for you before you even insert your own game code. We're months away from shipping a next major release, and for as many collaborators work on Godot, they've basically been years behind any of the features I or anyone on my team actually cared about. We have lag compensation that works over 3G, but if you asked anyone in the Godot community how you'd pull that off, it'd be some random guy not associated with the project, on their forums, with some code snippet he shared with you that is a far cry from first-class support. Why focus so much on rendering functionality? If you have a team that's actually remotely capable of generating assets at the labor velocity you would need to actually release a game, that team would almost be guaranteed to use Unreal anyway. It's really incredible how much game software lags in progress because of where development teams choose to put their efforts. [1]: https://www.planimeter.org/grid-sdk/ https://www.planimeter.org/grid-sdk/

nextaccountic 5y ago
Truth is, as an open source project, Godot would need people interested in multiplayer to implement that stuff. :(
okamiueru 5y ago
Is your sentiment not a little unreasonable? You seem to disagree with the godot maintainers on where the effort should be placed, but, this is as open source a project as they get. Improving one aspect doesn't belittle all others, nor does it really hinder it. As unsurprising as it might be, they are improving godot in the ways that they can, because they want it to be better. This is unrelated to the existence of UE. I'm sure the godot community wouldn't mind if you shared your experience on game networking, and possibly contributed in that regard. I myself would appreciate it, as with you, I've found it to be limited. The underlying components and language features are there, but how to tie it together with redundancy and prediction, and a bunch of other tricks of the trade, is not trivial.
- andrewmcwatters 5y ago
  Nope, this team makes 5 figures in donations a month, and they actually spent time writing their own programming language. Total waste of labor. 100%. Let's put it this way, say I gave you $250,000 and said in a year I want a game engine. What would you spend your labor on? It would not be writing a programming language.
  - djmips 5y ago
    Why the downvotes. I feel like there is some truth here. The world doesn't need another custom game scripting language.
    - lasagnaphil 5y ago
      This has been repeatedly said throughout Godot’s development history, but there are several crucial reasons as why the team was motivated to create their own scripting language. From the FAQ (https://docs.godotengine.org/en/stable/about/faq.html#what-were-the-motivations-behind-creating-gdscript https://docs.godotengine.org/en/stable/about/faq.html#what-w...): In the early days, the engine used the Lua scripting language. Lua is fast, but creating bindings to an object oriented system (by using fallbacks) was complex and slow and took an enormous amount of code. After some experiments with Python, it also proved difficult to embed. The main reasons for creating a custom scripting language for Godot were: - Poor threading support in most script VMs, and Godot uses threads (Lua, Python, Squirrel, JavaScript, ActionScript, etc.). - Poor class-extending support in most script VMs, and adapting to the way Godot works is highly inefficient (Lua, Python, JavaScript). - Many existing languages have horrible interfaces for binding to C++, resulting in large amount of code, bugs, bottlenecks, and general inefficiency (Lua, Python, Squirrel, JavaScript, etc.) We wanted to focus on a great engine, not a great amount of integrations. - No native vector types (vector3, matrix4, etc.), resulting in highly reduced performance when using custom types (Lua, Python, Squirrel, JavaScript, ActionScript, etc.). - Garbage collector results in stalls or unnecessarily large memory usage (Lua, Python, JavaScript, ActionScript, etc.). - Difficulty to integrate with the code editor for providing code completion, live editing, etc. (all of them). This is well-supported by GDScript.
stryan 5y ago
Is the current out-of-the-box multiplayer support[0] missing something? [0]https://docs.godotengine.org/en/stable/classes/class_multiplayerapi.html https://docs.godotengine.org/en/stable/classes/class_multipl...
- andrewmcwatters 5y ago
  No idea why they bother with this, not sure what it provides me over something like enet. That's my point. If your game engine is just saying, "Well, here are some sockets, have fun!" then it's not doing multiplayer networking. Maybe we have different definitions of out-of-the-box multiplayer, but Grid allows you to `git clone` and run `map <map name>` and you've got a multiplayer server and your friend can `connect <IP address>`. If you want to do a top-down game, great. If you want to do a side-scroller, sure. If you wanted to do a board game, you're set. Out-of-the-box multiplayer doesn't mean 1,000 lines of code later I can move something on my screen and some other guy finally sees it move, but it's not predicted, doesn't respond to field changes, etc. Out-of-the-box multiplayer to me means without writing a line of code, I can start a server and do everything a published video game can and I can do what I actually care about, which isn't serializing data, or figuring out when I should network something because it's not visible anymore.
  - jayd16 5y ago
    I would venture to guess the low level api is useful if you want to get Havok or some other non-built in physics engine working. Not every game fits into the same 2d pixel phsyics mold. You can't ship such a one size fits all solution with a general purpose game engine like Godot.
    - andrewmcwatters 5y ago
      There's no requirement to use physics in Grid, just as there's no requirement to use physics in LÖVE, which is what the engine is built on. We build the game engine from this approach because most games want "maps," and "entities." We use a Quake-style architecture because even if you're rebuilding a 2D version of Tabletop Simulator, you're going to want a map and entities. We'd rather have a one-size fits all solution (worked for Quake and Source pretty well) versus a Unity/Unreal style flashy game engine where you're suckered into still doing all the work yourself, but hey PBR looks good.
p1necone 5y ago
If you've spent 7 years working on an engine for the specific projects you're building it's going to have exactly the feature set you need for those specific projects. I don't think this is surprising, nor a sensible criticism of Godot.
detaro 5y ago
And plenty other people would wonder why you'd prioritize multiplayer, a feature many games don't even need.
egypturnash 5y ago
Y’all built an engine to fill your needs, the Godot folks built one to satisfy their needs. Which given everything they showcase seems to be much more targeted to single player experiences, and ease of use by non-programmers. You’ve just got an SDK, they’ve got a vast sprawling Game Editor System that includes map editors, 2d animation, and all kinds of stuff. Revamp Grid’s page to focus more on “hey you can start a new project and instantly have super solid net code, unlike every other game engine out there” and you’ve probably got a decent Show HN post to make, most “check out my game engine” posts have no unique selling points but “built from the ground up for multiplayer” is definitely one.
- andrewmcwatters 5y ago
  Why build all of that though? Why build a map editor? Why build a 2D animation suite? Those aren't game engine features. They're workflow features. You say sprawling, and I say lame FOSS competitor to Blender. That's my point: all of those features are pointless to spend labor on. Go spend some time in the game development FOSS ecosystem, there are plenty of people already building those tools. A game engine team does not need to reinvent programming, map making, animating, and so much more. Go take existing standards and defacto gamedev file formats and build momentum on things that actually matter.
aliswe 5y ago
I can assure you that effort will be placed on fun stuff and things that are critically needed (subjectively) by the developers. If you wanna change that then go ahead and do it yourself, or fund it ... Otherwise Open Source is Open Source, and always have been. It is what it is, not what you would wish it to be. Why not send a letter to the "ceo" or equivalent and voice your opinion? When I helped out with Warzone 2100, I strictly did stuff I think was giving value to me personally. That included helping out with features people needed, but certainly not always.

nextaccountic 5y ago

Truth is, as an open source project, Godot would need people interested in multiplayer to implement that stuff. :(

okamiueru 5y ago

Is your sentiment not a little unreasonable? You seem to disagree with the godot maintainers on where the effort should be placed, but, this is as open source a project as they get. Improving one aspect doesn't belittle all others, nor does it really hinder it. As unsurprising as it might be, they are improving godot in the ways that they can, because they want it to be better. This is unrelated to the existence of UE. I'm sure the godot community wouldn't mind if you shared your experience on game networking, and possibly contributed in that regard. I myself would appreciate it, as with you, I've found it to be limited. The underlying components and language features are there, but how to tie it together with redundancy and prediction, and a bunch of other tricks of the trade, is not trivial.

andrewmcwatters 5y ago
Nope, this team makes 5 figures in donations a month, and they actually spent time writing their own programming language. Total waste of labor. 100%. Let's put it this way, say I gave you $250,000 and said in a year I want a game engine. What would you spend your labor on? It would not be writing a programming language.
- djmips 5y ago
  Why the downvotes. I feel like there is some truth here. The world doesn't need another custom game scripting language.
  - lasagnaphil 5y ago
    This has been repeatedly said throughout Godot’s development history, but there are several crucial reasons as why the team was motivated to create their own scripting language. From the FAQ (https://docs.godotengine.org/en/stable/about/faq.html#what-were-the-motivations-behind-creating-gdscript https://docs.godotengine.org/en/stable/about/faq.html#what-w...): In the early days, the engine used the Lua scripting language. Lua is fast, but creating bindings to an object oriented system (by using fallbacks) was complex and slow and took an enormous amount of code. After some experiments with Python, it also proved difficult to embed. The main reasons for creating a custom scripting language for Godot were: - Poor threading support in most script VMs, and Godot uses threads (Lua, Python, Squirrel, JavaScript, ActionScript, etc.). - Poor class-extending support in most script VMs, and adapting to the way Godot works is highly inefficient (Lua, Python, JavaScript). - Many existing languages have horrible interfaces for binding to C++, resulting in large amount of code, bugs, bottlenecks, and general inefficiency (Lua, Python, Squirrel, JavaScript, etc.) We wanted to focus on a great engine, not a great amount of integrations. - No native vector types (vector3, matrix4, etc.), resulting in highly reduced performance when using custom types (Lua, Python, Squirrel, JavaScript, ActionScript, etc.). - Garbage collector results in stalls or unnecessarily large memory usage (Lua, Python, JavaScript, ActionScript, etc.). - Difficulty to integrate with the code editor for providing code completion, live editing, etc. (all of them). This is well-supported by GDScript.

stryan 5y ago

Is the current out-of-the-box multiplayer support[0] missing something? [0]https://docs.godotengine.org/en/stable/classes/class_multiplayerapi.html https://docs.godotengine.org/en/stable/classes/class_multipl...

andrewmcwatters 5y ago
No idea why they bother with this, not sure what it provides me over something like enet. That's my point. If your game engine is just saying, "Well, here are some sockets, have fun!" then it's not doing multiplayer networking. Maybe we have different definitions of out-of-the-box multiplayer, but Grid allows you to `git clone` and run `map <map name>` and you've got a multiplayer server and your friend can `connect <IP address>`. If you want to do a top-down game, great. If you want to do a side-scroller, sure. If you wanted to do a board game, you're set. Out-of-the-box multiplayer doesn't mean 1,000 lines of code later I can move something on my screen and some other guy finally sees it move, but it's not predicted, doesn't respond to field changes, etc. Out-of-the-box multiplayer to me means without writing a line of code, I can start a server and do everything a published video game can and I can do what I actually care about, which isn't serializing data, or figuring out when I should network something because it's not visible anymore.
- jayd16 5y ago
  I would venture to guess the low level api is useful if you want to get Havok or some other non-built in physics engine working. Not every game fits into the same 2d pixel phsyics mold. You can't ship such a one size fits all solution with a general purpose game engine like Godot.
  - andrewmcwatters 5y ago
    There's no requirement to use physics in Grid, just as there's no requirement to use physics in LÖVE, which is what the engine is built on. We build the game engine from this approach because most games want "maps," and "entities." We use a Quake-style architecture because even if you're rebuilding a 2D version of Tabletop Simulator, you're going to want a map and entities. We'd rather have a one-size fits all solution (worked for Quake and Source pretty well) versus a Unity/Unreal style flashy game engine where you're suckered into still doing all the work yourself, but hey PBR looks good.

p1necone 5y ago

If you've spent 7 years working on an engine for the specific projects you're building it's going to have exactly the feature set you need for those specific projects. I don't think this is surprising, nor a sensible criticism of Godot.

detaro 5y ago

And plenty other people would wonder why you'd prioritize multiplayer, a feature many games don't even need.

egypturnash 5y ago

Y’all built an engine to fill your needs, the Godot folks built one to satisfy their needs. Which given everything they showcase seems to be much more targeted to single player experiences, and ease of use by non-programmers. You’ve just got an SDK, they’ve got a vast sprawling Game Editor System that includes map editors, 2d animation, and all kinds of stuff. Revamp Grid’s page to focus more on “hey you can start a new project and instantly have super solid net code, unlike every other game engine out there” and you’ve probably got a decent Show HN post to make, most “check out my game engine” posts have no unique selling points but “built from the ground up for multiplayer” is definitely one.

andrewmcwatters 5y ago
Why build all of that though? Why build a map editor? Why build a 2D animation suite? Those aren't game engine features. They're workflow features. You say sprawling, and I say lame FOSS competitor to Blender. That's my point: all of those features are pointless to spend labor on. Go spend some time in the game development FOSS ecosystem, there are plenty of people already building those tools. A game engine team does not need to reinvent programming, map making, animating, and so much more. Go take existing standards and defacto gamedev file formats and build momentum on things that actually matter.

aliswe 5y ago

I can assure you that effort will be placed on fun stuff and things that are critically needed (subjectively) by the developers. If you wanna change that then go ahead and do it yourself, or fund it ... Otherwise Open Source is Open Source, and always have been. It is what it is, not what you would wish it to be. Why not send a letter to the "ceo" or equivalent and voice your opinion? When I helped out with Warzone 2100, I strictly did stuff I think was giving value to me personally. That included helping out with features people needed, but certainly not always.