Does Godot only capable for prototyping and small games only?

UnknownUser

Hi guys! This is my first post. I've been using godot for a while and successfully made a tower defense game. However, I ran into an issue where my fps dropped to 5 - 15 once there are >100 sprites and particles in one scene. I read on GitHub and they said GDScript is 10x slower than C# (based on the benchmark test) and is only good at rapid prototyping and tiny simple game. I was using Godot 3.0. Is it any better now in speak of performance?

Intel Core i7 7700HQ GTX 1050 16GB RAM

Unfortunately, my source code is gone so if you guys want to test the performance, I can only post my compiled game. https://drive.google.com/drive/folders/1d4CLegi8kHUZGJrYVyajIcKICjVvqE4C?usp=sharing Hold for 27 minutes then you'll experience lag spike.

TwistedTwigleg

Well, what you are asking and what the title is asking are two different things. To address each of them.

Question: Is Godot only capable for prototyping and small games only?

Answer: Godot is, in theory, just as capable as any other game engine out there. Especially with access to the source code, any barriers could be worked around with enough time, energy, and changes to Godot. In practice though, there are some roadblocks that keep Godot from being an ideal choice for some games. This is mostly limited to 3D though, where Godot is missing some key features. In either case, Godot should have the capability to make fully featured games, especially in 2D, it just may not be as easy as other game engines in certain aspects.

Question: Is performance in Godot better and/or would my game see improvements?

Answer: Yes, Godot performance has gotten better, especially in 2D. Godot now has sprite batching, which sounds like it would be a major boost in performance if your game is 2D and has lots of sprites and particles. I would highly recommend trying the latest version of Godot, Godot 3.2.2, and see what you think. Just make sure to make a backup first, just in case.

Additionally, bonus question: Is GDScript only good for rapid prototyping

Answer: I'd say it depends. For performance critical code or code that is called frequently, you probably want to use either C# (faster) or C++ (fastest). However, for the majority of game code, GDScript's slower execution speed is not too much of an issue because the code is either run infrequently, or is simple enough that the difference in performance is marginal when used in projects. I would suggest a hybrid approach for big/complex games, where GDScript and a more performant programming language are used together That said, this is just off my personal observations and game development experience, your results may vary.

(Side note: For some reason I cannot move this thread, but it ideally should be in the General Chat category due to the general nature of the questions. Not a huge deal either way though)

Megalomaniak

Basically reiterating what was said above however I'd say the ideal use case for GDScript is gameplay functionality, since it is a language targeting the game designers more than anything else.

For more complex and heavily performance hitting stuff you'd look towards either using GDNative/C++ for a plugin implementation or just implement it as a module straight in source as C++ effectively making your own custom forked engine.

UnknownUser

My game uses _physics_process almost in each element. Could that be the culprit? I apologize for misplaced thread. Anyway, could you guys point me where complete GDNative tutorial is? I'm not familiar with GDNative so I have a lot of question, like: - How do you store a value between GDNative and GDScript? - How to call a function from different languages? - How to install C++ into GDNative?

so on and so forth

Megalomaniak

It may, though in some respects that might be better than doing everything in _process().

If you have code that doesn't have to be constantly run and reevaluated then obviously making custom functions for them and only running those when they are needed is the way to go.

Make use of signals and threads and call_deferred and all that good stuff.

UnknownUser

I use a lot of signals and custom functions but I doubt my script is the one that slows down my game. It started to lag when there is a lot of sprites (building and enemies) and particles (towers shooting at hostiles, and the hostiles hitting the structures). So I thought it might be particles2D that causes lag?

TwistedTwigleg

One of the best ways to know is to profile your game. If scripts are causing issues, it should show up in the profiler, which you can find in the bottom bar of the Godot Editor. That would probably be the best way to find out what exactly is causing the issue, but you'd need the source code to figure it out.

If there are lots of sprites on the screen, your game probably would benefit from sprite batching, which was just introduced in Godot 3.2.2 :smile: