Hacker News Reader

Comment by Cyph0n | Hacker News Reader

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.

View on HN

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.

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

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.

Together with your grandparent post, this paints a fuller picture. Thanks!

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

Crystal space and Ogre3d were pretty active back then.

https://en.wikipedia.org/wiki/Crystal_Space

https://en.wikipedia.org/wiki/OGRE

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.

Thanks!

This should answer your question, 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.

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

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

Why didn't you just set the external editor options in Godot and use whatever editor you wanted?

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.

> A class file can inherit from a global class, another file or a subclass inside another file.

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

I'm having LPC flashbacks ...

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

[1] https://news.ycombinator.com/item?id=7209149

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

Moreover, there are very good languages out there, which are designed for simple embedding.

LUA, for example, seems to be quite popular among game engines.

Reinventing a custom embedding language is almost always a bad idea.

On the GDScript introductory page (http://docs.godotengine.org/en/latest/reference/gdscript.htm...), they give the explanation of the shortcomings of other languages:

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

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.

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

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?

They already tried:

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

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

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.

Thanks, sorry, you're right about UnityScript! I try to avoid it if I can help it ;)

Do they have a document detailing their scripting language?

And can they expose bindings for other scripting languages? Is so, maybe this is something they can move to.

Ah. They can!

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.

Reply on news.ycombinator.com