Unity 3D shitshow

[alCannium27]

This intense focus on GDScript is bikeshedding when you know ALL these other language options are available within it. Godot has quite a number of very real issues, but GDScript and wider language support isn't one of them. The people who complain about this are whining and bitching when you can learn the language syntax in an hour(learning the library, all the components available, engine behaviour etc takes a lot longer). Quit bikeshedding on the language and learn it or use a supported language. A lot of programming languages don't have real world usefulness either(Forth, Smalltalk, Lisp, Scheme... Javascript if I want to be a contrarian).

Nah, GDnative is not a user friendly option to code, just because it supports it, doesn't mean it will be helpful for expanding the engine's reach. Learning a new engine already takes a lot of time, switching from Unity to any other engine already creates overhead, no indie studio can afford to waste even more time trying to figure out a new scripting language.
One ought to call a shit bike a shit bike when the bike is shit, any of the popular, well-taught coding languages is times better than GDScript, it should be C++, C#, hell, even Java that's supported in the UI's editor, not GDscript.

 

[RisingThumb]

One ought to call a shit bike a shit bike when the bike is shit, any of the popular, well-taught coding languages is times better than GDScript, it should be C++, C#, hell, even Java that's supported in the UI's editor, not GDscript.

Java is a terrible alternative due to the Garbage collector. You know this if you tried to use Java for games programming. I think you insinuate this, but you don't properly know how performance degrades due to this.
Just because something is popular or widely taught, does not make it good. Javascript should be proof alone.
Look at the reasons why you'd want to use GDScript for games programming.
C++ and C is slower to get to an initial prototype. C# is less readable as you're carrying a bunch of Object oriented cruft in the same way as Java(not nearly as bad, but still pretty nasty).

One ought to call someone out for talking out their ass, if they're talking shit about something they have no skin in the game for. The shit on the bike? That's your shit. It's plain you haven't used Java or Python or GDScript or C++ for any games programming and when you use any of these, you'll see each of their deficiencies.

 

[no_chill]

Pay up Goyim!

 

[Collision]

switching from Unity to any other engine already creates overhead, no indie studio can afford to waste even more time trying to figure out a new scripting language.

well-taught coding languages is times better than GDScript, it should be C++, C#, hell, even Java that's supported in the UI's editor, not GDscript.

I agree, it would have been better for Godot to be centered around a standardized programming language. I think the rationale behind GDScript's existence is questionable at best. Actually, I think Epic is generally right about just doing everything in C++ anyway. GDScript isn't that hard to pick up though. Any software developer who can't pick up and write effective code in GDScript in one to two weeks is probably not worth paying.

This attitude is self-defeating anyway. It's exactly how you get locked-in to an environment, like Unity, where you have no control over your own products. Software developers who have been banking on Unity staying cheap-ish and royalty-free are guilty of luxuriating in an unsustainable practice. During the time where Unity was viable for them, these developers should have made an effort to build their own technology or contribute to free technology. Most, obviously, never did this and will now have to pay their debts in one way or another. Everyone gets what's coming to them eventually.

Now that many developers want to change to Godot, there will be lots of demand to ease that transition. How many people will contribute work to achieve it though? How many people will employ developers to achieve it?

 

[RisingThumb]

I agree, it would have been better for Godot to be centered around a standardized programming language.

Which language do you think fits the bill best?

For me, I think it's a tossup between Go, C# and Lua. C# has runtime overhead problems, and too much syntactic sugar. Go has too much syntactic sugar and a garbage collector, though the latter can be disabled(but then you run into memory management discussions). Lua might be a decent choice. I know often people write engine code in C/C++, and game code in Lua(teleglitch, GMod).

How many people will employ developers to achieve it?

This is actually a really interesting point. Can you elaborate what they'd probably be employed for in switching engines from Unity to Godot?

 

[Collision]

Which language do you think fits the bill best?

C# seems like the obvious choice only because of how popular it is with game developers already. Lua is another good choice but isn't standardized. I think it's worth it, in the long term, to prefer a standardized language. Go, Rust, and other languages that are tied up in one organization without a standard document seem like dangerous choices to me. None of this has to do with functionality though. It's just about how much influence some other person has in screwing you over.

For standardized choices I would suggest: C#, JavaScript, or Ruby.
For non-standardized choices would I would suggest: Lua or Python.

Can you elaborate what they'd probably be employed for in switching engines from Unity to Godot?

I don't have any specific ideas in mind. I'm just saying Godot can be modified to make transitioning from Unity easier. My question is how many organizations, of the current crop of organizations looking to transition, are willing to pay someone to work on Godot for them? It's easy to say things like, "get to it open source devs." It's harder to commit your own resources to get the features you want. A lot of people want to use a deeply integrated development environment with lots of sophisticated tools to make their products. Far fewer people want to extend any effort to make those tools.

This is different from financially supporting the development of Godot itself. Supporting the development of Godot financially doesn't mean you get to make requests of any particular person working on the project.

Anyway, I'm not an expert on what Unity Engine aficionados would like Godot to do so I can only speculate about what they would employ someone to change Here are some ideas though:

• Add better support for C# to Godot's GUI editor (this is what @alCannium27 was talking about).
• Add better support for inverse kinematics (I've heard this is a pain point, but I don't know personally).
• Add a Unity-style compatibility layer to make it easier to convert Unity scripts to Godot scripts.
• Add modules to Godot to support various proprietary file formats.
• Implement functionality provided by specific Unity packages for Godot.
• Fix specific project blocking issues with Godot that aren't receiving attention from core Godot developers.

 

[maskedwallaby]

Still a lot cheaper than using Unreal engine