What support like for macos?
I use it on macOS and Windows, and it is lovely! I even have Steamworks.NET integrations working on both platforms with it. It can be a bit tricky to setup the `.csproj` correctly to resolve native dependencies, but not anything impossible.
It’s time to make that indie C# game in Godot
41–50 of 228 posts
Re: It’s time to make that indie C# game in Godot
#42Earlier quoted context omitted.
Custom scripting language seems to be a common error - early on Unity emphasized a pseudo-custom scripting language (Boo) over C# and had to slowly extract it out of the product, documentation etc. It makes sense as a risk management strategy early on in engine development, though, since integrating something like C# can be difficult and they may have been afraid that they would regret building around C# later on.
Normally I'd agree with you, especially as someone that's embedded a scripting language into AAA games, but I think GDScript is the exception to the rule. Or, it's very tightly integrated with the engine's way of handling memory and it feels refreshing compared to a VM that has some bindings to native functions.
On the other hand, GDScript is not that great a language. No one would use it as a general purpose scripting language outside of Godot, it's like a more awkward wannabe Python without many of Python's useful features, and outright frustrating features like "pass" and funcref and not actually being able to type-hint signals.
To each their own, but I've never enjoyed using GDScript, which is unfortunate because the framework itself is amazing.
Re: It’s time to make that indie C# game in Godot
#43Earlier quoted context omitted.
I use it on macOS and Windows, and it is lovely! I even have Steamworks.NET integrations working on both platforms with it. It can be a bit tricky to setup the `.csproj` correctly to resolve native dependencies, but not anything impossible.
Thanks, can you suggest resources that would be useful in seeing up on macos?
You can also look at the way that project itself is setup, and the `.csproj` files. If you need more help, feel free to join our Discord (link in the blog)!
Re: It’s time to make that indie C# game in Godot
#44> Devs not baking monetisation into the creative process are “fucking idiots”, says Unity’s John Riccitiello
https://mobilegamer.biz/devs-not-baking-monetisation-into-th...
If he talks in public like that, imagine how this guy talks to his employees behind closed doors...
Re: It’s time to make that indie C# game in Godot
#45That's my biggest complaint with Unity at this point. So much is built around the GameObject implementation that when you start using ECS you can feel the friction - you're writing a lot more code, you're doing things in a way that feel like swimming upstream, and there's less support + documentation.
How does Godot compare? Are highly threaded features out of the box? I would use Unreal but the C# Unreal interfaces I've seen are very immature.
Re: It’s time to make that indie C# game in Godot
#46Earlier quoted context omitted.
The quoted statement is 100% accurate. Unity is very slow. When I worked on Unity with a larger project, I'd often have to wait 10+ seconds for Unity to rescan the entire project every time I switched windows from my IDE to Unity, or every time I ran the project. In similar project sizes, Godot was always lightning fast. > Godot looks like Unity from 2008, it's easy to boast efficiency when you have a limited product…
As someone who uses Unity professionally to make a 2D game, here are some key areas I find godot lacking vs unity: - Scalable text support a la TextMeshPro (sdf-based rendering) - the in-editor console is horrible. it frequently tells me "output overflow, print less text!". wtf? also, it doesn't let me click on a line to jump to the code - the built-in tile editor is very painful in my experience. the UI is clunky an…
> Scalable text support a la TextMeshPro (sdf-based rendering)
Someone in our Discord recently found a way to scale their project UI correctly according to screen DPI, not sure if that solves your problem or not. Their project is also open source: https://github.com/derkork/openscad-graph-editor
> - the in-editor console is horrible. it frequently tells me "output overflow, print less text!". wtf?
That can be solved by upping the debugger output limit in your project. (https://github.com/chickensoft-games/go_dot_test/blob/1fb342...)
Re: It’s time to make that indie C# game in Godot
#47Yes indeed, it's time to move from Unity to something else because I don't want to pay for that kind of people's salary: > Devs not baking monetisation into the creative process are “fucking idiots”, says Unity’s John Riccitiello https://mobilegamer.biz/devs-not-baking-monetisation-into-th... If he talks in public like that, imagine how this guy talks to his employees behind closed doors...
Nobody tries to hide anymore that a lot of game companies just create skinner boxes
Re: It’s time to make that indie C# game in Godot
#48Earlier quoted context omitted.
The quoted statement is 100% accurate. Unity is very slow. When I worked on Unity with a larger project, I'd often have to wait 10+ seconds for Unity to rescan the entire project every time I switched windows from my IDE to Unity, or every time I ran the project. In similar project sizes, Godot was always lightning fast. > Godot looks like Unity from 2008, it's easy to boast efficiency when you have a limited product…
As someone who uses Unity professionally to make a 2D game, here are some key areas I find godot lacking vs unity: - Scalable text support a la TextMeshPro (sdf-based rendering) - the in-editor console is horrible. it frequently tells me "output overflow, print less text!". wtf? also, it doesn't let me click on a line to jump to the code - the built-in tile editor is very painful in my experience. the UI is clunky an…
Agreed, this could be better.
> the in-editor console is horrible. it frequently tells me "output overflow, print less text!". wtf? also, it doesn't let me click on a line to jump to the code
Agreed.
> the built-in tile editor is very painful in my experience.
Agreed, but I hear it's better in 4.0
> the built-in text editor is _very_ basic
Actually, I disagree here. Fuzzy find, quick open, search in files, and autocomplete all work and are blazing fast. It is missing some things like a decent Vim mode, I'll admit. However, I tried both using vscode and the godot text editor, and I found that you saved so much time by not having to jump between IDE and Godot that it actually made up for a few of the more minor deficiencies.
> gdscript's heavy reliance on "magic" strings and lack of type-safety throughout
Agreed, but this improves in 4.0.
> unity's UI system sucks, but it's still more capable than Godot's especially for things
I honestly find Godot's workable enough. With Unity I would get into stupid issues because it was scaled 1000x larger than my game (who in their right mind thought this was a good idea?!?). Also, I remember Unity having 3 different modes for their UI, all of which were confusing and counter intuitive. Godot's UI is simple enough to hack.
Re: It’s time to make that indie C# game in Godot
#49Yes indeed, it's time to move from Unity to something else because I don't want to pay for that kind of people's salary: > Devs not baking monetisation into the creative process are “fucking idiots”, says Unity’s John Riccitiello https://mobilegamer.biz/devs-not-baking-monetisation-into-th... If he talks in public like that, imagine how this guy talks to his employees behind closed doors...
"mobilegamer.biz" is betting on you not reading before getting outraged, and it looks like that paid off.