Something I learned in 2022 through Godot is why these engines often seem to write their own scripting language. It frustrated me for years: I don’t want to learn your custom language. Just use something that exists!
But after spending time making some games for fun and learning, I realised: 90% of making a game isn’t coding. The code is usually just glue, and you aren’t hiring software engineers at crazy tech salaries to do that. You’re empowering your game devs to do it.
(Of course there’s a lot of more complex coding in many games, and there’s bindings for other languages when you need that).
> The code is usually just glue, and you aren’t hiring software engineers at crazy tech salaries to do that.
And the result is that there is no other software category that ships so extremely buggy code.
The code quality of games is the lowest I've ever seen.
Dynamic scripting languages only add to this overall mess…
The other problem is: Building a proper language and runtime is a full time job already. Adding this as a "side project" to a game engine (which is a very complex piece of code by itself!) is a big error imho.
I hope we see soon some strongly typed static language with very good type inference and a nice, clean, and simple syntax in Godot.
Would be than nice if Godot would concentrate on the game engine (and the editor) instead of trying to invent a language on the side also, as Godot as such is really great! One of the nicest programs I've ever used. (Especially compared with the incredibly buggy and terribly "documented" shit show that Unity is).
Games are also frequently going to be some of the most complex software you'll ever install. Bugs are just inevitable no matter what you do, short of writing games in Haskell (maybe), which sounds like a nightmare to me.
That said I've only ever used C# in Godot. Hasn't let me down yet.
> Bugs are just inevitable no matter what you do, short of writing games in Haskell (maybe), which sounds like a nightmare to me.
Bugs are evitable. That's just a question of money. But yes, for games the cost would be to high usually.
Also I don't think Haskell would help much. (And it would be unusable most likely, imho).
But proper abstractions and strong types can help a lot!
On the abstraction side Godot seems great. But the scripting language (even nice in isolation) is not a good idea, imho.
Refactorings in dynamic code-bases are almost not manageable without introducing bugs. (Especially as you don't have proper tooling support without static types).
C# as such isn't bad. But it's syntactically unpleasant. Way to much overhead for game logic "scripting tasks". Still I would use it instead of GDScript. One needs proper tooling support when writing code.
Let's see what else will come up in Godot. They have some interface layer for other languages (even not fully supported with alternative languages).
Agree with this. I'm a huge proponent of static typing systems and good languages, so seeing Godot create their own language was a huge sticking point for me - I even created a typescript to gdscript compiler! But after a while, I realized that GDScript was remarkably productive, even though it lacks a lot of the bells and whistles that I'm accustomed to.
But dynamic languages are a big horror when it comes to bigger projects. Especially when things get "reworked" heavily the whole time (as not uncommon with especially games).
GDScript seems very similar to a simple Python syntax. I really had no problem picking it up when working through some Godot tutorials. The syntax is so simple that if you ever needed to port it to another language it should be quite trivial to do so. I would be interested to hear the experiences and opinions of anyone who’s written a considerable amount of GDScript though.
Also the scripting language is tightly integrated with the C++ object model without a lot of binding code because they can rely on conventions in defining C++ classes and native facilities built into the scripting language. You don’t really need to develop native C++ extensions anymore but it’s a really neat system to work with when you do.
So you exclusively used GDScript? I find myself kind of on the edge of trying it out. I have experience with C#, so just wondering if it would be worth it.
But after spending time making some games for fun and learning, I realised: 90% of making a game isn’t coding. The code is usually just glue, and you aren’t hiring software engineers at crazy tech salaries to do that. You’re empowering your game devs to do it.
(Of course there’s a lot of more complex coding in many games, and there’s bindings for other languages when you need that).