Live data from Hacker News

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

jolexxa.medium.com

91–100 of 228 posts

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

#91

I feel like now is a terrible time to use C# in Godot, since they're (AFAIK) switching from Mono in 3.X to .NET Core in 4. I love Godot and I use .NET in my day job, but I feel like C# in Godot has always been a second class citizen.

What's wrong with .NET core? It's the future of .NET afaik and it has multiplatform support and it's open source.

> .NET (Core) -- A cross-platform and open source implementation of .NET, rethought for the cloud age while remaining significantly compatible with .NET Framework. Used for Linux, macOS, and Windows apps.[0]

[0]: https://docs.microsoft.com/en-us/dotnet/core/introduction

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

#92
post #45

Unity is suffering because it can't find a way to make DOTS/ECS first class without completely redoing basically everything. That'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 + documen…

This might be of use: https://godotengine.org/article/why-isnt-godot-ecs-based-gam...

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

#93

People are overreacting to Unity's acquisition (technically a merger) of ironSource and Riccitiello's comments on monetization. Many developers want to make money from their games, so I think it's positive and worthwhile for Unity to give them tools to do that. As for Unity's market cap, the market as a whole has taken a beating over the past few months. As someone who works with Unity and sees the enormous value it…

[deleted]

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

#94
post #72
post #63

Earlier quoted context omitted.

> How does Godot compare? Are highly threaded features out of the box? Ish. But Godot very much embraces OO. Everything is a node extending another node with messages passed between. But IMO it's OO done right.

OO doesn't matter if you want to simulate 100k objects at once without slowdowns.

And how many games actually do that?

Also, if you really want, with Godot you can bypass the scene node system and also just use C++.

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

#95
post #66
post #45

Unity is suffering because it can't find a way to make DOTS/ECS first class without completely redoing basically everything. That'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 + documen…

If you're doing high-end 3D stuff, Godot 3.x will probably disappoint you anyway. If you're doing graphically simple games with a complex simulation under the hood (everyone loves RimWorld as an example), then you don't really benefit from an ECS that's tightly integrated with the engine. You just do all that stuff however you want, and use the engine as an I/O layer.

> If you're doing high-end 3D stuff, Godot 3.x will probably disappoint you anyway

Maybe 3.x, but I've seen/read some exciting stuff about 4.0's graphics engine

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

#96
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.

Blender was already a well-developed product before it was bought collectively (crowdsourced) and made a Free Software project.

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

#97
As much as I'd like to use Godot, there are two features missing that I really don't think I could do without:

- Asset store. I totally get it, handling payments, curating, etc. are a huge task... but man, I'm a coder, and I don't have the funds to pay an artist or a musician full time. Being able to just go buy a pack of trees for $20 or something is a huge timer saver.

- Animation re-targeting. It seems like there's a 3rd party plugin for this but it also seems like it hasn't been updated in a year. In unity I can buy a big pack of animations for pretty cheap and reuse it on almost all my humanoid characters. That's huge. I think this can be done in Blender or Maya, but it's so seamless in the engine compared to using a 3rd party tool.

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

#98
I've been using Godot for hobby projects on-and-off for a while now, and overall I vastly prefer it to Unity. The scene hierarchy of Godot is a better mental model (for me) than the GameObject/MonoBehavior ever was.

That said, I have a _few_ items that I think are absolute showstoppers for solo-dev side projects.

1. The asset pipeline is simply not as clean as Unity's. The ability to drop a .blend file in the project in Unity is so underrated. In Godot FBX imports are unreliable, texture imports misbehave frequently, and rigging goes wrong even in the recommended file formats. There's a lot less clarity around the path to getting real assets in game, which can be a major pain point for solo devs.

2. Along the same lines, there is no equivalent of Unity's mecanim. With Unity, if you can model and rig a character in Blender, you can pull free mocap or other animations from the asset store and get to work. In Godot you're still best off authoring your own animations for each character. This drastically increases the amount of time spent making assets.

3. Godot is in a weird spot version wise for anyone who wants to use C#; the beta version of 4.0 is rapidly approaching, and guarantees to break any project you start in 3.x --- but 4.0 still doesn't come built with C# support. Hopefully this gets resolved soon.

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

#99

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

I switched to Unreal after using Unity for many years, both at my day jobs and as an indie. If I had known what it is actually like to work in Unreal, rather than how the grapevine vaguely typecasts it, I would have switched a long time ago, or more likely never used Unity in the first place. Unreal is a delight.

It's unfortunate that Epic ever let Unity persuade people that it's better suited to anything or anyone at all.

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

#100
post #91

I feel like now is a terrible time to use C# in Godot, since they're (AFAIK) switching from Mono in 3.X to .NET Core in 4. I love Godot and I use .NET in my day job, but I feel like C# in Godot has always been a second class citizen.

What's wrong with .NET core? It's the future of .NET afaik and it has multiplatform support and it's open source. > .NET (Core) -- A cross-platform and open source implementation of .NET, rethought for the cloud age while remaining significantly compatible with .NET Framework. Used for Linux, macOS, and Windows apps.[0] [0]: https://docs.microsoft.com/en-us/dotnet/core/introduction

I think gp is saying that since it switch from mono to core before you will be able to finish a game, you might have a bad time when they switch implementations.
Post reply on HN