Hacker News new | ask | show | jobs
by Tepix 4323 days ago
I recently started getting to know Unity3d and it was extremely easy and quick to learn. One annoying discovery was that their variant of JavaScript is not real JavaScript, it's "UnityScript". It took me quite some time to convert a simple script that I had written for node.js to UnityScript.

I need the pro version of Unity3d to generate iOS, Android or VR games for the Oculus Rift. For someone who is just doing a bit of indie development, that's too expensive.

So I checked out UE4 also. You can subscribe for a month for $19 and then continue using the version that was the current version during your one month of subscription. If you need updates later on, subscribe for another month.

UE4 is harder to learn but looks a lot better than Unity OOTB.

Anyway, I hope Unity will be competitive again regarding pricing with the imminent announcement of their 5.0 release.

6 comments

This is the worst mistake Unity made, inside unity it call those scripts "JavaScript" and it even uses the .js extension but is not a superset of JavaScript, is not a subset of JavaScript, is an abomination that just opens new questions and errors and calling it JavaScript doesn't help one little bit.

If you think I'm exaggerating just as a quick overview, there are no object literals (e.g. {value: true}), there is no array literals (e.g. [1]), you have to use new Array() which is deprecated in real JavaScript, they also implement some of the JS native functions but forget others making everything more confusing (for example parseInt exists but btoa doesn't), colons don't do anything they do in JavaScript, nothing, they are use to specify type, because UnityScript is a semi-typed language. Functions are not first class citizens and is not prototype based; at the end is just a mask for C# and that would be okay if it wasn't for them calling it "JavaScript" or even gasps "Unity-Flavored JavaScript"

> Anyway, I hope Unity will be competitive again regarding pricing with the imminent announcement of their 5.0 release.

The last couple of paragraphs from this Unity blog post from today seem to indicate that they are happy with the current pricing:

http://blogs.unity3d.com/2014/08/14/building-and-maintaining...

Why would you choose to develop for a game in JavaScript anyway? The language devs use for Unity tends to be C#. The design of the language fits the framework much more. I've been using C# with Unity and using JavaScript on webpages for years and JavaScript has always been much more cumbersome and error-prone to write nontrivial logic in. So many errors all the time that would've been found at compile-time in C#. Maybe Unity's JS is different; I haven't used it.
Unity's JS is different. It's all Mono under the hood. It's not at all like working with browser Javascript.
It's not JavaScript, it's UnityScript. Basically since everything that's not compiled to native code is run through Mono.

By default Unity provides support for UnityScript, C#, and Boo. However, since it's just IL all the way down, you can easily use IronPython, IronScheme, ClojureCLR, F#, etc., etc. just as easily.

Indie devs -- particularly one man shops -- should also take note that the hardware requirements to run UE4 are magnitudes higher than what is required to run Unity. I was basically ready to jump ship to UE before I realized this.
I just discovered this for myself this past week. I've been playing with Unity for a while now and just recently decided to give UE4 a try. I couldn't even do a serious evaluation of it on my PC with my current graphics card. I didn't have any problems with Unity at all but with UE4 I could barely open or run the sample projects. Even the blueprint editors were terribly laggy. I purchased a new graphics card and it runs beautifully now. I'm not sure how I feel about this. UE4 is definitely a lot "prettier".
What are the specs of your system?
It's over 4 years old - i5, 8GB ram, GTX 750 ti (GTS 250 before)
If you're interested in writing games in Javascript, you might like to take a look at PlayCanvas [playcanvas.com] which has Unity/UE4-like tools for building WebGL/Javascript games.
Has WebGL solved the local storage limitation yet? I've been waiting for a few years for that. There's still no way to "install" a game into a browser, as far as I know, and redownloading 1GB+ of assets every time the game loads isn't an option.
If, for whatever reason, you're hell-bent on producing a AAA-quality game with javascript and WebGL, you could always use something along the lines of node-webkit[0] and distribute it the usual way.

Personally, I rather significantly doubt that people would play more AAA games if they could download them in their browser rather than Steam.

[0] https://github.com/rogerwang/node-webkit

Why wouldn't you want to produce a AAA-quality game with javascript and WebGL? It should be the default, not some crazy thing.

The best argument against javascript + WebGL is "javascript is bad." But the disadvantages of JS are sometimes strengths. The lack of static typing, for example, allows a REPL. It's true that with an average gamedev team, you'll get below average results. But with an above-average team, powerful languages tend to translate into stellar results.

Oh well, I guess I'll wait a few more years for browser vendors to implement some kind of concept of a webapp installation.

> The lack of static typing, for example, allows a REPL

Uh? Languages with static typing can have REPLs. See: Scala, Haskell and more. I don't think that is what makes JS an option for game development, but rather its ubiquity in browsers. If you remove that, I don't see why you would choose it for serious development.

Why does Haskell have a REPL but not Go?
> Why wouldn't you want to produce a AAA-quality game with javascript and WebGL? It should be the default, not some crazy thing.

Performance. Show me some like gears of war running in a browser and then I will be convinced.

> The best argument against javascript + WebGL is "javascript is bad."

That is the worse attempt to portray the other side's argument I have seen a while.

> The lack of static typing, for example, allows a REPL.

You can also just have a console implemented, like most AAA games. They are also built into engines like Source.

> It's true that with an average gamedev team, you'll get below average results. But with an above-average team, powerful languages tend to translate into stellar results.

I don't understand how javascript would allow someone like John Carmack to make anything new, I write Javascript every day but when it comes to games I much prefer something like c#.

Look up Unreal engine in the browser. It runs quite nicely.

You're right that I did a poor job explaining why people are against JS for gamedev. Sorry about that.

This has been up for three hours, and it's telling that no one has replied to it with a rebuttal.
You could always package the game as a node-webkit app.
AppCache?
It sounds like AppCache limit is 5MB. I can't find very much info, though, but a reasonable limit for gamedev circa 2014 would be 16GB or so.

http://grinninggecko.com/2011/02/24/developing-cross-platfor...

http://stackoverflow.com/questions/6757945/cache-manifest-si...

There are the HTML5 local filesystem extensions, in addition to that. Just no idea how these are called.
> I need the pro version of Unity3d to generate iOS, Android or VR games for the Oculus Rift

Not true anymore. You can generate iOS and Android versions of your game with the free version of Unity3d (although with a reduced featureset in comparison to the pro version).

I think he was referring to the Oculus Rift part. Pro has one feature (is it deferred rendering?) which is requisite for OR development.