Some meta discussion: "xyz reaches/releases version number 234234.324234" is entirely meaningless and the best way to ensure that nobody will care about your release announcement. Your project may internally have a very well defined and entirely logical policy as to how exactly to change version numbers based on internal project changes, but from the outside this is 100% untrustable and invisible, meaning your 2.0 release could mean anything from "we rewrote the entire thing" or "a set amount of time went by" (see Firefox/Perl/probably others).
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.
Arguably anyone following the project will be familiar with their version numbering policy. For those that are new to the project (including myself) a list of benefits in the title provides little information anyway as I have no background knowledge of the project before this release. Either way the best option is to read the announcement to find out more.
Yeah or announcing other things that are actually valuabe to readers like "Game engine XYZ reached 1000 published games" or "Game engine ABC reached this new platform DEF".
Yeah I would say the version number definitely has meaning, particularly in the case of a major version release.
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.
The features page looks well presented but has anyone actually used Godot? What are their experiences with it compared to writing your own games from scratch?
"From scratch" isn't the right metric, you'd compare it to unity or unreal. The key difference is this is actually open source so you have 100% control over your own distribution and licensing.
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.
I don't see the sample games listed on their site but found some googling. I'd be very interested in a good sample point&click adventure game especially for a FLOSS-engine. Creating one has always been in my "neat project" pile but I suck too much at drawing to motivate myself. Last time I tried (with no engine, just pygame) I got stuck figuring out a good way to do paths/movement/blocking areas and it sort of fizzled :D
I tried it out for a hobby project a while back. I really wanted to like it but there was a lot that felt broken. One problem, if I recall correctly, was that running from within the editor worked but exporting a standalone build produced something that just would not run.
Honestly, having been burned once after investing a significant amount of time, I would stay away unless they've significantly overhauled things.
One thing I don't get with game engines: why do they feel the need to make a X-like scripting language, where X=Python in this case, and X=JavaScript in Unity's case?
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.
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.
There's a history of reinventing the wheel in game development just for the sake of doing so.
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.
Yes, I'm aware of the AAA exceptions. Source, CryEngine and Unreal Engine were around since long before Unity. They represent an extreme minority of games. Obviously the concept of game engines is older than Unity, I didn't think I needed to explain that here...
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.
I've been part of a community of hobbyist/indy gamedev since 2002. At that that time, there were very few engines usable by hobbyists due to price constraints:
- Quake 3 Engine for FPS-like. Other FPS engine were moddable, but as the source code was not available it limited the possibilities.
- RPG Maker for old school JRPG
- Adventure Game Studio and GameMaker for Sierra/LucasArts adventure games. I could probably include ScummVM.
- Mugen (and another one I forgot the name) for VS fighting games.
I certainly forget some others.
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#.
Not that it alters your point in any way whatsoever (except to date third party engine-reuse even further), but Hexen used a variant Doom engine, not quake. Hexen 2 was the one that used the Quake Engine.
> "One thing I don't get with game engines: why do they feel the need to make a X-like scripting language..."
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.
So in other words: make it like "X" to confuse people who already are fluent with "X", and remove the undefined behavior in "X" and introduce new undefined behavior, which will happen eventually as no language is immune to this.
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.
Why not extend an existing language? Python's meta programming capabilities are excellent. Keep the syntax the same, but introduce new features as you see fit. Wouldn't that work?
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...
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.
> 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.
Totally agree. I made the same small game in Unity and Godot about a year ago to compare them. Learning and using Godot script was no big deal.
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.
It was a while ago, so I can't remember exactly. It was either that the option didn't exist at that point, or the pain of using the built-in editor was offset by something else, like the ability to debug or syntax highlighting or autocompletion.
- 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.
> One thing I don't get with game engines: why do they feel the need to make a X-like scripting language, where X=Python in this case, and X=JavaScript in Unity's case?
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.
What's interesting here, is that they seem to have actually started with Lua, but then switched to a custom language at some point. I'm not quite sure what were the exact reasons, as googling leads to a github wiki which since "has moved", but there's some discussion in an earlier HN submission [1]. That said, personally I can't say I'm really convinced (although I'm not a game programmer by any means).
That's an over generalisation. Unity uses JavaScript, Boo, and C#. Cryengine and Stingray use Lua. They are those exact languages, not "like" those languages.
UnityScript is a JavaScript-like language derived from the Boo compiler. Essentially, boo with the input parser modified to consume an input stream that looks like JavaScript. No first-class functions, no Object class, etc. I feel like it was designed to give people already comfortable with JS or AS2 an easy transition. I always recommend c# instead.
>why do they feel the need to make a X-like scripting language, where X=Python in this case, and X=JavaScript in Unity's case?
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.
Unity's Javascript was actual Javascript. You might be thinking of their (deprecated) Boo language which was a variant of Python. Nowadays though Unity has pretty embraced C# as the language of choice.
UnityScript is closer to ActionScript or Javascript-flavored C# than it is to Javascript. It uses class-based instead of prototypical inheritance and generally uses the conventions and concepts of OOP instead of functional programming.
Godot is awesome. It's a great alternative to Unity. It has a friendly community (IRC). The all-in-one editor is nice. The scripting language is easy to get into and if you need to, you can extend the engine and scripting language with C++. And the export to windows, linux, mac, ios, android and web works actually quite well.
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.
same here. much much better at 2d than unity and holds its own in 3d as well, even if not really comparable to what unity 5 can do.
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 problem with it (and many of the other alternatives) is not having an associated Asset Store. Not that I have an overarching need to buy stuff, but because there is a curated place where I can find a model or prop I need that will (almost always) import properly and work and scale the way I expect. Yes, you can scour the internet for "free" 3d stuff, but as often as not it's worth what you paid for it, and unless you're running the program it was created in you will spend more than a little time getting it to behave.
> 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.
Anybody know if Godot has a business model behind it or is it co-ordinated purely by volunteers? Perhaps it's enough that improving the game engine via open source could help Okam Studio produce games more quickly?
58 comments
[ 2.9 ms ] story [ 122 ms ] threadIf 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.
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.
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#.
https://en.wikipedia.org/wiki/Crystal_Space
https://en.wikipedia.org/wiki/OGRE
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.
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.
[1] https://news.ycombinator.com/item?id=7209149
[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.
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.
http://atomicgameengine.com/