Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It’s time to make that indie C# game in Godot

jolexxa.medium.com

Post reply on HN
Print view View original

31–40 of 228 posts

Re: It’s time to make that indie C# game in Godot

#31

Post by danbolt »

kevingadd wrote: post #19
bluefirebrand wrote: post #18

Earlier quoted context omitted.

I love working with Godot but I can't help but feel like GDScript is a mistake. I want better language support and community when working on a project. I want to use nice VSCode plugins that auto format my code (and give type hints... Untyped languages hurt me so much these days) I can't wait for better C# integration for Godot. It's ok now but I'd love it to be rock solid.

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.

Re: It’s time to make that indie C# game in Godot

#32

Post by BoorishBears »

Entinel wrote: post #5
pipeline_peak wrote: post #2

> It’s no secret that Unity is painful to use: it’s slow to open, and it often pauses to re-scan the entire project while you’re trying to work Is this actually true? I always figured Unity's selling point was being lighter and easier to use than unreal. Godot looks like Unity from 2008, it's easy to boast efficiency when you have a limited product.

Anyone who used Unity 2.x in 08 would tell you Godot is far beyond where Unity was in 2008 in terms of features and stability.

As someone who did I'd say it's a silly comparison. Godot has a decade of advancements in technology on Unity 2.x, things are generally "nicer" than when Unity started

Re: It’s time to make that indie C# game in Godot

#33

Post by thrillgore »

johnfn wrote: post #6
pipeline_peak wrote: post #2

> It’s no secret that Unity is painful to use: it’s slow to open, and it often pauses to re-scan the entire project while you’re trying to work Is this actually true? I always figured Unity's selling point was being lighter and easier to use than unreal. Godot looks like Unity from 2008, it's easy to boast efficiency when you have a limited product.

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…

The only real FUD that has any basis is 1) The lack of good 3D support and 2) DOTS style architecture. These are things the community is addressing now for future releases.

The 3D support will be significantly overhauled in 4.x https://www.youtube.com/watch?v=DNJXkcQxXEg and additional enhancements will reduce the need for DOTS/ECS for many. There's also Godex https://github.com/GodotECS/godex that adds ECS to the engine.

Re: It’s time to make that indie C# game in Godot

#36

Post by bluescrn »

bluefirebrand wrote: post #25
kevingadd wrote: post #19

Earlier 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.

I do wonder if integrating C# is more effort than building and maintaining a language though. But I do understand it. I just am not sure it's a good strategy for longterm growth.

Pushing people towards a non-standard scripting language is definitely not a strategy for long-term growth.

It needs a widely-known language with good performance and high quality debugging support (you can use the Visual Studio debugger with Unity C# or UE C++, for example)

Re: It’s time to make that indie C# game in Godot

#37

Post by jolexxa »

pleb_nz wrote: post #35

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.

Re: It’s time to make that indie C# game in Godot

#38

Post by singhrac »

Mattish wrote: post #21

The problem with Godot is still it's age, and the lack of proven projects which many people are working on at once. Myself and plenty of others at small or above size studios would have to make a huge leap into Godot and hope you don't run into any scaling issues. Not just from a project point of view, but integration on the artistic side. LTS versions of Unity despite the known "un-fun" of it, are stable in a sense.…

Do you think Blender overcame this challenge, or is it still a sticking point in the VFX industry? I know they're at very different levels of maturity but I'm curious if the open projects ended up helping with ironing out these kinks.

Re: It’s time to make that indie C# game in Godot

#39

Post by aroman »

johnfn wrote: post #6
pipeline_peak wrote: post #2

> It’s no secret that Unity is painful to use: it’s slow to open, and it often pauses to re-scan the entire project while you’re trying to work Is this actually true? I always figured Unity's selling point was being lighter and easier to use than unreal. Godot looks like Unity from 2008, it's easy to boast efficiency when you have a limited product.

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 and it's lacking important features I depend on in Unity, like tile rules.

- the built-in text editor is _very_ basic, and support for external editors is limited vs Unity (and hampered by lack of mature tooling for gdscript vs C#)

- gdscript's heavy reliance on "magic" strings and lack of type-safety throughout

- unity's UI system sucks, but it's still more capable than Godot's especially for things

Re: It’s time to make that indie C# game in Godot

#40

Post by marcodiego »

Some excerpts:

> At first glance, Unity is so laughably ahead of Godot in sheer number of features supported that it seems comical to compare the two.

> In practice, Unity requires 3rd party tools for tweens, timers, and networking, all of which Godot includes out-of-the-box. Still, I’d argue that it doesn’t actually matter for the vast majority of us indie game developers.

Post reply on HN