Godot 4.0 development enters feature freeze ahead of the first beta(godotengine.org)
godotengine.org
Godot 4.0 development enters feature freeze ahead of the first beta
https://godotengine.org/article/godot-4-0-development-enters-feature-freeze
121 comments
I found and fixed a small Godot bug, starting from zero knowledge of the engine code, in about a day and a half free time. It's really not hard to just patch stuff yourself if you're comfortable with C++.
Godot is not beautiful modern code or anything, but it's definitely not inscrutable layers of spaghetti which require deep expertise. It's very readable and compiles reasonably fast.
Godot is not beautiful modern code or anything, but it's definitely not inscrutable layers of spaghetti which require deep expertise. It's very readable and compiles reasonably fast.
Out of curiosity, are you funding it?
I've been funding it (a small amount monthly) for a long time now. I wish it had existed about 15 years ago in college when I had lots of time on my hands for toying with game making.
I've been funding it (a small amount monthly) for a long time now. I wish it had existed about 15 years ago in college when I had lots of time on my hands for toying with game making.
I'd fund it if I could use it to actually ship something and make money. I've donated to other software projects. If, say, for several thousand bucks they'd actually give me a tiny bit of support by fixing bugs in the "stable" branch that affect me then I'd pay up. At this point though if I want to actually ship using open source I find I can actually get things done faster using SDL2. Because SDL2 is a minimal layer over native if there is an issue I can actually figure out what native calls are happening in what order. If controller inputs are wonky or textures are the wrong color I can figure out why. Godot does try to use an understandability friendly subset of C++ (no template metaprogramming and such) but it is still too sophisticated for me to quickly dive in and understand how it all works; and it is certainly too complicated for its core maintainers to be able to quickly dive in and fix longstanding open issues in "stable".
How do you people feel about the Godot object and lifetime model? I found it hard to test my code because of how objects are tied to the tree, that emulating the tree isn't easy during testing, and that initialization during live use is different than if you instantiate manually, making it hard to rely on a constructor, since you might not be able to use it live.
I can't remember the exact details around this, since I only used Godot for a couple of jams and the last time was a year ago. But I was wondering if others have had the same reaction, perhaps this could be fixed? I love the engine in general, but this thing irked me.
I can't remember the exact details around this, since I only used Godot for a couple of jams and the last time was a year ago. But I was wondering if others have had the same reaction, perhaps this could be fixed? I love the engine in general, but this thing irked me.
/sarcasm/ Why would game devs write tests?
On a more serious note, I do expect test-ability isn't a high customer priority for Godot. Godot is self-hosted, maybe check how they run their tests?
On a more serious note, I do expect test-ability isn't a high customer priority for Godot. Godot is self-hosted, maybe check how they run their tests?
It’s something that’s pretty nice once you’ve implemented these lifecycles a bunch.
The tree turns out to be a great place to keep things, and you get several levels of control. Here’s how I think about it now.
`_init`: constructor. I usually use this to create dynamic child nodes
`_enter_tree`: now we have a parent; subscribe to signals, copy initial config, etc
`_ready`: I can be sure that all child nodes have called _ready, so anything I depend on there is… er, ready
`_exit_tree`: cleanup, especially anything we did with the parent and other ancestors. usually symmetric to `_enter_tree` if I’m using them
I just did a find all in my biggest recent project, and I never actually use `queue_free` or `free` for explicit memory management. Most of the times when I’ve thought I needed to, I actually was creating a bug
The tree turns out to be a great place to keep things, and you get several levels of control. Here’s how I think about it now.
`_init`: constructor. I usually use this to create dynamic child nodes
`_enter_tree`: now we have a parent; subscribe to signals, copy initial config, etc
`_ready`: I can be sure that all child nodes have called _ready, so anything I depend on there is… er, ready
`_exit_tree`: cleanup, especially anything we did with the parent and other ancestors. usually symmetric to `_enter_tree` if I’m using them
I just did a find all in my biggest recent project, and I never actually use `queue_free` or `free` for explicit memory management. Most of the times when I’ve thought I needed to, I actually was creating a bug
Thanks. Do you setup an artificial tree during testing? If so, how?
I’m not sure your mental model matches mine, but in my “real job” I deal with the shadow and virtual DOM. Maybe that’s the metaphor you’re looking for?
I’ll have to be a little practical and hope it makes sense. The tree in the editor is the same tree. Godot engine is written in Godot engine, so what is the distinction between being in the editor and being in the game?
The answer is that godot will ignore all project scripts by default while you are in the editor, but it offers mechanisms to enable them. The main way is a keyword in GDScript.
In Godot 3, you put `tool` as the first line of a script, and it will be loaded. Godot 4 has grown a pre-processy decorator syntax, so it’s the same, but `@tool`.
In your scripts, you can detect whether you are in the editor by checking `Engine.editor_hint`. You can do amazing things with this.
Then you can take it a step further, and convert your tool scripts into an addon. With an addon, which is just a directory structure for assets, your custom in-editor functionality becomes indistinguishable from native godot behavior.
https://docs.godotengine.org/en/stable/tutorials/plugins/run...
PS: I created a virtual node tree a few times to wrap UI components. Much like react. But honestly, I usually find a more idiomatic pattern later.
I’ll have to be a little practical and hope it makes sense. The tree in the editor is the same tree. Godot engine is written in Godot engine, so what is the distinction between being in the editor and being in the game?
The answer is that godot will ignore all project scripts by default while you are in the editor, but it offers mechanisms to enable them. The main way is a keyword in GDScript.
In Godot 3, you put `tool` as the first line of a script, and it will be loaded. Godot 4 has grown a pre-processy decorator syntax, so it’s the same, but `@tool`.
In your scripts, you can detect whether you are in the editor by checking `Engine.editor_hint`. You can do amazing things with this.
Then you can take it a step further, and convert your tool scripts into an addon. With an addon, which is just a directory structure for assets, your custom in-editor functionality becomes indistinguishable from native godot behavior.
https://docs.godotengine.org/en/stable/tutorials/plugins/run...
PS: I created a virtual node tree a few times to wrap UI components. Much like react. But honestly, I usually find a more idiomatic pattern later.
How do you remove objects if you don't queue free them? Just remove them from the tree?
Yes, or they are free’d automatically as the parent is free’d recursively. If you have called `add_child` on a node you created dynamically, godot will handle its lifecycle from there.
If you don’t add a dynamically-created node to the tree, you are responsible for `free`.
That almost never comes up, because I eventually figure out how to decompose everything into a tree Node, or! A Resource.
Resources are managed in a separate memory pool, and don’t need to be added to the tree for godot to take care of it. Go ahead, you just try and `free` a resource! ;)
If you don’t add a dynamically-created node to the tree, you are responsible for `free`.
That almost never comes up, because I eventually figure out how to decompose everything into a tree Node, or! A Resource.
Resources are managed in a separate memory pool, and don’t need to be added to the tree for godot to take care of it. Go ahead, you just try and `free` a resource! ;)
In the docs for Node.remove_child(Node node)[1] it says
"Removes a child node. The node is NOT deleted and must be deleted manually."
Do you still have to queue_free the top node that was removed from the tree, or else how is it being deleted. Or is there a different method to call for removing it from the tree.
BTW: I really like the `_init` / `_enter_tree` / `_ready` / `_exit_tree` lifecycle as was described.
1:https://docs.godotengine.org/en/stable/classes/class_node.ht...
"Removes a child node. The node is NOT deleted and must be deleted manually."
Do you still have to queue_free the top node that was removed from the tree, or else how is it being deleted. Or is there a different method to call for removing it from the tree.
BTW: I really like the `_init` / `_enter_tree` / `_ready` / `_exit_tree` lifecycle as was described.
1:https://docs.godotengine.org/en/stable/classes/class_node.ht...
queue_free removes the node from the tree and frees it.
remove_child just deactivates it, but keeps it around in memory for later.
remove_child just deactivates it, but keeps it around in memory for later.
Damn, I didn't know that. Time to remove queue_free from my project :)
Probably not the most efficient way to do it, but I setup test scenes for just the functionalities I wanted to test and run those manually.
It's not clear to me whether .NET 6 (and therefore C# support) is going to make 4.0 freeze. It's really just been one guy working on the dotnet6 branch, which is unfortunate.
I'm really excited for many features of Godot 4, and GDScript is perfectly adequate for UI glue code and stuff, but to write a serious game you really want C#.
I'm really excited for many features of Godot 4, and GDScript is perfectly adequate for UI glue code and stuff, but to write a serious game you really want C#.
>but to write a serious game you really want C#
I haven't followed game development in a long time, but has the industry moved to C#? I thought C# was limited to Unity and everyone else was still using C++?
I haven't followed game development in a long time, but has the industry moved to C#? I thought C# was limited to Unity and everyone else was still using C++?
You're correct, the industry has not moved to C#. Not even close.
The biggest player that uses it is Unity, but even they have their own special fork of Mono to get it to play nice.
Full Disclosure: I work for a Microsoft/Xbox Studio.
The biggest player that uses it is Unity, but even they have their own special fork of Mono to get it to play nice.
Full Disclosure: I work for a Microsoft/Xbox Studio.
Unity uses their own AOT compiler IL2CPP that translates C# code to C++. Mono is an option in builds, but most projects are using IL2CPP nowadays and have been moving to .Net core. Although C++ is king, C# has quickly caught up to be a close 2nd. Unity is used to make 50% of all mobile, pc, and consoles games (according to Unity https://unity.com/our-company).
[deleted]
> but to write a serious game you really want C#.
This is ridiculous. You absolutely can write a full game with GDScript or GDScript and C++. Keep in mind Godot has first class support for C++.
In fact, I'd argue C++ is far better than a bolted on C#...
This is ridiculous. You absolutely can write a full game with GDScript or GDScript and C++. Keep in mind Godot has first class support for C++.
In fact, I'd argue C++ is far better than a bolted on C#...
I don't have experience with GDScript, so please forgive the ignorant question.
Does GDScript have good debugging, linting, and profiling tools?
I'm not a game developer, but I'd love to hear your perspective on some of the criticisms I've encountered on the topic of scripting languages for game development.
One of the main criticisms I've heard of using scripting languages for game development is that they tend to be lacking when it comes to tooling.
The second form of criticism I've heard is that type issues become a serious problem as the size of game code growns past a certain point.
Does GDScript have good debugging, linting, and profiling tools?
I'm not a game developer, but I'd love to hear your perspective on some of the criticisms I've encountered on the topic of scripting languages for game development.
One of the main criticisms I've heard of using scripting languages for game development is that they tend to be lacking when it comes to tooling.
The second form of criticism I've heard is that type issues become a serious problem as the size of game code growns past a certain point.
> Does GDScript have good debugging, linting, and profiling tools?
Yes, everything is provided for. No need for separate tools, Godot comes with everything out of the box. (Of course "good" needs to be defined but I personally had no problems.)
> The second form of criticism I've heard is that type issues become a serious problem as the size of game code growns past a certain point.
GDScript has gradual typing support. You get at least TS-level of type safety if you want (but without the headache of TS.)
Also C# is not traditionally a game development language. It has automatic garbage management for which game development happens to be on of the few areas where that is not exactly ideal.
C# is mostly interesting for people already knowing C# or when there are specific performance needs where C# still outperforms GDScript (though personally I would rather write the performance sensitive parts in C++ or Rust).
Most people are highly advised to at least try GDScript. (Also it is very easy to mix and match languages. You can have parts in C#, parts in GDScript, parts in C++, no need to commit early to a specific language.)
Yes, everything is provided for. No need for separate tools, Godot comes with everything out of the box. (Of course "good" needs to be defined but I personally had no problems.)
> The second form of criticism I've heard is that type issues become a serious problem as the size of game code growns past a certain point.
GDScript has gradual typing support. You get at least TS-level of type safety if you want (but without the headache of TS.)
Also C# is not traditionally a game development language. It has automatic garbage management for which game development happens to be on of the few areas where that is not exactly ideal.
C# is mostly interesting for people already knowing C# or when there are specific performance needs where C# still outperforms GDScript (though personally I would rather write the performance sensitive parts in C++ or Rust).
Most people are highly advised to at least try GDScript. (Also it is very easy to mix and match languages. You can have parts in C#, parts in GDScript, parts in C++, no need to commit early to a specific language.)
> Also C# is not traditionally a game development language. It has automatic garbage management for which game development happens to be on of the few areas where that is not exactly ideal.
Are you forgetting about the now decades worth of games made with Unity? C# works perfectly fine for games, GC behavior can be optimized, it can be transpiled to native code, it has a huge ecosystem and is very easy to pick up. .NET 6 or 7 are faster than ever, while Unity is stuck on an old version of Mono, too.
It's certainly easier for devs coming from C++ or Java than "weird python-like scripting language that we had to invent and are now stuck with".
Are you forgetting about the now decades worth of games made with Unity? C# works perfectly fine for games, GC behavior can be optimized, it can be transpiled to native code, it has a huge ecosystem and is very easy to pick up. .NET 6 or 7 are faster than ever, while Unity is stuck on an old version of Mono, too.
It's certainly easier for devs coming from C++ or Java than "weird python-like scripting language that we had to invent and are now stuck with".
Did I say, you can't make games in C#? Why do you feel the need to defend C#? You are arguing against a straw man.
It is simply a fact that a large part of the professional gaming industry uses C++. That one might be better off using a language without automatic garbage collection for performance critical parts in many cases is pretty standard wisdom. Not sure what there is to argue about.
> It's certainly easier for devs coming from C++ or Java than "weird python-like scripting language that we had to invent and are now stuck with".
So you have never used GDScript but feel qualified to have a strong opinion on that matter, why is that?
It is simply a fact that a large part of the professional gaming industry uses C++. That one might be better off using a language without automatic garbage collection for performance critical parts in many cases is pretty standard wisdom. Not sure what there is to argue about.
> It's certainly easier for devs coming from C++ or Java than "weird python-like scripting language that we had to invent and are now stuck with".
So you have never used GDScript but feel qualified to have a strong opinion on that matter, why is that?
> So you have never used GDScript but feel qualified to have a strong opinion on that matter, why is that?
I have, which makes me feel confident in stating that it's a language that didn't have to exist, doesn't have a healthy ecosystem backing it, which pulls focus from the actual good (or to be good) bits of Godot, which there are a lot of, and in the end makes people doubt that the language they would actually be productive in is a first class citizen for the engine vendors.
I have, which makes me feel confident in stating that it's a language that didn't have to exist, doesn't have a healthy ecosystem backing it, which pulls focus from the actual good (or to be good) bits of Godot, which there are a lot of, and in the end makes people doubt that the language they would actually be productive in is a first class citizen for the engine vendors.
> I have, which makes me feel confident in stating that it's a language that didn't have to exist
If you have, you should be aware of the history of the project and then I am perplexed why you would make this claim.
They tried using multiple different languages until finally settled for developing GDScript. It is not a decision they just made willy-nilly but something they decided after using different languages did not work out as they hoped it would.
> doesn't have a healthy ecosystem backing
What ecosystem? The ecosystem is Godot and GDScript is an integral part of it.
> in the end makes people doubt that the language they would actually be productive in is a first class citizen for the engine vendors
If you had proper experience with Godot you would know that GDScript is very well liked in the community and people are actually very critical about C# integration, seeing it as more of a distraction and waste of resources. (Of course people that don't like GDScript might simply not stay in the Godot community, so I admit some self selecting bias might be going it.)
The C# integration was only done because Microsoft paid them to do it.
If you have, you should be aware of the history of the project and then I am perplexed why you would make this claim.
They tried using multiple different languages until finally settled for developing GDScript. It is not a decision they just made willy-nilly but something they decided after using different languages did not work out as they hoped it would.
> doesn't have a healthy ecosystem backing
What ecosystem? The ecosystem is Godot and GDScript is an integral part of it.
> in the end makes people doubt that the language they would actually be productive in is a first class citizen for the engine vendors
If you had proper experience with Godot you would know that GDScript is very well liked in the community and people are actually very critical about C# integration, seeing it as more of a distraction and waste of resources. (Of course people that don't like GDScript might simply not stay in the Godot community, so I admit some self selecting bias might be going it.)
The C# integration was only done because Microsoft paid them to do it.
> They tried using multiple different languages until finally settled for developing GDScript. It is not a decision they just made willy-nilly but something they decided after using different languages did not work out as they hoped it would.
This is a fair point and it was probably a good fit for their own needs, but I think that the person you're responding to seems to suggest that GDScript and the entire idea behind it basically suffers from NIH - Not Invented Here. So while it may seem like a good idea to them and even many other people out there, they are missing out on a large amount of great tooling (IDEs like Rider or even Visual Studio), lots of development tooling (which they have to write themselves), code style checks, static code analysis tools (I don't think GDScript is supported by SonarQube or has an equivalent to gofmt), as well as a lot of knowledge about design patterns and possibilities of the type systems, which will sometimes feel odd, like Godot's approach to Singletons: https://docs.godotengine.org/en/stable/tutorials/scripting/s...
That's not to say that this will matter for most people - it's likely that for most users it's perfectly sufficient to have a quick and simple language that can have its scripts be edited right there in the editor and is reasonably easy to learn, which is where GDScript shines. Plus, no compile times are really great as well, at least for smaller projects (anyone who has tried compiling large codebases will know how annoying iteration can be in them).
But when you want to hire developers in the industry and take advantage of the existing C#/C++ knowledge, then using either of those and building the whole engine/documentation around them is probably the better choice. If you don't, your efforts might be split a bit thin, e.g. how C# documentation might not be as fleshed out in comparison (a bit like Boo used to be in Unity, which was deprecated eventually), or how C++ might be way lower level (which Unreal Engine also suffers from, because of which they offer their Blueprints system).
> What ecosystem? The ecosystem is Godot and GDScript is an integral part of it.
With time, Godot will probably have lots of possibilities around game development related topics, albeit in a focused manner - there was a terrain plugin written in GDScript, some efforts to get dynamic rendering scales up and running, probably some game logic related stuff and libraries for working with splines and whatnot. That said, many of these will feel a bit barebones and underdeveloped, because Godot doesn't have a large (or any) paid assets scene, which in turn means that the majority of packages will be volunteer efforts, for example: https://godotengine.org/asset-library/asset/231
That said, GDScript absolutely does not have a large ecosystem around general purpose computing tasks. Suppose I want a file server embedded in my multiplayer game, to allow users to fetch asset packages dynamically, like Half Life community server maps, which might turn out a bit difficult with GDScript. Similarly, if I want a WebSocket connection to subscribe my game to announcements from a central server, that might be difficult to get working. Similarly, if I want gRPC calls or to consume messages from RabbitMQ, there might also be no support from that. Talking among multiple other peer servers with PKIX or JWT? Probably not too easy to do. OAuth2 flows or something like OIDC? Connecting to a database from a server, to fetch player profiles? Nope, still need an additional separate API app that will talk through a RESTful API that GDScript might allow me to consume - even when I know that I will only be running the servers myself and don't need to think about the n-tier architecture. Of course, I think there were attempts at getting SQLite support working, which was pretty cool!
Of course, most of what's mentioned are just ideas around larger projects that might need some sort of a networking implementation, but the same might apply to image processing, audio processing, parsing data formats etc. That's not to say that Godot won't get around to at least some of those eventually, but in the case of C# and .NET/Mono in general, it might just mean pulling a NuGet package and reusing some of your old code from Unity/Stride projects (at least the non game engine specific parts).
That's not relevant for like 98% of the games out there like single player platformers, shooters etc., but you'd be surprised about how many cool ideas people have around general purpose computing in games!
> If you had proper experience with Godot you would know that GDScript is very well liked in the community and people are actually very critical about C# integration, seeing it as more of a distraction and waste of resources.
This is definitely a pain point and an issue that will cause division - since most game engines won't fare too well supporting multiple languages, especially if already spread thin without the support of a million/billion dollar org behind it all.
That said, you can hire C# developers and C# game developers, with experience in other engines. In that regard, GDScript might be a tough sell. The current community doesn't care much about that, or the things I've mentioned before, because they're largely hobbyists who generally develop games due to their own passion, instead of what a Gantt chart says. Thus, there might be a bit of a self-selection going on.
Either way, here's hoping that Godot will have a bright future ahead of it, currently still considering using it over Unity due to its open nature, albeit primarily using C# with engine agnostic code libraries. I do hope that C# support doesn't fizzle out, because personally I find it to be a pretty great language with a nice ecosystem around it.
This is a fair point and it was probably a good fit for their own needs, but I think that the person you're responding to seems to suggest that GDScript and the entire idea behind it basically suffers from NIH - Not Invented Here. So while it may seem like a good idea to them and even many other people out there, they are missing out on a large amount of great tooling (IDEs like Rider or even Visual Studio), lots of development tooling (which they have to write themselves), code style checks, static code analysis tools (I don't think GDScript is supported by SonarQube or has an equivalent to gofmt), as well as a lot of knowledge about design patterns and possibilities of the type systems, which will sometimes feel odd, like Godot's approach to Singletons: https://docs.godotengine.org/en/stable/tutorials/scripting/s...
That's not to say that this will matter for most people - it's likely that for most users it's perfectly sufficient to have a quick and simple language that can have its scripts be edited right there in the editor and is reasonably easy to learn, which is where GDScript shines. Plus, no compile times are really great as well, at least for smaller projects (anyone who has tried compiling large codebases will know how annoying iteration can be in them).
But when you want to hire developers in the industry and take advantage of the existing C#/C++ knowledge, then using either of those and building the whole engine/documentation around them is probably the better choice. If you don't, your efforts might be split a bit thin, e.g. how C# documentation might not be as fleshed out in comparison (a bit like Boo used to be in Unity, which was deprecated eventually), or how C++ might be way lower level (which Unreal Engine also suffers from, because of which they offer their Blueprints system).
> What ecosystem? The ecosystem is Godot and GDScript is an integral part of it.
With time, Godot will probably have lots of possibilities around game development related topics, albeit in a focused manner - there was a terrain plugin written in GDScript, some efforts to get dynamic rendering scales up and running, probably some game logic related stuff and libraries for working with splines and whatnot. That said, many of these will feel a bit barebones and underdeveloped, because Godot doesn't have a large (or any) paid assets scene, which in turn means that the majority of packages will be volunteer efforts, for example: https://godotengine.org/asset-library/asset/231
That said, GDScript absolutely does not have a large ecosystem around general purpose computing tasks. Suppose I want a file server embedded in my multiplayer game, to allow users to fetch asset packages dynamically, like Half Life community server maps, which might turn out a bit difficult with GDScript. Similarly, if I want a WebSocket connection to subscribe my game to announcements from a central server, that might be difficult to get working. Similarly, if I want gRPC calls or to consume messages from RabbitMQ, there might also be no support from that. Talking among multiple other peer servers with PKIX or JWT? Probably not too easy to do. OAuth2 flows or something like OIDC? Connecting to a database from a server, to fetch player profiles? Nope, still need an additional separate API app that will talk through a RESTful API that GDScript might allow me to consume - even when I know that I will only be running the servers myself and don't need to think about the n-tier architecture. Of course, I think there were attempts at getting SQLite support working, which was pretty cool!
Of course, most of what's mentioned are just ideas around larger projects that might need some sort of a networking implementation, but the same might apply to image processing, audio processing, parsing data formats etc. That's not to say that Godot won't get around to at least some of those eventually, but in the case of C# and .NET/Mono in general, it might just mean pulling a NuGet package and reusing some of your old code from Unity/Stride projects (at least the non game engine specific parts).
That's not relevant for like 98% of the games out there like single player platformers, shooters etc., but you'd be surprised about how many cool ideas people have around general purpose computing in games!
> If you had proper experience with Godot you would know that GDScript is very well liked in the community and people are actually very critical about C# integration, seeing it as more of a distraction and waste of resources.
This is definitely a pain point and an issue that will cause division - since most game engines won't fare too well supporting multiple languages, especially if already spread thin without the support of a million/billion dollar org behind it all.
That said, you can hire C# developers and C# game developers, with experience in other engines. In that regard, GDScript might be a tough sell. The current community doesn't care much about that, or the things I've mentioned before, because they're largely hobbyists who generally develop games due to their own passion, instead of what a Gantt chart says. Thus, there might be a bit of a self-selection going on.
Either way, here's hoping that Godot will have a bright future ahead of it, currently still considering using it over Unity due to its open nature, albeit primarily using C# with engine agnostic code libraries. I do hope that C# support doesn't fizzle out, because personally I find it to be a pretty great language with a nice ecosystem around it.
> But when you want to hire developers in the industry and take advantage of the existing C#/C++ knowledge, then using either of those and building the whole engine/documentation around them is probably the better choice.
Programming in C++ is well supported though. This is the main reason I personally would not use C# in Godot much. It is really good general purpose language that will do fine in almost any situation but it will not excel as much on performance critical stuff like C++ does but also does not have the ease of use for quick scripting like GDScript.
I guess it is a matter of the philosophies. Some people really like to use just a single language and then C# is a excellent choice while I think having languages optimized for certain strengths might be a good idea. So for me it is GDScript + C++/Rust/Nim if need be (the later ones also providing some safety on top of performance). Plus the vast majority of hobbyist devs will never run into any limitation with GDScript to begin with.
> That said, GDScript absolutely does not have a large ecosystem around general purpose computing tasks.
You have the whole C/C++ ecosystem of libraries that you can use if need be. Maybe not from GDScript directly but from a GDExtension language binding of your choice. If you are at the point that you can even dare to think about complex multiplayer games, you are a professional and can be safely expected to know how to use C/C++ libraries, mostly.
Though the ecosystem C# brings additionally to the table is also very nice to have, that much I admit.
> That said, you can hire C# developers and C# game developers
Can you, though? Writing a CRUD app in C# is quiete different to writing C# in Unity which is different to C# in Godot.
Maybe I am biased because I enjoy learning programming language but I am genuinely confused about the practice of hiring for specific languages. Maybe there are some developers that refuse to learn anything new, having been much on the other side.
Learning a new language takes days or worst case a week, learning libraries, best practices, switching towards a whole new area like game dev vs backend dev, that takes lots and lots of time. You can't really take a Unity dev and have them be productive in Godot from day one, they still need to learn how the engine works, how it expects them to structure their code and so on.
Anyone that has worked with a scripting language before can learn GDScript in a few hours, that is not a blocker at all. Wrapping you head around nodes and all on the other hand takes some time.
I think hiring for general game dev experience works out much better, as the concepts translate through languages and specific engines.
> Either way, here's hoping that Godot will have a bright future ahead of it, currently still considering using it over Unity due to its open nature, albeit primarily using C# with engine agnostic code libraries. I do hope that C# support doesn't fizzle out, because personally I find it to be a pretty great language with a nice ecosystem around it.
I think they are quiete committed to it at this point. There is obviously vast outside interest in it from all the people coming from Unity. Plus Microsoft has obviously an interest to keep C# in Godot and so will probably keep the money flowing.
That said Godot is not ready for complex 3d games yet with or without C#. It is still far away from Unity. Godot 4 did make big steps but I would expect that will take at least until 4.1 for it to be ready for bigger professional projects. For 2d though it might be best in class and superior to Unity.
Programming in C++ is well supported though. This is the main reason I personally would not use C# in Godot much. It is really good general purpose language that will do fine in almost any situation but it will not excel as much on performance critical stuff like C++ does but also does not have the ease of use for quick scripting like GDScript.
I guess it is a matter of the philosophies. Some people really like to use just a single language and then C# is a excellent choice while I think having languages optimized for certain strengths might be a good idea. So for me it is GDScript + C++/Rust/Nim if need be (the later ones also providing some safety on top of performance). Plus the vast majority of hobbyist devs will never run into any limitation with GDScript to begin with.
> That said, GDScript absolutely does not have a large ecosystem around general purpose computing tasks.
You have the whole C/C++ ecosystem of libraries that you can use if need be. Maybe not from GDScript directly but from a GDExtension language binding of your choice. If you are at the point that you can even dare to think about complex multiplayer games, you are a professional and can be safely expected to know how to use C/C++ libraries, mostly.
Though the ecosystem C# brings additionally to the table is also very nice to have, that much I admit.
> That said, you can hire C# developers and C# game developers
Can you, though? Writing a CRUD app in C# is quiete different to writing C# in Unity which is different to C# in Godot.
Maybe I am biased because I enjoy learning programming language but I am genuinely confused about the practice of hiring for specific languages. Maybe there are some developers that refuse to learn anything new, having been much on the other side.
Learning a new language takes days or worst case a week, learning libraries, best practices, switching towards a whole new area like game dev vs backend dev, that takes lots and lots of time. You can't really take a Unity dev and have them be productive in Godot from day one, they still need to learn how the engine works, how it expects them to structure their code and so on.
Anyone that has worked with a scripting language before can learn GDScript in a few hours, that is not a blocker at all. Wrapping you head around nodes and all on the other hand takes some time.
I think hiring for general game dev experience works out much better, as the concepts translate through languages and specific engines.
> Either way, here's hoping that Godot will have a bright future ahead of it, currently still considering using it over Unity due to its open nature, albeit primarily using C# with engine agnostic code libraries. I do hope that C# support doesn't fizzle out, because personally I find it to be a pretty great language with a nice ecosystem around it.
I think they are quiete committed to it at this point. There is obviously vast outside interest in it from all the people coming from Unity. Plus Microsoft has obviously an interest to keep C# in Godot and so will probably keep the money flowing.
That said Godot is not ready for complex 3d games yet with or without C#. It is still far away from Unity. Godot 4 did make big steps but I would expect that will take at least until 4.1 for it to be ready for bigger professional projects. For 2d though it might be best in class and superior to Unity.
> Programming in C++ is well supported though. This is the main reason I personally would not use C# in Godot much. It is really good general purpose language that will do fine in almost any situation but it will not excel as much on performance critical stuff like C++ does but also does not have the ease of use for quick scripting like GDScript.
This is an excellent point, though it also brings the complexity of C++ as a language to light as well. That's why many use Blueprints in Unreal Engine, just so they wouldn't deal with a powerful language like C++ that has lots of footguns, despite its libraries, interop and other capabilities. So much so, that they tried getting C# support into the engine (as well as a few others over the years).
In a sense, it's a spectrum, with something like C++ on one end, C# somewhere in the middle (reasonably performant and capable, but also with relatively few footguns) and GDScript on the other end, even though the library support isn't as good as, say, Python. Hence, if you need bunches of fancy functionality, you'll probably need to choose between either C++ or C#, not having access to the latter complicating things.
> Can you, though? Writing a CRUD app in C# is quite different to writing C# in Unity which is different to C# in Godot.
The concerns are a bit different, especially when you're racing against the render loop, but I'd argue that it's not all that dissimilar, be it in regards to C# in specific engines or different types of applications.
Personally, with a few key differences in mind, there isn't that much difference between developing local CRUD apps, doing web development, or even game development - those key differences in the case of game development being more focus on linear algebra and performance, and utilizing other abstractions (for example the whole scene graph concept and traversing it, which honestly is not that dissimilar from something like Pinia stores, which might be an interesting comparison).
Between different engines, you have the whole component system of Unity, which I think is a better fit for my personal headspace, but then again having everything be nodes in Godot is also great, especially since dealing with prefabs is no longer quite as awkward, even though you cannot attach multiple scripts to a single node, which is inconvenient.
In comparison, writing any kind of piece of software in Rust would be a wildly different experience from doing the same in C#, due to how different the language concepts (e.g. borrow checker) are. Similarly, I'd personally say the same about C++ and C# (the whole approach to memory management, even with smart pointers) and C# and GDScript (the gradual typing in particular).
> Learning a new language takes days or worst case a week, learning libraries, best practices, switching towards a whole new area like game dev vs backend dev, that takes lots and lots of time.
I'd suggest that learning a new language can take anywhere from a few months to close to multiple years, depending on the language and what you intend to do in it, especially when coupled with particular stacks/frameworks/engines. Just look at how much C++ software there is out there and how much of it is full of memory management related bugs. Sure, you might knock something together after a weekend with a book or two, but getting to truly know the ins and outs of a language, as well as some of the more popular design patterns (at least in the context of that language) will probably take way more than a week.
I do fully agree with your points about different engines having plenty of specifics, but would like to offer the suggestion that transferring from C# in Unity to C# in Godot will be a comparatively easy process, versus learning GDScript and not being able to use any of your in house non game engine specific libraries for development. Something like maths for splines, some back end logic for handling inventories, levelling up, dialogue trees, quest systems etc. Of course, in practice many end up being tied to a particular engine because nobody cares about portability - much like ORMs in practice rarely allow for painfree migration across different DBs.
> That said Godot is not ready for complex 3d games yet with or without C#.
With this, I can agree. It's nice to think about the future of the game engine, though. Somehow Godot seems to have gotten way more traction than the likes of Stride (which was great), NeoAxis, or even something like jMonkeyEngine. Not sure what their magic sauce was, but I hope they have a bright future ahead of them.
This is an excellent point, though it also brings the complexity of C++ as a language to light as well. That's why many use Blueprints in Unreal Engine, just so they wouldn't deal with a powerful language like C++ that has lots of footguns, despite its libraries, interop and other capabilities. So much so, that they tried getting C# support into the engine (as well as a few others over the years).
In a sense, it's a spectrum, with something like C++ on one end, C# somewhere in the middle (reasonably performant and capable, but also with relatively few footguns) and GDScript on the other end, even though the library support isn't as good as, say, Python. Hence, if you need bunches of fancy functionality, you'll probably need to choose between either C++ or C#, not having access to the latter complicating things.
> Can you, though? Writing a CRUD app in C# is quite different to writing C# in Unity which is different to C# in Godot.
The concerns are a bit different, especially when you're racing against the render loop, but I'd argue that it's not all that dissimilar, be it in regards to C# in specific engines or different types of applications.
Personally, with a few key differences in mind, there isn't that much difference between developing local CRUD apps, doing web development, or even game development - those key differences in the case of game development being more focus on linear algebra and performance, and utilizing other abstractions (for example the whole scene graph concept and traversing it, which honestly is not that dissimilar from something like Pinia stores, which might be an interesting comparison).
Between different engines, you have the whole component system of Unity, which I think is a better fit for my personal headspace, but then again having everything be nodes in Godot is also great, especially since dealing with prefabs is no longer quite as awkward, even though you cannot attach multiple scripts to a single node, which is inconvenient.
In comparison, writing any kind of piece of software in Rust would be a wildly different experience from doing the same in C#, due to how different the language concepts (e.g. borrow checker) are. Similarly, I'd personally say the same about C++ and C# (the whole approach to memory management, even with smart pointers) and C# and GDScript (the gradual typing in particular).
> Learning a new language takes days or worst case a week, learning libraries, best practices, switching towards a whole new area like game dev vs backend dev, that takes lots and lots of time.
I'd suggest that learning a new language can take anywhere from a few months to close to multiple years, depending on the language and what you intend to do in it, especially when coupled with particular stacks/frameworks/engines. Just look at how much C++ software there is out there and how much of it is full of memory management related bugs. Sure, you might knock something together after a weekend with a book or two, but getting to truly know the ins and outs of a language, as well as some of the more popular design patterns (at least in the context of that language) will probably take way more than a week.
I do fully agree with your points about different engines having plenty of specifics, but would like to offer the suggestion that transferring from C# in Unity to C# in Godot will be a comparatively easy process, versus learning GDScript and not being able to use any of your in house non game engine specific libraries for development. Something like maths for splines, some back end logic for handling inventories, levelling up, dialogue trees, quest systems etc. Of course, in practice many end up being tied to a particular engine because nobody cares about portability - much like ORMs in practice rarely allow for painfree migration across different DBs.
> That said Godot is not ready for complex 3d games yet with or without C#.
With this, I can agree. It's nice to think about the future of the game engine, though. Somehow Godot seems to have gotten way more traction than the likes of Stride (which was great), NeoAxis, or even something like jMonkeyEngine. Not sure what their magic sauce was, but I hope they have a bright future ahead of them.
> It's certainly easier for devs coming from C++ or Java than "weird python-like scripting language that we had to invent and are now stuck with".
??? You can do everything in Godot in C++...
And GDScript isn't exactly a 'weird' language, it's downright ordinary in terms of semantics and features. The feature is that it's part of the engine and maps directly to C++ methods in the game engine...
??? You can do everything in Godot in C++...
And GDScript isn't exactly a 'weird' language, it's downright ordinary in terms of semantics and features. The feature is that it's part of the engine and maps directly to C++ methods in the game engine...
GDScript is fine and I use it but it's a stretch to compare its type system to TypeScript. GDScript doesn't have generics let alone conditional types, string template types, variadic tuple types, etc. TS is significantly more sound as well if you turn on a lot of the strictness options.
Between XNA, monogame, Unity, etc. there a metric f###-ton of games written using the C# language.
I mean, GDScript doesn't exist outside of the Godot engine. Debugging for it is the same as debugging a Godot game. All GDScript functions are C++ methods. Also, there are type hints if you want.
If you're going to be doing a very large, ambitious game, odds are you'll also be creating your own C++ methods and thus debugging using C++ tools and the game engine tools...
If you're going to be doing a very large, ambitious game, odds are you'll also be creating your own C++ methods and thus debugging using C++ tools and the game engine tools...
GDScript 2.0 has had some major performance improvements. While C# will still be faster, I find GDScript in Godot 4 to be viable now for things it wasn't in Godot 3.
I still rely on GDNative for really performance critical systems though.
I still rely on GDNative for really performance critical systems though.
Sounds like Godot 4 is replacing GDNative with GDExtension. Just wondering if you have tried it out and have any thoughts. Is it a smoother experience / about the same etc.
I have only briefly looked at it. All in all it looks very similar to GDNative, albeit a little cleaner. It will be nice to finally be able to expand functionality without recompiling the engine.
Right now I rely on nim bindings for GDNative so it might be awhile before I make the change over, unless I decide to port my code to C++ or update the bindings myself.
Right now I rely on nim bindings for GDNative so it might be awhile before I make the change over, unless I decide to port my code to C++ or update the bindings myself.
> but to write a serious game you really want C#.
I asked someone on Twitter about this the other day [0], and I'm genuinely curious: what is it about C# that makes game development serious?
0. https://twitter.com/LegatXyotic/status/1552219744723402756
I asked someone on Twitter about this the other day [0], and I'm genuinely curious: what is it about C# that makes game development serious?
0. https://twitter.com/LegatXyotic/status/1552219744723402756
I won’t use the word “serious” but my limited personal experience is that C# feels like the right balance between flexibility and performance.
Rust is a joy to write in but I personally find that it asks a lot from you when you just want to ship a game that doesn’t need to be safety rated.
C++ is a great choice but it’s C++ and I’m just not good enough to enjoy a language with fewer guardrails. It also has similar verbosity issues to Rust and (likely because I’m a noob) eats up a lot of my time chasing dumb bugs rather than making a game.
I do most of my game dev in TypeScript because it’s a wonderful language and web is a great platform to easily ship toy games (my specialty). But it just isn’t fast enough for anything major.
Rust is a joy to write in but I personally find that it asks a lot from you when you just want to ship a game that doesn’t need to be safety rated.
C++ is a great choice but it’s C++ and I’m just not good enough to enjoy a language with fewer guardrails. It also has similar verbosity issues to Rust and (likely because I’m a noob) eats up a lot of my time chasing dumb bugs rather than making a game.
I do most of my game dev in TypeScript because it’s a wonderful language and web is a great platform to easily ship toy games (my specialty). But it just isn’t fast enough for anything major.
I find it hard to imagine whatever glue language you choose for an engine like Godot would really matter that much. All you’re implementing is the business logic. Even the slowest language can run through basic business logic in the blink of an eye relative to the heavy duty that the Godot systems are doing.
Eve Online runs on *python*, for instance. So does Blender. For a glue language, I am highly doubtful that the .net is that much faster than v8 or any other runtime to make a difference.
Eve Online runs on *python*, for instance. So does Blender. For a glue language, I am highly doubtful that the .net is that much faster than v8 or any other runtime to make a difference.
Agreed - our company's app isn't a game but is built on top of UE4, and nearly all of our code is in Python and it's never the bottleneck, not by a mile.
So you think all the talk about performance tuning in games is just made up, or what?
What ends up happening is you write scripts for lower compile times and ease of use. Then if something is too slow you rewrite it in native. The speed of the scripting tier lets you write less in native. Its not irrelevant at all.
What ends up happening is you write scripts for lower compile times and ease of use. Then if something is too slow you rewrite it in native. The speed of the scripting tier lets you write less in native. Its not irrelevant at all.
Most of it is, because most of it is cargo-culting by amateurs who just believe what they read on SO and forums and who have never actually written anything non-trivial, much less shipped a game.
Are you saying they misunderstand what they're cargo-culting or are you saying amateur game scripts run fast enough? To cargo-cult it needs to be relevant somewhere, so either way it shows the blanket statement is false, no?
I'm saying most amateur games do run fast enough, and that for those which don't, the bottleneck is more likely to be related to poor caching, unnecessary allocations or unoptimized assets, etc, rather than just the language used. You really have to go out of your way nowadays to actually slow a game down with just bad code.
And many of the idioms people abide by may no longer be relevant, or may only be relevant in niche but not general cases.
And many of the idioms people abide by may no longer be relevant, or may only be relevant in niche but not general cases.
Exactly. The Godot components are very performant, and the glue code doesn't get in the way. And Godot 4 is getting compute shaders, IIRC.
I've built a few custom engines over the past decode, also shipped a few games. I've lately been working with Bevy in Rust, and I really absolutely love it. It's the perfect framework (for me). Bevy gets out of the way enough where I don't feel like I have to fight with it, which is what always annoyed me with actual game engines. Plus, I love working with Rust.
> isn’t fast enough for anything major.
I think it could be fast enough if portability to different platforms wasn't such a high priority for game studios these days. Nobody wants to write typescript and then pay $50M for someone to port it for Switch or whatever.
I think it could be fast enough if portability to different platforms wasn't such a high priority for game studios these days. Nobody wants to write typescript and then pay $50M for someone to port it for Switch or whatever.
gdscript is dynamically typed. If you have the large arrays of structs common in gamedev, then all data members are boxed, significantly increasing memory usage compared to something like C#.
C# objects are boxed too.
Boxing is taking a Value Type (struct, int, enum, etc) and converting it to an Object. So Objects aren’t boxed.
Apparently we have different definitions of boxing. To me, and I've always used it (and seen it used) like this, a boxed value is a value that's stored on the heap and passed as a pointer. Maybe C# has a different definition?
No, from the C# docs[1] - Boxing is the process of converting a value type to the type object or to any interface type implemented by this value type
[1] https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...
[1] https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...
Right, so then in C# a boxed value is an object as far as I can tell.
That’s correct, but not what you said. You said objects are boxed. Values are boxed to create a reference by wrapping it in an object, objects are already reference types so there’s no boxing.
I'm not extremely familiar with C# objects, but I think I get the confusion now. My point was that objects are boxed values, and that most things in C# are (to my knowledge) objects. I guess I used slightly the wrong words.
Well you could always go with C++ but C# has a solid balance of high level features, good libraries, good tooling, a feature full (if not slick) threading mode, performance features when you need them and good interoperability with native code.
Its not always fun or sexy to rewrite a reference type to a value type to get around your GC but you _can_ do that in C#. Its a have your cake and eat it sort of language.
Its not always fun or sexy to rewrite a reference type to a value type to get around your GC but you _can_ do that in C#. Its a have your cake and eat it sort of language.
Can you elaborate on that? Do you mean rewriting existing classes as structs so they go on the stack?
Yes, just an example of one of the many performance minded complications that C# brings to the table. You can even use raw pointers if you want to.
https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
Probably not serious, just that it's the language used in unity
Does Godot's implenetation of C#/.net include the .net temeletry?
https://github.com/dotnet/sdk/issues/14556
https://github.com/dotnet/sdk/issues/14556
The telemetry isn’t in C#/.NET proper, it’s in the `dotnet` CLI utility.
Former professional game dev getting into Godot recently for fun and maybe for hire.
What are the limitations of gdscript you allude to? Let's say I want to render an infinite scrolling hex grid. Why would c# excel or gdscript struggle?
What are the limitations of gdscript you allude to? Let's say I want to render an infinite scrolling hex grid. Why would c# excel or gdscript struggle?
GDscript is a bit slow. It's not an issue if you use it to keep track of a reasonable amount of in-game data and control the objects to render. But it becomes an issue if you decide to write game intelligence in it, or keep track of a lot of things.
It also doesn't have an all integrated top of the market IDE, only the Godot IDE. (Although I don't think you gain anything from using a 3rd party IDE in a Godot game. Even less something like Visual Studio.)
It also doesn't have an all integrated top of the market IDE, only the Godot IDE. (Although I don't think you gain anything from using a 3rd party IDE in a Godot game. Even less something like Visual Studio.)
The Wiki page says it already supports C#. As completely on the outside, what is missing?
It doesn't support .NET6 specifically which is what parent is asking. According to the github issue it seems that the plan is that .NET6 support will be merged after godot 4 is fully released and stabilized.
Godot ~3.2+ has support for a slightly older version of C# via Mono, I think it's the equivalent of .NET 4.8.
IIRC (and this could be wrong / have changed since I last looked into it) the idea was to re-work this in Godot 4 to provide more like bindings, so that users could opt to use Mono, .NET 6, CoreCLR, NativeAOT, or whatever version they preferred.
IIRC (and this could be wrong / have changed since I last looked into it) the idea was to re-work this in Godot 4 to provide more like bindings, so that users could opt to use Mono, .NET 6, CoreCLR, NativeAOT, or whatever version they preferred.
[deleted]
Godot is effectively not accepting contributions, and masquerades as open source. List comprehension, one of the most sought-after features and requested by dozens of people, is repeatedly undermined by maintainers, because they happen to dislike the syntax. Godot offers nothing similar in terms of processing arrays, so it makes any code involving them ugly and more complex than it needs to be.
There was even a pull request implementing this feature opened, but they claim the assigned maintainer just didn't have the time to review it yet (over 5 years!). One person can effectively stall all progress out of spite. That's no way to run an open source project.
Just look at this discussion: https://github.com/godotengine/godot-proposals/issues/2972
There was even a pull request implementing this feature opened, but they claim the assigned maintainer just didn't have the time to review it yet (over 5 years!). One person can effectively stall all progress out of spite. That's no way to run an open source project.
Just look at this discussion: https://github.com/godotengine/godot-proposals/issues/2972
> That's no way to run an open source project.
The way contributions are accepted (or not) is completely unrelated to the project being open source or not. It's always up to the maintainer to decide whether a feature should be merged or not. Open source projects are not popularity contests.
The way contributions are accepted (or not) is completely unrelated to the project being open source or not. It's always up to the maintainer to decide whether a feature should be merged or not. Open source projects are not popularity contests.
I find it a bit untrustworthy when someone frames a language design issue as representative of the way the project is run. List comprehension is a feature that comparatively few languages have, and I can easily imagine that the GDScript team has other things they consider a priority.
For a programming language, 5 years is not at all an unusual delay when we're talking about an extension to the basic syntax.
For a programming language, 5 years is not at all an unusual delay when we're talking about an extension to the basic syntax.
Open source != open contribution.
Don't like how they run it? Fork it. The maintainers have ZERO obligation to merge your PRs, especially when they don't actually agree with it.
Don't like how they run it? Fork it. The maintainers have ZERO obligation to merge your PRs, especially when they don't actually agree with it.
Why would you want list comprehensions in a game engine? It's just sugar to make looping over a list or array look more functional but not particularly useful in a game.
What's so special about games that makes it not useful? Python has it and it's bread and butter, and Godot language is basically a gimped, less expressive, and less useful knockoff of python
> gimped, less expressive
That's the point. Lots of what Python does isn't required in a game engine and is slow.
It's basically visual scripting but quicker to produce, the whole thing is C++ underneath.
That's the point. Lots of what Python does isn't required in a game engine and is slow.
It's basically visual scripting but quicker to produce, the whole thing is C++ underneath.
So basically instead of
number_list = [ x for x in range(20) if x % 2 == 0]
print(number_list)
auto number_list = std::views::iota(0, 20) | std::views::filter([](const int n) {return n % 2 == 0; });
for(int num: number_list)
std::cout << num << ' ';Maybe look at the code of real games out there to find out why list comprehensions aren't needed in a game engine specific language and what typical code looks like...
Once upon a time I was on SCEE offices in SOHO, was IGDA member for almost a decade, attended a couple of GDCE back in the day, regular visitor of Flipcode and GameDev.net back when they actually mattered.
Maybe don't try to guess the possible lack of knowledge of random people on the Internet.
Maybe don't try to guess the possible lack of knowledge of random people on the Internet.
Fair enough but while I've used list comprehensions or similar constructs while doing stats, never seen it in game code.
Usually it's just incrementing things in a loop, rather than creating lists...
Like why wouldn't you just do:
for x in range(20):
Usually it's just incrementing things in a loop, rather than creating lists...
Like why wouldn't you just do:
for x in range(20):
if x % 2 == 0
print(x)
I was pointing out how much Python like code it is possible to write in modern C++, everything else is irrelevant.
> One person can effectively stall all progress out of spite.
I'm not sure about this one, I can understand why someone might agree with some of the arguments about list comprehension making readability worse, like stated in this comment: https://github.com/godotengine/godot-proposals/issues/2972#i...
Personally, I enjoy both LINQ in C# and Streams in Java, perhaps more than a one liner. But again, that's a personal preference and the opinions are often split about syntax related questions.
I'm not sure about this one, I can understand why someone might agree with some of the arguments about list comprehension making readability worse, like stated in this comment: https://github.com/godotengine/godot-proposals/issues/2972#i...
I have to agree with @pycbouh. While a lot of things python does is good, I really don't like list comprehension, especially when it becomes nested.
numbers = [[1, 2, 3], [4, 5, 6], [7, 8, 9]]
print([n for sublist in numbers for n in sublist if n % 2 == 0])
# > [2, 4, 6, 8]
Not very readable, and you save what, 3 lines? Not worth.
Personally, I enjoy both LINQ in C# and Streams in Java, perhaps more than a one liner. But again, that's a personal preference and the opinions are often split about syntax related questions.
GDScript went through a major rewrite for Godot 4, so they avoided adding lots of new features in the meantime and focused on getting it stable.
The rewrite should make it easier to add new features now.
Also the design of Godot values ease of use and simplicity to an great degree. They are very conservative about adding new features and I think they have a point there.
Also list comprehension is an odd example, I wouldn't really rank it that highly when it comes to features I miss. More annoying for me is not having traits or interfacse. You are expected to go full in with "everything is a node" and are a bit limited when it comes to more advanced abstractions. I understand why they are reluctant adding them though and I respect their commitment to keeping things simple.
The rewrite should make it easier to add new features now.
Also the design of Godot values ease of use and simplicity to an great degree. They are very conservative about adding new features and I think they have a point there.
Also list comprehension is an odd example, I wouldn't really rank it that highly when it comes to features I miss. More annoying for me is not having traits or interfacse. You are expected to go full in with "everything is a node" and are a bit limited when it comes to more advanced abstractions. I understand why they are reluctant adding them though and I respect their commitment to keeping things simple.
Is there a reason you wouldn't use a game engine to create general purpose cross-platform apps? Is it cumbersome to create textual, structural interfaces (e.g. a twitter clone, google sheets clone, or an ecomm checkout flow)?
For desktop and mobile apps, it could work.
For example, here is kanban PoC made by someone:
https://github.com/alfredbaudisch/Godello
But for web, that could be too much for browsers to handle. Godello loading at webbrowser has only some time watching at spinner, when you have fast Internet connection, loading about 10 MB of code, WASM etc.
But when I tried to save Godot 3D game example to HTML5, and load it to webbrowser, Chromium etc browsers can not handle that much data.
Some webbrowser users have slow connections. If there are many users, they start to complain webpages loading too slowly. With Godot everything is browserside, and generated with save button, from that it's hard to move anything to serverside.
But if you instead code frontend and backend with Javascript, it's possible to move more of frontend Javascript code to run serverside.
For example, here is kanban PoC made by someone:
https://github.com/alfredbaudisch/Godello
But for web, that could be too much for browsers to handle. Godello loading at webbrowser has only some time watching at spinner, when you have fast Internet connection, loading about 10 MB of code, WASM etc.
But when I tried to save Godot 3D game example to HTML5, and load it to webbrowser, Chromium etc browsers can not handle that much data.
Some webbrowser users have slow connections. If there are many users, they start to complain webpages loading too slowly. With Godot everything is browserside, and generated with save button, from that it's hard to move anything to serverside.
But if you instead code frontend and backend with Javascript, it's possible to move more of frontend Javascript code to run serverside.
You certainly could. You would probably run into a lot of issues in areas that games don't care about that much like multiple windows, smooth window resizing, fancy text layout and input, fast initial load times, matching OS themes and widget behavior, low resource usage at idle, copy/paste/drag/drop, software rendering, etc.
Add accessibility to that list. Screen readers, magnifiers, switch controls, etc. Usually game engines don't support these while your native OS UI probably does, and the web is also not bad in that regard.
IIRC there is actually an ongoing Godot accessibility effort.
Agreed with the poster below. Godot def could, but I know text rendering is not as nice as browsers last I checked.
Yeah, likely you won't get as many tools to help with structured GUIs and expected hooks to the operating system commands that your user will want to use, but if what you're looking for is unstructured, quirky, or artsy content, possibly the way old school flash sites wanted to be, then it's certainly a fun option for cross platform apps.
The thing I am working on is intended to be useable to also build GUI apps and command line tools.
The tech that is often used in game engines, especially related to GPU support but also memory management and GUI structure is often 10-100x faster than what is commonly used elsewhere.
Text rendering can be just as nice as any desktop app, it is not trivial but not rocket science either, and quite a few smart guys have been doing nice work in this field.
The tech that is often used in game engines, especially related to GPU support but also memory management and GUI structure is often 10-100x faster than what is commonly used elsewhere.
Text rendering can be just as nice as any desktop app, it is not trivial but not rocket science either, and quite a few smart guys have been doing nice work in this field.
> The thing I am working on...
> ...quite a few smart guys have been doing nice work in this field
can you expand on that? like creating quality of life improvements to existing tools like Godot, or something entirely new but in the spirit of game engines?
> ...quite a few smart guys have been doing nice work in this field
can you expand on that? like creating quality of life improvements to existing tools like Godot, or something entirely new but in the spirit of game engines?
Flutter is essentially just that. Its graphics are built on Skia Graphics Engine and the tooling is designed to cater for UI interaction needs instead of gaming needs.
Apple's own UI libraries use their graphics engines too(SpriteKit, SceneKit), unfortunately supported only on Apple platforms.
Apple's own UI libraries use their graphics engines too(SpriteKit, SceneKit), unfortunately supported only on Apple platforms.
Well, the Godot editor is actually a Godot applications, they are dog-fooding their own UI.
So it is absolutely possible to create complex applications with it.
Games engines are generally not used for apps, as games are optimized differently to apps. Games need to run smoothly at a high refresh rates at all times while apps can not hog all CPU power but need also be optimized to not needlessly drain the battery. This is no an issue in Godot specifically because it offers a low processor usage mode though.
So yes, Godot is a decent solution for apps. Only real issue is support for accessibility. There are screen reader plugins but if you want to do it properly, you might be better of with an app using native elements.
So it is absolutely possible to create complex applications with it.
Games engines are generally not used for apps, as games are optimized differently to apps. Games need to run smoothly at a high refresh rates at all times while apps can not hog all CPU power but need also be optimized to not needlessly drain the battery. This is no an issue in Godot specifically because it offers a low processor usage mode though.
So yes, Godot is a decent solution for apps. Only real issue is support for accessibility. There are screen reader plugins but if you want to do it properly, you might be better of with an app using native elements.
My blunt review of Godot after using it for about 3 weeks, it's the community's Unity.
But it's just not there yet, things which take seconds in Unity take minutes in Godot. Or are just impossible.
It's not done yet, it's going to probably be done in either late 2023 or 2024. Godot 4 needs to come out, and they need to add mono. I've never been more frustrated with a programming language before I found Godot script, just why.
Why not use Python, why, why not use? I don't know, haxe.
Even Godot's creator tried to calm everybody down, you're comparing what's basically a souped-up hobbyist project by maybe two or 300 volunteers to professional products by multi-billion dollar companies of tens of thousands of people.
All that said, I am fighting through Godot right now and I'm having the most fun with game development I've had in years. I try to armory as well, which is not nearly as advanced as Godot, but has the most welcoming community I've ever seen.
I Feel like, back when I first learned a program when I work with Godot. With mono, which is on 3.5 which is very nice.
Too long. Read, if you want to make a commercial product, you're still stuck using Unity or Unreal,
However, if you want to just make games for the sake of making games.
Godot.
But it's just not there yet, things which take seconds in Unity take minutes in Godot. Or are just impossible.
It's not done yet, it's going to probably be done in either late 2023 or 2024. Godot 4 needs to come out, and they need to add mono. I've never been more frustrated with a programming language before I found Godot script, just why.
Why not use Python, why, why not use? I don't know, haxe.
Even Godot's creator tried to calm everybody down, you're comparing what's basically a souped-up hobbyist project by maybe two or 300 volunteers to professional products by multi-billion dollar companies of tens of thousands of people.
All that said, I am fighting through Godot right now and I'm having the most fun with game development I've had in years. I try to armory as well, which is not nearly as advanced as Godot, but has the most welcoming community I've ever seen.
I Feel like, back when I first learned a program when I work with Godot. With mono, which is on 3.5 which is very nice.
Too long. Read, if you want to make a commercial product, you're still stuck using Unity or Unreal,
However, if you want to just make games for the sake of making games.
Godot.
> Why not use Python, why, why not use? I don't know, haxe.
Neither Python nor Haxe (presumably) have built-in types for vectors, quaternions, and matrices. Quite nice convenience features. Though I'd rather write in a lot of other languages than GDscript.
Neither Python nor Haxe (presumably) have built-in types for vectors, quaternions, and matrices. Quite nice convenience features. Though I'd rather write in a lot of other languages than GDscript.
Python also doesn't have builtin types for linear algebra, hence NumPy.
So it isn't as if they couldn't add the support.
So it isn't as if they couldn't add the support.
Is there something inherent with game engines that prohibits small, frequent software delivery? (call it agile or lean, if you want)
They do small, frequent software updates, it's called minor and patch versions. But when you're making a tool for creative professionals you don't want to release major versions of the tool every year, because these professionals care more for consistency and using their current skillset more than shiny new features in the next version.
Except that we have releases of Adobe and Unity and things multiple times a year. Creatives value consistency but they also value ease of use. Improvements to UX and workflow should be allowed to break the mold of "don't touch it if it works". What they don't do is dictate the release cycle. Many patches end up in committee to be pooled together (or paywalled) into a vX.N.0 patch released when the business decides to.
Everyplace I've worked that's used Unity has locked into a version at the start, and only upgraded (other than minor versions/bug fixes) between projects. New projects today would use last years version.
Adobe is less an issue because the new version of Photoshop isn't going to break your PSD.
Adobe is less an issue because the new version of Photoshop isn't going to break your PSD.
> Everyplace I've worked that's used Unity has locked into a version at the start, and only upgraded (other than minor versions/bug fixes) between projects.
Having used Unity for a few years, this feels like the only sane approach. It might sometimes be possible to update a project or even follow the best practices with package updates, but in practice there's just too much brittle stuff that breaks (e.g. all of the materials in a project breaking and becoming invisible or other weird things, like scripts suddenly throwing plenty of runtime exceptions).
Just pin to whatever the latest LTS version is and then conservatively update packages as necessary.
Thankfully most games aren't too integrated with network solutions and don't have to worry about security related topics, like how a typical .NET or Spring Boot webapp would have to.
Having used Unity for a few years, this feels like the only sane approach. It might sometimes be possible to update a project or even follow the best practices with package updates, but in practice there's just too much brittle stuff that breaks (e.g. all of the materials in a project breaking and becoming invisible or other weird things, like scripts suddenly throwing plenty of runtime exceptions).
Just pin to whatever the latest LTS version is and then conservatively update packages as necessary.
Thankfully most games aren't too integrated with network solutions and don't have to worry about security related topics, like how a typical .NET or Spring Boot webapp would have to.
This especially true since this is a FOSS tool so there's no need to ship product bumps to sell units or anything like that. They can just release stuff when its ready.
Major version bumps with major features are still a great marketing tool; like this article making it to the HN frontpage. That attracts users and developers, both desirable for FOSS.
A lot of games are fragile, and have poor or no test coverage. So if the engine changes, it can break or have all sorts of unforeseen consequences. So you want to be building in an engine that isn't changing.
Unity has bug fix releases every two weeks so no.
That said, I would say a lot of changes can be breaking because backwards compatibility is a much lower priority then code speed or size.
That said, I would say a lot of changes can be breaking because backwards compatibility is a much lower priority then code speed or size.
They are still updating Godot 3, even backporting features from 4.
Their users. Game engines are big and complex and the foundation of building a big and complex product. You can't have your foundation introducing fundamental changes on a regular, unpredictable basis.
Releasing big versions means your game can use version X.Y with only bugfixes to the engine added as updates and you don't have to make fundamental changes when the game engine changes.
Releasing big versions means your game can use version X.Y with only bugfixes to the engine added as updates and you don't have to make fundamental changes when the game engine changes.
They do, it's called the master GitHub branch. But generally if you're shipping something that doesn't get updated as often (you don't want to update via Google Play or Steam as often as a website would) you'd like a little stability...
Comes in a good moment considering recent Unity backlash.
Friends in the industry all say it's a nonstarter that it does not (and will not) have cross platform support, as much as they hate Unity. Godot's official stance on it is that you should hire a team to port it for you lol...
If you're long on the games industry we are probably in the last generation of game console architecture. Everything is going to be Windows or Linux boxes with PC hardware next gen.
I could see Nintendo bucking this trend but they have enough IP to be their own island.
It might be smart for Godot to punt; it lets them go faster than Unity and catch up
I could see Nintendo bucking this trend but they have enough IP to be their own island.
It might be smart for Godot to punt; it lets them go faster than Unity and catch up
I've been hearing that since the first Xbox came out (which used an x86 architecture before the Xbox 360 moved to powerpc) and it still hasn't happened.
Consoles are actively migrating their audiences onto digital subscription services so that the brand has an identity separate from the console. The future is selling hardware if you must, so you can make money selling PC games.
Microsoft's strategy is to sell PC games on Windows devices. They might call some of them Xboxes.
Valve's strategy is to maintain a Linux distro that can play PC games.
Sony also ran.
Microsoft's strategy is to sell PC games on Windows devices. They might call some of them Xboxes.
Valve's strategy is to maintain a Linux distro that can play PC games.
Sony also ran.
> Everything is going to be Windows or Linux boxes with PC hardware next gen.
Are you sure about this? I mean, as awesome as that would be just look at the mobile market - Android had every chance to be a properly open OS (e.g. AOSP), but instead its a mess of flakey drivers, locked down bootloaders and other anti-user practices that curb our freedoms with our devices.
I foresee that trend mostly remaining as it is in regards to consoles as well (and IoT devices), outside of projects like Steam Deck. But then again, I'm still bummed out that it wasn't possible for me to install Linux on my PS4 and use it as a development box (since updates explicitly fixed any vulnerabilities that would allow for that), because its form factor was great.
Hell, it's probably just a matter of time until PCs and laptops are sold with locked down bootloader and only run Windows or whatever other manufacturer sanctioned/mandated OS would be included.
Are you sure about this? I mean, as awesome as that would be just look at the mobile market - Android had every chance to be a properly open OS (e.g. AOSP), but instead its a mess of flakey drivers, locked down bootloaders and other anti-user practices that curb our freedoms with our devices.
I foresee that trend mostly remaining as it is in regards to consoles as well (and IoT devices), outside of projects like Steam Deck. But then again, I'm still bummed out that it wasn't possible for me to install Linux on my PS4 and use it as a development box (since updates explicitly fixed any vulnerabilities that would allow for that), because its form factor was great.
Hell, it's probably just a matter of time until PCs and laptops are sold with locked down bootloader and only run Windows or whatever other manufacturer sanctioned/mandated OS would be included.
[deleted]
Is that just for 4.0? Since the features page[1] lists a number of deploy targets for 3.X:
* Export to desktop platforms: Windows, macOS, Linux, UWP, and BSD.
* Export to mobile platforms: iOS and Android.
* Consoles: Nintendo Switch, PlayStation 4, Xbox One via third-party providers
[1]: https://godotengine.org/features
* Export to desktop platforms: Windows, macOS, Linux, UWP, and BSD.
* Export to mobile platforms: iOS and Android.
* Consoles: Nintendo Switch, PlayStation 4, Xbox One via third-party providers
[1]: https://godotengine.org/features
No, it looks like the same situation as 3.x: Godot is MIT licensed, and they don't believe it's possible for them as an open-source project to sign NDAs with console manufacturers and build in native compatibility without violating either the NDA or their open source principles.
https://godotengine.org/article/godot-consoles-all-you-need-...
They mention a few other platforms where 3rd parties have implemented commercial compatibility libraries, but Godot is much bigger in scale & scope, and nobody's done the legwork on that.
https://godotengine.org/article/godot-consoles-all-you-need-...
They mention a few other platforms where 3rd parties have implemented commercial compatibility libraries, but Godot is much bigger in scale & scope, and nobody's done the legwork on that.
I think you mean it doesn’t include “console support” not “cross-platform” support, and as it is very much cross-platform across desktop and mobile targets.
And your friends are clearly just working in a different way than the many people who Godot is a good fit for.
Even beyond hobbyists and new game developers, there are plenty of business models and artistic visions that don’t need a console port or that can indeed outsource it once there’s some financial momentum.
And your friends are clearly just working in a different way than the many people who Godot is a good fit for.
Even beyond hobbyists and new game developers, there are plenty of business models and artistic visions that don’t need a console port or that can indeed outsource it once there’s some financial momentum.
Their official stance is that they can not release the code for consoles because of NDAs. You won't find any open source engine with console support because of that. They are hoping that consoles loosen up and open source their SDK.
I'm not a game dev, but I read you can deploy to desktop (across multi os), mobile and web. That sounds pretty multi platform to me. What am I missing?
Godot has excellent cross platform support, just not for consoles that requires NDA's and stuff to develop for. This can't be helped on the Godot side but is the fault of the console manufactures who make the rules.
Also paying a third party to port a game to a different platform is not really that uncommon, even in the Unity world. I remember the Dev of The First Tree did exactly this.
It is not like you can just put your game in the PlayStation-store even if you use Unity or Unreal. There is a process to it and your game has to fulfill certain standards.
A good strategy is to first publish for PC and see if the game gains any traction. If it does, well the console port will pay for itself. If not, you saved yourself lot's of work.
See also: https://godotengine.org/article/godot-consoles-all-you-need-...
Also paying a third party to port a game to a different platform is not really that uncommon, even in the Unity world. I remember the Dev of The First Tree did exactly this.
It is not like you can just put your game in the PlayStation-store even if you use Unity or Unreal. There is a process to it and your game has to fulfill certain standards.
A good strategy is to first publish for PC and see if the game gains any traction. If it does, well the console port will pay for itself. If not, you saved yourself lot's of work.
See also: https://godotengine.org/article/godot-consoles-all-you-need-...
Every single time a Godot bug bites me I find that a bunch of other devs reported the issue more than a year ago but no one has had time/money to fix the issue. For example, I was just bitten by #45628 opened Feb 1, 2021:
When implementing controller support for a top-down Zelda-like game, it's normal to allow either the d-pad or left analog stick to control direction. But if you enable both at the same time in Godot then d-pad inputs cause your character to "freeze".
Eventually Godot will stabilize and be to game engines what Blender currently is to 3D modelers. If I had time to learn the Godot C++ code I would volunteer to help but I want to actually make video games instead of working on an engine.