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

101–110 of 228 posts

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

#101

Post by overgard »

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's very true; I remember one game I was working on, when you pulled down the code and new assets it'd take a long time to rebuild the "Library" (which is not something you can check in). And sometimes, if your version of the project was acting wonky and everyone else was fine, the solution was to delete the Library and rebuild it from scratch. If you were doing it from scratch, it could take hours. They've made some improvements but it's still a mess.

The editor itself always seems very buggy. If you have the "Console" open (which you will if you're coding), it's pretty much guaranteed you're going to see a lot of random errors that have nothing to do with even your code. A lot of them don't even make sense or could be ignored. Like you'll get weird asset import errors if you upgrade versions, but a lot of times they're just red herrings and not important. There's also a lot of QOL stuff that's very frustrating, like arrays being annoying to edit (I'm not sure if they've fixed this yet or not). It's also easy to accidentally brick your editor on your own, with debugger shenanigans or loops that don't end.

Also, if you're trying to build a an editor extension, omg was that a nightmare. Just getting things like Undo/Redo and object serialization working correctly are difficult and in some cases impossible. And frankly, you need extensions for a lot of things to actually be useful, like until recently the builtin terrain editor was basically useless, and you have things like Odin because the builtin inspector is a nightmare.

There's a lot to like about Unity, but there's also a huge amount of pain points with it.

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

#103

Post by wilg »

throwaway675309 wrote: post #78
wilg wrote: post #65

Ugh, not more C#! I hope one of these projects takes off: https://github.com/migueldeicaza/GodotSwift https://github.com/kelvin13/godot-swift Excited to try Godot in a couple of years when it's more mature. Hopefully they can be the Blender of game engines – where it started rough and now is better than Maya or other alternatives.

Do you have an actual specific disagreement with c# or are you just venting because you are not familiar with the language? C# is a robust language with a lot of features like lambdas pattern matching etc. I also find that most of the people who know Swift are Apple developers, so I feel like there isn't a broad enough appeal especially for game devs who are going to be more Windows or Linux centric.

Yes, I know C# reasonably well. I use it in Unity for game development, where it is the only option.

C# is better than many alternatives, but Swift is simply a better language in every regard.

C#'s GC is a constant issue for games, and it makes using things like LINQ nearly impossible since it does so much allocation. Swift is designed around automatic reference counting instead. C#'s structs work weirdly and are hard to use.

Swift is so much more ergonomic. C# has added a few nice things lately, but it's much more verbose than Swift.

Swift is also more focused on performance, and is always AOT compiled.

Unity has had to come up with some insane things to get C# to work across platforms – they have their own .NET IL to C++ compiler (https://docs.unity3d.com/Manual/IL2CPP.html) that doesn't always work right. They also have a SECOND custom C# compiler for high-performance programming (https://docs.unity3d.com/Packages/com.unity.burst@0.2/manual...).

I'm also very excited about Swift 6's upcoming opt-in Rust-like lower-level memory management which should help a ton for performance-critical code. (https://github.com/apple/swift/blob/main/docs/OwnershipManif...)

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

#104

Post by wilg »

ianlevesque wrote: post #74
wilg wrote: post #65

Ugh, not more C#! I hope one of these projects takes off: https://github.com/migueldeicaza/GodotSwift https://github.com/kelvin13/godot-swift Excited to try Godot in a couple of years when it's more mature. Hopefully they can be the Blender of game engines – where it started rough and now is better than Maya or other alternatives.

C# is really well suited to the task thanks to value types and structs, that gives you back control of memory that is lost in Java for example. It also has a lot of syntax sugar to avoid being too verbose and the memory safety and GC are desirable most of the time and can be avoided with well known tricks, like object pools, when performance needs are more paramount.

Swift is entirely designed around value types and structs, and has a much more predictable ARC model instead of GC for game programming. Plus, an upcoming feature will add Rust-style lifetimes for more control (https://github.com/apple/swift/blob/main/docs/OwnershipManif...).

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

#105

Post by wilg »

TulliusCicero wrote: post #82
weberer wrote: post #70

Earlier quoted context omitted.

Godot's default language is GDscript, which is similar to Python. I'd highly recommend that to new people switching to Godot. I think C# is just cruft for people coming from Unity and stuck in old habits/frameworks.

I tried GDScript and hated it, ended up manually porting what I wrote to C#. GDScript currently only has partial support for static typing, which makes things a much bigger pain in the ass. Using C# was a breath of fresh air after that.

Yeah, I don't want a weird scripting language like Unreal Blueprint or GDScript or Lua. C# beats all of those by a mile. I want a robust, ergonomic, high-performance, compiled language like Swift.

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

#106

Post by wilg »

overgard wrote: post #83
ianlevesque wrote: post #74

Earlier quoted context omitted.

C# is really well suited to the task thanks to value types and structs, that gives you back control of memory that is lost in Java for example. It also has a lot of syntax sugar to avoid being too verbose and the memory safety and GC are desirable most of the time and can be avoided with well known tricks, like object pools, when performance needs are more paramount.

I don't know Swift very well, but I seem to recall the creator talking about using automatic reference counting instead of garbage collection as an intentional tradeoff. If that's still the case, I'd much rather use Swift over C# in a game (and I am using C# in a game!). The value types and structs are very limited compared to classes and reference types.

Yes ARC is definitely an intentional and well-chosen tradeoff. Swift has real first-class value types (strings, collections, etc are all value types) and copy-on-write semantics that make it all work quite well. C# value types feel like they are funkily bolted on and aren't really very useful in practice (at least in Unity).

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

#107

Post by jayd16 »

wilg wrote: post #103
throwaway675309 wrote: post #78

Earlier quoted context omitted.

Do you have an actual specific disagreement with c# or are you just venting because you are not familiar with the language? C# is a robust language with a lot of features like lambdas pattern matching etc. I also find that most of the people who know Swift are Apple developers, so I feel like there isn't a broad enough appeal especially for game devs who are going to be more Windows or Linux centric.

Yes, I know C# reasonably well. I use it in Unity for game development, where it is the only option. C# is better than many alternatives, but Swift is simply a better language in every regard. C#'s GC is a constant issue for games, and it makes using things like LINQ nearly impossible since it does so much allocation. Swift is designed around automatic reference counting instead. C#'s structs work weirdly and are har…

Sounds like you mostly just don't like what Unity has needed to do over the years with the Mono runtime, not the language.

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

#108

Post by wilg »

binarynate wrote: post #54

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…

I tend to agree, but I do really worry about Unity's technical roadmap. There are so many half-baked systems that rarely get updates, 3 confusing choices of render pipeline, and there's not robust well-utilized implementations of common gameplay elements like Unreal has.

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

#109

Post by wilg »

wilg wrote: post #103
throwaway675309 wrote: post #78

Earlier quoted context omitted.

Do you have an actual specific disagreement with c# or are you just venting because you are not familiar with the language? C# is a robust language with a lot of features like lambdas pattern matching etc. I also find that most of the people who know Swift are Apple developers, so I feel like there isn't a broad enough appeal especially for game devs who are going to be more Windows or Linux centric.

Yes, I know C# reasonably well. I use it in Unity for game development, where it is the only option. C# is better than many alternatives, but Swift is simply a better language in every regard. C#'s GC is a constant issue for games, and it makes using things like LINQ nearly impossible since it does so much allocation. Swift is designed around automatic reference counting instead. C#'s structs work weirdly and are har…

@jayd16 No, they have dropped the Mono runtime for many cases (which causes some of the problems). The language itself is simply much less pleasurable to program in than Swift, and performs worse in key areas.

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

#110

Post by berkut »

debacle wrote: post #72
Mikeb85 wrote: 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.

ECS on its own doesn't always help - it's not a magic bullet for every situation: sometimes you need to use spatially-aware data structures / acceleration structures for those type of "queries", and vanilla ECS (i.e. similar to a DB in terms of queries) doesn't always help you in these type of situations.
Post reply on HN