Live data from Hacker News

Godot game engine reaches 2.0

godotengine.org

31–40 of 59 posts

Re: Godot game engine reaches 2.0

#31

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 U…

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.

My .02 worth as a casual indie developer.

Re: Godot game engine reaches 2.0

#32

Earlier quoted context omitted.

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.

As far as I'm aware, Unity does not have JavaScript. It has the superficially similar "UnityScript" [0]. [0]: http://wiki.unity3d.com/index.php/UnityScript_versus_JavaScr...

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.

Re: Godot game engine reaches 2.0

#33
post #31

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 U…

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…

Looks like it is going to happen next.

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.

Re: Godot game engine reaches 2.0

#34
post #17

Earlier quoted context omitted.

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 prem…

> Until Unity became popular, everybody was doing their own game engine for their own game. 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.

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#.

Re: Godot game engine reaches 2.0

#35
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?

Re: Godot game engine reaches 2.0

#36
post #30
post #12

Earlier quoted context omitted.

> "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. Sounds awesome.

What is your one-size-fits-all-possible-use-cases scripting language they should all use instead?

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.

Re: Godot game engine reaches 2.0

#37
post #36
post #30

Earlier quoted context omitted.

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. Sounds awesome.

What is your one-size-fits-all-possible-use-cases scripting language they should all use instead? 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.

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?

Re: Godot game engine reaches 2.0

#38
post #4

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?

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.

Re: Godot game engine reaches 2.0

#40
post #8

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…

>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.

Post reply on HN