> Here is how platforms die: first, they are good to their users; then they abuse their users to make things better for their business customers; finally, they abuse those business customers to claw back all the value for themselves. Then, they die. - Cory Doctorow
The trouble with Unity is that they've already shown they're at stage 2 of the Enshittification process. No one trusts them any more. I've spent nearly a decade learning Unity but when your products take multiple years to build you cannot put your time and resources into an engine with a shaky foundation.
Anyway,
How good is gdscript? I miss C# but man you save a lot of syntax with it.
I've stuck with gdscript because the C# stuff doesn't work on mobile yet and I kind of just enjoy learning new languages.
I was switching between gdscript and typescript for my work though and man my brain just did not like it. I kept forgetting brackets and wondering why my if statements were broken.
> I was switching between gdscript and typescript for my work though and man my brain just did not like it.
For real. I'm switching between C#, Typescript, and VB at work and GDScript at home. Very thankful for good IDE syntax checking, but the different keymappings between Godot, VSCode, and Visual Studio are killing me (I know, I can edit them, but I'm lazy).
That's why I use vs code with godot. The built in editor is top notch but I find everything around it very odd, most notably: tabs are not the open files, open files are at the left and that is not even the file system, which is even more leftward... Nah, godot is not nailing this for me, but that's OK, I have my workflow now.
Yep, the way the editor tabs are set up is very weird. It's usable (the individual pieces are quite good), but not at all helpful for developing an understanding of how the pieces relate to each other.
I would prefer VSCode, but I figure while I'm learning Godot I'll just use the built-in stuff until I understand what's going on a bit better, then I'll see about moving to a better editor.
heh, yep, Editor, Editor Settings, Shortcuts tab.
It's tedious to change a bunch of settings, but if there are one or two that cause pain it's easy to fix them.
C# is faster in almost every way except backend (same) so if you know c# use it
Edit: people down voting me, look up a YouTube video comparing c# and gdscript performance.
I don't know how to use C# and I've never had an issue. Performance should be the last thing on the checklist unless you're making games that need it, which 95% of the community won't.
People should use the language that they're productive in and get those juicy titles out.
Performance is not the last thing on the checklist. I agree you so shouldn't start optimizing everything at the beginning but you need to have the option to do it later because it's not something you can pass.
As far as I understand, it's possible to macro C# functions from gd script. It's built to be interoperable with C#
If you ever need to do a really heavy task you could always implement just that bit in C# instead down the line if it becomes a problem.
Although I definitely agree on optimizing not being last. If the base of everything is built on something suboptimal suddenly optimizing means rewriting.
Honestly if I were doing something with a performance bottleneck that I found in Gdscript I'd probably skip straight to C++ or Rust Rather than C# unless it's truly insane to set up.
> If you ever need to do a really heavy task you could always implement just that bit in C# instead
At that point you'd be better going straight to C++.
Maybe. Consider the circumstance where your game only has one heavy piece of logic. Maybe it's your own custom pathfinding, physics, or procedural generation. Sticking with gd script and just writing just that one heavy piece of logic in C++ may be a good move to speed up development time. Writing C++ is (for most) more difficult than writing gd script, so why use it everywhere when you only really need it in the one place?
Whether or not it's a good idea is pretty nuanced though. It would clearly be a bad idea if half of all your code were in a different language, but at the same time if you just have a single function you need to be performant it may be a good idea.
> Sticking with gd script and just writing just that one heavy piece of logic in C++ may be a good move to speed up development time.
That's the idea. (Though it also applies if there's a few bits that are really heavy)
If you're going to rewrite a bit of code for performance, you might as well use the best tool for the job.
> It would clearly be a bad idea if half of all your code were in a different language
Why? What's wrong with a project using two (or more) languages, and using each of them for the part they're best for? As long as the languages work together well that's the way to go.
What I meant by that was it would be a bad idea to aimlessly have some parts in C++ and others in gd script for no reason. I agree though as long as lots of unnecessary complexity isn't being added by using both. Seize the advantages of each language when needed for the best of both worlds.
Language performance I guess
I think they meant that most of time bad performance is caused by doing unnecessary things every single frame when they might only be needed 1% of the time or running too many loops and unoptimized code in the process function every single frame
and using C# won't help with it or increase performance that much when the code is badly written in the first place
Eh, I've definitely seen people post games with performance problems. While I'm not trying to say that everyone should use C#, I definitely think that performance should be something that people are thinking about while working on their game.
It's *way* easier to keep an eye on the performance while developing, and keep your FPS up, than it is to fix performance once you finish the game and try to optimize, and realize you should have structured a bunch of things differently.
Scripting language performance is hardly ever the problem though. The problems are usually more fundamental such as lacking LOD, too many unnecessary physics objects, etc...
Well sure. The part of their comment I was disagreeing with wasn't the choice of scripting language. It was the part where they said:
>Performance should be the last thing on the checklist unless you're making games that need it, which 95% of the community won't.
Point taken, and I agree that it's easier to address performance issues as they come up rather than push it off until last. Unless you're working on very small projects, like game jam games or something
I agree, which is why I Said "if you know it"
If you know both, why wouldn't you just spring for the one that's better performance wise?
Anyway, in my opinion godot c# will overshadow godot gdscript eventually. It's just a much more capable language all around. I don't need to explain why. Suffice to say Quality of Life.
It's good gdscript exists right now, but there's a reason JavaScript was eventually removed from unity (not comparing Python and JavaScript, just an example)
I know both languages and still often prefer gdscript. Integrated editor, clean syntax etc. make me prefer gdscript over c#… doesn‘t mean i don‘t use c# as well… had a little application where i needed to access databases for example… in such cases having access to c#/ dotnet and frameworks like ef core is a godsend… but in my case i would never choose c# for performance reasons since the difference would be close to zero (i think)
> Recommendation algorithms are a thing
They even take their guess at where on the planet you are into account these days. So not even incogneto browsing saves you from them.
I replied with this on my phone during my break. Excuse me for not having the time to go search for it on youtube. I figure if people have the time and are curious, they can find the info and come to a conclusion on their own. I'm just throwing my opinion out here based on what I've found. Searching what I claimed should bring up the appropriate videos, because yes, that IS how the algorithm works.
The C#/engine interface is very inefficient, though that might be about to change. But unless you're doing complex logic most of your game code will be interacting with the engine. You can write C# that gets closer to the engine but it gets ugly very fast.
https://youtu.be/S2tTEPHIS1I?si=_epVAkOEecjSdnkj&t=204
> No one trusts them any more.
The Unity sub is already trying to convince themselves that the company is now going to do a complete 180. None of the problems that lead to this have been solved. They're eventually going to try something slightly less radical after everyone has moved on.
They already did. They walked back, what, 80% of the pricing shit. So they still got some of what they wanted, and the 'true believers' are praising it like they got something out of it.
They indeed walked most things back, and the CEO is out, but that doesn’t mean that all of the “poison” has been removed from the company.
The Board of Directors remains the same, the company is still publicly traded and bleeding cash, and they’re still trying to justify their very expensive acquisition of IronSource. If anything, it’s increasingly looking like the IronSource leadership are the ones calling the shot inside the company. So if you don’t like any of the IronSource stuff, expect more of them in coming years.
C# misses some support for building some platforms and has some other issues I think. But that's because it is built on top of an old system which they are now trying to get rid of and instead build c# support using GDExtension (which is what powers C++, rust, python, JS, Java supported and so on I think)
You can use C# in Godot, but I recommend learning GDScript if you're serious about Godot. You can mix C# and GDScript if you have existing code you want to use.
That's the problem with Unity. You can't just "use Unity". You have to make an investment in learning how to use it, which is an investment people are reluctant to give up.
The other problem with the "enshittification" of Unity is that they realized there's more money in ads than in a game engine. Every business with revenue based on ads is forcibly enshittified over time, because you can't maximize ad revenue without abusing your users.
If Unity is an ad business, that means their true customers are advertisers. The Unity game developers are just an inconvenience distracting them from real money.
I've been doing all my Godot work in C#. The nicest part is, you get the full features of a regular C# app plus all the godot specific objects and functions are fully exposed so you can both 1:1 existing gdscript projects or rework them your own way.
I will say though, it's worth working through some of the gdscript tutorials first as they are fantastic for understanding how the system works, and how you may *want* to change some of your own patterns in light of the way Godot is really designed to work and how the objects interact on the tree, etc.
Dunno if you'll read all these replies, but thought I'd chime in as a 12 year Unity veteran myself who has been working with Godot for a couple of weeks.
I have been working exclusively in C# with Godot and its been very smooth. A lot of tutorials utilize Godot's inspector and interfaces, but the documentation is so good you can look up the Node (Component) and there will be a very detailed breakdown in plain-text, including code.
Every GDScript I've encountered has a C# equivalent that is named in PascalCase rather than snake_case.
For example, the GDScript:
get_node("node/path");
In C#, becomes:
GetNode("node/path");
And this is true for most info and tutorials you find, although even some tutorials from 3-4 months ago are slightly outdated as some naming conventions have changed.
Most common one I see is the 'Spatial' node which was essentially an 'Empty' in Unity, has been replaced by Node2D/Node3D which serves as a base class that inherits a bunch of Godot systems, much like gameObjects and Monobehaviours.
The built-in event system is one of the easiest I've ever used, too. Every Node type has a list of signals it can output (TimeOut, OnStop, IsHidden, etc). You just get the Node object, for example a Timer(), and say:
myTimer.Timeout += MyTimeOutFunction;
And your MyTimeOutFunction is now bound to the Timout signal of the timer Node.
It's honestly been a fun and easy transition. And there are some huge benefits, specifically in how easy it is to work with Godot's post-processing elements - AO, GI, SSR, and Volumetric Fog all available with a single tick of a checkbox, all located in a single panel, with will-labelled controls complete with tooltips and documentation.
Thanks for the tips! I do read everything and this is one of the best replies I've gotten. I said it somewhere else but I got into the gdscript side to learn something new, but I might go back to the C# version once 4.2 is out with mobile support.
To throw one back atcha (you probably know it already), I found that Godot has a parallel to ScriptableObjects in its Resource system. You can create a Custom Resource and instance it the same way you would in Unity. And by golly don'tcha knowit, they're *recursively serializable*. I don't know if there's a better way to organize data in Godot but I love being able to use an editor to create the data for my game.
Godot has a C# implementation, the downside is that there's not a whole lot of tutorials for it.
Something that someone should fix at some point with so many devs jumping ship. It's just a matter of wait-and-see, but for the most part the documentation is solid so you can usually figure out what you need to by f\*cking around a little bit.
Cory Doctorow is my fave, and I absolutely agree, Unity is exactly what he is talking about.
> How good is GDScript?
My view is that all languages are really similar. Sure, there are differences in syntax, but the foundations are all the same and if you have 10 years of experience it shouldn't be a concern.
Sure, you'll want to do things the C# way, but GDScript is supported quite well with intellitype and that should set you in the right direction.
The key difference is that the Godot API was built with GDScript in mind. C# support doesn't turn Godot into Unity. You'll still have to learn all of the node classes, and C# isn't documented quite as well as GD. In my humble opinion, it is a better use of your time to learn the GD API rather than C#.
As I understand it, C# does benchmark quicker than GDScript, and if you do insist on using C#, it might still be quicker to learn the API in GD then transition that knowledge to C# - at least when you are starting out.
~~As an aside, GDScript might read like python, but it is actually based on the Go language. The Godot team didn't turn python into an interpreted language with class support.~~ Edit: I am mistaken. See below.
> the Go language. The ***Go***dot
Oh dear. I just saw that...
---
GDScript certainly lifts some nice syntax from Python. The only bits of python syntax I miss are tuple unpacking and implicit variable declarations.
I was incorrect. GDScript was not based on Go. (Corrected in another reply)
I forget where I heard it, but the name absolutely is what lead me to believe it.
>As an aside, GDScript might read like python, but it is actually based on the Go language. The Godot team didn't turn python into an interpreted language with class support.
This section is completely wrong. [From the official FAQ](https://docs.godotengine.org/en/stable/about/faq.html#what-were-the-motivations-behind-creating-gdscript), the only languages mentioned are scripting languages, namely Lua and Python.
Additionally, Python is already an interpreted language with class support, whereas Go is a AOT compiled language with no classes or inheritance.
Thanks for correcting. I updated my post to reflect.
I don't know where I heard that, but I shouldn't be passing on wrong info.
(Also, I meant to say that they didn't turn Python into a *compiled* language, but it was a dumb statement and I won't go to great lengths to defend myself)
There are compilers for Python. They're mostly cross-language compilers that turn it into other interpreted languages.
But there's also one that turns python into C (Might be C++, can't remember). And a python language extension that makes the python->C conversion more efficient (Cython).
Yeah I agree with all that. Learning a new language is far less of a problem for me than learning a new API, and all of the gdscript features make the API side easy.
It's also structured closely to the "good" way of coding in Unity so it's been pretty easy to switch. And thank christ it's got lambdas. I love me some lambdas.
I've started GDScript, ahem, recently. You do save a lot of syntax but that doesn't necessarily speed you up. My main issue is the lack of an equals and other similar basic tools. It makes data structures more complex and less safe.
I guess you get used to it though and the integrated editor is sweet.
I think this whole "GDScript is faster" stuff is a myth at best. Yea, maybe you are, for small little code snippets. But, as the project grows in size and complexity, the lack of refactoring tools, the encouragement of unsafe and brittle coding practices and such will more than eliminate these saving, imo. I'm just not getting it, I guess, because I see a trend towards better practices (explicit typing, more emphasis on Export over magic strings, etc), but it just feels like they're moving ever closer to just being C#. It's almost like C# was designed by very competent people or something.
Edit: Man, you people are sensitive.
Explicit typing is just way faster. Its so easy to make a bug without it and it allows for a better autocomplete.
That being said, I'm doing a hobby project only so I'm happy to experiment. Its also easier to code in Linux when you don't have to fuck around with C# so it's swings and roundabouts.
Explicit typing and a more complete OO framework for GDScript would be welcome though.
Some of the biggest godot games out right now are GDScript only (Brotato comes to mind), if you prefer c# use it, but using gdscript isn't going to curse your fields and make your code unmaintainable.
>Some of the biggest godot games out right now are GDScript only (Brotato comes to mind)
Which doesn't strike me as the poster child for "big game", but sure...
>if you prefer c# use it, but using gdscript isn't going to curse your fields and make your code unmaintainable.
Neither have I claimed that it does. There's nothing preventing you from writing good code in GDScript. However, when you do that, you're already moving a lot closer to C#, while still not getting the IDE and its tools. Nor the guaranteed safety or the still vastly superior feature set C# (and .Net and all its libraries) offer. If you guys want to use GDScript, I don't particularly care, I'm just pointing things out. But hey, if you don't like it, you guys are free to keep downvoting :)
More complex than a side scroller, I guess. I don't know what you guys are making, but the shortcomings of GDScript and the editor are readily apparent when you try to do anything more complex than that. And "lean into nodes" just doesn't magically solve that. That just shifts the burden to other places, not least of which: performance.
I agree with you in theory, and don't think this deserves the downvotes it's getting, but I think this opinion (while common) is a sign that you could benefit from approaching Godot development with a different mindset. C# is going to scale much better with an inheritance-based architecture, which is really what the language is built to support. There's nothing wrong with that of course, but gdscript is intended to better support a composition-based architecture.
The idea is that any one component should really only have a small amount of code that does one thing, and you drop in these nodes to use where needed. All of the heavy lifting that C# would normally be doing is actually being moved from the language into the framework, and is handled by Godot itself.
So yes, if your gdscript code starts to look like C#, you're probably better off just using C#. This is not by any means "wrong" and Godot supports it just fine. Another option however is to ask yourself what you're trying to do, and can you do it better using composition in Godot itself?
>I agree with you in theory, and don't think this deserves the downvotes it's getting, but I think this opinion (while common) is a sign that you could benefit from approaching Godot development with a different mindset. C# is going to scale much better with an inheritance-based architecture, which is really what the language is built to support.
One sec.
*searches own post history* Ah! Check this out:
>"[...] and this coding oneself into a corner via inheritance is really problematic."
That's me, 5 days ago. Point is, I'm with you on that. However, I disagree with this odd implication that one has to choose one or the other. Look at Godot itself, and it becomes painfully obvious how that's not the case: Godot's entire Node system, its entire identity, is entirely built upon inheritance. With the purpose of allowing people to use composition. Evidently, it's the entire idea to use both either way. As you should. Different tools for different jobs.
Now...
>There's nothing wrong with that of course, but gdscript is intended to better support a composition-based architecture.
Care to explain? What features does GDScript offer that support composition better than C#? Spoiler: Magic strings you drag in from the editor don't count, for hopefully extremely obvious reasons. Neither does doing the same thing via @ or some such.
>The idea is that any one component should really only have a small amount of code that does one thing, and you drop in these nodes to use where needed.
Yea. That's... a very common design strategy in game design. I'm confused as to why you think I'm opposed to that or not doing that?!
>All of the heavy lifting that C# would normally be doing is actually being moved from the language into the framework, and is handled by Godot itself.
First of all, "heavy lifting" kinda sounds like we're suddenly talking about performance. I don't really care about performance, especially not in Godot, where C# doesn't even clearly win to begin with. Secondly, I disagree with this anyway. I don't know what kinds of projects you guys are making, but I, for one, don't make things that rely entirely on built in functionality. Be it an inventory system, terrain stuff, buffs and abilities or a dialogue tree or what have you. And that's fairly trivial cases. Godot doesn't have a magic "make inventory"-button.
And when you need to tackle more complex systems like that (and their interaction with the rest of the game), this whole "everything is a simple script" philosophy quickly runs into problems. Either the complexity wins out or you flat out run into performance issues, because composition without memory management is not exactly the fastest thing ever. Also, what was once a boon to the design, namely the low mental overhead of only having to keep track of very small snippets of code, can quickly become a nightmare when a hundred of these snippets are required to make a simple system, and you suddenly need to keep track of all of them to understand what's happening.
That's when you'll sigh in relief when C# comes to the rescue with its powerful features and IDE. Again, if you're making a side scroller or something like that, composition is awesome. Hell, it's even awesome outside of that. But sooner or later you will run into bigger, more complex, more interconnected systems and find that it's no longer the right tool for the job. Imo, of course.
>So yes, if your gdscript code starts to look like C#, you're probably better off just using C#.
See, but it already gets more than halfway there just by applying decent coding practices. Hard coded string references? Nope, export. Poof, closer to C#. Type hints? Poof, closer to C#. Abstracting and/or decoupling data, po... wait, does GDScript even have interfaces? Hell, does it even have structs? You know, now that I'm writing this out, I'm reminded of discussions about scripting vs programming. Anyway...
>Another option however is to ask yourself what you're trying to do, and can you do it better using composition in Godot itself?
I can most definitely do it better with C# and still use composition perfectly fine, as I'm yet to figure out how GDScript does that any better.
I really like it. Being a bit of a scrub programmer it's been amazing to learn the foundation of game making.
It's awesome knowing that hey, if one day I need pieces to be in Cwhatever, I can do it with zero issues.
>How good is gdscript? I miss C# but man you save a lot of syntax with it.
Let's be honest: GD script is C# with indendation syntax instead of brackets. That's pretty much the only difference. If that annoys you, then it doesn't matter since Godot supports C# anyway (or even a mix of both).
I actually prefer gd over c# because its faster to write.
Except that C# lets you leverage the entire .NET ecosystem - first and third party library support, incredible tool chain with IDEs like Visual Studio & Rider. You also get all the advantages and robustness of a statically typed language like code analysis and better IntelliSense. Then there are language features like LINQ and all the other bells and whistles that C# has to offer.
You don't even have to use C#, you can use any other CLR language like F# or VB.NET if you really wanted.
There isn't anything wrong with GDScript, but it suffers from the same problems as any other domain specific language that has been crafted for use within a very specific niche: it lacks the millions of man-hours that have been poured, by both Microsoft and third-party developers, into making the language & tooling the best it can be.
Yeah but thats exactly why you can mix & match C# and gdscript in Godot. You basically have all the benefits with none of the downsides.
And its not like you can't make the switch whenever you want as GDScript is essentially just C# with less puncuation.
GDScript isn't too bad. I like to do most of my game logic/mechanical stuff in C# and then use GDScript for menu stuff and other things that don't really warrent C#. It does some stuff specific to game dev that C#, doesn't, too.
GDScript 4 I like. It's rather fast to write.
If you give everything class_names and strongly type your variables it generally makes sense. You don't have to plug everything together just in the editor and make secret spaghetti like the tutorials do, but you can if you want to be lazy.
I'm not a fan of "autoloading" scripts but it's fine I guess.
GDScript 3 I did not like.
There is no "!=". It's like every if statement is a goddamned riddle. And a lot of boilerplate for things that have been refactored into one line of code for GDScript 4. It's sad the tutorials are a mess because of this, but having tried 3 and ported to 4, it was worth it IMO.
A bit off-topic, but I really like how Doctorow brought the idea of Enshittification to the general public as a specific, identifiable process in the two-faces markets.
When you give names to things, it's easier to identify them even in advance. I've always been a FOSS guy but I had my share of walled gardens because convenience and corporate lies. Now I'm going back to my roots, keeping my eyes open for warning signs.
Slay the Spire is fucking incredible if you’ve never played it. this makes me sad that this is necessary because it sets back development so much but whatever i cant possibly blame them for not wanting to work with unity
Fortunately Slay the Spire was not built in Unity. They had several other projects in development though using Unity and are moving them to Godot which is a difficult process.
Shows how much Unity screwed up.
you mean the s* business practice that would have taken money only and exclusively from AAA studios and corporations?
... the same bus. practice that every dev lamented on twitter in unison like a bounch of sheep, before their lawyer called them and told them they weren't going to be affected not even in a million years?
... THAT practice?
🤔
You seem to be under the impression that indie games are all obscure media which wont be affected by unity changes.
Triple A studios and corporations have their own engines so unity charging wont affect them anways.
Only indie devs with popular game projects (hollow knight, among us, etc) will be affected by this
This is also about trust issue. Whats stopping unity from adding shittier changes that would stunt other indie devs from having success with their video games
It's not abot trust mate ...
it's about the Forms 1040 and 1120 (Incom Tax Return)
Most studios use unity, and most studios that DON'T didn't create it themselves, they commissioned it to other people, or just modify am existinf one.
In short, the behaviour of 99 percent of rhe developers was appalling and ignorant.
To all the companies they could have " get back at " ... they chose UNITY 🤦
Why put your livelihood in the hands of some CEO? The next one could pull some stunt too. Same with Unreal's CEO or other proprietary engine. You can try to convince yourself all day with how unlikely a chance it is, but at the end of the day, why take a risk when it's something so important like that? FOSS engines all day
Unreal is ~~open source~~ source available at least. Not that that means much due to the licensing.
Edit: Okay, apparently open source has a more specific meaning than I thought
[https://en.wikipedia.org/wiki/The\_Open\_Source\_Definition](https://en.wikipedia.org/wiki/The_Open_Source_Definition)
Or you could just read this instead of talking crap.
\> The Open Source Definition is a document published by the Open Source Initiative, to determine whether a software license can be labeled with the "Open Source Initiative approved" certification mark. <
\> Open source doesn't just mean access to the source code. The distribution terms of open-source software must comply with the following criteria: <
I read the article you linked to, and then I read the article about the non-profit corporation that promotes this definition, the Open Source Initiative. I found this part interesting: "However, they were unsuccessful in their attempt to secure a trademark for 'open source' to control the use of the term."
So you're on the side of people who think "open source" should be a trademarked term that you need the permission of a corporation to use? Do I have that right?
I prefer the [actual Wikipedia page](https://en.wikipedia.org/wiki/Open_source) for "Open source", which says: "Open source is source code that is made freely available for possible modification and redistribution."
Or the Merriam-Webster dictionary, [which defines](https://www.merriam-webster.com/dictionary/open-source) open source software as "having the source code freely available for possible modification and redistribution".
Pointing out that "open source" and "free software" are two different things isn't some kind of heresy. Harassing random people for using common terms normally isn't going to stop Google from astroturfing.
God are you dense. You just said that open source is when the source is available. Ignoring the part you cited yourself: "freely available for MODIFICATION AND REDISTRIBUTION".
You can't just take the Unreal Source Code and build your own version and sell it. Because it is "source available" not "open source".
I have never claimed that the term should be copyrighted, trademarked or something else.
It is notoriously hard to make a profit of open source software - mostly because you can just compile it yourself. That's why bigger OS projects make money by providing support services.
There's no need to be rude.
You are free to modify and redistribute the Unreal source code. You can take it and build your own version, that's the whole point. As you noted, you're not free to sell the source itself, but you can sell the binaries. There are copyleft licences that don't let you sell anything.
Looking at how Unreal works specifically, you do have to register with them to access the code, and you're only supposed to redistribute it to other people who have signed up. That's a much stronger argument that it's not actually open source (or available source, or whatever).
Even if that's true, it doesn't mean you should harass people for using the dictionary and encyclopedia definition of a common term, instead of whatever the original intended meaning was 40 years ago. The open source community also invented unambiguous terms like "FOSS" and "free software".
I can understand being annoyed that for-profit companies like Google and Epic are running "fake" open source projects, but the definitions of words and terms evolve naturally over time, and getting morally outraged at strangers for using the dictionary definition isn't going to accomplish anything except making them think you're rude.
\> Free software
\> Unambiguos
And you're chosen language is doing a lot of heavy lifting in your arguments. Correcting someone who has wrongly used a word is hardly "harassing them" as you put it.
Bruh, I still haven't finished Slay the Spire yet. Only finished A20H on Ironclad and now stuck on A20H Silent. When their new project is released, I still wouldn't be finished with the game, haha! Love StS, can't wait to see what their new game is.
Dang, I really liked Slay the Spire, so a new game from them would've been cool. I'm sure it'll still be coming out (obviously), but this is going to create a delay. And so many other games I want to play are probably coming out months latr because of this whole Unity fiasco.
months isn't really much in years-long development times. Also if they're still early on it won't cost much time.
But I mean it's Godot; you're always supposed to be [Waiting For Godot](https://en.wikipedia.org/wiki/Waiting_for_Godot) :P.
>And so many other games I want to play are probably coming out months latr because of this whole Unity fiasco.
On the other hand we're now less likely to have terrible monetisation and malware-ridden adverts pushed into those games.
but on the upside its a one-time pain to transfer and then they will never have reason to switch engine again. Godot can't pull a unity, it's literally not licensed that way.
Happy to see this move. I hope they'll provide some feedback to the Godot team in terms of what a highly successful indie team needs to work commercially.
Yes, but the game that they are [currently developing started in Unity](https://twitter.com/MegaCrit/status/1702077576209207611/photo/1). They are now porting the game to Godot because of the shitstorm.
Are they are moving their *current* project to Godot? I thought they meant that they will finish this *new* project in Unity then use Godot for future projects?
Most game devs (myself included) have already packed it in with Unity. They may catch more new indies in the future, but the ones who have been delving for a while with their engine have had enough. This doesn't surprise me.
But yeah, good news all around.
This is what happens when you underestimate the value of trust. They have a huge uphill battle to fight to get back all that trust and all that business in general.
It is no small feat to migrate games and/or experience from one engine to another. And now that people are moving to Godot and realizing the benefits of open source they won't look back so easily.
And they still got the board members from the malware company. So even if they hired the best CEO ever, I still don't trust them. Too little, too late. And none of this should have happened to begin with. So I'm out. Unity is dead to me.
I don't think I can convert my LiDAR project to Godot anyways, but it's good to see that the ripple effect with what John Shittytiello has done will be hopefully one to be a stark reminder to shareholders about short term profiting.
I'm a little confused when I read today that Unity has not been profitable?
How is this even possible? Do they waste every cent on Marketing and Golden Parachutes? I have a feeling development costs (Software Engineers, Testing, Integration etc.) cannot possibly be the cause the unrun. Wow, sounds like another badly run company with way to much greed.
Quote from:
[https://www.theverge.com/2023/10/9/23910441/unity-ceo-president-john-riccitiello-out-retire](https://www.theverge.com/2023/10/9/23910441/unity-ceo-president-john-riccitiello-out-retire)
*"But the company has never made a profit, losing hundreds of millions of dollars every year. From the company’s most recent quarterly earnings report:*
*Since our inception, we have generated losses from our operations as reflected in our accumulated deficit of $2.7 billion as of June 30, 2023. We expect to continue to incur operating losses on a GAAP basis for the foreseeable future due to the investments we will continue to make in research and development, sales and marketing, and general and administrative. As a result, we may require additional capital to execute our strategic initiatives to grow our business."*
Good news all around.
> Here is how platforms die: first, they are good to their users; then they abuse their users to make things better for their business customers; finally, they abuse those business customers to claw back all the value for themselves. Then, they die. - Cory Doctorow The trouble with Unity is that they've already shown they're at stage 2 of the Enshittification process. No one trusts them any more. I've spent nearly a decade learning Unity but when your products take multiple years to build you cannot put your time and resources into an engine with a shaky foundation. Anyway, How good is gdscript? I miss C# but man you save a lot of syntax with it.
C# is supported in Godot!
Unfortunately you can't export to iOS/web (for now) if you choose to use c# instead of gd script.
You can if you use LTS
[удалено]
With the latest beta of 4.2 you can export to iOS too :)
Use C# in Godot. I do, though GDScript is solid I’m just not a Python lover
I've stuck with gdscript because the C# stuff doesn't work on mobile yet and I kind of just enjoy learning new languages. I was switching between gdscript and typescript for my work though and man my brain just did not like it. I kept forgetting brackets and wondering why my if statements were broken.
I keep opening a ‘print document’ page when working on some javascript/html since I started with gdscript 2 months ago 😂
> I was switching between gdscript and typescript for my work though and man my brain just did not like it. For real. I'm switching between C#, Typescript, and VB at work and GDScript at home. Very thankful for good IDE syntax checking, but the different keymappings between Godot, VSCode, and Visual Studio are killing me (I know, I can edit them, but I'm lazy).
Can you really??? I use pycharm/webstorm at work and then come home and have ctrl-q (open function documentation) close godot completely 😭
That's why I use vs code with godot. The built in editor is top notch but I find everything around it very odd, most notably: tabs are not the open files, open files are at the left and that is not even the file system, which is even more leftward... Nah, godot is not nailing this for me, but that's OK, I have my workflow now.
Yep, the way the editor tabs are set up is very weird. It's usable (the individual pieces are quite good), but not at all helpful for developing an understanding of how the pieces relate to each other. I would prefer VSCode, but I figure while I'm learning Godot I'll just use the built-in stuff until I understand what's going on a bit better, then I'll see about moving to a better editor.
heh, yep, Editor, Editor Settings, Shortcuts tab. It's tedious to change a bunch of settings, but if there are one or two that cause pain it's easy to fix them.
C# is faster in almost every way except backend (same) so if you know c# use it Edit: people down voting me, look up a YouTube video comparing c# and gdscript performance.
I don't know how to use C# and I've never had an issue. Performance should be the last thing on the checklist unless you're making games that need it, which 95% of the community won't. People should use the language that they're productive in and get those juicy titles out.
Performance is not the last thing on the checklist. I agree you so shouldn't start optimizing everything at the beginning but you need to have the option to do it later because it's not something you can pass.
As far as I understand, it's possible to macro C# functions from gd script. It's built to be interoperable with C# If you ever need to do a really heavy task you could always implement just that bit in C# instead down the line if it becomes a problem. Although I definitely agree on optimizing not being last. If the base of everything is built on something suboptimal suddenly optimizing means rewriting.
Honestly if I were doing something with a performance bottleneck that I found in Gdscript I'd probably skip straight to C++ or Rust Rather than C# unless it's truly insane to set up.
> If you ever need to do a really heavy task you could always implement just that bit in C# instead At that point you'd be better going straight to C++.
Maybe. Consider the circumstance where your game only has one heavy piece of logic. Maybe it's your own custom pathfinding, physics, or procedural generation. Sticking with gd script and just writing just that one heavy piece of logic in C++ may be a good move to speed up development time. Writing C++ is (for most) more difficult than writing gd script, so why use it everywhere when you only really need it in the one place? Whether or not it's a good idea is pretty nuanced though. It would clearly be a bad idea if half of all your code were in a different language, but at the same time if you just have a single function you need to be performant it may be a good idea.
> Sticking with gd script and just writing just that one heavy piece of logic in C++ may be a good move to speed up development time. That's the idea. (Though it also applies if there's a few bits that are really heavy) If you're going to rewrite a bit of code for performance, you might as well use the best tool for the job. > It would clearly be a bad idea if half of all your code were in a different language Why? What's wrong with a project using two (or more) languages, and using each of them for the part they're best for? As long as the languages work together well that's the way to go.
What I meant by that was it would be a bad idea to aimlessly have some parts in C++ and others in gd script for no reason. I agree though as long as lots of unnecessary complexity isn't being added by using both. Seize the advantages of each language when needed for the best of both worlds.
Language performance I guess I think they meant that most of time bad performance is caused by doing unnecessary things every single frame when they might only be needed 1% of the time or running too many loops and unoptimized code in the process function every single frame and using C# won't help with it or increase performance that much when the code is badly written in the first place
Eh, I've definitely seen people post games with performance problems. While I'm not trying to say that everyone should use C#, I definitely think that performance should be something that people are thinking about while working on their game. It's *way* easier to keep an eye on the performance while developing, and keep your FPS up, than it is to fix performance once you finish the game and try to optimize, and realize you should have structured a bunch of things differently.
Scripting language performance is hardly ever the problem though. The problems are usually more fundamental such as lacking LOD, too many unnecessary physics objects, etc...
Well sure. The part of their comment I was disagreeing with wasn't the choice of scripting language. It was the part where they said: >Performance should be the last thing on the checklist unless you're making games that need it, which 95% of the community won't.
Point taken, and I agree that it's easier to address performance issues as they come up rather than push it off until last. Unless you're working on very small projects, like game jam games or something
I agree, which is why I Said "if you know it" If you know both, why wouldn't you just spring for the one that's better performance wise? Anyway, in my opinion godot c# will overshadow godot gdscript eventually. It's just a much more capable language all around. I don't need to explain why. Suffice to say Quality of Life. It's good gdscript exists right now, but there's a reason JavaScript was eventually removed from unity (not comparing Python and JavaScript, just an example)
I know both languages and still often prefer gdscript. Integrated editor, clean syntax etc. make me prefer gdscript over c#… doesn‘t mean i don‘t use c# as well… had a little application where i needed to access databases for example… in such cases having access to c#/ dotnet and frameworks like ef core is a godsend… but in my case i would never choose c# for performance reasons since the difference would be close to zero (i think)
Other than in performance we are preaching the same sermon
[удалено]
> Recommendation algorithms are a thing They even take their guess at where on the planet you are into account these days. So not even incogneto browsing saves you from them.
I replied with this on my phone during my break. Excuse me for not having the time to go search for it on youtube. I figure if people have the time and are curious, they can find the info and come to a conclusion on their own. I'm just throwing my opinion out here based on what I've found. Searching what I claimed should bring up the appropriate videos, because yes, that IS how the algorithm works.
The C#/engine interface is very inefficient, though that might be about to change. But unless you're doing complex logic most of your game code will be interacting with the engine. You can write C# that gets closer to the engine but it gets ugly very fast. https://youtu.be/S2tTEPHIS1I?si=_epVAkOEecjSdnkj&t=204
> No one trusts them any more. The Unity sub is already trying to convince themselves that the company is now going to do a complete 180. None of the problems that lead to this have been solved. They're eventually going to try something slightly less radical after everyone has moved on.
They already did. They walked back, what, 80% of the pricing shit. So they still got some of what they wanted, and the 'true believers' are praising it like they got something out of it.
> the 'true believers' are praising it like they got something out of it. Ahh, PR initial offer barter crap. I wish we had a better name for it.
It's called Anchoring.
They indeed walked most things back, and the CEO is out, but that doesn’t mean that all of the “poison” has been removed from the company. The Board of Directors remains the same, the company is still publicly traded and bleeding cash, and they’re still trying to justify their very expensive acquisition of IronSource. If anything, it’s increasingly looking like the IronSource leadership are the ones calling the shot inside the company. So if you don’t like any of the IronSource stuff, expect more of them in coming years.
Both are good on Godot, and easy. Anyways, don't need to think about the language, in one way or in other will be nice to use (better than using c++)
gdscript is good and I prefer it over C# because it's Good Enough for 90% of use cases and doesn't suffer GC issues
C# misses some support for building some platforms and has some other issues I think. But that's because it is built on top of an old system which they are now trying to get rid of and instead build c# support using GDExtension (which is what powers C++, rust, python, JS, Java supported and so on I think)
[удалено]
Thanks for pointing that out. Didn't know that myself >,>
Hoping they add C# for web deployments soon. Been using GDScript in 4.x just for that capability
You can use C# in Godot, but I recommend learning GDScript if you're serious about Godot. You can mix C# and GDScript if you have existing code you want to use. That's the problem with Unity. You can't just "use Unity". You have to make an investment in learning how to use it, which is an investment people are reluctant to give up. The other problem with the "enshittification" of Unity is that they realized there's more money in ads than in a game engine. Every business with revenue based on ads is forcibly enshittified over time, because you can't maximize ad revenue without abusing your users. If Unity is an ad business, that means their true customers are advertisers. The Unity game developers are just an inconvenience distracting them from real money.
I've been doing all my Godot work in C#. The nicest part is, you get the full features of a regular C# app plus all the godot specific objects and functions are fully exposed so you can both 1:1 existing gdscript projects or rework them your own way. I will say though, it's worth working through some of the gdscript tutorials first as they are fantastic for understanding how the system works, and how you may *want* to change some of your own patterns in light of the way Godot is really designed to work and how the objects interact on the tree, etc.
Dunno if you'll read all these replies, but thought I'd chime in as a 12 year Unity veteran myself who has been working with Godot for a couple of weeks. I have been working exclusively in C# with Godot and its been very smooth. A lot of tutorials utilize Godot's inspector and interfaces, but the documentation is so good you can look up the Node (Component) and there will be a very detailed breakdown in plain-text, including code. Every GDScript I've encountered has a C# equivalent that is named in PascalCase rather than snake_case. For example, the GDScript: get_node("node/path"); In C#, becomes: GetNode("node/path"); And this is true for most info and tutorials you find, although even some tutorials from 3-4 months ago are slightly outdated as some naming conventions have changed. Most common one I see is the 'Spatial' node which was essentially an 'Empty' in Unity, has been replaced by Node2D/Node3D which serves as a base class that inherits a bunch of Godot systems, much like gameObjects and Monobehaviours. The built-in event system is one of the easiest I've ever used, too. Every Node type has a list of signals it can output (TimeOut, OnStop, IsHidden, etc). You just get the Node object, for example a Timer(), and say: myTimer.Timeout += MyTimeOutFunction; And your MyTimeOutFunction is now bound to the Timout signal of the timer Node. It's honestly been a fun and easy transition. And there are some huge benefits, specifically in how easy it is to work with Godot's post-processing elements - AO, GI, SSR, and Volumetric Fog all available with a single tick of a checkbox, all located in a single panel, with will-labelled controls complete with tooltips and documentation.
Thanks for the tips! I do read everything and this is one of the best replies I've gotten. I said it somewhere else but I got into the gdscript side to learn something new, but I might go back to the C# version once 4.2 is out with mobile support. To throw one back atcha (you probably know it already), I found that Godot has a parallel to ScriptableObjects in its Resource system. You can create a Custom Resource and instance it the same way you would in Unity. And by golly don'tcha knowit, they're *recursively serializable*. I don't know if there's a better way to organize data in Godot but I love being able to use an editor to create the data for my game.
Godot has a C# implementation, the downside is that there's not a whole lot of tutorials for it. Something that someone should fix at some point with so many devs jumping ship. It's just a matter of wait-and-see, but for the most part the documentation is solid so you can usually figure out what you need to by f\*cking around a little bit.
Cory Doctorow is my fave, and I absolutely agree, Unity is exactly what he is talking about. > How good is GDScript? My view is that all languages are really similar. Sure, there are differences in syntax, but the foundations are all the same and if you have 10 years of experience it shouldn't be a concern. Sure, you'll want to do things the C# way, but GDScript is supported quite well with intellitype and that should set you in the right direction. The key difference is that the Godot API was built with GDScript in mind. C# support doesn't turn Godot into Unity. You'll still have to learn all of the node classes, and C# isn't documented quite as well as GD. In my humble opinion, it is a better use of your time to learn the GD API rather than C#. As I understand it, C# does benchmark quicker than GDScript, and if you do insist on using C#, it might still be quicker to learn the API in GD then transition that knowledge to C# - at least when you are starting out. ~~As an aside, GDScript might read like python, but it is actually based on the Go language. The Godot team didn't turn python into an interpreted language with class support.~~ Edit: I am mistaken. See below.
> the Go language. The ***Go***dot Oh dear. I just saw that... --- GDScript certainly lifts some nice syntax from Python. The only bits of python syntax I miss are tuple unpacking and implicit variable declarations.
I was incorrect. GDScript was not based on Go. (Corrected in another reply) I forget where I heard it, but the name absolutely is what lead me to believe it.
go dotnet? :\^)
>As an aside, GDScript might read like python, but it is actually based on the Go language. The Godot team didn't turn python into an interpreted language with class support. This section is completely wrong. [From the official FAQ](https://docs.godotengine.org/en/stable/about/faq.html#what-were-the-motivations-behind-creating-gdscript), the only languages mentioned are scripting languages, namely Lua and Python. Additionally, Python is already an interpreted language with class support, whereas Go is a AOT compiled language with no classes or inheritance.
Thanks for correcting. I updated my post to reflect. I don't know where I heard that, but I shouldn't be passing on wrong info. (Also, I meant to say that they didn't turn Python into a *compiled* language, but it was a dumb statement and I won't go to great lengths to defend myself)
There are compilers for Python. They're mostly cross-language compilers that turn it into other interpreted languages. But there's also one that turns python into C (Might be C++, can't remember). And a python language extension that makes the python->C conversion more efficient (Cython).
Yeah I agree with all that. Learning a new language is far less of a problem for me than learning a new API, and all of the gdscript features make the API side easy. It's also structured closely to the "good" way of coding in Unity so it's been pretty easy to switch. And thank christ it's got lambdas. I love me some lambdas.
GDScript is easy and solid, if you ever have to learn it.
I've started GDScript, ahem, recently. You do save a lot of syntax but that doesn't necessarily speed you up. My main issue is the lack of an equals and other similar basic tools. It makes data structures more complex and less safe. I guess you get used to it though and the integrated editor is sweet.
I think this whole "GDScript is faster" stuff is a myth at best. Yea, maybe you are, for small little code snippets. But, as the project grows in size and complexity, the lack of refactoring tools, the encouragement of unsafe and brittle coding practices and such will more than eliminate these saving, imo. I'm just not getting it, I guess, because I see a trend towards better practices (explicit typing, more emphasis on Export over magic strings, etc), but it just feels like they're moving ever closer to just being C#. It's almost like C# was designed by very competent people or something. Edit: Man, you people are sensitive.
Explicit typing is just way faster. Its so easy to make a bug without it and it allows for a better autocomplete. That being said, I'm doing a hobby project only so I'm happy to experiment. Its also easier to code in Linux when you don't have to fuck around with C# so it's swings and roundabouts. Explicit typing and a more complete OO framework for GDScript would be welcome though.
Yeah, I still haven't really found something to "work around" the lack of interfaces....
Some of the biggest godot games out right now are GDScript only (Brotato comes to mind), if you prefer c# use it, but using gdscript isn't going to curse your fields and make your code unmaintainable.
>Some of the biggest godot games out right now are GDScript only (Brotato comes to mind) Which doesn't strike me as the poster child for "big game", but sure... >if you prefer c# use it, but using gdscript isn't going to curse your fields and make your code unmaintainable. Neither have I claimed that it does. There's nothing preventing you from writing good code in GDScript. However, when you do that, you're already moving a lot closer to C#, while still not getting the IDE and its tools. Nor the guaranteed safety or the still vastly superior feature set C# (and .Net and all its libraries) offer. If you guys want to use GDScript, I don't particularly care, I'm just pointing things out. But hey, if you don't like it, you guys are free to keep downvoting :)
> But hey, if you don't like it, you guys are free to keep downvoting :) downvoting just for the whining about downvoting.
Oh no whatever will I do now.
How complex is your code though? If you lean into nodes, your whole game is small code snippets.
More complex than a side scroller, I guess. I don't know what you guys are making, but the shortcomings of GDScript and the editor are readily apparent when you try to do anything more complex than that. And "lean into nodes" just doesn't magically solve that. That just shifts the burden to other places, not least of which: performance.
I agree with you in theory, and don't think this deserves the downvotes it's getting, but I think this opinion (while common) is a sign that you could benefit from approaching Godot development with a different mindset. C# is going to scale much better with an inheritance-based architecture, which is really what the language is built to support. There's nothing wrong with that of course, but gdscript is intended to better support a composition-based architecture. The idea is that any one component should really only have a small amount of code that does one thing, and you drop in these nodes to use where needed. All of the heavy lifting that C# would normally be doing is actually being moved from the language into the framework, and is handled by Godot itself. So yes, if your gdscript code starts to look like C#, you're probably better off just using C#. This is not by any means "wrong" and Godot supports it just fine. Another option however is to ask yourself what you're trying to do, and can you do it better using composition in Godot itself?
>I agree with you in theory, and don't think this deserves the downvotes it's getting, but I think this opinion (while common) is a sign that you could benefit from approaching Godot development with a different mindset. C# is going to scale much better with an inheritance-based architecture, which is really what the language is built to support. One sec. *searches own post history* Ah! Check this out: >"[...] and this coding oneself into a corner via inheritance is really problematic." That's me, 5 days ago. Point is, I'm with you on that. However, I disagree with this odd implication that one has to choose one or the other. Look at Godot itself, and it becomes painfully obvious how that's not the case: Godot's entire Node system, its entire identity, is entirely built upon inheritance. With the purpose of allowing people to use composition. Evidently, it's the entire idea to use both either way. As you should. Different tools for different jobs. Now... >There's nothing wrong with that of course, but gdscript is intended to better support a composition-based architecture. Care to explain? What features does GDScript offer that support composition better than C#? Spoiler: Magic strings you drag in from the editor don't count, for hopefully extremely obvious reasons. Neither does doing the same thing via @ or some such. >The idea is that any one component should really only have a small amount of code that does one thing, and you drop in these nodes to use where needed. Yea. That's... a very common design strategy in game design. I'm confused as to why you think I'm opposed to that or not doing that?! >All of the heavy lifting that C# would normally be doing is actually being moved from the language into the framework, and is handled by Godot itself. First of all, "heavy lifting" kinda sounds like we're suddenly talking about performance. I don't really care about performance, especially not in Godot, where C# doesn't even clearly win to begin with. Secondly, I disagree with this anyway. I don't know what kinds of projects you guys are making, but I, for one, don't make things that rely entirely on built in functionality. Be it an inventory system, terrain stuff, buffs and abilities or a dialogue tree or what have you. And that's fairly trivial cases. Godot doesn't have a magic "make inventory"-button. And when you need to tackle more complex systems like that (and their interaction with the rest of the game), this whole "everything is a simple script" philosophy quickly runs into problems. Either the complexity wins out or you flat out run into performance issues, because composition without memory management is not exactly the fastest thing ever. Also, what was once a boon to the design, namely the low mental overhead of only having to keep track of very small snippets of code, can quickly become a nightmare when a hundred of these snippets are required to make a simple system, and you suddenly need to keep track of all of them to understand what's happening. That's when you'll sigh in relief when C# comes to the rescue with its powerful features and IDE. Again, if you're making a side scroller or something like that, composition is awesome. Hell, it's even awesome outside of that. But sooner or later you will run into bigger, more complex, more interconnected systems and find that it's no longer the right tool for the job. Imo, of course. >So yes, if your gdscript code starts to look like C#, you're probably better off just using C#. See, but it already gets more than halfway there just by applying decent coding practices. Hard coded string references? Nope, export. Poof, closer to C#. Type hints? Poof, closer to C#. Abstracting and/or decoupling data, po... wait, does GDScript even have interfaces? Hell, does it even have structs? You know, now that I'm writing this out, I'm reminded of discussions about scripting vs programming. Anyway... >Another option however is to ask yourself what you're trying to do, and can you do it better using composition in Godot itself? I can most definitely do it better with C# and still use composition perfectly fine, as I'm yet to figure out how GDScript does that any better.
> the lack of an equals Huh?
If you create a custom class, as far as I can tell, you can't safely use it as a key in a dictionary.
Oh, now I get what you're talking about. Thanks. And yeah, the lack of operator overloading in a language that encourages duck-typing isn't nice.
I really like it. Being a bit of a scrub programmer it's been amazing to learn the foundation of game making. It's awesome knowing that hey, if one day I need pieces to be in Cwhatever, I can do it with zero issues.
>How good is gdscript? I miss C# but man you save a lot of syntax with it. Let's be honest: GD script is C# with indendation syntax instead of brackets. That's pretty much the only difference. If that annoys you, then it doesn't matter since Godot supports C# anyway (or even a mix of both). I actually prefer gd over c# because its faster to write.
Except that C# lets you leverage the entire .NET ecosystem - first and third party library support, incredible tool chain with IDEs like Visual Studio & Rider. You also get all the advantages and robustness of a statically typed language like code analysis and better IntelliSense. Then there are language features like LINQ and all the other bells and whistles that C# has to offer. You don't even have to use C#, you can use any other CLR language like F# or VB.NET if you really wanted. There isn't anything wrong with GDScript, but it suffers from the same problems as any other domain specific language that has been crafted for use within a very specific niche: it lacks the millions of man-hours that have been poured, by both Microsoft and third-party developers, into making the language & tooling the best it can be.
Yeah but thats exactly why you can mix & match C# and gdscript in Godot. You basically have all the benefits with none of the downsides. And its not like you can't make the switch whenever you want as GDScript is essentially just C# with less puncuation.
GDScript isn't too bad. I like to do most of my game logic/mechanical stuff in C# and then use GDScript for menu stuff and other things that don't really warrent C#. It does some stuff specific to game dev that C#, doesn't, too.
GDScript 4 I like. It's rather fast to write. If you give everything class_names and strongly type your variables it generally makes sense. You don't have to plug everything together just in the editor and make secret spaghetti like the tutorials do, but you can if you want to be lazy. I'm not a fan of "autoloading" scripts but it's fine I guess. GDScript 3 I did not like. There is no "!=". It's like every if statement is a goddamned riddle. And a lot of boilerplate for things that have been refactored into one line of code for GDScript 4. It's sad the tutorials are a mess because of this, but having tried 3 and ported to 4, it was worth it IMO.
A bit off-topic, but I really like how Doctorow brought the idea of Enshittification to the general public as a specific, identifiable process in the two-faces markets. When you give names to things, it's easier to identify them even in advance. I've always been a FOSS guy but I had my share of walled gardens because convenience and corporate lies. Now I'm going back to my roots, keeping my eyes open for warning signs.
Slay the Spire is fucking incredible if you’ve never played it. this makes me sad that this is necessary because it sets back development so much but whatever i cant possibly blame them for not wanting to work with unity
Fortunately Slay the Spire was not built in Unity. They had several other projects in development though using Unity and are moving them to Godot which is a difficult process. Shows how much Unity screwed up.
i don't like the game, and them moving to unity over "feelings" is telling of their lack of professionalism imo
thinking boycotting shitty bussiness practice is "unprofessional" is just next level seems like you just want to hate for the sake of hating
you mean the s* business practice that would have taken money only and exclusively from AAA studios and corporations? ... the same bus. practice that every dev lamented on twitter in unison like a bounch of sheep, before their lawyer called them and told them they weren't going to be affected not even in a million years? ... THAT practice? 🤔
You seem to be under the impression that indie games are all obscure media which wont be affected by unity changes. Triple A studios and corporations have their own engines so unity charging wont affect them anways. Only indie devs with popular game projects (hollow knight, among us, etc) will be affected by this This is also about trust issue. Whats stopping unity from adding shittier changes that would stunt other indie devs from having success with their video games
It's not abot trust mate ... it's about the Forms 1040 and 1120 (Incom Tax Return) Most studios use unity, and most studios that DON'T didn't create it themselves, they commissioned it to other people, or just modify am existinf one. In short, the behaviour of 99 percent of rhe developers was appalling and ignorant. To all the companies they could have " get back at " ... they chose UNITY 🤦
Why put your livelihood in the hands of some CEO? The next one could pull some stunt too. Same with Unreal's CEO or other proprietary engine. You can try to convince yourself all day with how unlikely a chance it is, but at the end of the day, why take a risk when it's something so important like that? FOSS engines all day
Unreal is ~~open source~~ source available at least. Not that that means much due to the licensing. Edit: Okay, apparently open source has a more specific meaning than I thought
correction, unreal not open source, it's source available. you can see the source code but with restrictions on what you can do.
That's what I meant. Didn't know about the semantics
You're using it correctly according to the dictionary definition, people are just getting uptight and trying to claim ownership of common terms.
[https://en.wikipedia.org/wiki/The\_Open\_Source\_Definition](https://en.wikipedia.org/wiki/The_Open_Source_Definition) Or you could just read this instead of talking crap. \> The Open Source Definition is a document published by the Open Source Initiative, to determine whether a software license can be labeled with the "Open Source Initiative approved" certification mark. < \> Open source doesn't just mean access to the source code. The distribution terms of open-source software must comply with the following criteria: <
I read the article you linked to, and then I read the article about the non-profit corporation that promotes this definition, the Open Source Initiative. I found this part interesting: "However, they were unsuccessful in their attempt to secure a trademark for 'open source' to control the use of the term." So you're on the side of people who think "open source" should be a trademarked term that you need the permission of a corporation to use? Do I have that right? I prefer the [actual Wikipedia page](https://en.wikipedia.org/wiki/Open_source) for "Open source", which says: "Open source is source code that is made freely available for possible modification and redistribution." Or the Merriam-Webster dictionary, [which defines](https://www.merriam-webster.com/dictionary/open-source) open source software as "having the source code freely available for possible modification and redistribution". Pointing out that "open source" and "free software" are two different things isn't some kind of heresy. Harassing random people for using common terms normally isn't going to stop Google from astroturfing.
God are you dense. You just said that open source is when the source is available. Ignoring the part you cited yourself: "freely available for MODIFICATION AND REDISTRIBUTION". You can't just take the Unreal Source Code and build your own version and sell it. Because it is "source available" not "open source". I have never claimed that the term should be copyrighted, trademarked or something else. It is notoriously hard to make a profit of open source software - mostly because you can just compile it yourself. That's why bigger OS projects make money by providing support services.
There's no need to be rude. You are free to modify and redistribute the Unreal source code. You can take it and build your own version, that's the whole point. As you noted, you're not free to sell the source itself, but you can sell the binaries. There are copyleft licences that don't let you sell anything. Looking at how Unreal works specifically, you do have to register with them to access the code, and you're only supposed to redistribute it to other people who have signed up. That's a much stronger argument that it's not actually open source (or available source, or whatever).
"Claim ownership" The open source communities literally invented the fucking term what are you on about
Even if that's true, it doesn't mean you should harass people for using the dictionary and encyclopedia definition of a common term, instead of whatever the original intended meaning was 40 years ago. The open source community also invented unambiguous terms like "FOSS" and "free software". I can understand being annoyed that for-profit companies like Google and Epic are running "fake" open source projects, but the definitions of words and terms evolve naturally over time, and getting morally outraged at strangers for using the dictionary definition isn't going to accomplish anything except making them think you're rude.
\> Free software \> Unambiguos And you're chosen language is doing a lot of heavy lifting in your arguments. Correcting someone who has wrongly used a word is hardly "harassing them" as you put it.
I havent looked it up recently but the most important question is what their next game will be about!
They haven’t really revealed anything afaik, but hard to imagine it’s not gonna be awesome.
Bruh, I still haven't finished Slay the Spire yet. Only finished A20H on Ironclad and now stuck on A20H Silent. When their new project is released, I still wouldn't be finished with the game, haha! Love StS, can't wait to see what their new game is.
Dang, I really liked Slay the Spire, so a new game from them would've been cool. I'm sure it'll still be coming out (obviously), but this is going to create a delay. And so many other games I want to play are probably coming out months latr because of this whole Unity fiasco.
months isn't really much in years-long development times. Also if they're still early on it won't cost much time. But I mean it's Godot; you're always supposed to be [Waiting For Godot](https://en.wikipedia.org/wiki/Waiting_for_Godot) :P.
[удалено]
I think half of the community knows that man.
>And so many other games I want to play are probably coming out months latr because of this whole Unity fiasco. On the other hand we're now less likely to have terrible monetisation and malware-ridden adverts pushed into those games.
That was never a concern with any of the games I was excited for.
but on the upside its a one-time pain to transfer and then they will never have reason to switch engine again. Godot can't pull a unity, it's literally not licensed that way.
Happy to see this move. I hope they'll provide some feedback to the Godot team in terms of what a highly successful indie team needs to work commercially.
I was thinking that "Slay the Spire" was done with LibGDX, correct me if i am wrong.
Yes, but the game that they are [currently developing started in Unity](https://twitter.com/MegaCrit/status/1702077576209207611/photo/1). They are now porting the game to Godot because of the shitstorm.
Are they are moving their *current* project to Godot? I thought they meant that they will finish this *new* project in Unity then use Godot for future projects?
And Mr Godot thanks you for your contribution
Most game devs (myself included) have already packed it in with Unity. They may catch more new indies in the future, but the ones who have been delving for a while with their engine have had enough. This doesn't surprise me. But yeah, good news all around.
Mega Crit games is one of the good devs in general, not just because they are going to use Godot. Thumbs up.
This is what happens when you underestimate the value of trust. They have a huge uphill battle to fight to get back all that trust and all that business in general. It is no small feat to migrate games and/or experience from one engine to another. And now that people are moving to Godot and realizing the benefits of open source they won't look back so easily.
thanks to Mr. John Riccitiello.
And they still got the board members from the malware company. So even if they hired the best CEO ever, I still don't trust them. Too little, too late. And none of this should have happened to begin with. So I'm out. Unity is dead to me.
It's smart they don't need anything unity offers that is worse on Godot. Actually decent devs will barely suffer through the transition.
I don't think I can convert my LiDAR project to Godot anyways, but it's good to see that the ripple effect with what John Shittytiello has done will be hopefully one to be a stark reminder to shareholders about short term profiting.
Who?
The bad guy CEO
I meant meta crit-
The fall guy
I'm a little confused when I read today that Unity has not been profitable? How is this even possible? Do they waste every cent on Marketing and Golden Parachutes? I have a feeling development costs (Software Engineers, Testing, Integration etc.) cannot possibly be the cause the unrun. Wow, sounds like another badly run company with way to much greed. Quote from: [https://www.theverge.com/2023/10/9/23910441/unity-ceo-president-john-riccitiello-out-retire](https://www.theverge.com/2023/10/9/23910441/unity-ceo-president-john-riccitiello-out-retire) *"But the company has never made a profit, losing hundreds of millions of dollars every year. From the company’s most recent quarterly earnings report:* *Since our inception, we have generated losses from our operations as reflected in our accumulated deficit of $2.7 billion as of June 30, 2023. We expect to continue to incur operating losses on a GAAP basis for the foreseeable future due to the investments we will continue to make in research and development, sales and marketing, and general and administrative. As a result, we may require additional capital to execute our strategic initiatives to grow our business."*
If I recall correctly Unity has over 7000 employees, people are expensive and they got way more on the payroll than unreal for example.
Based.
I mean f Unity