Gabriel Pickl (Oct 28 2022 at 11:12): Gabriel Pickl (Oct 28 2022 at 11:12):Personally I’m a big fan of the Godot game engine, but not of the Python-like scripting language. I would be very interested in integrating Roc as an alternative script language, though I haven’t really tried to do that yet
Brendan Hansknecht (Oct 28 2022 at 14:10):That would be really cool to see
Brendan Hansknecht (Oct 28 2022 at 14:11):Making it general may be hard, but making it for a specific game should definitely be doable
Kevin Gillette (Oct 28 2022 at 14:20):would making it general be that hard though? godot, like any game engine, congrats what you can do in exchange for making it easier (and more portable/correct) to do those things. A constrained integration surface (say compared to "the whole OS") should make it easier to build as a platform
Brendan Hansknecht (Oct 28 2022 at 14:23):The main problem is likely that different game will want to call into different roc functions at different times with different contexts.
So you can't just always call the roc main at the same location. If your game requires 10 different scripts, each of those needs to be exposed by the roc app.
Brendan Hansknecht (Oct 28 2022 at 14:24):So, quite naturally it will tailor to your specific game.
Brendan Hansknecht (Oct 28 2022 at 14:27):To be fair, I think this is more a comment on using roc as a convenient to write scripting language in a game rather than creating a game platform where an app developer would only write in roc.
Kevin Gillette (Oct 28 2022 at 14:27):if, in theory (ignoring difficulty), Roc were a selectable language in Godot's builtin script editor, would Roc programmers even use that editor, or would they edit from the outside in (via their editor of choice)?
Anton (Oct 28 2022 at 14:29):Probably "from the outside in" because of better integrated tools being available to write roc.
Kevin Gillette (Oct 28 2022 at 14:35):in terms of the multiple entry points note: I'm guessing there are only a finite list of _kinds_ of entry points (entity behavior vs input management, etc), and thus perhaps some form of mini-apps with platform-managed message passing could be useful
Georges Boris (Oct 28 2022 at 14:36):I'd be quite curious to see how a pure functional languages deals with the challenges of scripting as there are many imperative APIs involved.
Most nodes have their own API as well right? Would be awesome to deal with their APIs in a safe way.
Maybe the two main challenges would be to always compile down the result of the exposed functions to a set of imperative instructions and keep parity with the constantly evolving APIs/nodes so they can be interacted with through a typesafe interface.
Kristian Notari (Oct 28 2022 at 14:40):As per the editor experience, the coding for Godot games is already done with external editors if needed so that's not a big deal, Godot itself has some utilities to work with external editors (reflect changes and stuff like that)
Kevin Gillette (Oct 28 2022 at 14:41):Roc seems like it'd do a pretty good job in Entity Component System engines, iiuc (just my speculation), as that seems much more like batch processing of many entities rather than bespoke scripts attached to specific entities
Brendan Hansknecht (Oct 28 2022 at 14:41):Yeah, skimming the Godot docs, i think this would be a solid project to do in general. Just getting a hello world example building might be quite hard. After that, you still need a way to get Godot to speak in roc types. You likely have to tailor multiple roc functions to specific apis you want to expose to Godot. I think Godot has a lot of control and this would not be easy. Likely you would want to just dump the roc file as an object instead of trying to use any of the roc build/linking tooling. Though Godot can link to shared libraries which means Theoretically it could be game for the surgical linker.
Kevin Gillette (Oct 28 2022 at 14:42):https://github.com/godot-rust/godot-rust
Brendan Hansknecht (Oct 28 2022 at 14:42):Yeah, gdnative is how Godot speaks to shared libraries.
Kristian Notari (Oct 28 2022 at 14:42):this is a good reference I guess, one I've used in the past to see actual state for different languages:
https://github.com/Vivraan/godot-lang-support
Brendan Hansknecht (Oct 28 2022 at 14:43):They also have c++ modules which would be another option.
Kevin Gillette (Oct 28 2022 at 14:44):@Georges Boris the "imperative" problem seems analogous to how FP languages approach IO and, if needed, state. For example, you could return a list of actions to be performed and the platform can perform them on behalf of Roc
Brendan Hansknecht (Oct 28 2022 at 14:44):But yeah, going through the gdnative rust bindings is probably the easiest option with the current state of Roc.
Brendan Hansknecht (Oct 28 2022 at 14:46):You would generate your API in rust. Have that delegate to roc functions. Have roc dump an object file directly and have rust link to it while building the shared library. I guess that isn't super hard to get done, but that doesn't include all of the wrapping and type wrangling that likely has to be done so roc can communicate to Godot well through rust.
Georges Boris (Oct 28 2022 at 14:55):@Kevin Gillette yeah - I believe the problem would happen when you need to deal with values returned from IO functions. You could work basically inside tasks all the time.
Kevin Gillette (Oct 28 2022 at 14:56):godot allows named, typed (a few varieties of scalars and lists) script params to be defined in the godot editor. I imagine we could simplify some of the integration by passing that in as a Dict of union typed values (or list of key-val pairs), leaving the Roc entry point to transform that into something more structured?
That seems easier to me from a platform perspective than stitching godot params directly into a record with same-named fields
Gabriel Pickl (Oct 28 2022 at 15:53):Wow, this thread moved a lot^^’
A few points: i think gdnative is being sunset in favor of a new system that I haven’t looked into. If I remember correctly, godot has a way of integrating new “scripting” languages.
I also think most of the functionality of nodes should be mappable to purely functional code, although this is definitely a big design space to try and find the most ergonomic, safe, and performant approach.
As for the editor: wouldn’t it be really cool to integrate the roc editor into godot? Not sure how feasible this would be, but it would make for an interesting experience. Failing that, godot c# also works okay with external editors I guess.
One of the big challenges for me would be modeling the roc build so that roc files can be used similar to gd files (each exposing certain functions that get called by the platform) without users having to think much about the build process. As well as good debugging utilities at least for state. But I’m getting ahead of myself
Anton (Oct 28 2022 at 16:13):wouldn’t it be really cool to integrate the roc editor into godot?
Cool for sure but I don't think it would be worth all the work. I know very little about godot, what benefit would the integration bring?
Kristian Notari (Oct 28 2022 at 16:25):My vision of the game dev world (not saying it's accurate enough) is that if FP is becoming more and more common in general purpose programming, game dev is still anchored to what it used to be.
Kristian Notari (Oct 28 2022 at 16:27):So I only see two reasons on why roc could be a great alternative for godot dev:
Kevin Gillette (Oct 28 2022 at 16:37):There was some company or group doing game dev in Haskell about a decade ago, but i don't know if anything came out of it
Gabriel Pickl (Oct 28 2022 at 16:41):Well, it’s not really the first foray into FP gamedesign. There’s been a lot of great talks about it in the elm world, and as you may know from richards talks, even john carmack recommends the style (which is not the same as pure fp, but i thin you get what i mean)
The gaming dev world is also not at all static/traditional, with developments in ecs, dop and the sort.
But i do think roc could make pure fp as an embeddable language for games (in lieu of lua for example) more viable, which makes me very interested
Andrea Bueide (Sep 01 2024 at 19:57):I've been think roc would make a really good embedded scripting language for a card game (something like hearthstone or magic the gathering). Mtg itself is basically a state machine where each action transforms the state in a discrete way with a stack and everything.
Last updated: Jun 16 2026 at 16:19 UTC