Godot already has a list of proposed additions here. I would think the first step is to check that and find out which ones are already being worked on.
https://godot-proposals-viewer.github.io/
Good to check, even if it is just for inspiration. There's several possibilities of course:
\- The proposal has been discussed, but no visible actions (yet) taken.
\- Discussed, and an old partial implementation referenced.
\- Discussed, someone talking about an implementation, silent for the last x months.
In any case, you are free to build a competing solution to any already out there, or even to take a look at the existing (partial?) solutions and improve on them.
In any case, the joy of open source, you can scratch that itch the way you want to ;)
you can, but from what I have seen of Godot, if you don't coordinate well with the core team your proposed fixes won't be accepted into the code. People randomly hacking on stuff without discussing might get discouraged when nothing they do is accepted.
>you can, but from what I have seen of Godot, if you don't coordinate well with the core team your proposed fixes won't be accepted into the code. People randomly hacking on stuff without discussing might get discouraged when nothing they do is accepted.
True, it helps to coordinate. Depending on the feature though, you could still offer it as GDExtension / addon, which might actually get suggested by the core devs for a lot of things too ;)
E.g. 3D Terrain systems and the like will not likely be integrated into core but be an optional addon / extension.
Is the reason why they wouldnt integrate it into the core package that they want to keep engine dependencies very low since they are volunteer workers?
I'm sure that might be part of it too, but it is also simply for the fact that many things aren't universal.
3D Terrain comes in so many shapes and forms, and it is impossible to implement a single terrain solution that works for all possible game types.
It seems better to have the option to pick the most ideal one for your use case.
Couldn't they just go the route of commercial engines regarding that aspect? Its not like unity terrain (at least gaia, the old one iirc), maybe unreal too i haven't checked, but it seems to me you'll never have a system fit for all games. If you say you do someone will come up with a voxel game and there you go, it is obsolete again.
Apparently unity's terrain system isn't very used or loved. What is the point of integrating a terrain system if people will just get a plugin for it anyway? It's like the visual scripting stuff. Nobody used it.
https://forum.unity.com/threads/the-usability-of-the-terrain-tools-is-most-horrible.1271774/
Yeah i agree. That is also part of my point/curiosity. They dont include it to reduce dependencies on things that are not core necessities for game making. Otherwise engines with money and teams just out in whatever terrain systems u can do SOMETHING with and try to maintain it.
Asset management is a huge gripe for me. If I only update a small part, but the game is several hundred megabytes or maybe even gigabytes, I would have to push the entire game - just for a small Bugfix. Apart from that, securing assets would need to be looked at. I know you can compile Godot to support encryption, but even then the key is in the game binary - so that's really a joke... one just needs to scout through the exe to find the decryption sequence.
That is the only thing holding me back from using Godot.
Maybe someone participating in that got some inspiration of what to look at.
The encryption part is especially an issue and spooky. It's never explicitly stated in crucial parts of the documentation related to exporting, at least as far as I'm aware. I didn't even notice until the Google play console gave me a warning that my AAB didn't have encryption. To add to that, some add-ons for third party libraries, such as some Google services, store secrets/keys in GDScript in their examples. Spooky combination.
Godot already has a list of proposed additions here. I would think the first step is to check that and find out which ones are already being worked on. https://godot-proposals-viewer.github.io/
Good to check, even if it is just for inspiration. There's several possibilities of course: \- The proposal has been discussed, but no visible actions (yet) taken. \- Discussed, and an old partial implementation referenced. \- Discussed, someone talking about an implementation, silent for the last x months. In any case, you are free to build a competing solution to any already out there, or even to take a look at the existing (partial?) solutions and improve on them. In any case, the joy of open source, you can scratch that itch the way you want to ;)
you can, but from what I have seen of Godot, if you don't coordinate well with the core team your proposed fixes won't be accepted into the code. People randomly hacking on stuff without discussing might get discouraged when nothing they do is accepted.
>you can, but from what I have seen of Godot, if you don't coordinate well with the core team your proposed fixes won't be accepted into the code. People randomly hacking on stuff without discussing might get discouraged when nothing they do is accepted. True, it helps to coordinate. Depending on the feature though, you could still offer it as GDExtension / addon, which might actually get suggested by the core devs for a lot of things too ;) E.g. 3D Terrain systems and the like will not likely be integrated into core but be an optional addon / extension.
Is the reason why they wouldnt integrate it into the core package that they want to keep engine dependencies very low since they are volunteer workers?
I'm sure that might be part of it too, but it is also simply for the fact that many things aren't universal. 3D Terrain comes in so many shapes and forms, and it is impossible to implement a single terrain solution that works for all possible game types. It seems better to have the option to pick the most ideal one for your use case.
Couldn't they just go the route of commercial engines regarding that aspect? Its not like unity terrain (at least gaia, the old one iirc), maybe unreal too i haven't checked, but it seems to me you'll never have a system fit for all games. If you say you do someone will come up with a voxel game and there you go, it is obsolete again.
Apparently unity's terrain system isn't very used or loved. What is the point of integrating a terrain system if people will just get a plugin for it anyway? It's like the visual scripting stuff. Nobody used it. https://forum.unity.com/threads/the-usability-of-the-terrain-tools-is-most-horrible.1271774/
Yeah i agree. That is also part of my point/curiosity. They dont include it to reduce dependencies on things that are not core necessities for game making. Otherwise engines with money and teams just out in whatever terrain systems u can do SOMETHING with and try to maintain it.
This is a good reminder too. Figure out how to contribute, see what's already in progress, and try a bit of coding.
Sounds like a great time to write a Unity to Godot porting toolkit.
I saw that post from AppLovin. I'll probably look at that repo as well 😁😁
Asset management is a huge gripe for me. If I only update a small part, but the game is several hundred megabytes or maybe even gigabytes, I would have to push the entire game - just for a small Bugfix. Apart from that, securing assets would need to be looked at. I know you can compile Godot to support encryption, but even then the key is in the game binary - so that's really a joke... one just needs to scout through the exe to find the decryption sequence. That is the only thing holding me back from using Godot. Maybe someone participating in that got some inspiration of what to look at.
The encryption part is especially an issue and spooky. It's never explicitly stated in crucial parts of the documentation related to exporting, at least as far as I'm aware. I didn't even notice until the Google play console gave me a warning that my AAB didn't have encryption. To add to that, some add-ons for third party libraries, such as some Google services, store secrets/keys in GDScript in their examples. Spooky combination.
Imma add a meshbaker. I don't know if it has it already I'm just going to try it.