An Unreal Decision • Hacker News Board

Re: An Unreal Decision

#31

Post by sillysaurus3 » Fri, Aug 15, 2014, 2:09 AM UTC

shard972 wrote: post #27

sillysaurus3 wrote: post #18

Earlier quoted context omitted.

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, power…

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

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.

Re: An Unreal Decision

#32

Post by sillysaurus3 » Fri, Aug 15, 2014, 2:11 AM UTC

the_af wrote: post #30

sillysaurus3 wrote: post #18

Earlier quoted context omitted.

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, power…

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

Re: An Unreal Decision

#33

Post by christoph » Fri, Aug 15, 2014, 2:11 AM UTC

keerthiko wrote: post #29

My teammate and I started moonlighting on the first game for our studio about 8 months ago, right before Epic announced the current $19.95/seat pricing model. We decided to go with Unity purely because I already owned a Pro license, that we could use to make final beta builds and be responsible for the advanced visual effects that needed Pro. Additionally I already had lots of experience with Unity, and nearly none w…

You highlight one of Unity's real strengths here that is often forgotten - the asset store. Want to drop in a nice city scene? Thats 10 bucks. Want realistic car physics? That's 10 bucks. A few nice NPC's with rigged faces? Thats 20 bucks. A pack of nice shaders? 10 bucks.

I don't think Unity is targeting AAA developers at all. Its targeting small studios that want to get ideas built quickly. It's got great, simple Oculus integration as well. If you're planning on building something AAA (or close), you probably have modellers, artists and level designers and don't need the asset store. You probably need, or are already using Unreal.

Re: An Unreal Decision

#34

Post by dublinben » Fri, Aug 15, 2014, 2:14 AM UTC

err4nt wrote: post #28

dublinben wrote: post #25

Earlier quoted context omitted.

Programmers tend not to be artistic, and artists tend to not support ideals like free software/free culture.

I think that's selling content creators a little short - I think a lot of visual asset creators would love to contribute but are neither reached out to, nor sought after. It can be intimidating telling a graphics guy: just clone the git repo, put your assets in a fresh branch and we'll merge when were ready. You may as well be speaking Swahili to the poor volunteer! Making publically accessible list of needed assets,…

You're absolutely right that projects need to do a better job of welcoming non-technical volunteers. If some programmers have trouble contributing, it's even worse for everyone else.

Re: An Unreal Decision

#35

Post by [deleted] » Fri, Aug 15, 2014, 2:21 AM UTC

[deleted]

Re: An Unreal Decision

#36

Post by judk » Fri, Aug 15, 2014, 2:28 AM UTC

sillysaurus3 wrote: post #32

the_af wrote: post #30

Earlier quoted context omitted.

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

Haskell has an interpreter as well as a compiler. No one cares enough about making one for Go.

I used a C interpreter a decade ago.

Re: An Unreal Decision

#37

Post by LeftSideDrive » Fri, Aug 15, 2014, 2:48 AM UTC

dublinben wrote: post #25

mrfusion wrote: post #19

Earlier quoted context omitted.

Why aren't more production quality ones free or available for sale? It seems like it might encourage more foss games?

Programmers tend not to be artistic, and artists tend to not support ideals like free software/free culture.

I make 3d models for games. In fact, I make 3d models for the game in the OP at MartianCraft. There's a vibrant community of game and 3d artists supporting eachother, giving out free assets, free help, free advice, tutorials ETC. I take issue with your broad assertion that artists don't support free culture.

When it comes to assets, it's tough to put together a library of free, or even purchased ones, because the style, poly count, texture resolution, texture mood, art direction ETC just won't be consistent across assets. We even purchased a couple of low-priority models and found that it took more time to fix them and bring them up to MartianCraft standards than it would have taken for us to design, re-topologize and texture assets ourselves.

Furthermore, almost everything needs to be designed and and built for specific layouts and proportions. If that pillar is a little too tall or not tall enough, you can't just scale it up as it will stretch the textures and look terrible. Things you can see and judge with your eyes are more difficult to piece together from disparate/inconsistent parts than invisible code.

Re: An Unreal Decision

#38

Post by Keyframe » Fri, Aug 15, 2014, 2:52 AM UTC

dublinben wrote: post #25

mrfusion wrote: post #19

Earlier quoted context omitted.

Why aren't more production quality ones free or available for sale? It seems like it might encourage more foss games?

Programmers tend not to be artistic, and artists tend to not support ideals like free software/free culture.

In our defense (TD background), there are people that blend both, notably TDs ( http://en.wikipedia.org/wiki/Technical_director#Film ), sceners and game developers (especially indie ones) seem to fall into that category as well.

Re: An Unreal Decision

#39

Post by reitzensteinm » Fri, Aug 15, 2014, 2:57 AM UTC

I'm a PC game developer that's been using Unity for 2.5 years, and it was pretty clear after getting involved in the ecosystem that Unity Technologies was just resting on its laurels, and making decisions primarily on marketing to sell even more copies. Just a few pain points:

1) Mono hasn't been updated for five years due to licensing issues on iOS. GC pauses with a complex game can be hundreds of milliseconds, being stop the world non generational.

2) A similar story of PhysX, though I can't pin down the exact date, 2010 at the latest

3) They added a new particle system with flashy features, but no scripting access. I don't even...

4) Unity 4 added next to nothing useful (DX11 naturally on Windows only, Mechanim which was broken etc), though it was necessary to purchase to keep getting bug fixes

5) No 64 bit editor is very painful (I have 32gb of ram laying around doing nothing)

6) The project is riddled with bugs, being added and removed each release, though probably much less than hacky in house solutions which are the norm in the game industry

7) Nasty serialization formats make programatically changing the hundreds of meta files in a project next to impossible

However, I'm getting the impression that the new Unreal licensing scheme has been a real kick in the ass for UT, and they're taking the competition seriously. Nearly every major problem I've had with Unity seems to be being worked on now, for Unity 5, after a long period of atrophy.

I fully expected Unity to die a slow death, and that it was just a question of when to switch to something else (there is not much high quality competition), but now I'm not so sure. If they pull off their roadmap, it'll finally be an engine I will be happy to use and recommend. Right now my feeling is: it does the job, mostly.

Note that the experience making small puzzle games for iOS etc may be very different, I've done that kind of thing but not with Unity.

Re: An Unreal Decision

#40

Post by ivanca » Fri, Aug 15, 2014, 3:19 AM UTC

Tepix wrote: post #3

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

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"