this post was submitted on 13 Sep 2023
246 points (99.6% liked)

Godot

5916 readers
8 users here now

Welcome to the programming.dev Godot community!

This is a place where you can discuss about anything relating to the Godot game engine. Feel free to ask questions, post tutorials, show off your godot game, etc.

Make sure to follow the Godot CoC while chatting

We have a matrix room that can be used for chatting with other members of the community here

Links

Other Communities

Rules

We have a four strike system in this community where you get warned the first time you break a rule, then given a week ban, then given a year ban, then a permanent ban. Certain actions may bypass this and go straight to permanent ban if severe enough and done with malicious intent

Wormhole

[email protected]

Credits

founded 1 year ago
MODERATORS
 

I made a blog post about my experience switching from Unity to Godot earlier this year, and some tips for Unity devs.

top 31 comments
sorted by: hot top controversial new old
[–] [email protected] 19 points 1 year ago* (last edited 1 year ago) (5 children)

You can use C# (don't)

C# users are second-class citizens in Godot. Many features such as web exports don't work with C# projects, and C# often has bugs specific to it and often lacks tutorials/documentation

... welp. So... any more details on this? I'm not learning a single-purpose language.

Edit: yes, GDScript seems nice, I know. Please stop recommending it though :P

[–] [email protected] 20 points 1 year ago (1 children)

Honestly GDscript is really easy to learn if you've got a programming background. The concepts are mostly the same so you can head over to the GDScript reference and learn to use it in less than a day. As soon as you get used to the syntax you basically know it already.

[–] [email protected] 12 points 1 year ago (2 children)

I'm sure you're right, and it looks serviceable. It's not really about that, though. I've done the "learn a new language" thing many, many times. It gets old and I'm sort of over it - it's not as fun as it once was, particularly now I have my favorite that I know well and am good at.

[–] [email protected] 9 points 1 year ago (1 children)

GDScript works almost 1-1 like Python. Any experience with Python almost instantly translates into knowing what to do in GDSCript, but not necessarily the other way around, as their script has a couple more builtin features.

[–] [email protected] 5 points 1 year ago (1 children)

Was going to say this but you beat me to it: if you know Python, you pretty much already know GDScript. It's not at all like needing to learn another language from scratch.

[–] [email protected] 2 points 1 year ago

I don't understand why people are so afraid of GDScript, so many are literally refusing to even look at it. It's baffling.

[–] [email protected] 3 points 1 year ago

If you've done it a lot then you know how easy it is to get up and running with a new language.

Really, it's not that hard. GDscript is not some archaic clunker like COBOL with outdated paradigms, nor some esoteric joke language like Brainfuck that's just pointlessly difficult. You're going to be fine with it inside of a day.

[–] [email protected] 17 points 1 year ago

C# works fine, lots of Godot projects are using it.

That said, consider learning GD Script? Even if it's only used by Godot, it's simple, well integrated with the editor and is awesome for quickly building out your game.

Besides, it's very Python-esque. Whether you know Python or not, it's syntax is very straightforward and easy to work with.

[–] captain_aggravated 12 points 1 year ago

GDScript is very similar to Python; if you know Python, learning GDScript takes about an hour.

  • declaring a function uses the func keyword instead of def
  • there's an actual concept of variables and constants, in python you'd just say number = 3 but in GDScript you do var number = 3 or const number = 3.
  • the constants "true" and "false" aren't capitalized like in Python
  • "match" is switch...case but slightly more terse.
  • No lists, just arrays. There are also enums. There are also several built-in data types like vector2 or vector3 which are handy for storing position and velocity data in 2D or 3D space.
  • There isn't a module/library system; some things like random number generation, timing, math etc. are provided by the base language because they're ubiquitous in game making, others, such as functions for audio playback, are provided by the node that your script extends. Right about here we get into territory where it's more about how Godot works and less about how GDScript works, and concepts such as onready, signals etc. would be required learning no matter what language you use with Godot.
[–] [email protected] 10 points 1 year ago* (last edited 1 year ago)

The C# version of the project is separate from the main one. It is possible to entirely code a game in c++ though in the main one (you can use both c++ and gdscript in it in one game interchangeably). Gdscript is a really easy language to learn though and is similar to other scripting languages (the only things you really need to learn is some keywords godot added to make coding in it easier when using things in the engine. Stuff like node names etc you would have to learn regardless of the language you're using)

[–] [email protected] 2 points 1 year ago

C# works fine with Godot and with the changes in Godot 4.x its better than ever with Godot.

Here's a pretty good blog post comparing the two:

Personally I dislike using scripting languages as the primary language for any bigger project. The lack of proper static typing commonly causes issues with linting, code-completion, error highlighting and refactoring tools. Lack of namespaces can lead to name clashes with type names and such especially ones you start adding bunch of 3rd party plugins.

Also using having to include/preload any script files using string references like this: const Rifle = preload("res://player/weapons/rifle.gd") is not just plain bad in my books. Its just plain dirty compared to Namespaces in C# or Packages in Java.

I do like Python and I use it quite a bit at work to automate things as you can install and import bunch of ready made libraries for almost anything and just write script that is like sub 500 lines and does whatever. But the moment I need to make anything that contains multiple files and some object oriented practices things will get increasingly more annoying very fast.

Having interfaces is quite nice as well as it allows me to keep my code more loosely coupled. I try to keep my code as portable as possible by keeping much of my code in a separate project that has no dependencies to Godot. This way I can use nUnit in another separate project to do unit tests for the code and just write wrappers and whatever in Godot project. If Godot API changes I generally only need to fix the code in the wrapper classes.

[–] [email protected] 17 points 1 year ago (2 children)

"and it even adds the .gitignore for you!" I'm sold I hate trying to figure out what version of base gitignore I need for what version of Unity. Thank you for making this!

[–] [email protected] 7 points 1 year ago

It's definitely a big point for me too, using Git with Unity is a big pain. Even using the right gitignore I often have to upload large Unity-generated files to my github which might've pushed me to using Git LFS. Having something that just works is liberating.

[–] [email protected] 5 points 1 year ago (1 children)

As a non gamedev adding a .gitignore is a feature? 😮

[–] [email protected] 1 points 1 year ago

.gitignore is an amazing thing all but my simplest projects use them

[–] [email protected] 8 points 1 year ago (1 children)

Great post! Definitely helpful with the Unity drama going on now. I had initially started my game dev journey on Godot, but recently switched to unity bc of console support. Really thinking about switching back, especially now that v4 is out.

[–] [email protected] 7 points 1 year ago (1 children)

Godot has console support now. I think it has for a couple of years, actually.

[–] [email protected] 2 points 1 year ago (3 children)

The linked article literally says it is not officially supported though, so which one is right? Are you talking about W4 which sounds like some unofficial WIP workaround?

[–] [email protected] 5 points 1 year ago

theres no official support currently but thats what W4 will become. Theres a lot of unofficial support currently though

[–] [email protected] 4 points 1 year ago

Iirc, console development requires signing an NDA or something, which is why there are no official docs on porting a Godot game to Xbox, PlayStation, or Switch. There are, however, third party companies that Godot vouches for that have a good track record of specializing in porting Godot games to consoles.

[–] [email protected] 1 points 1 year ago

W4 isn't unofficial, it's literally the core engine devs who started a private company for the purpose of doing things the Godot Foundation can't.

W4 doesn't own Godot in anyway, but they can sign the required NDAs and gain access to the SDKs, which cannot legally be given out with an open source software like Godot.

[–] [email protected] 7 points 1 year ago (1 children)

You may want to change the fact that web exports don't work on macOS. MacBook Pro M1 user here. I'm happily running my Godot 4.1 as web exports on my server. Setting the headers is required for any browser / operating system, but things seem to work fine for me on Mac.

[–] [email protected] 2 points 1 year ago* (last edited 1 year ago) (1 children)

Weird, you may be an outlier. The issue for Mac web exports not working is one of the most upvoted on their Github: https://github.com/godotengine/godot/issues/70691

According to that, you have to manually set the renderer to Metal* or it might freeze/crash your browser (or take minutes to load). I've personally had many mac users tell me that my web projects aren't loading for them, I'm pretty sure the issue is still not resolved.

[–] [email protected] 1 points 1 year ago

That is weird! Once my project is in a shareable state, I'll post the link here. Maybe it's because (so far) it's not awfully complex...

[–] [email protected] -1 points 1 year ago (3 children)

I recently realized that Unreal is Open-source. I'm curious why it doesn't seem to get any love from the FOSS community? I would personnaly glady ditch unity, but I heavily rely on video tutorials for my very amateur projects . So I was actually moving to Unreal..

[–] [email protected] 34 points 1 year ago (1 children)

As far as I know Unreal's source code is available but the licensing isn't, so the company still owns it and can still charge you for using it.

[–] [email protected] 14 points 1 year ago

This is correct. If you took code from Unreal source and plopped it in Godot, you'd be in deep crap.

[–] [email protected] 20 points 1 year ago (1 children)

Open source is not necessarily FOSS

[–] [email protected] 1 points 1 year ago
[–] [email protected] 8 points 1 year ago (1 children)

Unreal is "source available", not Open Source. There's a big difference. With any Open Source project you can legally fork the project, distribute your custom version of the code, create a community around your variant... "source available" has none of that. The Unreal EULA is more permissive than most game engine licenses (with the obvious exception of Godot) but it still comes with plenty of restrictions. For example:

You are permitted to post snippets of Engine Code, up to 30 lines of code in length, online in public forums for the sole purpose of discussing the content of the snippet or Distribute such snippets in connection with supporting patches and plug-ins for the Licensed Technology, so long as it is not for the purpose of enabling third parties without a license to the Engine Code to use or modify any Engine Code or to aggregate, recombine, or reconstruct any larger portion of the Engine Code.

Which pretty clearly does not satisfy the Open Source Definition.

[–] [email protected] 2 points 1 year ago

That's a really informative reply, it clarifys things for me. Thanks a lot!