It’s time to make that indie C# game in Godot • Hacker News Board

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

#21

Post by Mattish » Thu, Jul 14, 2022, 4:33 PM UTC

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. Godot is moving fast, that isn't always a good thing for stability.

I'd love to jump on the new shiny and fun engine! But having to make the definitive choice for a company to make their next project in? Unfortunately just isn't there yet. "It's fun as a dev" just isn't a compelling argument for literally everyone else who isn't the engineer, compared to the number of all size studio pumping out Unity projects(Some even being successful!).

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

#22

Post by sfteus » Thu, Jul 14, 2022, 4:34 PM UTC

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.

Anecdotally, there's something about Godot's structure that just "clicks" better for me. It's odd because they seem pretty similar on the surface (nested scene graph, nodes with scripts that have hooks, etc), so it's hard to determine what exactly makes it easier to understand.

The only two concrete things I can point to are better documentation (IMO), and the first-class signal/observer support in Godot. I'm not sure if that exists in Unity or not, but it's a really intuitive way to handle entity interaction, and I think that makes it way more easy for beginners to get started.

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

#23

Post by Uehreka » Thu, Jul 14, 2022, 4:42 PM UTC

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.

It is outrageously painful. Half of the craft of working in Unity is knowing which kinds of operations will trigger a 15 minute re-import and basically scheduling your day so that you have other things you can do while that’s happening. It doesn’t happen every day or every time you open a project, but sometimes you’ll be looking at your master branch in git, and then you go to check out a branch where something big has changed, and then you alt-tab back to Unity and… time to go make a fresh pot of coffee.

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

#24

Post by BlargMcLarg » Thu, Jul 14, 2022, 4:46 PM UTC

sfteus wrote: post #14

BlargMcLarg wrote: post #10

C# hasn't been an issue for me at all bar a few oddities. Some things not working properly in C# (think some plugins or something back a while ago). Some code not directly mapping from GDScript to C#, causing huge object count issues. For reference, I've been using it since 3.1 in a hobby context. Really, it's not the developers you have to worry about. It's everyone else. Godot is made with developers in mind, but t…

> If you can't map things one to one from a different program or close to that through a plugin I've only used Godot in a hobby context, but the full on C# support compared to other engines is pretty amazing. Just as a proof of concept I imported an open source C# library I've worked on that's designed to play old DOS music formats, created a small wrapper node with control functions, and I was able to control it as…

Yeah, that works well. Most libraries do work depending on target platform. With C#, you can write your entire logic outside Godot and just use Godot as a graphical interface if you so desire.

But that's the point. We're discussing things from a developer point of view. This happens almost every day by now. That's not the issue. The issue is how everyone else struggles with Godot compared to Unity, if at all. When even basic particle patterns require diving into shader logic in 3.4 or loads of trial and error, that's a pretty hard sell for non-technical people.

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

#25

Post by bluefirebrand » Thu, Jul 14, 2022, 4:48 PM UTC

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.

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.

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

#26

Post by jayd16 » Thu, Jul 14, 2022, 4:51 PM UTC

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…

Are you comparing apples to apples with similar sized projects? I'd be curious to hear about larger Godot projects.

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

#27

Post by curioussavage » Thu, Jul 14, 2022, 5:05 PM UTC

I was really tempted to try out the c# support but I opted first for the rust godot bindings and then the nim bindings. Nim is working fantastically. I was a bit worried because the bindings are not really actively developed but from my experience so far I think they just don't need much work.

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

#28

Post by jpeter » Thu, Jul 14, 2022, 5:10 PM UTC

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…

I recently tried out unity with this tutorial https://www.youtube.com/watch?v=_Pm16a18zy8 and imported a sprite map. It took like 10 minutes to load. No idea why it takes so long

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

#29

Post by spywaregorilla » Thu, Jul 14, 2022, 5:13 PM UTC

Zhyl wrote: post #3

With 4.0 getting more and more advanced features [0] and Unity merging with an Ad company [1], Godot is looking like it could be an attractive proposition for a lot of Unity shops. [0] https://news.ycombinator.com/item?id=32003065 [1] https://news.ycombinator.com/item?id=32081051

Unity is already an ad company

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

#30

Post by jayd16 » Thu, Jul 14, 2022, 5:20 PM UTC

Hopefully the async/await story gets fleshed out. Unity just made the default scheduler run on the main thread. That's pretty much all it takes but it would be nice if it was built in.