Godot game engine reaches 2.0
godotengine.org
godotengine.org
What's really nice is the notion of scenes which I prefer to the way scenes are handled in Unity. Scenes in Godot are are simply node-trees which you can instantiate in existing scenes. For example you create a character in a single scene which you instantiate in a level scene. I always had the impression that this favored encapsulation compared to highly interdependent components in unity.
What brought me back to unity was 3D, scripting and debugging. 3D in Godot feels limited. Shader graphs are not really usable, yet. It's a lot simpler to create something nice in Unity with the standard shader and some assets. And well, the debugger, it's simply not comparable to Visual Studio. Variables are sometimes not inspectable. I missed refactoring alot. And sometimes you need to dig very deep to understand how stuff works because many things are not yet documented.
All-in-all, I love Godot. It's a nice cross-platform development environment. I simply hope that I can come back later when all rough edges are gone.
gscript is a little too slow, but layouts are great to make ux with and the event framework is sane enough to make user input not a chore as in other engines.
eventually moved to phaser.js because that's even more cross platform and I'm fitting more and more stuff in shaders anyway.
My .02 worth as a casual indie developer.
From the post:
> Godot community keeps growing and users keep producing more assets, scripts, modules, etc. we are in need of an unified platform for sharing them. As such, we will be working towards having an asset sharing platform (website + REST API + Godot integration) for 2.1. The built-in platform will be free (it will be integrated with GitHub), but we will make sure that the REST API is well defined so anyone can make a commercial asset sharing platform and integrate it with Godot.
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.
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.
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.
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.
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#.
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...
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!
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.
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.
[0]: http://wiki.unity3d.com/index.php/UnityScript_versus_JavaScr...
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.
I haven't looked at it in 6mo but back then on the 1.x branch there were many, many thoroughly polished example games ranging from 2D (platform / isometric / tile) to 3D (third person, others i forget).
Normally you get 1 incomplete mechanic as an example, not an actually playable "game" with more polish than most app store stuff.
I was pleasantly surprised with these polished examples, but at that time the docs were not that thorough (cursory look tells me they've improved), but the examples pretty much made up for it. Almost any game you'd want to make you could start with their example and build out.
I'm excited it's growing. I'll probably play with it for 7DRL.org in a couple weeks.
The examples are in godot/examples or something after you extract it I think.
Honestly, having been burned once after investing a significant amount of time, I would stay away unless they've significantly overhauled things.
If you actually care at all about your release announcement being read, include in the title line the actual benefit the new version provides to people.
Now a lack of release notes and a major features/what's new document - that's a release promotion fail.
I could see something like "Godot reached 2.0.1" getting a little tiresome. I would agree that, for a minor release like that, wording the announcement as "Godot engine now supports xyz" would definitely be more helpful.
But when they've got 20 or so major new features, there's not really a better way than to say "Godot 2.0 released" with a link to the changes.