4 ms·

It’s surprising to me that javascript wasn’t chosen as the scripting language for all these gaming engines. Though I do see the benefit of C# being typed and co

It’s surprising to me that javascript wasn’t chosen as the scripting language for all these gaming engines. Though I do see the benefit of C# being typed and compiled.

chii 4y ago
i'm glad javascript isn't the scripting language chosen, as C# is very much superior, and would run faster!
krapp 4y ago
Everyone who uses javascript has to write it in a superset language that has sane types, a (poorly implemented) standard library, and other features javascript lacks, and treat it like a batch of volatile chemicals because outside of its specific niche of scripting the DOM, javascript is a terrible, unstable language at best adequate for purpose, a necessary evil because the web doesn't support anything else (barring WASM.) Gamedev isn't (necessarily) tied to the browser, so why not use a better language to start with? That said, there are forks of Godot that support JS/TS but I don't know how up to date or ready they are.
- beezlewax 4y ago
  Is there a use case for WASM here and rust for example to run games in the browser? There are game engines written in rust Bevy for example
- eropple 4y ago
  > so why not use a better language to start with? Perhaps consider that for many programmers, TypeScript is JavaScript, and TypeScript is that better language. I've put a decent amount of thought into using TypeScript for games because it allows for a flexible, expressive data model in a way that few other languages do. The performance might be a problem for some flavors of games, but I'm interested in discrete simulations almost exclusively, where it doesn't matter at all. But TypeScript allows effectively encoding intent into data structures and into code in a really ergonomic and pleasant way, while also running on virtually every gaming platform on the planet. (Rust, etc. are fine. If that's your bag, that's great. I'll write Rust if I need to, but I don't enjoy it, and don't seek out opportunities to write it.)
  - krapp 4y ago
    Typescript as its own thing, with real types, not compiling to JS or being limited to its semantics, I could get behind as a language for game scripting.
  - imtringued 4y ago
    In don't know what you mean by discrete simulations but I would expect simulation games to be more performance intensive because of unbounded complexity vs say an FPS game.
    - eropple 4y ago
      "Discrete simulations" are things like turn-based strategy games, roguelikes, and so on. You can think of it as "automated board games" in a lot of ways. https://en.wikipedia.org/wiki/Discrete-event_simulation https://en.wikipedia.org/wiki/Discrete-event_simulation In truth, I think V8 is almost certainly more than fast enough for real-time games (real-time in the gaming sense, not in the OS sense); Mono is fast enough for Unity, even, and Mono is creaky and slow, with a really poor garbage collector, on its best day. But for the stuff I'm interested in, I just don't care at all.
spyremeown 4y ago
I, for one, am very glad Javascript wasn't chosen as a scripting language.
JoeyJoJoJr 4y ago
All I really want is a decently performant 2D immediate mode rendering library with a decent console supported JavaScript/Typescript runtime. I’d love to see something like this pop up in the Deno ecosystem.
sovietmudkipz 4y ago
Unity used to have a JS interface, where one could either write their game object components in JS or C#. They deprecated the JS interface. I imagine it was too much work to support two languages? As a dev reading docs, I used to have to deconflict the parts of the docs talking about JS from C# (not difficult as an experienced dev -- I wonder how the first timers fared). I'd also have to translate advice from JS Unity programmers into C# when researching how to do certain game things. I'm sure JS Unity devs had to do the same with C# advice. I'm happy they aligned on one language. If JS had an optional type system baked into the language, I think it would be a better choice. However; it doesn't.
- wccrawford 4y ago
  I think it was more that Unity's "JS" was actually their own language that was just very similar to real Javascript. They were forced to support the language itself as well as the integration. It was a lot easier to just support C#, which is maintained by others.
  - llanowarelves 4y ago
    Hmm. Cocos Creator manages JavaScript/TypeScript ontop of their bespoke (ios:Obj-C++, Android: Java) + C++ native stack and they don't have that many engineering resources. Granted, they did have multiple breaking non-backwards compatible re-architecturings of their engine(s), along the way.
    - kevingadd 4y ago
      Cocos is likely using actual JavaScript. When I used Unity's JS dialect (a very long time ago, to be fair) it was very much not traditional JS and was its own beast, so Unity likely was having to do a lot of work on it.
- debugnik 4y ago
  UnityScript wasn't actually JavaScript, but a custom .NET language with a JS-like syntax, largely incompatible of course. Naturally people wanted to use C# instead.
fuzzy2 4y ago
Not really surprising. JavaScript-the-language is missing lots of features that could be useful, like operator overloading. Or any overloading, really. Nothing is stopping you from compiling JavaScript though, browsers do it. The lack of static types makes this harder, of course.
- beezlewax 4y ago
  Suppose you could use typescript and compile that?
  - fuzzy2 4y ago
    Yes and no. Yes that's possible but no, this is no longer (full) TypeScript. Check AssemblyScript on that topic, it's TS to WASM. Most of the dynamic code stuff isn’t allowed and, of course, there’s a different standard library underneath.
- deleted 4y ago
  [deleted]
moonchrome 4y ago
JavaScript doesn't have value types or operator overloading (also applies to Java) - this makes writing vector math pretty shitty imo - and you're working with vectors all over the place in games.
- Kiro 4y ago
  How does it help with vector math?
  - rmeby 4y ago
    I would imagine operator overloading helps with vectors so you can do things like: public static Vector operator -(Vector a, Vector b) { Vector v = new Vector(); v.X = a.X - b.X; v.Y = a.Y - b.Y; return v; } So then you can just write: Vector result = myVector1 - myVector2;
    - kevingadd 4y ago
      Also if you wrote the JS equivalent of that, each vector would be 3-4 individually heap-allocated doubles in v8, because they aren't able to allocate floating-point values inline. There would also be a new heap allocation for the result vector itself when performing each operation. The overhead really adds up. :/ At one point Mozilla had a prototype implementation of strongly-typed value types in JavaScript, but it fell by the wayside once WebAssembly became a thing.
      - ygra 4y ago
        You can use an array to keep the doubles together. V8 has something like half a dozen different array types, depending on what is inside and how it's used.
    - throwaway23532 4y ago
      Why not implement a method? var result = myvector1.sub(myvector2)
  - 4y ago
LelouBil 4y ago
C# has : - easy interop with native programs/libraries - modern language features (pattern matching, async, and many more) - Strongly typed
orthoxerox 4y ago
It's mostly a historical accident, like Python ending up as the data science language. Microsoft XNA used to be a popular indie game framework that used C#. Stardew Valley, Celeste and Terraria run on XNA. Mono used C#. Xamarin used Mono to create a cross-platform application framework that worked on mobile. Unity leveraged Xamarin to create a cross-platform game engine that worked on mobile, ending up using C#. Thus, two generations of indie gamedevs ended up learning C# to create games. Then Unity grew a whole lot, so more and more people ended up associating C# with game engines, so as soon as Godot was released people started asking for C# support. But C# being the language of choice doesn't really depend on specific C# features. It could've just as easily been Lua or JavaScript instead. For example, RPG Maker moved from Ruby to JavaScript when they upgraded to a new engine, again, because their new rendering engine was nw.js, and getting it to run almost anywhere was easy.
- kevingadd 4y ago
  I'd argue that the availability of value types in C# gives it a leg up over languages like JavaScript for performance-sensitive games work. These days v8 and spidermonkey have incredible garbage collectors capable of incremental/parallel collection so people have been able to ship JS-based games on PC+Console, but when it comes to game scripting it's either languages with value types like C#/C++ or languages with more predictable garbage collection behavior and performance like Lua and Ruby (Ruby especially is popular with Japanese developers, likely because the language originated over there.) C# being possible to mostly AOT compile (some exceptions) is also an advantage over JS for scripting since JS is not particularly efficient to run in an interpreter and many deployment targets don't allow you to JIT code at runtime. Languages like Lua have much better characteristics for those targets since they have high performance interpreters and cleaner language semantics.
  - mardifoufs 4y ago
    I'm completely uninformed about lua, but why isn't it being used more to build games then? I know it's a popular scripting language for games, but are there any engines that mainly use lua (in the same way Unity uses C#)?

It’s surprising to me that javascript wasn’t chosen as the scripting language for all these gaming engines. Though I do see the benefit of C# being typed and compiled.

chii 4y ago

i'm glad javascript isn't the scripting language chosen, as C# is very much superior, and would run faster!

krapp 4y ago

Everyone who uses javascript has to write it in a superset language that has sane types, a (poorly implemented) standard library, and other features javascript lacks, and treat it like a batch of volatile chemicals because outside of its specific niche of scripting the DOM, javascript is a terrible, unstable language at best adequate for purpose, a necessary evil because the web doesn't support anything else (barring WASM.) Gamedev isn't (necessarily) tied to the browser, so why not use a better language to start with? That said, there are forks of Godot that support JS/TS but I don't know how up to date or ready they are.

beezlewax 4y ago
Is there a use case for WASM here and rust for example to run games in the browser? There are game engines written in rust Bevy for example
eropple 4y ago
> so why not use a better language to start with? Perhaps consider that for many programmers, TypeScript is JavaScript, and TypeScript is that better language. I've put a decent amount of thought into using TypeScript for games because it allows for a flexible, expressive data model in a way that few other languages do. The performance might be a problem for some flavors of games, but I'm interested in discrete simulations almost exclusively, where it doesn't matter at all. But TypeScript allows effectively encoding intent into data structures and into code in a really ergonomic and pleasant way, while also running on virtually every gaming platform on the planet. (Rust, etc. are fine. If that's your bag, that's great. I'll write Rust if I need to, but I don't enjoy it, and don't seek out opportunities to write it.)
- krapp 4y ago
  Typescript as its own thing, with real types, not compiling to JS or being limited to its semantics, I could get behind as a language for game scripting.
- imtringued 4y ago
  In don't know what you mean by discrete simulations but I would expect simulation games to be more performance intensive because of unbounded complexity vs say an FPS game.
  - eropple 4y ago
    "Discrete simulations" are things like turn-based strategy games, roguelikes, and so on. You can think of it as "automated board games" in a lot of ways. https://en.wikipedia.org/wiki/Discrete-event_simulation https://en.wikipedia.org/wiki/Discrete-event_simulation In truth, I think V8 is almost certainly more than fast enough for real-time games (real-time in the gaming sense, not in the OS sense); Mono is fast enough for Unity, even, and Mono is creaky and slow, with a really poor garbage collector, on its best day. But for the stuff I'm interested in, I just don't care at all.

spyremeown 4y ago

I, for one, am very glad Javascript wasn't chosen as a scripting language.

JoeyJoJoJr 4y ago

All I really want is a decently performant 2D immediate mode rendering library with a decent console supported JavaScript/Typescript runtime. I’d love to see something like this pop up in the Deno ecosystem.

sovietmudkipz 4y ago

Unity used to have a JS interface, where one could either write their game object components in JS or C#. They deprecated the JS interface. I imagine it was too much work to support two languages? As a dev reading docs, I used to have to deconflict the parts of the docs talking about JS from C# (not difficult as an experienced dev -- I wonder how the first timers fared). I'd also have to translate advice from JS Unity programmers into C# when researching how to do certain game things. I'm sure JS Unity devs had to do the same with C# advice. I'm happy they aligned on one language. If JS had an optional type system baked into the language, I think it would be a better choice. However; it doesn't.

wccrawford 4y ago
I think it was more that Unity's "JS" was actually their own language that was just very similar to real Javascript. They were forced to support the language itself as well as the integration. It was a lot easier to just support C#, which is maintained by others.
- llanowarelves 4y ago
  Hmm. Cocos Creator manages JavaScript/TypeScript ontop of their bespoke (ios:Obj-C++, Android: Java) + C++ native stack and they don't have that many engineering resources. Granted, they did have multiple breaking non-backwards compatible re-architecturings of their engine(s), along the way.
  - kevingadd 4y ago
    Cocos is likely using actual JavaScript. When I used Unity's JS dialect (a very long time ago, to be fair) it was very much not traditional JS and was its own beast, so Unity likely was having to do a lot of work on it.
debugnik 4y ago
UnityScript wasn't actually JavaScript, but a custom .NET language with a JS-like syntax, largely incompatible of course. Naturally people wanted to use C# instead.

fuzzy2 4y ago

Not really surprising. JavaScript-the-language is missing lots of features that could be useful, like operator overloading. Or any overloading, really. Nothing is stopping you from compiling JavaScript though, browsers do it. The lack of static types makes this harder, of course.

beezlewax 4y ago
Suppose you could use typescript and compile that?
- fuzzy2 4y ago
  Yes and no. Yes that's possible but no, this is no longer (full) TypeScript. Check AssemblyScript on that topic, it's TS to WASM. Most of the dynamic code stuff isn’t allowed and, of course, there’s a different standard library underneath.
deleted 4y ago
[deleted]

moonchrome 4y ago

JavaScript doesn't have value types or operator overloading (also applies to Java) - this makes writing vector math pretty shitty imo - and you're working with vectors all over the place in games.

Kiro 4y ago
How does it help with vector math?
- rmeby 4y ago
  I would imagine operator overloading helps with vectors so you can do things like: public static Vector operator -(Vector a, Vector b) { Vector v = new Vector(); v.X = a.X - b.X; v.Y = a.Y - b.Y; return v; } So then you can just write: Vector result = myVector1 - myVector2;
  - kevingadd 4y ago
    Also if you wrote the JS equivalent of that, each vector would be 3-4 individually heap-allocated doubles in v8, because they aren't able to allocate floating-point values inline. There would also be a new heap allocation for the result vector itself when performing each operation. The overhead really adds up. :/ At one point Mozilla had a prototype implementation of strongly-typed value types in JavaScript, but it fell by the wayside once WebAssembly became a thing.
    - ygra 4y ago
      You can use an array to keep the doubles together. V8 has something like half a dozen different array types, depending on what is inside and how it's used.
  - throwaway23532 4y ago
    Why not implement a method? var result = myvector1.sub(myvector2)
- 4y ago

LelouBil 4y ago

C# has : - easy interop with native programs/libraries - modern language features (pattern matching, async, and many more) - Strongly typed

orthoxerox 4y ago

It's mostly a historical accident, like Python ending up as the data science language. Microsoft XNA used to be a popular indie game framework that used C#. Stardew Valley, Celeste and Terraria run on XNA. Mono used C#. Xamarin used Mono to create a cross-platform application framework that worked on mobile. Unity leveraged Xamarin to create a cross-platform game engine that worked on mobile, ending up using C#. Thus, two generations of indie gamedevs ended up learning C# to create games. Then Unity grew a whole lot, so more and more people ended up associating C# with game engines, so as soon as Godot was released people started asking for C# support. But C# being the language of choice doesn't really depend on specific C# features. It could've just as easily been Lua or JavaScript instead. For example, RPG Maker moved from Ruby to JavaScript when they upgraded to a new engine, again, because their new rendering engine was nw.js, and getting it to run almost anywhere was easy.

kevingadd 4y ago
I'd argue that the availability of value types in C# gives it a leg up over languages like JavaScript for performance-sensitive games work. These days v8 and spidermonkey have incredible garbage collectors capable of incremental/parallel collection so people have been able to ship JS-based games on PC+Console, but when it comes to game scripting it's either languages with value types like C#/C++ or languages with more predictable garbage collection behavior and performance like Lua and Ruby (Ruby especially is popular with Japanese developers, likely because the language originated over there.) C# being possible to mostly AOT compile (some exceptions) is also an advantage over JS for scripting since JS is not particularly efficient to run in an interpreter and many deployment targets don't allow you to JIT code at runtime. Languages like Lua have much better characteristics for those targets since they have high performance interpreters and cleaner language semantics.
- mardifoufs 4y ago
  I'm completely uninformed about lua, but why isn't it being used more to build games then? I know it's a popular scripting language for games, but are there any engines that mainly use lua (in the same way Unity uses C#)?