A list of features approved for Goost development

[Xrayez]

This list represents features which are meaningful to implement in Goost, and is continuously updated. If you'd like to work on some of these yourself, you can open another issue to discuss implementation details, or simply say that you're already working on this here if the feature is trivial to implement and/or has been discussed with others. May also contain Godot Improvement Proposals.

Note that any PR implementing a particular feature would still need to go though the review process before merging. Opening a discussion before working on any non-trivial feature is highly recommended. At the very least, maintainers and contributors must agree upon the public API first and foremost.

Godot 3.x - gd3 branch

Note: All features approved for Godot 3.2 are also applicable for Godot 4.0.

• [x] ← a feature is already implemented (either in Goost or Godot).

Core

• [ ] Database backends: godotengine/godot#37070
• [ ] Exposing PropertyInfo structure as a class to GDScript (?)
  • See also #30.
• [ ] Most items in godot-extended-libraries/godot-ideas#11, but some need design work.
• [ ] uuid(): godotengine/godot#42408.
  • Can be implemented in the existing Random singleton: #29.
• [x] godotengine/godot-proposals#3948
• [x] Random.pop(): https://github.com/godotengine/godot-proposals/issues/3454#issuecomment-1024971678
• [ ] godotengine/godot-proposals#3848
• [x] Implementing Bresenham line algorithm: godotengine/godot#43916. Implemented in #75
• [x] Command-line parsing: godotengine/godot#44594, implemented in #123.
• [x] godotengine/godot-proposals#3259 (implemented in Godot 4.0).
• [ ] https://github.com/goostengine/goost/discussions/151
• [ ] #193

Scene

• [ ] godotengine/godot-proposals#115
  • This should be implemented with custom font drawing API for better integration.
  • See GDScript implementation at godot-next.
• [x] godotengine/godot-proposals#710
• [x] godotengine/godot-proposals#1126
• [x] godotengine/godot-proposals#2878
• [ ] godotengine/godot-proposals#4282

UI

• [x] godotengine/godot#43807
• [ ] godotengine/godot-proposals#97

Resources

• [ ] BitSet
  • See GDScript implementation at godot-next.
• [ ] BitFlag: godotengine/godot-proposals#923.
  • See GDScript implementation at godot-next.
• [x] godotengine/godot-proposals#1677
• [ ] Matrix: #14.

Editor

• [ ] godotengine/godot-proposals#748
• [x] godotengine/godot-proposals#3511
• [x] godotengine/godot-proposals#4307

Modules

• [x] GIF save support via ImageFrames.save_gif(): #104.

List of community modules to consider merging or get inspired from:

• https://github.com/Louis-Simon22/poisson_disk_sampling_module
• https://github.com/Relintai/thread_pool
• https://github.com/Lucrecious/pathfinder

Godot 4.x - gd4 branch

Note: Godot 4.0 is still in development, so no gd4 branch is created in Goost yet.

Some classes are deprecated in Godot 3.x, so if someone still needs an exact implementation written in C++ without reverting to using the AssetLib version (if available), then these classes can be safely ported to Goost.

• [ ] InterpolatedCamera: documentation and source code, deprecated in godotengine/godot#42113.
  • See also https://github.com/godot-extended-libraries/godot-interpolated-camera3d where more features could be potentially implemented.
• [ ] ClippedCamera3D, removed in godotengine/godot#53354.
• [ ] Collada importer, may be removed in godotengine/godot#53418.

[Extarys]

Not sure if I can ask this here, but I never heard/read about Goost in the Godot documentation. Is it because it's development is in the early stage? If not, I think this as an extension would need/have more publicity.

Here because of issue #31655 (Gradient2D...)

[Xrayez]

@Extarys the development of this extension is not governed by Godot development, currently this is more like a place where me (and possibly other interested contributors) can more or less freely build upon the existing engine in C++ without having to go through the strict process of proposing, reviewing, approving, and implementing proposals in Godot (these features can be eventually added to Godot, if seen useful by Godot core developers, that's the point of this extension). I used to have a bunch of C++ modules which I simply merged into one (now Goost), mainly due to maintenance reasons, and I decided that it may be a good opportunity to make it appealing. 🙂

The way I see it, we still need a place for those rejected and not-yet-approved proposals or opened pull requests, so this is where Goost could be an alternative for engine contributors (but yeah I'd still expect for the feature to be proposed at Godot and attracting a handful of 👍's before considering implementing features in Goost).

If not, I think this as an extension would need/have more publicity.

I agree, though I don't actively advertise the extension currently. Godot core developers are free to link to this repository in documentation if they find this kind of workflow useful, but it's not necessary. 😛

I'm also trying to setup some realistic expectations, this is why I created this list, for instance, so you can better understand the scope of new features, some features may just be too specific to a single genre of games to be implemented in Goost.

[Extarys]

I feel you. I bookmarked your repo and I will happily look into it more when I play with Godot again.

Thanks for clarifying as I was slightly confused.

BTW the logo is sick!

[Xrayez]

Here because of issue #31655 (Gradient2D...)

@Extarys if curious, GradientTexture2D is now implemented in Goost: #43 (in Godot 3.2) 🙂

godotengine/godot-proposals#1677 is still not approved despite community support/requests in godotengine/godot#31655, so it's better that this feature to become usable in a module like Goost, at least for now. I'd still prefer for this to be available in Godot, unfortunately new features take too much time to get reviewed, also according to https://github.com/godotengine/godot/pull/31655#issuecomment-525472775, I think this is unlikely to get implemented in Godot anyways (out of the box).

[Extarys]

Thanks, it is very nice of you to let me know! Like I said earlier, I find this feature quite essential and I don't understand the resilience of Godot devs to implement this.

[Xrayez]

I'd just like to say that implementing neural networks/deep learning would be nice to have, see related Godot proposal at godotengine/godot-proposals#2506.

Goost would probably need to introduce AI component, but this certainly needs discussion. It's ok to use third-party machine learning libraries in Goost. I'm new to this, but perhaps I'd chime in at some point if opportunity arises.

[sairam4123]

I'd recommend adding 3D counter parts to Geometry and other modules. As a 3d Godot developer, I see a lot of things missing in godot3d part but available on godot 2d part, It'd be cool if you could fill up the gap between 2d and 3d nodes.

[Xrayez]

@sairam4123 this makes total sense indeed, but unfortunately I'm limited to my own knowledge of 2D development, I rarely if ever had to touch 3D code. If someone would like to implement 3D counterparts in Goost and to fill up the gaps in Godot this way, that would be really appreciated!

As of now, the development totally depends on self-motivated people that need particular features themselves and who are capable to implement them, of course. Myself included.

[sairam4123]

I can probably try that, could give me an idea of what are the things that are in 2D Counterpart? I can probably try implement it into Godot 3D.

[Xrayez]

First thing which comes to mind is ShapeCast2D, which can be implemented in 3D with the same or similar API. Godot even has a proposal about this: godotengine/godot-proposals#2896 (not replacing RayCast, but you get the idea).

Implementation for ShapeCast2D is here: https://github.com/goostengine/goost/tree/gd3/scene/physics/2d, which you could take as a base (many classes in Godot are first implemented in 2D, in fact).

As a bonus, both ShapeCast2D and ShapeCast3D could have a higher chance to be merged directly in Godot, see my original proposal: godotengine/godot-proposals#710.

[sumadithya]

Cool. I'll implement https://github.com/godotengine/godot-proposals/issues/3948 on goost first.

[ghost]

I implemented the uuid here https://github.com/goblinengine/goblin/commit/48168db3da936efeaee61e7c2d6d264b4cf5fcc0

[ghost]

Also implemented weighted choices here https://github.com/goblinengine/goblin/commit/4dd4a0539d829c0e949a3d47a28b024c01a2e815

EDIT: I have updated this to work more like Python minus cummulative weights https://github.com/goblinengine/goblin/commit/33d22b428c4b9f8c8652d392e9c1e3f3a5011d28

[ghost]

Now here is what I have learned about weighted choices.

String produce gibberish and and make little sense when you use arrays for weights [1,1,4,5] for characters "abcd". I have found no practical use of weighted characters from a string.

Dictionaries have another issue, data duplication. You will have the exact value copied over many times. May in fact cause issues with losing track of the original record. I think it should instead operate only on keys of dictionaries ie dict.keys() then using the generated weighted array of keys back on the dictionary to get the data ie for key in weighted_keys.

In other words it should operate strictly only on Array or PoolByteArray (and subtypes).

[sumadithya]

EDIT: I have updated this to work more like Python minus cummulative weights https://github.com/goblinengine/goblin/commit/33d22b428c4b9f8c8652d392e9c1e3f3a5011d28

Is there a problem with using cumulative weights?

You will have the exact value copied over many times.

I do not get this.

Also, using cumulative weights (like the python implementation) could let us do a binary search (bisect) to reach the index faster but at the cost of having to use an array for cumulative weights. (but I don't think it affects the total time complexity).

[ghost]

@sumadithya No problem is just that I never implemented cummulative weight. If you have a dictionary for example { a = 1, b = 2, c = 3} then if you created a weighted dictionary of say 6 items then you gonna get something like {a = 1, a = 1, b = 2, c = 3, a = 1, a = 1} You cannot have duplicate keys. You would need to adjust the keys to make them unique which completely defeats the purpose. The correct way to do this would be to extract the keys() then created a weighted array of only the keys ["a","a","b","c","a","a"] which then you can loop though and get the original value . Now you could support passing the Dictionary directly and extracting the keys but is pointless as all you need to write is .keys() to use it as Array that's it and works.

Example using dictionary with my implementation

var dict = { a = 1, b = 2, c = 3}
var weighted_keys = Rand.choices(dict.keys(), 6, [1,5,3]) # 6 values with a weighted 1, b weighted 5 and c weighted 3
for key in weighted_keys:
   print(dict[key]) #you can use it for whatever you need and gives you a weighted dictionary 

[sumadithya]

@filipworksdev I think the point of using dictionaries is to avoid passing another array for weights. So the keys of the dictionary would be the things that are returned in the array/list. And the the value for each key corresponds to its weight.

var dict = {a = 3, b = 6, c = 9} # [3,6,9] would be the weights of a,b,c
var weighted_random_vals = Rand.choices(dict.keys(), 6)

weight_random_vals should contain something like [a,a,b,c,a,a]

[ghost]

You can do this already var weighted_random_vals = Rand.choices(dict.keys(), 6, dict.values()) . This is why I mentioned having a special behavior just for dictionaries is kinda pointless. You can already do pretty much everything you need using just Array implementation.

[sumadithya]

If I had to make it take cumulative_weights as an optional parameter, should I overload the function or should I give the parameter a default empty value {} ?

[Xrayez]

If I had to make it take cumulative_weights as an optional parameter, should I overload the function or should I give the parameter a default empty value {} ?

It's not possible to overload functions in Godot's C++ (limitation of ClassDB). So yeah, you'd just pass in an empty Variant() actually (DEFVAL(Variant())), which denotes the null value (slight optimization which avoids instantiation of empty dictionary).

I think the point of using dictionaries is to avoid passing another array for weights.

Yeah, that's the point. Random.choice() (singular) already takes a similar approach, so I'd prefer to have Dictionary support for consistency, at least. But note that both arrays and dictionaries can be supported.

By the way, lets focus discussion in godotengine/godot-proposals#3948, or feel free to create a separate discussion here in Goost: https://github.com/goostengine/goost/discussions, or feel free to submit a work-in-progress PR to have implementation discussion there.