5 ms·

Seems like implicitly it's better to take notes from current users than actual users, since your first effort might not be what the potential users expect. Ive

by scrame 4y ago

Seems like implicitly it's better to take notes from current users than actual users, since your first effort might not be what the potential users expect. Ive only poked at godot, is there a reason that GDscript is so dominant? ETA: is the IDE based around it, or other things aren't well supported, or is visual scripting something that just doesn't fit godot's model

kroltan 4y ago
Visual scripting works reasonably well for very high level scripting, but even then it is very "verbose and space inefficient". Writing actual game logic requires a lot of moving stuff around even for small changes. It is also hard to share in our text-first world, so helping or getting community help on it ends up in attachment hell or trading screenshots, both of which are not ideal. As the blog post says, it can probably work better in something like Unreal because the engine already has a lot of things that Godot (and Unity and other similar engines, for that matter) simply does not aim to support. Just as an example, Unreal has a centralized concept of "health" and "dying", so they can provide default libraries to handle the minutia of such things (can health go negative? is "dead" a recoverable state? etc) As for why GDScript specifically is the most popular choice, it's both due to community and due to the engine's design itself. Being literally made for the engine, Godot and GDScript have ver closely tied semantics, which are a (a little) bit more boilerplate-y to handle with GDNative-based alternatives. And since it's such less hassle (and until recently was near the only option), most of the community has built learning materials and libraries optimized for that use.
- Natsu 4y ago
  I've worked with that kind of programming before in another product and it works much better if you have a lot of useful high-level primitives, it's easy to make your own primitives in a standardized way, and you can easily convert all or part of it to/from a text representation like YAML, which itself should be how the engine stores it in your project so it can be in source control.
  - kroltan 4y ago
    Yep, I've been on the other end, developing such a tool, with similar findings. Though for serialization it really needs to use a flat-ish format where each node is _at least_ on its own separate line, and sorted using some stable ordering, as otherwise there will be lots of spurious diffs in source control.
    - Natsu 4y ago
      You can put IDs in the nodes and order by ID, but you still have to be a little careful in how you do that or people can add/delete the same node and create lots of changes too. I think YAML works out pretty good as a serialization format because it doesn't create a lot of overhead unlike, say, XML which is ugly for that. You also want to have clear standards for how you pass parameters around (some use a dictionary object passed implicitly), standards for types, good ways to do common data conversions, etc. It's probably better when you have stronger ideas about how things should be done for a given system than as a mess of boxes trying to be a general programming language.
      - kroltan 4y ago
        Yep, in my case it was a storytelling tool for visual novel games, so there wasn't much data to pass around, most nodes were either modal interactions or affecting changes upon the game world. It's also a pretty constrained domain so a lot of the bookkeeping could be done internally rather than needing to be exposed to the narrative designer. A lot of the problems you mention just didn't need to exist. In terms of how it was implemented (C#, for context), every possible node had to be a pure object (no internal mutation) with an asynchronous "run" method. This "run" method receives the game world as a parameter (Basically just a service locator. Services hold the mutable data). At design time, we would instantiate the nodes and use reflection to display their fields to the designer, using specific widgets if the field was a pointer to another node. The design tool also kept an unique identifier for each node, and sorted by those on serialization. We used an ini-like custom format (hadn't heard of TOML at the time or would have probably gone with that) so that there was no nesting of nodes. Instead, fields that point to other nodes would just be serialized as the target's ID. When deserializing, we would have two passes, one reads the story file into an intermediate representation, so that every node is "known", and another to apply the actual properties (which can include references to out of order nodes). But yes, as you mention, it is a system very fit for the domain, with some choices that don't make as much sense generally. Which is part of why I see that project as successful, and kind of demonstrates how much work goes into making a good visual scripting tool.
johnfn 4y ago
> Ive only poked at godot, is there a reason that GDscript is so dominant? GDScript is excellent. I was a huge skeptic of it at first - in fact, if you dig through my reddit account I wrote a huge screed about why it could never succeed when it was first announced like 5+ years ago. The Godot team totally proved me wrong - GDScript is really really good. It's super productive to work in - you can bang out features super quickly.
- krapp 4y ago
  GDScript is adequate. The only real benefit it has is integration with Godot itself, but I can't imagine anyone preferring to use it as a general purpose language.

by scrame 4y ago

kroltan 4y ago

Visual scripting works reasonably well for very high level scripting, but even then it is very "verbose and space inefficient". Writing actual game logic requires a lot of moving stuff around even for small changes. It is also hard to share in our text-first world, so helping or getting community help on it ends up in attachment hell or trading screenshots, both of which are not ideal. As the blog post says, it can probably work better in something like Unreal because the engine already has a lot of things that Godot (and Unity and other similar engines, for that matter) simply does not aim to support. Just as an example, Unreal has a centralized concept of "health" and "dying", so they can provide default libraries to handle the minutia of such things (can health go negative? is "dead" a recoverable state? etc) As for why GDScript specifically is the most popular choice, it's both due to community and due to the engine's design itself. Being literally made for the engine, Godot and GDScript have ver closely tied semantics, which are a (a little) bit more boilerplate-y to handle with GDNative-based alternatives. And since it's such less hassle (and until recently was near the only option), most of the community has built learning materials and libraries optimized for that use.

Natsu 4y ago
I've worked with that kind of programming before in another product and it works much better if you have a lot of useful high-level primitives, it's easy to make your own primitives in a standardized way, and you can easily convert all or part of it to/from a text representation like YAML, which itself should be how the engine stores it in your project so it can be in source control.
- kroltan 4y ago
  Yep, I've been on the other end, developing such a tool, with similar findings. Though for serialization it really needs to use a flat-ish format where each node is _at least_ on its own separate line, and sorted using some stable ordering, as otherwise there will be lots of spurious diffs in source control.
  - Natsu 4y ago
    You can put IDs in the nodes and order by ID, but you still have to be a little careful in how you do that or people can add/delete the same node and create lots of changes too. I think YAML works out pretty good as a serialization format because it doesn't create a lot of overhead unlike, say, XML which is ugly for that. You also want to have clear standards for how you pass parameters around (some use a dictionary object passed implicitly), standards for types, good ways to do common data conversions, etc. It's probably better when you have stronger ideas about how things should be done for a given system than as a mess of boxes trying to be a general programming language.
    - kroltan 4y ago
      Yep, in my case it was a storytelling tool for visual novel games, so there wasn't much data to pass around, most nodes were either modal interactions or affecting changes upon the game world. It's also a pretty constrained domain so a lot of the bookkeeping could be done internally rather than needing to be exposed to the narrative designer. A lot of the problems you mention just didn't need to exist. In terms of how it was implemented (C#, for context), every possible node had to be a pure object (no internal mutation) with an asynchronous "run" method. This "run" method receives the game world as a parameter (Basically just a service locator. Services hold the mutable data). At design time, we would instantiate the nodes and use reflection to display their fields to the designer, using specific widgets if the field was a pointer to another node. The design tool also kept an unique identifier for each node, and sorted by those on serialization. We used an ini-like custom format (hadn't heard of TOML at the time or would have probably gone with that) so that there was no nesting of nodes. Instead, fields that point to other nodes would just be serialized as the target's ID. When deserializing, we would have two passes, one reads the story file into an intermediate representation, so that every node is "known", and another to apply the actual properties (which can include references to out of order nodes). But yes, as you mention, it is a system very fit for the domain, with some choices that don't make as much sense generally. Which is part of why I see that project as successful, and kind of demonstrates how much work goes into making a good visual scripting tool.

johnfn 4y ago

> Ive only poked at godot, is there a reason that GDscript is so dominant? GDScript is excellent. I was a huge skeptic of it at first - in fact, if you dig through my reddit account I wrote a huge screed about why it could never succeed when it was first announced like 5+ years ago. The Godot team totally proved me wrong - GDScript is really really good. It's super productive to work in - you can bang out features super quickly.

krapp 4y ago
GDScript is adequate. The only real benefit it has is integration with Godot itself, but I can't imagine anyone preferring to use it as a general purpose language.