Godotcaml for Godot 4.2 | Hacker News Reader

Godotcaml for Godot 4.2

fizzixnerd.com

135 pointsp4bl052 comments

Oh this is really cool! It also feels highly targeted at my interests (I worked professionally in OCaml for many years, now make games, and bounced off of Godot because I found GDScript really unpleasant to program in[1]).

From looking through the TODOs here, I think the one thing that would stop me from playing with this soon is signal support. I can't quite tell how non-existent the signaling support is here: can I just Obj.magic (unsafe cast) stuff and get it to work, albeit without type safety? Signals in Godot are great and I'm already used to them not being type safe (they're just strings in Godot 3! Gross!) so that'd be tolerable.

Anyway, very cool stuff.

[1] I've been meaning to go back at try out C#, which might be more my taste. I held off partially because I don't know C# yet and partially because examples for C# in Godot seemed a little lacking when I last looked - but also because Godot 4 web exports were pretty busted for a while, which irritated me enough to make me use something else. I think there's been some progress here though!

> Godot 4 web exports were pretty busted for a while, which irritated me enough to make me use something else. I think there's been some progress here though!

Still no web export support for C# yet, it's reliant on upstream support in .NET Core which isn't quite there yet.

oh I didn't even realize that C# was also a problem here - I was thinking about how web exports are (were?) pretty busted for Chromium-type browsers on Mac in Godot 4[1] due to some graphics backend stuff that I don't fully understand.

Thanks for the heads up! Guess it's not time for me to revisit Godot yet :(

[1] https://github.com/godotengine/godot/issues/70691

Yeah, there are a lot of problems with Godot 4 web exports generally - due to the fact that it's a lot more multi-threaded in general than Godot 3, which presents problems for web exports and requires certain features to be enabled server-side via headers. Godot 4.3 "fixes" this by allowing you to export a single-threaded build - which obviously isn't the ideal fix, more of a workaround that may result in worse performance.

Godot 3.x supports web exports for C#, due to the mono runtime being long available as a WASM target. But .NET Core still doesn't quite work there, there are experimental builds while using Blazor specifically, but for hosted runtime stuff (such as Godot) the support isn't there yet, despite MS promising it since .NET 6 it hasn't arrived yet.

What I dislike in Unity and Godot in regards to C#, is magic methods outside common .NET practices.

I guess it is a price to pay for making the language relevant for game devs.

I think it'd be interesting to compare against F#, especially since Godot already has first-class support for .NET. When the bindings get fully fleshed out, what will OCaml bring to the table to warrant the extra hoops for the user that has no prior preferences for either languages?

Godot uses source generators to fill out C# partial classes, so it doesn't quite have native F# support. You'd at least need C# shims for your types that inherit from Godot classes.

Bummer, I had no idea about that. But I guess that, at least for turn-based games, it wouldn't be super annoying if you manage to split the logic (F#) from the UI glue (C#), right?

(I never got around to that point though, I usually start making games as libraries and then get nerd sniped into reading about game theory for the AI before I make them playable for humans.)

This is why I haven't done f# with godot yet, haven't felt like building out the shims.

Is it first-class support? I hear lots of godot devs saying "I can't use X because I'm using C# instead of gdscript"

C# support is great. But yes, if you need to call a library/extension written in gdscript from the C# code, you'll need to write some C# bindings to make it practical.

The only thing not available in C# in godot 4 is web exports - they'll come whenever upstream support arrives.

Using C# actually nets you more features, not less.

It is first-class support, as far as I know everything is accessible from C#. I developed YKnytt, an open source game, fully in C# and never had the issue of something not working in C# as it did in GDScript.

> the extra hoops for the user

The idea of Godot is "extra hoops."

Can you elaborate on that? I thought it was a fairly batteries included game engine, if you use gdscript at least.

Miguel de Icaza's [Swift Godot](https://github.com/migueldeicaza/SwiftGodot) effort is also very active and worth tracking I think.

Which all languages have viable bindings with Godot 4.x?

Does Java have one? What about Javascript?

Here is a list [0] of them but should give you a good idea even if it's old. It claims that Javascript is production ready but I can't find much info on Java. So Java probably has 0 support.

I know a lot of people say GDScript is close to both Javascript and Python but it's not close enough for me personally. So if you want to use Python just use one of the Python game enignes (such as Panda3D, Pygame, Arcade, Ursina) instead. Javascript and Java also has a lot of good engines too so don't feel like you have to use Godot.

[0] https://github.com/Godot-Languages-Support/godot-lang-suppor...

Officially there is just gdscript, c#, and c/c++.

There's a lot of unofficial bindings with godot's GDExtension interface. Looks like there are supposedly "production ready" bindings for JavaScript/typescript, lua, nim, and rust. I've been looking into using rust with godot though, and it looks like it only works with desktop apps, not web or mobile yet.

And then there's even more that are supposedly "almost production ready": closure, D, and haskell

In development but not production ready: f#, go, kotlin, python, Swift, wasm, zig

Godot bindings for Swift https://github.com/migueldeicaza/SwiftGodot

I want to try my hand at development, what would you suggest to shorten the learning curve, Godot or Unity (https://unity.com) ?

I’m an external examiner for CS students in Denmark. One of the places I do this is some form of “gaming CS” education. Which tends to produce some of the poorest students, but it does give me some insight into what they build.

In 8 years I’ve never seen a successful Unity project despite them actually being taught Unity. The only “finished” game I’ve seen was for Robolox, but in general the students who chose to do pygame fared decently. I haven’t seen a Godot project, so I’m not sure how much help this is outside telling you that Unity is probably not as “easy” as you might think.

Thank you, Sir!

I'd say find a reasonably short but high watch count tutorial on youtube for each and see which looks like it'd fit your thought process better. I used Unity off and on for like a year but stuff like the load and compile times made it hard for me to get in a flow state, where as Godot takes a lot to slow down similar to even a simple Unity project. Also the fact prefabs are just scenes to create more consistency just feels more reasonable to my personal development tastes.

Big caveat if you want to do mobile dev Unity is still better, though hopefully as the work The Forge/Google did for the renderer this will be less true.

Thank you for the detailed explanation.

Not a problem. Helping people get started with godot is a bit of a hobby of mine, but it also is not for everyone so I try to not oversell it because the best thing for a dev is use the right tool for their brain and target game type.

Right now Unity has more resources, is much more powerful, and the UI is a lot more polished. Godot's getting better quickly but still has a lot of rough edges. However, Godot seems like it's built on a better base and has avoided many, many engine warts that Unity has embraced.

Unity's development outlook seems kind of bleak to me and it's lost all community goodwill, while Godot has more attention than ever; in 2-3 years it might be a tougher choice, but for now Unity's probably your shortest path to learning what you want to.

Thank you very much.

Godot is optimized to actually build your game, the cracks start to appear with everything that’s not explicitly about building your game (codec support, shipping to non Desktop platforms etc). Unity is really good at abstracting the finicky shipping stuff away but lousy to actually build a videogame with.

Thanks a lot.

I found Godot more intuitive and easier to get into than Unity

I also find Unity's business practices to be sketchy and I wouldn't personally trust any part of my projects to a company that has a history of rug-pulling (and then reluctantly walking back)

Thank you so much.

Unity has way more tutorials whuch can shorten the learning curve a lot. Another thing to keep in mind is that once you learn one engine it's easy to learn another.

Thank you.

Why didn't Ruby take off in the game industry? As I understand OOP is a critical language feature which led to the success of Java and C#. Is it maybe because of dynamic typing?

OOP experience in Ruby is very pleasant and I wish the language was used more.

Mostly other languages like Lua and Python also being good choices.

Lua is simpler, is much, much easier to embed into your project and is much faster, especially with LuaJIT. It is the perfect fit for this task

Too much OO can hurt performance quite badly and while some form of OO is common in the game industry there is also more emphasis on keeping things simple. Ruby is a very nice language and not a bad choice for non-performance critical code but Lua is the default choice for game scripting for a reason.

And for the cases there Lua is too simple, well there is Python. Sure Ruby does a few things better but it doesn't really have a clear advantage over Python while also being less popular.

Late reply, but maybe it’ll be useful to other people coming across this post.

1. mRuby is trivial to embed.

2. S7 Scheme is also trivial to embed.

3. LuaJIT will not work on consoles (proprietary CPU architectures), and JIT isn’t supported on iOS or Android. You have to use vanilla Lua.

4. Lua has historically been the default because it was first to provide a nice embed story.

5. Lua as a language leaves a lot to be desired (Ron Gilbert really disliked using it within his games)

6. This gist post goes into details wrt the deficiencies of Lua [1]

7. Here are two GH repos with Roguelike Tutorial. One in Lua [2], the other in mRuby [3]. It’s worth comparing and contrasting.

8. If I want extremely performant code, then I drop down to C. For scripting level/game code. mRuby is plenty fast [4].

[1] https://gist.github.com/amirrajan/2c42315ffef311600ecb2d8dcf...

[2] https://github.com/Lycea/Rogue/tree/master/components

[3] https://github.com/kfischer-okarin/roguelike-tutorial-2021/t...

[4] https://m.youtube.com/watch?v=MFR-dvsllA4

I used to code in Ruby for indie games (well, RPG Maker). For me the reason is several things:

1. Its performance meant that it would never survive against Java/C# for AA/AAA games, not to speak of C++

2. Lack of libraries. Last time I tried no physics engine worked with Ruby 2.3, and ouch that made my game or many games impossible

3. No significant advantage over Python, especially given that for indie games Python had the popularity advantage, the numpy/numba/Pillow/easier to write high performance code advantage. Bitmap manipulation in Python using even numpy is much easier than whatever I can do in Ruby.

4. OOP is not actually that important especially for the market Ruby can break into. DragonRuby is in the right step, but look at pico8, love2d, or even Unity3D -- there is not a lot of inheritance going on. Simplicity is good.

Of course the above factors play into each other.

It is used for some of the RPG Maker engines [0]. There's also DragonRuby [1] which I believe is made by someone heavily involved in SDL.

I'm sure a lot of people will say it's too slow, etc. but the truth is that great games come from a very wide range of tools and if Ruby fits your needs then you should use it.

[0] https://www.rpgmakerweb.com/

[1] https://dragonruby.org/toolkit/game

Maybe it is because the games industry evolves more slowly now and depends a lot on legacy technology. You don't see a bunch of new game engines being built and the two most popular ones use C++ and C#. The emphasis is much more on content now and much less on technology.

Ruby still gets used in indie and professional games for scripting but it's just got fewer advantages vs something like Lua or even JavaScript.

I would assume Object Oriented Programming isn't very important in games. In fact I think there might be a aversion to it now.

As an aside I've been thinking lately that OOP isn't very well defined unlike FP. I think that's why there is a disagreement on what is OOP. Many think it's about inheritance because of Java while Alan Kay says it's about message passing as in Smalltalk. Whereas functional programming is just programming using pure functions. That simple, no confusion.

Creator of DragonRuby here. Send me an email and I’ll hook you up with a license to the game engine :-)

at[at]amirrajan[dot]net

Anything with a stop-the-world GC is a non-starter in games land.

GC doesn't have to stop the world. There are fully concurrent GC engines.

Correct, but ruby historically (and might still) use a stop-the-world gc.

That’s why I specifically said “with a stop-the-world GC”

it is incredibly slow and is interpreted not compiled.

Yes. I completely forgot that games need to be fast.

This kinda just made me curious about the Rust api. Sorry. :)

This is going to sound stupid, but bear with me. Godot is a very simple engine once you get past its learning curve. I know that this thing could be said about anything, but you only need a couple of hours/days to grasp the basics. And once you know the basics, you pretty much know the whole engine and can refer to documentation for anything you want to do. For example, for a Godot beginner even creating a simple 3D cube can be a problem. But once you understand that you need to compose it out of different building blocks, how you should do this and why, everything clicks. It's a delight, I recommend everyone to try Godot

exciting and unexpected. i'll try it but i'll be pleasantly surprised if it's good

Quite nice achievement.

Reply on news.ycombinator.com