develop long term strategy for bindings #77

New issue

Open

opened 2026-10-18 16:23:56 +00:00 by Roboticy3 · 0 comments

Roboticy3 commented

2026-10-18 16:23:56 +00:00

(Migrated from github.com)

Im getting overwhelmed with the integration of louder_rust with godot for the purposes of the crpg example. That was the main project of this weekend.

The short term solution is to do the slow, tedious thing: using the current state of the integration to the best of my ability. As remarked earlier, this interface is clunky. However, there ate issues open to centralized its usage in the current working example and rebuild the server script.

After that, the main priority is implementing engine holes I found during writing and playtesting the demo.

Then, the main project with the engine becomes improving the api. I chose rust for the engine because of rust's amazing ability to do codegen. Codegen enables the implementation of macros that convert the louder_rust api into adapters between a louder_rust binary and other languages. The current issues with the gdext adapter godot_rust are:

it is not automatic
there are unintuitive translations between engine types and scripting types, most notably that of the different kinds of ids.
it is very complex, but not usable.

This is on me for using AI too heavily. While this did allow me to work on the more artistic parts of the demo, it required a lot of work to monitor and also clearly misaligned, either by the model's error or in ways my prompting didn't account for. I also attempted to use AI to use other bindings, but simple visual inspection reveals these bindings have similar weaknesses. While rust does have impressi e codegen abilities, the models in my toolkit are slow to use them relative to Python based codegen, which is also worth consideration.

The engine could also be reimplemented in a custom intermediate language, with scripts that then convert it to:

Rust with gdext (i still prefer this to c++ extensions because the cargo crate is easier to set up than the equivalent cpp project)
C
Other languages at will using AI generated conversion scripts.

Anyway, this issue is half planning, half reflection. My point is that I should prioritize the ingredients that finish the demo first and do so as healthily as possible. And for now, I've earned a break!

Im getting overwhelmed with the integration of louder_rust with godot for the purposes of the crpg example. That was the main project of this weekend. The short term solution is to do the slow, tedious thing: using the current state of the integration to the best of my ability. As remarked earlier, this interface is clunky. However, there ate issues open to centralized its usage in the current working example and rebuild the server script. After that, the main priority is implementing engine holes I found during writing and playtesting the demo. Then, the main project with the engine becomes improving the api. I chose rust for the engine because of rust's amazing ability to do codegen. Codegen enables the implementation of macros that convert the louder_rust api into adapters between a louder_rust binary and other languages. The current issues with the gdext adapter godot_rust are: - it is not automatic - there are unintuitive translations between engine types and scripting types, most notably that of the different kinds of ids. - it is very complex, but not usable. This is on me for using AI too heavily. While this did allow me to work on the more artistic parts of the demo, it required a lot of work to monitor and also clearly misaligned, either by the model's error or in ways my prompting didn't account for. I also attempted to use AI to use other bindings, but simple visual inspection reveals these bindings have similar weaknesses. While rust does have impressi e codegen abilities, the models in my toolkit are slow to use them relative to Python based codegen, which is also worth consideration. The engine could also be reimplemented in a custom intermediate language, with scripts that then convert it to: - Rust with gdext (i still prefer this to c++ extensions because the cargo crate is easier to set up than the equivalent cpp project) - C - Other languages at will using AI generated conversion scripts. Anyway, this issue is half planning, half reflection. My point is that I should prioritize the ingredients that finish the demo first and do so as healthily as possible. And for now, I've earned a break!