5 ms·

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

by Cyph0n 11y ago

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.

chris_wot 11y ago
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.
- chris_wot 11y ago
  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.
scrollaway 11y ago
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.
- eru 11y ago
  > 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.
  - scrollaway 11y ago
    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.
    - eru 11y ago
      Together with your grandparent post, this paints a fuller picture. Thanks!
  - cgarrigue 11y ago
    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#.
SeanDav 11y ago
> "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.
- Cyph0n 11y ago
  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.
  - SeanDav 11y ago
    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 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.
    - Cyph0n 11y ago
      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?
      - chris_wot 11y ago
        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.html?highlight=gdscript http://docs.godotengine.org/en/latest/reference/gdscript.htm...
oolongCat 11y ago
This should answer your question, http://docs.godotengine.org/en/latest/reference/gdscript.html?highlight=gdscript 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.
- mpinteractiv 11y ago
  > 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.
- hrnnnnnn 11y ago
  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.
  - stcredzero 11y ago
    > 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.
  - adolson 11y ago
    Why didn't you just set the external editor options in Godot and use whatever editor you wanted?
vog 11y ago
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.
- pizza234 11y ago
  On the GDScript introductory page (http://docs.godotengine.org/en/latest/reference/gdscript.html?highlight=gdscript 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.
mpinteractiv 11y ago
> 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.
akavel 11y ago
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 https://news.ycombinator.com/item?id=7209149
bananaboy 11y ago
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.
- anglebracket 11y ago
  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_JavaScript http://wiki.unity3d.com/index.php/UnityScript_versus_JavaScr...
  - robterrell 11y ago
    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.
  - bananaboy 11y ago
    Thanks, sorry, you're right about UnityScript! I try to avoid it if I can help it ;)
- deleted 11y ago
  [deleted]
davexunit 11y ago
>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.
hesdeadjim 11y ago
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.
- icosa 11y ago
  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.

by Cyph0n 11y ago

chris_wot 11y ago

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.

chris_wot 11y ago
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.

scrollaway 11y ago

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.

eru 11y ago
> 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.
- scrollaway 11y ago
  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.
  - eru 11y ago
    Together with your grandparent post, this paints a fuller picture. Thanks!
- cgarrigue 11y ago
  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#.

SeanDav 11y ago

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

Cyph0n 11y ago
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.
- SeanDav 11y ago
  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 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.
  - Cyph0n 11y ago
    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?
    - chris_wot 11y ago
      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.html?highlight=gdscript http://docs.godotengine.org/en/latest/reference/gdscript.htm...

oolongCat 11y ago

This should answer your question, http://docs.godotengine.org/en/latest/reference/gdscript.html?highlight=gdscript 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.

mpinteractiv 11y ago
> 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.
hrnnnnnn 11y ago
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.
- stcredzero 11y ago
  > 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.
- adolson 11y ago
  Why didn't you just set the external editor options in Godot and use whatever editor you wanted?

vog 11y ago

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.

pizza234 11y ago
On the GDScript introductory page (http://docs.godotengine.org/en/latest/reference/gdscript.html?highlight=gdscript 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.

mpinteractiv 11y ago

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

akavel 11y ago

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 https://news.ycombinator.com/item?id=7209149

bananaboy 11y ago

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.

anglebracket 11y ago
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_JavaScript http://wiki.unity3d.com/index.php/UnityScript_versus_JavaScr...
- robterrell 11y ago
  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.
- bananaboy 11y ago
  Thanks, sorry, you're right about UnityScript! I try to avoid it if I can help it ;)
deleted 11y ago
[deleted]

davexunit 11y ago

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

hesdeadjim 11y ago

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.

icosa 11y ago
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.