Godot is a reasonably light-weight, highly featured, open-source game engine that’s been in development for more than a decade. I started playing with it not long after it was mentioned by TheHappieCat on YouTube and found myself enjoying it in most every respect. The editor was, as the tagline implied, small and lightweight while being very feature complete. Version 3.0 brought with it high-fidelity visuals (a la PBR), a new physics system, and a slew of other additional enchancements. Fun on most every front.
The one area where I found Godot most lacking was GDScript. Coming from languages like Python and Kotlin and Java and C, I found it to embody most of the pieces I didn’t like about Python with none of the things I did like. It was just similar enough to cause problems and be unintuitive. As good as the documentation is, the language is fundamentally too limited for the kinds of things I like to do in games. (Has anyone written a matrix library for GDScript?)
Enter GDNative: what appears to be the ability to simply build a DLL and then call the methods from GDScript! We’re saved!
Almost.
GDNative doesn’t provide a way to call arbitrary methods in a DLL or .so and, from what I can gather in the IRC and Discord channels, there’s no intent to include Dylib or another system for gathering those. Instead, there are key methods which are exported and need to be defined so that the DLL can register with Godot. The problem then is nontrivial, but it’s not impossible.
There are plenty of paths that let us go from Kotlin to Godot and it’s worth describing the desired output before we enumerate them.
We could want nothing more than to produce some exported methods that take standard data types and return standard data types. This was my desired use case. I had two methods I wanted for my game, Terminus. Those were compile(string code, byte[] memory) that accepted a string and compiled it into instructions for the virtual CPU. I didn’t need to define any special node type or interface with other Godot types. I just wanted to put two methods into a DLL and call them.
Another option is interop with the other Godot node types. This means having the ability to subclass Godot’s Node and interact with Variants. This provides, arguably, the most versatile of solutions at a small amount of added complexity.
The most obvious path forward is to have Kotlin Native produce a DLL that we can import as a native library. When I last tried this I ran into an issue where it’s not possible to define the name of a method in the DLL with Kotlin Native**. I considered then building a static library and having a small C wrapper that defined the required nativescript_init method. This, too, turned out to not be an option. Kotlin Native can produce a KLIB library file, but not a lib. Finally, I turned to building bytecode with LLVM and then using that in place of a static library. The process for setting up LLVM in Windows is straightforward, but between fighting with MSVC, not being able to find link.exe, and a handful of other technical issues, I thought this would be too cumbersome a path for the average user.
The next path, then, is to use the cinterop tool along with the Godot header files to produce a klib file that can be used by Kotlin native. With a little fandangling, this can be wrapped up and shipped nicely as just the KLib and a build.gradle file, allowing for a quick and painless way of producing nodes with Kotlin. This is the approach I’m trying to implement right now, and it remains to be seen how trivial the process is.
** Note: As of Kotlin/Native 0.6.0, exporting function names with @CName is possible. One must simply figure out how to import kotlinx.cinterop. I’m currently working on that.
UPDATE: 2018/03/26: This issue is now tracked on YouTrack at https://youtrack.jetbrains.com/issue/KT-23455