Well, I'm leaving godot for some time...

Question

Hi,

I know anyone will care about my decission :), but as I said hello when I came in I wanted to say laters beforeI leaving.

I must say I really like godot. It has been a nice surprise to come across it but after doing some tests with GDScripting I think it is not for me. I'm not saying this because the language is not easy to learn, etc... but it is too slow for me. And I don't want to be travellig too much between C++ <-> GDScript world. One of the main things I like about godot is that it is autocontained. All in just one place, no need to go to vs for coding, no need to go to a external program/web to build shaders, etc... The bad thing is that there are things that I could build up in scripting language (C# in unity for example) like a combo system, fSM, etc... at decent speed and I'm starting to guess this will be an important caveat with other more intensive tasks.

My game needs a bunch of enemies on screen and it is important that it runs smooth. So, I'm leaving godot until the big guys decide what to do with the scripting thing. I have been listening about dynarecs, make it static typed, etc... don't know what could be bettery and the best solution to fit into the engine, but I will be returning back as soon as I feel confortable with a fast scripting language.

I must say that you guys rock too, community is incredible, IRC channel awesome and really helpfull. But I need my games to be finished and can't rely on godot yet.

Thanks a lot to godot team for creating such a nice piece of free software. Hope to see you soon!

Laters!.

Comments

Is godot that much slow?

---

What exactly were you trying to do with gdscript that made you think it was too slow?

---

I am disappointed by some of the priorities chosen by the main devellopers.
It's only focused on usability for a too long time.
Most Godot users wait for performance and better 3D but now developers want to implement a visual scripting system... How many time this feature will delay the real priorities ?

---

It's difference in speed compared to C# is insignificant and everybody knows dynamically typed languages are better for games. Also, you don't need to pay for it, and don't need to show "Made with Unity - Personal Edition". Unity doesn't even have tilemap! It's better in every way. Unless you're going to do a 3D game. Then I understand you.

---

What? A visual scripting system? Like in Unreal engine? Please no. I don't see any value in doing that. Such system is too limited compared to standard scripting.

---

everybody wants their needs and the all needs are different. :)
what I can be sure is godot has so much well designed.
try to ask to some another engines to improve usability as much as godot.

and what I had seen since 1.0 alpha,
people complains usability, and dev team focused on it.

and since a some day, people complains about performance.
I think godot dev team did their job well. :)

---

but now developers want to implement a visual scripting system...

If this is true... it's very, very... very bad news...
Really the wasted time of the developers. One problem - one solution. GDScript a comprehensive solution.

---

Most Godot users wait for performance and better 3D but now developers want to implement a visual scripting system...

Source? There is no plan to focus on that anytime soon. Godot development follows what users ask for: for months people have been asking for usability improvements, and they were made. Since 2-3 months people are starting to be concerned with performance and 3D; it means that usability-wise, we're starting to be good and people are shifting their focus. We're shifting ours too.

Before complaining about performance and 3D, users were complaining about plugins and all begging for an asset sharing platform, drag and drop, etc. That's what 2.1 is about.

Don't know how you manage to think the devs should/can do more than that. Fork it, and implement what you need if you really think the development focus is not good.

Answer 1

Godot for me is a bit slow compared to other languages, for example C# when running simple algorythms. I have seem some graphs around on the net (can't find them now) confirming my suspects. GML (Game maker) seems to be the worse one.

On the other hand and based on this I don want to write all my game in GDScript at this moment because I don't want to be kaged later when real problems come because of performance.

For this game I will stick with unity (And its poor 2D workflow) but at least I can code in C# with "great" performance.

I have read that GDScript when running in release improves x 3 or x 4 but this si somthing that I would have to test.

On the other hand, I could just code everything in c++ but it is not my thing these days.

Cheers!

Comments

It's your choice, but you're making it on some pretty vague assumptions.

---

sorry, this was answered as an "anwer" instead of a comment.

---

Well, I ussually base all my decisions in my tests, comparison of the this tests against other's tests and how I see the future of my game. Have been too many times forced to move to another engines (frameworks) because of a poor initial decision. As I said, godot is a really nice tool for me, but I'm a programmer, and I need something a bit more elaborated than just GDScript to build my systems, etc... without going the C++ route.

I have read a lot about why the developers went GDScript way instead of C# or Java, but I think this was not a good decision. GDScript is a great entry point scripting language for newcomers but lacks too much features that cold help in rapid development too and one of the worse is it being in the slow side of things.

Cheers

---

Is nice to see negatives comming. Some prove that I'm wrong will say much more than this.

---

So you're dumping Godot based on the performance of your scripts in the editor, packed with tons of debugging features, without ever having tried the optimized release binaries?

Well, good luck with your next engine :)

---

As I said previously, I read somewhere that gdscript is between 3x-4x faster in release mode. I tested both versions with my stress code. Anyway, I think I will give some more time to godot. You all have changed my mind and I think it deserves a second chance :).

Cheers.

Answer 2

One of the biggest advantages of Godot (and certainly the biggest difference between Godot and Unity) is that Godot pushes you into the right direction in terms of clean code and project structure.

There is a long thread on github discussing the pros and cons of adding C# as a scripting language and among others I have written quite a bit to explain why I think that that would be a bad idea, so I am going to outline the arguments here and then just link to that thread so I don't have to type everything again.

While both Unity and C# have features that are designed to make mixing and matching of structures and patterns easier (see here for a longer explanation) Godot has features that support clean object oriented structures. One of these features is the combination of a very concise scripting language that is optimized for game-specific scripting and a very clean C++ interface that makes extending the engine very easy.

In my experience having a language that is optimized for library programming like C# as a scripting language has a bad effect on the code and the resulting gameplay. See here for a longer explanation. So I strongly suggest that you write gameplay specific code in GDScript and reusable code in C++. Most likely that will automatically fix your performance concerns, since performance critical things mostly happen in low-level code, not in gameplay code.

So right now I couldn't disagree with you more and I am also not able to follow your reasoning.
You may want to explain
- why you don't want to use C++
- what features GDScript is missing that would help in rapid development, i.e. that make development more "quick" rather than more "quick and dirty".
- how huge your combo system or your fsm is supposed to be that it's going to affect performance.

Also don't believe too much in rumors about where the engine is heading. The thread I linked was started because of the rumor that C# might be added to the engine at some point and so far several people have argued against it and only one has provided an argument in favor of C# (and not even a good one), so I don't really expect it to happen anymore. I mean it's going to be available as a side project for sure, since Godot has a very active open source community, but I am not afraid anymore that GDScript will suffer the same fate as Unity's Boo language.

Comments

Exactly,
I'm satisfied as it is and I think that the developers know exactly what they want do for Godot engine....those are just agents :-)) of Unity and want to ensure that we had the same mess in the engine as they have.

---

Things improve because different people think different and try to give his point of view. Please do not call me "An agent of Unity". I am not an agent of anyting, perhaps I'm a zx sinclair spectrum as amuch. I just expressed what I saw with my tests.

I'm not saying devs don't know what they want but perhaps their views are not aligned with mine. Thanks all.

---

About the question why I don't wnat to use C++ it is simple... it is not a good language to write gameplay and there are other languages that lay inbetween gameplay and low level. Thanks all.

I'm still developing my combo system in godot with gdscript, I just want to see if my intuition driven by my tests are correct or not. I will post it when finished.

---

Yes, C++ is not as suited for gameplay code as other languages but it is very good for library code. GDScript on the other hand is not a good choice for library code but it is very good for gameplay code.

If you don't like the idea of using two languages then I recommend sticking to Unity. That's one of the strengths of that engine, that it doesn't push you to create a clean structure.
In my opinion and from my experience the negative side effects of that are undesirable, but luckily there are different engines with different philosophies to choose from.

I don't want to sound condecending, but I think that you are overestimating the difficulty of writing part of your code in one language and the other in another language, and more importantly that you are underestimating the importance of writing part of your code in a very clean and portable way and the other part in a very quick and concise way.
If you are like me and you want your game code to be simple and readable while your non-game-specific code should be robust and portable, then using two languages as a very visible way to mark which is which is actually really helpful.

Answer 3

Hello, about Godot priorities.

In my view, the main focus that is usability right now is an important one. You may disagree, but Godot is coming out of a stage where it wasn't all that usable at all (ie. had a lot of basic UI features missing even such as a color picker).

I am thinking the developers are on the right track if the idea happens to be the concept of a usable engine attracting developers who then contribute to the source (as opposed to leaving it on the backburner and focus instead on performance and features). On that, it's also simply a part of the Godot development paradigm, where each new release has a major focus it spends a lot of time (like 1.x for 2D, 2.x for usability, and 3.x for 3D and performance). I also don't think focusing on performance instead would've meant there would be no complaints either, because then there would be complaints as to why Okam doesn't seem to care about usability.

In short, due to the focused nature of the releases, just wait a little bit until they shift their focus to include performance.

Comments

I don not understand this discussion. Iam not a Godot-Expert, coz i don´t have
written this engine and like every other programm you have not written by yourself
you have take the time to read the source code or you don´t ...like most of the people.
But what i can tell about C# vs GDScript only needs some lines:
C# is not a native language like C++/C and you can compare it to JavaScript.
To put it in simple words: C# is like a Script-Language.
It´s heavy and slow compared to C++/C coz it does tons of checks.
C# is checking, checking, checking this one, that one and everything else you can
imagine. That makes it thread safe and safe in all other terms.
It´s seems like C++ by construction but it does so many heavy weighted and
sometimes needles checks (so most times nothing wents wrong in a good C# code)
that your time-critical game getting slower and slower by increasing it with C# code.
On the other hand i can not understand that anybody who is able to code
a gameplay in C# is not able to code it in C++.
You are able to code everything you want in C++ and C.
GDScript seems to faster than C# in my opinion. You are just calling C++ Code
with GDScript. So there is nothing to complain about GDScript.
You can edit/optimize your GDScript-Commands in the source-code coz the commands
are just C++ code.
When you use Unity and write your Gameplay in C# what you are doing?
Do you write plain C# Code? No you don´t you just call the Unity-Api by C#
and nothing else more.
Be sure: Godot GD-Script is not slow compared to call plain API-Calls-from C#.

---

I agree with a lot of your thoughts but not with all...

This part: When you use Unity and write your Gameplay in C# what you are doing?
Do you write plain C# Code? No you don´t you just call the Unity-Api by C#
and nothing else more.

I write a bunch of logic in c#. I have, for example added complex IA through c# through my own behaviour tree engine that is running on c#. Of course, in the end you must call Unity API to let the magic show, but I'm talking about the "middleware" not written in native through a extension or exposed by unity native engine.

One of the things I don't like about unity is that as other states and you did too, it goes against clean and robust code.

Cheers.

Answer 4

Looks like Godot is getting Mono/C# support
https://twitter.com/reduzio/status/757726271493312513

Sorry to see you Godot (GOH-DOH)

Comments

So there will be a visual scripting tool. Plus they add C# (which is not bad by itself). I guess version 3 won't come before a long while.

I'm afraid the Godot team set their goal way too high and eventually won't be able to keep up with them. Plus, that would make the engine much heavier. I remember that someone once said that godot takes 2 GB. I can start now to see why.

---

The 2 GB thing was a fools' day joke, as you can see at this news: https://godotengine.org/article/godot-aims-mainstream