An Unreal Decision
martiancraft.comI'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.
> 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.
I really don't get why this is like this still.
Currently they seem more willing to implement their own IL2C++ generator, than agreeing with Xamarin about a new license.
Personally, specially given that C++11/14 is quite an improvment over C++98, I would go Unreal instead.
Or maybe these are all difficult things to solve and you're just now seeing large projects to address them finally reach completion?
Sorry, but your "resting on its laurels" is clearly not true. If you had bothered to track the improvements made to Unity's rendering engine (or the addition of Unity 2D support) over the last two years (well before the Unreal engine subscription launch), you'd see they actually have been doing quite a bit.
I do agree that the situation around Mono is pretty unfortunate, and that is clearly a business decision they've made. But they're also trying to find a way to mitigate that as should be clear from announcements made over the last year.
As I understand it, the projects aren't nearing completion. The features are coming in Unity 5.x, which means over the next few years (since 5.0 isn't even out yet).
If the timing were purely coincidental, and the effort routine, you'd expect to see a big problem being solved every now and then. Instead we've gone from radio silence to a barrage of activity.
You also seem to be making the mistake of assuming that the Unreal engine subscription public announcement was the first Unity Technologies realized the threat. It's a small industry, and the default assumption should be that people talk to one another and know which way the wind is blowing.
Unity2D is actually one of the things I had in mind when I wrote the post. It seemed to me to be aimed at increasing the potential market size for Unity, rather than something that made life better for existing developers.
My post was not to claim that Unity was doing nothing; only that they were not acting like they had a fierce competitor. I believe that now they are. And that is a fantastic thing. It makes me much more comfortable being on the Unity platform, because my ideal preference is to stay on something like this for a decade. I want Unity to succeed.
Not true, instead of focusing in people that are a bit serious about game development they have done plenty of bad chooses, 64 bit processors on home PCs exist since more than a decade ago, and their engine was created in 2006 for 32 bit platforms, when it was clear 64 bits processors were here to stay. Also the GUI system is one of the worst GUI systems I have ever seen, yeah yeah they say they are going to fix it in Unity 5 but we need to develop games now, not tomorrow. Also calling JavaScript to their "implementation" of what comes down as just a mask for C# was a huge marketing mistake.
Disclaimer: I work for Unity. -As for 64 bit support, the biggest problem for that with Unity is all the dependencies to third party technologies we integrate. We've managed to get all those resolved for the Runtime part (Mac/Windows/Linux standalone players) a while ago (we've been adding 64 bit versions of those during the 3.x and 4.x release cycles), which meant getting Mono, PhysX, FMOD, Substance, etc all working on 64 bit. For the editor, however, there are a lot more third party libraries involved (such as a web browser engine for the asset store), not all of which had 64 bit versions to start with. So there were a lot of dependencies to resolve, which is why this took time. Good news is, we have all this working in 5.0, which will be out later this year.
-For the new GUI, we are not going to fix this only in Unity 5, but already in Unity 4.6, which should be out really soon.
-About the "JavaScript" misnomer, I agree that that was a bad decision in retrospect, though it is not trivial to change at this point.
What is the deal with software being hard to release as 64-bit?
I'll fully admit that I don't work in C/C++ on the desktop, at all. This just seems like a button toggle problem (I know it was that way for C#/.NET apps, again, grossly simplify and apples to oranges) though, and it's surprising that you aren't just able to ping someone at these companies and ask for a 64-bit build.
> This just seems like a button toggle problem
Sometimes it is, sometimes it isn't. The problem is knowing when it is or isn't. That needs building with all warnings enabled and vetting through them manually, a run with a static analysis tool searching for possible 64 bit bugs, or at worst, running extensive test suites to try to detect errors at runtime.
Some (older) software might also have some internal structures that are designed on the assumption that pointer size equals 32 bits.
This issue is made worse by the loose conventions in implicit integer type casts in C and C++. Warnings do help here, but there's going to be a huge amount of spurious warnings too.
So, at best, all you need to do is change compiler flags. At worst, you'll need a lot of manual labor in making sure that your applications build cleanly for 64 bit machines.
To the point that Microsoft even introduced 32to64 porting tools in the Windows SDK, because not everyone made proper use of platform agnostic types and helper macros to start with.
> What is the deal with software being hard to release as 64-bit?
(disclaimer: I work at Unity)
It is a button toggle problem, if the code does not do nasty things (like casting between a pointer and a 4-byte-integer -> all works until pointers are not 4 bytes). Or if a code depends on, for example, inline assembly (VisualC++ remove that in 64 bit). Or if the code generates code at runtime, for example JavaScript engines - for 64 bit they need to generate different code.
In Unity's case, the biggest holdup, of all things, was WebKit (used for asset store window & some other things). Turns out, there's no 64 bit webkit for Windows (or there wasn't a while ago). We had to replace Webkit with Gecko, which was quite involved task.
On OS X switching from 32 to 64 bit also means no longer being able to use many Carbon APIs.
I would imagine that cross platform software is more likely to use the Carbon APIs because they are procedural and often a bit more low-level than the “modern” Cocoa equivalents.
From what I've seen, I think Unity draws the UI non-natively, using it's own UI system, but I could be wrong. I'm basing this simply on the fact that it looks exactly the same on OSX/Windows.
I actually like their UI quite a lot (as a programmer), and love the fact that the Editor can be extended while it's working.
Correct - we draw all the UI ourselves. Yet, we did indeed have a lot of dependencies on Carbon APIs for all sorts of different things like handling rendering into windows or fullscreen contexts, getting images from WebCams, input, etc. We had to rewrite quite a bit of that code to move to 64-bit. A problem with that is that often the replacement APIs have only been introduced in more recent OS X versions (which have always been trying to keep long backward compatibility with old systems), which means that in several places we had a choice of maintaining two separate code paths or dropping functionality in 32-bit. Or releasing 64-bit versions later when we could safely drop backwards compatibility with old OS X versions. This was not the biggest reason for us to take long to support 64-bit, but it was one.
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 with UE.
We are only a two-person team, making a fairly limited-scope 3D puzzle racer game. Thus we didn't hit the major issues with collaboration bugs (we did a few times) or platform switching (we're focusing only on PC). We were able to build our MVP in less than 2 weeks of hacking, and it felt amazing. The asset store was also an amazing resource to circumvent the artist issues.
However, it's been nearly a year since then, and polishing the game to the standards we'd like has been presenting larger and larger challenges -- performance, obscure shader behaviour, limited editor extensibility (it's good, but not quite good enough), and reading this post, it looks like at this stage of development Unreal would have served us much much better.
If we can get our studio rolling and increase our team size to actually incorporate dedicated artists, we'll have to seriously consider switching to UE4 for our next game.
Jeff's write-up sheds insight that few people can have, given not everyone has spent the time to get well-enough acquainted with both engines in the team setting to know their professional tradeoffs as well, and I appreciate it a lot.
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.
Absolutely false, using imported materials and creating your own is extremely easy to do in Unreal, and there are tons online of stores where you can buy 3D models, Unreal integrates pretty well with all kinds of 3D models (including riggs) specially those from Autodesk Maya. And over top of that there is an Asset Store for Unreal, is called the Marketplace and the EPIC team is filling it itself with tons of free high quality materials and models.
Agreed, the amount of sites and places on thr internet devs/designers can find sounds, textures, 3D assets, images, vector, and etc far surpasd the value provided by the Asset Store. And the open source code and paid third-party lib ecosysyem outside of Unity's purview is much more rich.
Yes but the point in OP and GP is that the amount of content available in the Unity store is greater than other stores. Sure Unreal has the same goodness but there just isn't as much stuff readily available in the Store you can just pick up and use.
So it's a content issue, not a technical issue with the engine itself.
@christoph:
As the article's author pointed out, you don't need many of those addons in UE4 because the functionality is ALREADY built into the engine.
Want realistic car physics? Already built in! Want great shaders? Already built in! Want rigged faces or a cityscape background? As regular assets, buy them anywhere on the internet (including the Unity asset store), and then put them into UE4!
And this is why one of Unity's strengths is also one of its weaknesses. The reliance on so many third party libraries for basic functionality means that A) integration with the engine isn't always perfect, B) updates and fixes are dependent on the third party author, and C) the UT community is nickeled and dimed for many things which should be included already.
Then people publish whiny posts on how tough the mobile game market is and how nobody notices their game (which is a bunch of scripts tying together pre-made components and assets).
As someone who tried to develop a Unity game on a big team, it was hell. The collaboration is horrible, there are conflicts all the time for no reason. Simply getting the source, running the game and updating would produce conflicts. We also had to buy the cache licenses to make it somewhat workable.
But the worst was the support. It was worthless. Anytime we would open a ticket, they would simply google and return us links to forum threads that didn't address our issue. When we asked about missing important features or bug fixes, they told us to buy something on the asset store.
I'm sure you know this, but for anyone who is new to Unity, one thing that helps a tiny bit is to open the Edit/Project Settings/Editor panel and change the Asset Serialization Mode to Force Text. Then your .unity scene files and such will be text files instead of binary. Whenever I start a new Unity project I flip this setting right away and save the empty project with text assets as the first commit.
This won't solve the problem at all - the asset files are still fairly inscrutable and the slightest change in the editor can result in all kinds of seemingly unrelated changes - but at least you'll have text diffs instead of huge binary files in the repo.
Wow, that's horrible. So what do you recommend?
For a big team, either use Unreal or the in house engine.
I heard good things about Havok's game engine too, and their support is the best I've ever seen.
I'm not sure what you would classify as being a big team but you can definitely pay for dedicated support (and source code) should your organisation want to. Of course that comes at a cost significantly more than a couple of pro licenses.
Don't worry we had the whole package. They just simply didn't care.
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.
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.
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?
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.
A quick Googling would have shown two REPLs for Go, though they're old and haven't been updated in a long time. I'm guessing the Go playground and "go run file.go" compiling and running so quickly, make it not a real concern.
I don't know why Go doesn't have a REPL, I'm not familiar with the language. My point is that having static typing does not preclude a nice REPL.
Because Go sucks? What point are you trying to get at here?
My point? Before I get to my point, how about a rant: It mystifies me how nobody sees the obvious advantages of in-browser games, both for development and deployment. It should be obvious to anyone in the field, because the current method of developing and deploying games completely sucks. Do you honestly think that in 100 years, people are going to be deploying games through Steam, or worrying about cross-platform OS support? If so, you may want to rethink that. If not, then why wait 100 years? There's no reason to put up with the current limitations.
Except, oh wait, the only reason we do have to put up with the current limitations is because we're beholden to the browser manufacturers to implement support into their browsers for features that gamedevs will use. Like, say, having a >5MB area to store art assets. I'm pretty sure that's the only real reason we're not seeing in-browser games. Not because JS sucks. Not because WebGL sucks. But because even if you actually do make a game using a browser as the platform, there's nowhere to store the damn thing!
So, back to that "point" you were asking about. What was my point with my oh-so-pointed "Why does Haskell have a REPL but Go doesn't" question? Well, it was a question. The thing you ask when you want to learn something. In this case, I had no idea why Go (a statically typed language) doesn't have a REPL, when Haskell (a statically typed language) apparently does. In fact, I had no idea Haskell had a REPL at all! I had no idea that it was even possible for a statically typed language to have a REPL. Those ideas seem as separate as oil and vinegar. So it's pretty damn cool to hear that it is in fact possible and practical to have a REPL for statically typed languages, and now there's a mystery: Since REPLs are such a productivity boon, why don't all statically typed languages have them? I'm not at all afraid to admit ignorance; I wear it on my sleeve. It's the only way to learn. But I guess we're so far gone, here, that people misunderstand a simple question meant to learn something as some kind of snide, rhetorical, or coy remark.
So, yes, sure. Go sucks. JS sucks. WebGL sucks. Steam is amazing. The only real way to develop a game is with C++, deployed as a native OS binary, or with someone else's engine, also deployed as a native OS binary. Keep the status quo. Pretty boring, isn't it?
Ok, my apologies. I genuinely thought you were trying to make some kind of point. Haskell has a REPL, Scala has a REPL, OCaml has a REPL, F# has a REPL; it's not at all unusual for a statically typed language to have a REPL.
(If I had to guess why Java doesn't have one I'd assume its emphasis on OO and everything-is-a-class; expressions in a REPL are almost inherently not contained in a class. For C/C++ I'd guess the emphasis on manual memory management and programmer-visible memory layout don't play nicely with a REPL. And for go I'd guess because it doesn't like including features that weren't in Algol '58. I don't think that's the real reason, but I am literally incapable of understanding what people like about go. Those are just guesses though)
> It should be obvious to anyone in the field, because the current method of developing and deploying games completely sucks. Do you honestly think that in 100 years, people are going to be deploying games through Steam, or worrying about cross-platform OS support? If so, you may want to rethink that. If not, then why wait 100 years? You can invent the future today. There's no reason to put up with the current limitations.
To me the browser just seems like an extra layer of junk, particularly when you're talking about things like WebGL where the API talks more-or-less directly to the graphics card. So I certainly hope the future looks more like steam - a library interface where I can run any program I want, automatically updated, with my saved data automatically kept in sync. Once you have a system that looks like that, what's the advantage of the browser? Put another way, if we're writing a game runtime, why would we include a document layout engine, an extremely complex styling system, and all the other stuff a browser comes with? I certainly hope the future looks more like Steam than like the browser.
I agree that developers shouldn't have to worry about cross-platform. I think it's a damning indictment of our industry that the best way to get a cross-platform runtime environment for your program is to bodge it into a scripting language that was written in three days to bolt on to a remote document viewer. I'm hoping that things like MonoTouch mean we're getting closer to a cross-platform runtime that provides a better platform for general-purpose applications and games.
"Boring" is what platforms should be; stable, reliable, almost invisible unless you're looking at them. I agree that there are better things than C++, and I do what I can to contribute to them. But I really hope the browser isn't the best we can do.
If a browser is an extra layer of junk, then surely a bunch of the features that come with an OS are unnecessary junk too. Printer drivers, for example. But of course, printer drivers don't impede the ability to make games in any way. The fact that platforms have features which are useful for other purposes is unrelated to whether a platform can be useful for a specific purpose, like making games.
There's nothing that Steam can do which can't also be done in a browser. Except, of course, store more than 5 MB of assets.
Why not use Steam? Because Gabe is going to die someday, and there's no reason to think that his successor will inherit his good judgement. Locking yourself into a monoculture isn't a good idea when your whole business can be smashed by one poor decision by the company pushing that monoculture. It's the same reason you don't see any companies built solely on Facebook or Twitter. (Apple is a notable exception, but companies can still live or die based on whether Apple feels like admitting you into their appstore.) Yes, Steam is pretty awesome right now, but arguing against exploring other alternatives is arguing against progress of any kind.
Your objections seem to boil down to "a browser isn't meant for games." Well, nothing short of a gaming console is truly meant for games. But a browser can be used for games, if only the manufacturers would provide a single necessary tool: a place to put them. That is the sum total of my argument, and it mystifies me why so many people are not only against this idea, but somehow offended that a browser might be repurposed for anything other than viewing lines of text.
> If a browser is an extra layer of junk, then surely a bunch of the features that come with an OS are unnecessary junk too. Printer drivers, for example. But of course, printer drivers don't impede the ability to make games in any way. The fact that platforms have features which are useful for other purposes is unrelated to whether a platform can be useful for a specific purpose, like making games.
But if you don't want to use them, printer drivers don't get in the way. Even if I'm laying out my screen by hand, I still have to worry about what the browser layout engine will do if the user resizes the window. If I want to capture keyboard input, or even just make API calls, I have to jump through hoops to convince the browser I'm not a malicious remote document. And whatever I'm writing, I have to transpile it into javascript, which is a pain for debugging.
> Why not use Steam? Because Gabe is going to die someday, and there's no reason to think that his successor will inherit his good judgement. Locking yourself into a monoculture isn't a good idea when your whole business can be smashed by one poor decision by the company pushing that monoculture. It's the same reason you don't see any companies built solely on Facebook or Twitter. (Apple is a notable exception, but companies can still live or die based on whether Apple feels like admitting you into their appstore.) Yes, Steam is pretty awesome right now, but arguing against exploring other alternatives is arguing against progress of any kind.
Are you that much safer on the browser? You'll write games that work for one, maybe two rendering engines - one of them made by google, the other made by an organization that gets most of its funding from google. The web's standards might theoretically be open, but they're so enormous and complex; writing your own browser from scratch (to the standard that modern html games require) is beyond the resources of all but the biggest organizations.
I'd certainly favour an open standard for a steam-like games runtime. Which would be a lot simpler than the browser standards, which would make competing implementations much more practical.
> Your objections seem to boil down to "a browser isn't meant for games." Well, nothing short of a gaming console is truly meant for games. But a browser can be used for games, if only the manufacturers would provide a single necessary tool: a place to put them. That is the sum total of my argument, and it mystifies me why so many people are not only against this idea, but somehow offended that a browser might be repurposed for anything other than viewing lines of text.
I am offended, because I have a sense of engineering aesthetics, and bodging everything into the browser is ugly. And from a practical point of view, I fear a future where the only programming jobs require javascript, because having to write javascript makes me very sad.
> Why not use Steam? Because Gabe is going to die someday, and there's no reason to think that his successor will inherit his good judgement. Locking yourself into a monoculture isn't a good idea when your whole business can be smashed by one poor decision by the company pushing that monoculture.
I fully agree with your opinion on this. I also can envision a future where AAA games can run fine on the browser, which would act like a universal platform. Not sure if this will ever come to pass, but it is technically feasible. I just don't like javascript :)
There are REPL like implementations for Java, like Eclipse's scratchpad.
For C and C++ you can use CINT, for example.
Two nice REPL experiences for strong type languages similar to Interlisp-D and Smalltalk, were the Mesa/Cedar environment and Oberon, which was inspired by Wirth's experience with Cedar.
> Do you honestly think that in 100 years, people are going to be deploying games through Steam, or worrying about cross-platform OS support? If so, you may want to rethink that. If not, then why wait 100 years?
In 100 years most of my plans revolve around being dead. The best tools for delivering AAA-quality games right NOW are native binaries on Windows and dedicated gaming consoles.
And yes, JavaScript and WebGL "suck" for AAA gaming development. JavaScript is a dynamically-typed, garbage collected language that can't deliver the performance of well-written C/C++ code, and WebGL is a subset of OpenGL, which by definition makes it less powerful than the full OpenGL that's available. And on Windows, the biggest platform for AAA games that also runs a full web browser, WebGL is just a wrapper that sits on top of DirectX, which means an additional performance hit.
I support your overall idea that there must be some kind of universal platform such as the browser. And that Steam and similar services -- as much as I love them now -- are not the long term answer.
But javascript? Is there any reason why we can't have a better language on the browser? Languages and tools do matter, after all.
> Why does Haskell have a REPL but not Go?
Because no one's bothered to create a REPL for 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.
The only game demo I can currently find for UE4 in the browser is Flappy Chicken (I know they had some up earlier, but they seem to be taken down). Not really a compelling AAA demo. And their 3D games still only run about half as fast as a native C++ engine. That's very impressive, but you won't be putting out AAA games with a 50% performance hit.
And even then, unreal engine in the browser doesn't run Javascript written by developers. It compiles the C++ code into asm.js. Huge difference. Unless you can code asm.js by hand, you won't be able to do that. Here's a sample of the Flappy Chicken UE4Game-HTML5-Shipping.js file, because the code is just too long and ugly to paste.[0] Definitely not 'JS for gamedev.'
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.
I've been bitten before by some of the problems regarding Unity and collaboration with source control. Everyone wants to test out their changes on the same scene, but it just blows up when you go to merge... even if you use a dumb merge strategy like ours or theirs (as a Git user) it seems to break things. Unity seems really cool, but I'm never going to use it again for any project with more than one programmer.
We build BitGym (www.bitgym.com) using Unity, and it has a lot of moving parts and 2-3 developers working on scene, code and assets, and we've made it work with git. It really comes down to developing and maintaining some best practices:
- Always use prefabs wherever possible. But avoid nesting prefabs
- Always save your prefabs, then save the scene before pushing. Thus the .prefab files are also updated through git: these are more robust and have higher priority than the scene.
- Make sure source control uses meta files (unless you're using Unity's Asset Server) so that scene references are stored again in separate files updated through git.
- Make sure individual developers have a lock on individual prefabs. Unlike scripts, Unity will bomb changes from one side of the merge on binary files, but this is expected when using git on binary files. Of course you can treat the scripts as any other code project, and they merge fine.
It's still not ideal, and we occasionally wind up with merge issues or a day of having to carefully iron out scene conflicts when doing larger branch merges, but they haven't been so dreadful as to make us decide never to use it again because of the collaboration issues.
That's very helpful, thanks! One question...
> Make sure individual developers have a lock on individual prefabs.
Can you elaborate on that? Git doesn't have file/directory locking unless you use something like gitolite, so what kind of locking do you mean?
I found UnityLock in the asset store, which is supposed to let you lock assets against editing, but it doesn't seem to work in 4.5:
https://www.assetstore.unity3d.com/en/#!/content/4851
The code seems straightforward enough, so I may see about getting it working if the author doesn't do it.
Yes to this! You can also use the additive scene loading to build pieces of your product independently of each other and pull them all together at runtime.
Their entire attitude of accessible, changeable source, accepting patches and responsiveness is really refreshing. If you do windows or apple dev, the frustrations of having none of that available is a big productivity drain. The high amount of responsiveness part is even nicer, since that seems rarer in platforms such as unity or android.
These are my gripes with Unity, in question format :) Would love to hear from anyone that has concrete answers for these:
- How does UDK build apps for iOS natively on Windows without requiring a Mac? Are they doing some kind of insider thing that Unity can't replicate?
- I see Unity as massively extensible and that's one thing I like about it. Comparisons are often made between vanilla Unity and UDK; what about Unity + PlayMaker + UFrame + Level Builder, etc. I don't see this ease of editor extensibility with UE4 (I'm sure it's there; but the Unity Asset Store just lets me cherry-pick one, click buy and then just have it to use immediately after download - I like that).
- My biggest gripe with the editor is the font size. Will the new UI that's coming in 4.6 and/or 5.0 allow me to increase the font size used by the Unity editor to actually make it comfortably usable rather than fatiguing?
FWIW I've preordered Unity 5 and I use UE4 at the moment as well. Nothing big completed in either engine (just some side work here and there) but no fanboy-ism for any particular one (though a bit of a fondness for Unity as I encountered it back in the old Mac days when Unity were called Over The Edge Entertainment; GooBall was pretty cool by the way).
I don't know how UDK does iOS but I'd like to mention that was also a big draw to adobe air for me - you can develop/compile/deploy to ios from windows (don't know how it does it either but apparently it's possible).
Unreal iOS Building: They are probably building the .ipa on their server and then sending it back to you
I may eventually do the same for a project I'm working on, although for me the draw would be UE's battle-tested network prediction code.
For visual programming in Unity, there's PlayMaker -- an add-on available from the asset store. It allows creation and graphical editing (and graphical runtime debugging) of FSMs (though not hierarchical FSMs). It's quite a good implementation of a FSM / event / action framework. It's basically superior to some tech I spent half of 2013 developing for an in-house proprietary engine.
I agree on the collaboration problems. Even with purely text-based serialization, collaboration is one of Unity's weak points.
I'm writing my own engine. That's a terrible idea, I'd be much better off with either unity or unreal. But since game dev is more of a hobby for me, and writing the engine is the fun part, I'm ok with that.
However, for smallish projects (smaller than Republic Sniper, I mean) sometimes it's the right choice. I see a lot of indies struggling with lugging around and maintaining a huge engine (unity, especially, but even cocos2d), and running up against the limitations like difficulty integrating with native sdk features, and their game's requirements are modest enough that they could probably code it from scratch in not too much time.
Also hacking together a development environment through different open source projects and own code is not a bad idea. It's harder in the beginning but also gives you more control and more skill in the long run.
Side question. Where do single indie developers get the artwork for games?
By hiring a graphics person or by creating it yourself.
There are some free assets out there but they're mostly low-quality and the few production-quality ones are used in numerous low-quality games.
Why aren't more production quality ones free or available for sale? It seems like it might encourage more foss games?
Besides the reasons mentioned, another point I've heard from talented artist friends is that specific art assets have a tiny market -- Most games require the art to be customized a non-trivial amount to suit their game's atmosphere, theme, color schemes, etc -- Even generic things like zombies, fighter jets, rocket launchers, medkits, etc. So stock art assets tend to only be used in prototyping phases, and after that an artist is contracted to finalize the asset.
Since this is the usage of their products (early prototypes), artists can't charge the premium they deserve for the quality of the product.
The only way they can is they create super-specific but very cliche/popular artwork, like planet earth, Eiffel Tower, Statue of Liberty, iPhone, Desert Eagle, etc, which can actually be sold for a premium because they can be used as-is in polished final games. And then, only the best one or two of each item rise to the top of the marketplace and obviously noone needs the rest.
The Unity Asset store is a good place to look to get an idea for the economics of free/for-sale art assets. There are very few models/art assets that can be used in production, and the most usable/popular items are either tools, customizable assets like shaders, particle effects and materials, prototyping asset packs, or the specific items like I mentioned. And none of them can sell for very much.
From Unity devs I've heard the tools category makes the most money.
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.
Thanks for the detailed writeup of your experiences. What would you say would be different for a hobbyiest just learning 3D game development? Would free assets be more viable if you don't need a professional, polished look? Could you still get a playable game?
Ehhh, it's tough. What happens when you need a vertex moved or a poly count reduced? Visual assets really impact game performance in a way that requires bespoke work on almost everything. It doesnt help that the number of free game-ready assets out there is basically 0
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, and a straightforward submission process for getting assets from contributors to programmers for integration might be the missing piece of the puzzle.
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.
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.
I use Turbosquid for free 3D models, and then customize them in Lightwave or Blender. I work on my own textures.
For audio I rely on Looperman for free music and sound fx.
Wow. Thanks to the link. Would this be a good way to go for beginner (hobbiest) oculus rift development?
Are there any tutorials out there that explain your process a bit?
I use Cocos3D for iOS and Android 3D apps and games. It's also free. :)
Best bet is to load up the project "Cocos3D Mashup". Then you can adjust things, try loading new models and taking programmatic control of the scene.
I remember being at a private game programming school, there was a school project to make a game with unity 2 or 3. An entire class was using it.
Things were synced using subversion.
I never really jumped in that. I did not continue at that school.
I really think a video game is something that should be made with your custom tools. A good smith makes his own tools. Of course if you want to save time, you can use an expensive, well-made tool, but it will be at the expense of something else.
I'll always remember at that school, quickly arguing with a guy, that in C++ a vector is just a linked list.
Game programming is often highly technical, and often much more complex than what you're expecting it to be. That's why you should not neglect your tools and highly concentrate on making choices that fit your work.
> A good smith makes his own tools
The problem is, this can be taken to infinitely far ends.
Editor annoys you? Modify it to your desires. Don't like the compiler? Write your own. Get sick of the programming language? Invent your own. Get annoyed with how the OS does something? Change it or invent your own. Bump up into x86's limitations? Start on custom FPGAs.
Ten years later, you might still have 0% completion on your videogame, and indetermine completion on your ever-fractaling toolchain. (And this isn't just a thought exercise; I remember a HN submission earlier this year that was nigh-identical to what I describe)
I would rephrase what you said as "A good smith knows his tools and their limitations, and knows when it's appropriate to make his own tools". Even when talking in analogy... a smith's apprentice would not presume to make his own tools before experiencing his master's, and even further I suspect most smiths did NOT make their own anvils, or mine their own steel... ;)
There's also a healthy serving of "Worse is better" in this line of argument.
Yes it's true, but I would not take the smith tools argument that far.
You could say there's a spectrum of low level/high level tools you will either work with or build yourself.
Most low level tools are now quite good enough. The more you go high level, the more will deal with specific cases that will restrain your ability to do thing the way you intended. Like the article said, Unity will fit for very small teams and very simple games, but it will be hard to do anything really complex.
I think compilers, languages and engines are better suited for more use cases than an editor like unity is. It's a dilemma of flexibility versus speed and ease of development.
ease of development/flexibility:
ease<|--#-------------------------|>flexibility
ease<|-----#----------------------|>flexibility
ease<|----------#-----------------|>flexibility
ease<|--------------#-------------|>flexibility
ease<|------------------#---------|>flexibility
ease<|----------------------#-----|>flexibility
ease<|-------------------------#--|>flexibility
I have been Producing a very large game project with Unity. We have a large team, at times 50+. Our graphics aren't as state of the art as they could be but the performance of the Unity engine does not seem bad. The cross platform compatibillity is very strong. The third party tools are very strong. It's worked out well.
Unity seems like it was built with ease of of entry as a first consideration. As people do larger and more ambitious projects with it they are hitting some of the tradeoffs and limitations. I am sure UE4 is a good choice as well.
Haven't used the tools much, but I'm subscribed, and simply in awe of Unreal's internal UI system (used for the Tools), and hope EPIC release it in some more independent form.
Recently moved to UE4 too. Used to do Unity.
I moved because I was originally a C++ developer. Had code lying around I could use easily.
How was the move from C++ to C#? The last time I seriously touched C++ was 10+ years ago. I've been doing almost all C# (and a bit of Java) since. The only reason I feel like I'm sticking with Unity is because of how familiar I am with C#.
C# felt like it is tooled well for doing many things on game stacks. Would love to spend more time with it.
The problem is that Unity3d is being mis-marketed as a triple 'A' tool-set. It's not.
> The other big obstacle was that the UDK tools which were Windows only. MartianCraft is a shop of (mostly) dyed-in-the-wool Mac folk who’d rather not spend their days using Windows.
That really doesn't seem like a great way to run a railroad.