[HN Gopher] Godotcaml for Godot 4.2
       ___________________________________________________________________
        
       Godotcaml for Godot 4.2
        
       Author : p4bl0
       Score  : 109 points
       Date   : 2024-07-16 11:25 UTC (11 hours ago)
        
 (HTM) web link (fizzixnerd.com)
 (TXT) w3m dump (fizzixnerd.com)
        
       | rphln wrote:
       | 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?
        
         | TillE wrote:
         | 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.
        
           | runevault wrote:
           | This is why I haven't done f# with godot yet, haven't felt
           | like building out the shims.
        
           | rphln wrote:
           | 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.)
        
         | nox101 wrote:
         | 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"
        
           | eole666 wrote:
           | 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.
        
           | YoukaiCountry wrote:
           | 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.
        
         | doctorpangloss wrote:
         | > the extra hoops for the user
         | 
         | The idea of Godot is "extra hoops."
        
           | __jonas wrote:
           | Can you elaborate on that? I thought it was a fairly
           | batteries included game engine, if you use gdscript at least.
        
       | eieio wrote:
       | 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!
        
       | kragen wrote:
       | exciting and unexpected. i'll try it but i'll be pleasantly
       | surprised if it's good
        
       | binary132 wrote:
       | This kinda just made me curious about the Rust api. Sorry. :)
        
       | billfruit wrote:
       | Which all languages have viable bindings with Godot 4.x?
       | 
       | Does Java have one? What about Javascript?
        
         | raytopia wrote:
         | 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...
        
         | Austizzle wrote:
         | 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
        
       | alabhyajindal wrote:
       | 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.
        
         | honkycat wrote:
         | it is incredibly slow and is interpreted not compiled.
        
         | georgeecollins wrote:
         | 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.
        
         | raytopia wrote:
         | 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
        
         | bobajeff wrote:
         | 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.
        
         | runeblaze wrote:
         | 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.
        
         | cardanome wrote:
         | 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.
        
         | kevingadd wrote:
         | 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.
        
       | lovegrenoble wrote:
       | I want to try my hand at development, what would you suggest to
       | shorten the learning curve, Godot or Unity (https://unity.com) ?
        
         | bluefirebrand wrote:
         | 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)
        
         | raytopia wrote:
         | 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.
        
       | berkeleynerd wrote:
       | Miguel de Icaza's [Swift
       | Godot](https://github.com/migueldeicaza/SwiftGodot) effort is
       | also very active and worth tracking I think.
        
       ___________________________________________________________________
       (page generated 2024-07-16 23:01 UTC)