Until Unity became popular, everybody was doing their own game engine for their own game. All those game engines have their own image formats, sound formats, archive packing format, etc. None of this is ever open source, of course...
And before you think "in the name of performance", it's usually actually in the name of premature optimization and ends up being a bad idea. Reinventing the wheel indeed.
Edit: I've been in the games industry (specifically, in reverse engineering and dealing with these exact issues) for a decade and this is all true, and from experience. I see I'm still being downvoted, without any reasonable explanations though. If someone here disagrees, I'd like to hear it.
The very first Half-Life was already using one of the Quake engines. As was Hexen.
The first Deus Ex was using the Unreal engine.
That was all probably ten years before Unity.
These engines being tailored-made for a specific type of game, people wanting to do something else had to create their own engine, often in C++, sometimes in Python or Lua, reinventing the wheel most of the time. The barrier for entry being so high, game designers had to team with coders, but their end-goal not being always aligned (creating the game vs learning how game engines are coded) this lead to the demise of many projects.
With Unity, a general purpose game engine became available for a very low price (in particular compared to Flash). Many game designers saw it as a way to work on prototype without needing to recruit a team of coders. And for many coders, it was a way to try their hand at game design, while being able to push the engine further using C#.
And even then, CryEngine, Unreal and Source are all engines centered on a very specific kind of game (fps style). There was no serious general-purpose game engine before that, that devs actually used.
As for my personal experience with GDScript, I used to experiment with Godot a while back, and honestly I never felt like GDScript was some sort of hindrance never felt it was in the way. It was really, really easy to pick up if you know another programming language already.
Nobody is saying that it's wrong or an "hindrance", it's just yet another language to learn for a single purpose,yet another ecosystem to write libraries for. But the main issue is that it's either that or C++ (nothing against C++ either, it's just that it cannot be put into random hands). Choice is good. But there is Processing,Haxe,Vala,... + all other general purpose languages and co in this space already. It's not like they couldn't pick something that already existed.
The main difference was that I could use VS for Unity and it had a vim plugin, but if I wanted to edit text in-editor I was stuck with Godot's own one.
Yet another move the one should not copy from Smalltalk.
> # optionally, extend from another file
> extends "somefile.gd"
> # extend from a subclass in another file
> extends "somefile.gd".Subclass
Interesting feature.
# a file is a class!
So I checked the doc
> GDScript is a dynamically typed scripting language to fit inside Godot. It was designed with the following goals: (...)
So yeah, it's close to python but with a different syntax. Why ? it's a big fustrating.
Granted Python wasn't necessary developed with game design in mind(though there is absolutely no issue with developing games in Python). I feel there is a lost opportunity here.
> As with most dynamically typed languages though, the higher productivity (code is easier to learn, faster to write, no compilation, etc) is balanced with a performance penalty, but most critical code is written in C++ already in the engine (vector ops, physics, math, indexing, etc), making the resulting performance more than enough for most types of games.
Then why not go with a statically typed language at first place? I began programming with Flash and never had an issue with learning AS from scratch, granted AS2 was less difficult than AS3 for beginners.
Anyway, first time I hear about this project and it looks quite gorgeous.
LUA, for example, seems to be quite popular among game engines.
Reinventing a custom embedding language is almost always a bad idea.
- Godot embeds scripts in nodes, most languages are not designed with this in mind. - Godot uses several built-in data types for 2D and 3D math, script languages do not provide this, and binding them is inefficient. - Godot uses threads heavily for lifting and initializing data from the net or disk, script interpreters for common languages are not friendly to this. - Godot already has a memory management model for resources, most script languages provide their own, which resulted in duplicate effort and bugs. - Binding code is always messy and results in several failure points, unexpected bugs and generally low maintainability.
The gave a shot at LUA, and it didn't work out well.
They make it in "X" because they want a scripting language that is familiar to a large number of users and they only want it "X-like" because they don't want to recreate the entire language, including edge cases and undefined behaviour.
Sounds awesome.
Lua? Counterpoint: https://julien.danjou.info/blog/2011/why-not-lua
Any scripting language will have issues. It is far easier to reason about and deal with issues created by your own DSL than some other 3rd party language that you have minimal or no control over.
Initially, Godot was designed to support multiple scripting languages (this ability still exists today). However, only GDScript is in use right now. There is a little history behind this.
In the early days, the engine used the Lua scripting language. Lua is fast, but creating bindings to an object oriented system (by using fallbacks) was complex and slow and took an enormous amount of code. After some experiments with Python, it also proved difficult to embed.
The last third party scripting language that was used for shipped games was Squirrel, but it was dropped as well. At that point, it became evident that Godot would work more optimally by using a built-in scripting language...
http://docs.godotengine.org/en/latest/reference/gdscript.htm...
This is the age old external vs. embedded DSL battle. I'm firmly in the latter camp, which is why I'm disappointed that Godot invented their own language. Embedding domain-specific languages within general purpose programming languages is better for users and developers alike. For the developer, they don't have to spend valuable resources maintaining a compiler tower. For the user, they get to take advantage of all of the cool libraries (which the external DSL will have none of) and learning resources for the host language. In other words, the embedded DSL composes, and the external DSL does not. We should strive to use things that compose, and get rid of the things that don't.
[0]: http://wiki.unity3d.com/index.php/UnityScript_versus_JavaScr...
And can they expose bindings for other scripting languages? Is so, maybe this is something they can move to.
Initially, Godot was designed to support multiple scripting languages (this ability still exists today). However, only GDScript is in use right now. There is a little history behind this.
Why do they make people re-learn the specifics and slight differences of a language that has been around for more than a decade? On top of this, they are making their engines more difficult to maintain: bug fixes, new features, deprecation and backwards compat., keeping docs up to date, writing tutorials for the language, etc. etc.
I just don't see why these engines want to re-invent the wheel, even though what they end up with is simply a slightly modified wheel. /endrant
The engine looks cool however, and the fact that it's FOSS makes it a better option for budding game devs. I might give a go when I decide to make a simple game.