8 ms·
Godotcaml for Godot 4.2
- rphln 2y agoI 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 2y agoGodot 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 2y agoThis is why I haven't done f# with godot yet, haven't felt like building out the shims.
- rphln 2y agoBummer, 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 2y agoIs 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 2y agoC# 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 2y agoIt 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.
- lewispollard 2y agoThe 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.
- doctorpangloss 2y ago> the extra hoops for the user The idea of Godot is "extra hoops."
- __jonas 2y agoCan you elaborate on that? I thought it was a fairly batteries included game engine, if you use gdscript at least.
- eieio 2y agoOh 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!
- lewispollard 2y ago> 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.
- eieio 2y agooh 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 https://github.com/godotengine/godot/issues/70691
- lewispollard 2y agoYeah, 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.
- kragen 2y agoexciting and unexpected. i'll try it but i'll be pleasantly surprised if it's good
- binary132 2y agoThis kinda just made me curious about the Rust api. Sorry. :)
- billfruit 2y agoWhich all languages have viable bindings with Godot 4.x? Does Java have one? What about Javascript?
- raytopia 2y agoHere 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-support https://github.com/Godot-Languages-Support/godot-lang-suppor...
- Austizzle 2y agoOfficially 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
- gerardpg 2y agoGodot bindings for Swift https://github.com/migueldeicaza/SwiftGodot https://github.com/migueldeicaza/SwiftGodot
- alabhyajindal 2y agoWhy 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.
- amirrajan 2y agoCreator 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
- honkycat 2y agoit is incredibly slow and is interpreted not compiled.
- alabhyajindal 2y agoYes. I completely forgot that games need to be fast.
- georgeecollins 2y agoMaybe 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 2y agoIt 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/ https://www.rpgmakerweb.com/ [1] https://dragonruby.org/toolkit/game https://dragonruby.org/toolkit/game
- bobajeff 2y agoI 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.
- lovegrenoble 2y agoI want to try my hand at development, what would you suggest to shorten the learning curve, Godot or Unity (https://unity.com https://unity.com) ?
- bluefirebrand 2y agoI 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)
- lovegrenoble 2y agoThank you so much.
- raytopia 2y agoUnity 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.
- lovegrenoble 2y agoThank you.
- npinsker 2y agoRight 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.
- lovegrenoble 2y ago
- berkeleynerd 2y agoMiguel de Icaza's [Swift Godot](https://github.com/migueldeicaza/SwiftGodot https://github.com/migueldeicaza/SwiftGodot) effort is also very active and worth tracking I think.
- efilife 2y agoThis 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
- pjmlp 2y agoQuite nice achievement.