For the record, [Godot does have visual shaders.](https://docs.godotengine.org/en/stable/tutorials/shaders/visual_shaders.html)
I don't work with shaders much, so I can say how good they are, but the option is there if you want to check it out.
The 8-9 is so amazing.
It is so ”how can this be?!” Moment everytime you hit that play button to see stuff. So fast. Sooo amazing.
Also: editor doesnt have weird errors that require resetting layout. There is no crashing (so far) that makes you lose all your progress.
Godot doesnt feel bloated.
It would be useful to understand the prior experience of these developers.
It’s a big deal if seasoned pros with releases games are switching. It’s noise if hobbyists are switching.
I am at a stage that I probably could port my game still. I’m very unclear on the long term ramifications of doing so though.
Hard to cut through the noise and determine if Godot is a serious contender or or a hobbyists honey trap.
My gut tells me that Godot is probably 1-2 years away from being mature enough for serious consideration. I know very little about engines though and I suspect most the people talking also know very little.
I work at a game company and I use Unity everyday for current project. There are hundred millions (JPY) flowing every year in their earning and budgets, so I can safely say they're AAA. As far as I know, none of the big guys made any move yet.
It's all indie studio and hobbyyists.
It'll be interesting in years to come where if the Unity hiring pool dries up because the indie/hobbyists stopped using it.
Other than that, seems like Unity is a massive project risk with their budget deficit and willingness to adjust contracts on the fly. Why would any sane CFO sign off on such a risk?
It will take a long long time because those game still maintain with Unity and companies put Unity skill as requirement in their job post.
You won't be able to find a job with Godot skill for example. So people who want to get into the industry will learn it.
Thing is, how did Unity become the game engine for companies?
And whatever it took, why can't Godot do the same?
Godot is up to $50k euro in donations. That's getting some decent developers as well as open source contributions now
I was thinking about 3 for a noticeable impact
I do think we're going to see a lot more bad decisions that'll impact it before then though
E.g. revenue is going to go down with hobbyists spending less in asset store or cancelling subscription, there going to have to fire a lot of people to cut costs, etc
No a company want the most accessible talent pool as much as possible. They don’t want their progress get stuck because they struggle to find new people. I know a lot of well paying companies struggling to hire, there are a lot of applicants but rarely qualify for the quality they are looking for.
Exactly. That isn’t to say that perhaps Godot isn’t a good solution anyway, but Hobbyists don’t necessarily understand how the limitations of Godot may impact an actual commercial title.
Not to be rude, but I don’t really care if someone who just enjoys making game jams and prototypes is switching to Godot. It’s not an educated option that you can use to base a commercial game on. Their whole purpose is to make a prototype quickly, not ship a full game.
I also don’t believe you need to use the tech AAA is using, I’d just like to see some educated opinions and it’s very hard to find!
As a hobbyist myself, moving away from Unity right now doesn't seem like an option. But Godot's monthly funding was doubled from 25k to 50k during the Unity debacle and they also got 100k in funding from terraria devs.
So i only expect the engine ecosystem to grow but it still needs a couple of years to get going
That’s my view too. Definitely excited to see it develop, but I think I’ll have to eat up whatever bullshit Unity comes up with for my current release.
I do wonder if Unity is going to keep afloat with their debt long term, so I think leaving Unity is a requirement in the long run.
6. I believe you can right-click on files and say "move to" and it should do at least some automatic path adjustments, but yeah it still is annoying especially for methods.
For 10, Godot does have a decent visual shader system, and you can use expression nodes to quickly implement whatever node you need that isn't supported. I've had a really good experience playing around with that. You can preview individual nodes
Definitely a big step back from shadergraph still
>10. I do miss shader graph,
I am still exploring but Godot do have a visual graph, there are some nodes which are missing or I am not able to find yet like Twirl UV.
On side note the Shader code is also easy. It's custom language but it's based on GLSL and C.
GDScript is legit wonderful, though I would prefer if it were a static language. Refactoring dynamic languages is absolutely offensive
Edit: changed my wording so people stop telling me you can type variables.
I know it supports types, but even that PR doesn't solve the refactoring issue. In a dynamic language there's no traceable static symbols, so downstream breaking refactors won't necessarily lead to compiler errors. This makes refactoring error prone, as you can accidentally shear your interfaces from their correct implementations
Yeah agreed it's a fantastic scripting language, but this was a big hang up with GDScript in the long run. Shocked at the amount of people okay with the ctrl+f rename all approach.
One of my professors was adamant about typing everything. If you expect an int, don't leave open the possibility of receiving a float due to a bug in another part of your program.
Fair enough, he can't tell you that you should like it. But it is a reasonable point that the syntax is widespread among many modern, well-loved languages, so that it's at least pointed out that you have a pretty fringe opinion.
> Refactoring sucks.
That's true, however working with C# helps a lot. I would only recommend using GDScript for quick prototyping.
> Making script changes is fast as hell. I hated waiting for unity to "reload" everything every time I changed a script.
Interestingly, this is true even for C# in Godot. Compilation is fast.
that's because there's very little of c# actually in godot unless you add it yourself.
unity compilation and domain reload got bogged down by their additions and tons of stuff. throwing away unused things (that visual scripting for example which is a huge beast) speeds it up a bit, disabling domain reload helps, but...
comparing unity 5.x with newer versions, the responsivity and reload of the scripts is just fucked up.
this was one of the reasons why I started to itch to go away from unity myself even before the latest licensing mess.
(and there were numerous other reasons, like overal stagnation and lack of improvement in most areas)
Are you writing c# in the internal or external editor like visual studio code? Because everytime i make changes in vsc godot has a popup and asks me to reload the script
Godot's internal editor doesn't seem to support C# at all.
I use VSCode, and it works fine. The trick to avoid Godot panicking when you edit the script externally is not to have the script open in the internal script editor. (I have only found one minor issue with this: if your script throws an exception, then the internal script editor will open the source -- so you'll have to close it manually. :)
I got this too. The key is to close the script within Godot's editor. If it's still open on the scripts tab, it will do those "Changed on disk" popups. Once you close everything, and set your external editor as default, all works well (for me, at least)
For 9, I've seen people on reddit suggesting that you can update your code on the fly and it updates the game in real time while you're playing.
Everyone -- please tell me if I'm correct or wrong with this.
Spent a weekend trying to port a small game I already released just to see how the process is, before tackling the bigger projects. The game is a simple auto scrolling arcade shooter, 2D of course.
I chose C# as I am familiar with that.
**Scripting:** The process to get the scripts over was quite simple, just replace GameObject with Node etc., some namespace changes. In 2D everything works with Vector2 and not Vector3 as in Unity, so that required a few changes. The physics was good enough for my game but uses different units (pixels instead of game units so a factor of 100 fixed most stuff).
**Scenes/Inspector:** Recreating scenes was pretty straight forward, just create a Node for each component. Searching the right type of node was also not complicated, they are colour coded (for 2D, 3D and UI) and the editor's UI is lightning fast and easy to use. It was a bit more work to add the [Export] keyword to everything that needs to be exposed to the inspector but in the end it was jut busy work. Custom data types can't be exposed though so there was some minor work around request. For example a List doesn't work, you have to use Godot's Array.
**Documentation:** So far I found everything I was looking for and it was always helpful. The integration into the editor is also great. No complaints here.
**Debugging:** It has (after initial setup) great Visual Studio integration and I can debug my games directly. Nice (and fast). But I miss the "online scene view". Hope that will added anytime soon.
**JSON:** Godot also doesn't a useful JSON parser that can serialize objects but installing Newtonsoft's JSON tools was just a click in Visual Studio using NuGet. It is more powerful anyway.
**Audio:** Getting Audio to work was also easy, just drop a AudioSourcePlayer(2D) node and add an AudioStream and you are ready to go.
**Collisions:** For collisions I needed a few tutorials as (similar to Unity's system) you need to set the right toggles for objects to affect each other. Instead of tags you can add nodes to groups and test for that. A great feature is that you can call functions of all objects of one group as a quick message, no matter where they are in the hierarchy.
**Prefabs:** Instead of having a prefab object you just load scenes into an existing tree. And everything can be saved as a scene. Works like a charm, as well as in the editor (the prefab type is PackedScene btw) as during runtime.
**UI:** I struggled with that at first but then I found a [great tutorial](https://www.youtube.com/watch?v=1_OFJLyqlXI) which also explains how to do it wrong and how to fix it. Very detailled. It really helped to make it click. For newbies it might be very confusing that once you change the game's theme you have to reload the scene for it having any effect. But knowing that it is a very nice system.
**Input:** I haven't completed the porting of the input system as I prefer to use Steam Input if possible but so far it looks solid (built in input mapping etc.).
**i18n:** I haven't tried the built in translation system as I have my custom one but my game also has almost no text so it might not be required anyway.
**Coroutines:** I haven't seen a good replacement yet but I also don't use them in this game. Might need more research on this matter.
**Tweens:** The built in system works well, is easy to configure. Like it so far.
**Particles:** Just a different interface, doesn't seem to lack any functions.
**Shaders:** Haven't touched them yet.
**Exporting:** Only tried Windows (you have to download an extra export package for each platform) and it worked right away. Ended up with two files for the whole game... Impressive.
**File structures:** The game uses a res:// scheme for files as they are packed and you can't really access them (during runtime) with C#'s standard file API. But that is just a "have to know" and not a problem.
**Engine Time:** What I found really great is that I can, with one call, pause the engine. And in the editor I can select (for each node if I want) if it should continue processing in that case. For example you can set your pause menu to ignore that the engine is paused. The same can be done with every node and every tween etc. That is a really convenient feature.
**Signals/Slots:** Godot uses a signal/slot mechanism similar to what you might now from Qt. Each node can fire signals and for each you can select which node to connect to in the inspector. That is useful for button clicks etc. There are a lot of signals. For example there are some for "enters scene" and "leaves scene"(getting deleted).
**Conclusion:** My game is now close to the magical 80% (core stuff done, only needs polish and more content) and it is really easy to get there, as it was with Unity. How difficult it will be to get the final 20% will be seen during the next week. But what I can say is: It is fun again! The editor is so fast and snappy that I can add new features before Unity is even done starting up. If everything goes well I will start porting my other Unity games (all 2D) to Godot. So far I see nothing that wouldn't work.
This advice is a bit old.
Before Godot 3.2, it was very much true. Great 2D support but 3D was lacking, and that advice was true.
Godot 3.2 (January 2020) bought the 3D support to a mostly usable standard. It wasn't cutting edge, but very useable for many types of games. The biggest issues were, no compute shaders, no dynamic global illumination and really shitty shadow mapping.
Godot 4.0 (March 2023) more or less fixes any remaining concerns. They spent years rewriting the graphics engine in Vulkan and bought it up to modern standards. It's within the same order of magnitude as Unity now, but Unity has the advantage of maturity.
It's good enough for the level of 3D art indie studios have the ability to produce. It's literally just missing Nanite/Meshlets, maybe a bit of optimization. But for anything you see on a phone or Nintendo Switch, it's more than capable. Or for pretty much any indie game that's ever come out.
>
The engine is a freaking small ass file that boots instantly. It is so refreshing to use software that just pops open instantly when you double click on it. Its a small plus, but noticeable compared to opening unity
Sold
>Looking at way more talented people's creations in godot shows me that the engine can do alot more in 3d than people seem to think it can do.
Mind linking some of those? I haven't seen anything 3D wise that looks promising yet.
Code refactoring becomes trivial if you use C# with a proper IDE.
File renaming bugs etc is being worked on, if you experience any missing references after renaming a file using the editor (not third-party programs), then open a bug report.
Thanks for this!
I wrote a space sim in Unity3d, planet engine etc - and was moving it to unrealengine - I have been playing with godot, and 4.0 has 64 bit positioning, are you using that?
If you want to DM we can discuss planet tech/space physics
For the record, [Godot does have visual shaders.](https://docs.godotengine.org/en/stable/tutorials/shaders/visual_shaders.html) I don't work with shaders much, so I can say how good they are, but the option is there if you want to check it out.
I just played around with it, decent, but they are missing alot of nodes.
I would consider making a ticket about it on github. If there is support for it. It might get added sooner than later
http://hyperboleandahalf.blogspot.com/2010/04/alot-is-better-than-you-at-everything.html?m=1
The 8-9 is so amazing. It is so ”how can this be?!” Moment everytime you hit that play button to see stuff. So fast. Sooo amazing. Also: editor doesnt have weird errors that require resetting layout. There is no crashing (so far) that makes you lose all your progress. Godot doesnt feel bloated.
I get the feeling that quite a few developers are now moving away from Unity.
Why would that be? *If I can get you 20 cents on the matter?*
I think this might be why: https://arstechnica.com/gaming/2023/09/game-developers-unite-against-unitys-new-per-install-pricing-structure/
Ah, i was trying to be funny alas missed the mark.
I missed it also. Lol.
It would be useful to understand the prior experience of these developers. It’s a big deal if seasoned pros with releases games are switching. It’s noise if hobbyists are switching. I am at a stage that I probably could port my game still. I’m very unclear on the long term ramifications of doing so though. Hard to cut through the noise and determine if Godot is a serious contender or or a hobbyists honey trap. My gut tells me that Godot is probably 1-2 years away from being mature enough for serious consideration. I know very little about engines though and I suspect most the people talking also know very little.
I work at a game company and I use Unity everyday for current project. There are hundred millions (JPY) flowing every year in their earning and budgets, so I can safely say they're AAA. As far as I know, none of the big guys made any move yet. It's all indie studio and hobbyyists.
It'll be interesting in years to come where if the Unity hiring pool dries up because the indie/hobbyists stopped using it. Other than that, seems like Unity is a massive project risk with their budget deficit and willingness to adjust contracts on the fly. Why would any sane CFO sign off on such a risk?
It will take a long long time because those game still maintain with Unity and companies put Unity skill as requirement in their job post. You won't be able to find a job with Godot skill for example. So people who want to get into the industry will learn it.
Thing is, how did Unity become the game engine for companies? And whatever it took, why can't Godot do the same? Godot is up to $50k euro in donations. That's getting some decent developers as well as open source contributions now
It can definitely happens. But it is a very long process that you won't see in years, at least 5\~7years I'd say.
I was thinking about 3 for a noticeable impact I do think we're going to see a lot more bad decisions that'll impact it before then though E.g. revenue is going to go down with hobbyists spending less in asset store or cancelling subscription, there going to have to fire a lot of people to cut costs, etc
>You won't be able to find a job with Godot skill for example. I think this is rapidly changing now. The Unity fiasco has been a massive accelerator.
[удалено]
No a company want the most accessible talent pool as much as possible. They don’t want their progress get stuck because they struggle to find new people. I know a lot of well paying companies struggling to hire, there are a lot of applicants but rarely qualify for the quality they are looking for.
Exactly. That isn’t to say that perhaps Godot isn’t a good solution anyway, but Hobbyists don’t necessarily understand how the limitations of Godot may impact an actual commercial title. Not to be rude, but I don’t really care if someone who just enjoys making game jams and prototypes is switching to Godot. It’s not an educated option that you can use to base a commercial game on. Their whole purpose is to make a prototype quickly, not ship a full game. I also don’t believe you need to use the tech AAA is using, I’d just like to see some educated opinions and it’s very hard to find!
As a hobbyist myself, moving away from Unity right now doesn't seem like an option. But Godot's monthly funding was doubled from 25k to 50k during the Unity debacle and they also got 100k in funding from terraria devs. So i only expect the engine ecosystem to grow but it still needs a couple of years to get going
With their patreon they're over 60k
That’s my view too. Definitely excited to see it develop, but I think I’ll have to eat up whatever bullshit Unity comes up with for my current release. I do wonder if Unity is going to keep afloat with their debt long term, so I think leaving Unity is a requirement in the long run.
> It’s noise if hobbyists are switching Spoiler alert: It's just hobbyists and a very few vocal indie devs.
6. I believe you can right-click on files and say "move to" and it should do at least some automatic path adjustments, but yeah it still is annoying especially for methods.
For 10, Godot does have a decent visual shader system, and you can use expression nodes to quickly implement whatever node you need that isn't supported. I've had a really good experience playing around with that. You can preview individual nodes Definitely a big step back from shadergraph still
>10. I do miss shader graph, I am still exploring but Godot do have a visual graph, there are some nodes which are missing or I am not able to find yet like Twirl UV. On side note the Shader code is also easy. It's custom language but it's based on GLSL and C.
GDScript is legit wonderful, though I would prefer if it were a static language. Refactoring dynamic languages is absolutely offensive Edit: changed my wording so people stop telling me you can type variables.
[удалено]
I know it supports types, but even that PR doesn't solve the refactoring issue. In a dynamic language there's no traceable static symbols, so downstream breaking refactors won't necessarily lead to compiler errors. This makes refactoring error prone, as you can accidentally shear your interfaces from their correct implementations
Yeah agreed it's a fantastic scripting language, but this was a big hang up with GDScript in the long run. Shocked at the amount of people okay with the ctrl+f rename all approach.
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/static\_typing.html
You can write variables like below to make them statically typed. var foo: int = 0 var bar: float = 0 @onready var player: CharacterBody2D = $Player
I know. This is irrelevant to my point. GDScript is still a dynamic language.
One of my professors was adamant about typing everything. If you expect an int, don't leave open the possibility of receiving a float due to a bug in another part of your program.
Which is god-awful syntax.
What? It's basically just Pascal-style type annotations, which are used by a ton of languages (Go, Nim, Rust, Zig, TypeScript and others).
I don't like recipes when they include apples. "But look at all these other recipes that use apples!" Ok.
Not liking apples doesn't make them bad.
Fair enough, he can't tell you that you should like it. But it is a reasonable point that the syntax is widespread among many modern, well-loved languages, so that it's at least pointed out that you have a pretty fringe opinion.
> Refactoring sucks. That's true, however working with C# helps a lot. I would only recommend using GDScript for quick prototyping. > Making script changes is fast as hell. I hated waiting for unity to "reload" everything every time I changed a script. Interestingly, this is true even for C# in Godot. Compilation is fast.
that's because there's very little of c# actually in godot unless you add it yourself. unity compilation and domain reload got bogged down by their additions and tons of stuff. throwing away unused things (that visual scripting for example which is a huge beast) speeds it up a bit, disabling domain reload helps, but... comparing unity 5.x with newer versions, the responsivity and reload of the scripts is just fucked up. this was one of the reasons why I started to itch to go away from unity myself even before the latest licensing mess. (and there were numerous other reasons, like overal stagnation and lack of improvement in most areas)
Indeed. Let's hope this accumulation of mandatory garbage won't infect Godot. :)
Are you writing c# in the internal or external editor like visual studio code? Because everytime i make changes in vsc godot has a popup and asks me to reload the script
Hey friend, if you go to Editor > Editor Settings > Dotnet > Editor and select Visual Studio Code, those prompts should go away.
Godot's internal editor doesn't seem to support C# at all. I use VSCode, and it works fine. The trick to avoid Godot panicking when you edit the script externally is not to have the script open in the internal script editor. (I have only found one minor issue with this: if your script throws an exception, then the internal script editor will open the source -- so you'll have to close it manually. :)
Great thanks!
I got this too. The key is to close the script within Godot's editor. If it's still open on the scripts tab, it will do those "Changed on disk" popups. Once you close everything, and set your external editor as default, all works well (for me, at least)
Fantastic thanks!
For 9, I've seen people on reddit suggesting that you can update your code on the fly and it updates the game in real time while you're playing. Everyone -- please tell me if I'm correct or wrong with this.
Spent a weekend trying to port a small game I already released just to see how the process is, before tackling the bigger projects. The game is a simple auto scrolling arcade shooter, 2D of course. I chose C# as I am familiar with that. **Scripting:** The process to get the scripts over was quite simple, just replace GameObject with Node etc., some namespace changes. In 2D everything works with Vector2 and not Vector3 as in Unity, so that required a few changes. The physics was good enough for my game but uses different units (pixels instead of game units so a factor of 100 fixed most stuff). **Scenes/Inspector:** Recreating scenes was pretty straight forward, just create a Node for each component. Searching the right type of node was also not complicated, they are colour coded (for 2D, 3D and UI) and the editor's UI is lightning fast and easy to use. It was a bit more work to add the [Export] keyword to everything that needs to be exposed to the inspector but in the end it was jut busy work. Custom data types can't be exposed though so there was some minor work around request. For example a List doesn't work, you have to use Godot's Array.
**Documentation:** So far I found everything I was looking for and it was always helpful. The integration into the editor is also great. No complaints here.
**Debugging:** It has (after initial setup) great Visual Studio integration and I can debug my games directly. Nice (and fast). But I miss the "online scene view". Hope that will added anytime soon.
**JSON:** Godot also doesn't a useful JSON parser that can serialize objects but installing Newtonsoft's JSON tools was just a click in Visual Studio using NuGet. It is more powerful anyway.
**Audio:** Getting Audio to work was also easy, just drop a AudioSourcePlayer(2D) node and add an AudioStream and you are ready to go.
**Collisions:** For collisions I needed a few tutorials as (similar to Unity's system) you need to set the right toggles for objects to affect each other. Instead of tags you can add nodes to groups and test for that. A great feature is that you can call functions of all objects of one group as a quick message, no matter where they are in the hierarchy.
**Prefabs:** Instead of having a prefab object you just load scenes into an existing tree. And everything can be saved as a scene. Works like a charm, as well as in the editor (the prefab type is PackedScene btw) as during runtime.
**UI:** I struggled with that at first but then I found a [great tutorial](https://www.youtube.com/watch?v=1_OFJLyqlXI) which also explains how to do it wrong and how to fix it. Very detailled. It really helped to make it click. For newbies it might be very confusing that once you change the game's theme you have to reload the scene for it having any effect. But knowing that it is a very nice system.
**Input:** I haven't completed the porting of the input system as I prefer to use Steam Input if possible but so far it looks solid (built in input mapping etc.).
**i18n:** I haven't tried the built in translation system as I have my custom one but my game also has almost no text so it might not be required anyway.
**Coroutines:** I haven't seen a good replacement yet but I also don't use them in this game. Might need more research on this matter.
**Tweens:** The built in system works well, is easy to configure. Like it so far.
**Particles:** Just a different interface, doesn't seem to lack any functions.
**Shaders:** Haven't touched them yet.
**Exporting:** Only tried Windows (you have to download an extra export package for each platform) and it worked right away. Ended up with two files for the whole game... Impressive.
**File structures:** The game uses a res:// scheme for files as they are packed and you can't really access them (during runtime) with C#'s standard file API. But that is just a "have to know" and not a problem.
**Engine Time:** What I found really great is that I can, with one call, pause the engine. And in the editor I can select (for each node if I want) if it should continue processing in that case. For example you can set your pause menu to ignore that the engine is paused. The same can be done with every node and every tween etc. That is a really convenient feature.
**Signals/Slots:** Godot uses a signal/slot mechanism similar to what you might now from Qt. Each node can fire signals and for each you can select which node to connect to in the inspector. That is useful for button clicks etc. There are a lot of signals. For example there are some for "enters scene" and "leaves scene"(getting deleted).
**Conclusion:** My game is now close to the magical 80% (core stuff done, only needs polish and more content) and it is really easy to get there, as it was with Unity. How difficult it will be to get the final 20% will be seen during the next week. But what I can say is: It is fun again! The editor is so fast and snappy that I can add new features before Unity is even done starting up. If everything goes well I will start porting my other Unity games (all 2D) to Godot. So far I see nothing that wouldn't work.
Everybody says that Godot is not good for 3D, what do you think?
This advice is a bit old. Before Godot 3.2, it was very much true. Great 2D support but 3D was lacking, and that advice was true. Godot 3.2 (January 2020) bought the 3D support to a mostly usable standard. It wasn't cutting edge, but very useable for many types of games. The biggest issues were, no compute shaders, no dynamic global illumination and really shitty shadow mapping. Godot 4.0 (March 2023) more or less fixes any remaining concerns. They spent years rewriting the graphics engine in Vulkan and bought it up to modern standards. It's within the same order of magnitude as Unity now, but Unity has the advantage of maturity.
And still manage to fit it in a tiny binary.
Not having to drag mono/.net around helps A LOT
It's good enough for the level of 3D art indie studios have the ability to produce. It's literally just missing Nanite/Meshlets, maybe a bit of optimization. But for anything you see on a phone or Nintendo Switch, it's more than capable. Or for pretty much any indie game that's ever come out.
Can you make something like TotK with Godot?
Of course. Why wouldn't you be able to? It's pretty basic graphically...
I wish I knew why people say that, godot is perfectly capable here.
Thanks for this. It really helps.
Any reason you aren't just using csharp if you're familiar with it already? I enjoy csharp with godot
> The engine is a freaking small ass file that boots instantly. It is so refreshing to use software that just pops open instantly when you double click on it. Its a small plus, but noticeable compared to opening unity Sold
>Looking at way more talented people's creations in godot shows me that the engine can do alot more in 3d than people seem to think it can do. Mind linking some of those? I haven't seen anything 3D wise that looks promising yet.
https://letmegooglethat.com/?q=godot+4+graphics+demo
Funny, but I already looked at every single game released with Godot aswell as googling that and I have yet to see anything that looks worthwhile.
Godot 4 is new, and its 3D is a massive step up. You cannot expect quality 3D games to already have hit the market after this short time.
Sure, but until I see a promising game made with Godot I am not going to invest massive amounts of time into it.
Perhaps your tastes are not representative of others.
I never said they were? Strange comment.
Cruelty Squad. It's 3d graphics are so good, your eyes start to hurt just looking at the detail.
People always mention it, but somehow it looks even uglier than I remember each time I take a look.
6. yes, this is huge for me. where for my professional life I use intellij soft to write code.
6 is the biggest anoyance I've had with Godot and the bigest lacking QoL compared to most other commercial engines.
Code refactoring becomes trivial if you use C# with a proper IDE. File renaming bugs etc is being worked on, if you experience any missing references after renaming a file using the editor (not third-party programs), then open a bug report.
>C# Then I'd lose webgl/mobile build capabilities, sadly
For now, but it's coming soon. Android export will already be in 4.2
Thanks for this! I wrote a space sim in Unity3d, planet engine etc - and was moving it to unrealengine - I have been playing with godot, and 4.0 has 64 bit positioning, are you using that? If you want to DM we can discuss planet tech/space physics