Unity 4 is here | Hacker News Reader

Unity 4 is here

unity3d.com

130 pointsdysoco69 comments

disclaimer: I spent the last three years making Unity.

You can share code between projects by having seperate visualstudio projects that create a managed library. just put the managed library into your assetsfolder. it live reloads as smoothly as when you edit just one script.

While I'll be the first to admit that we have some things that you can consider basic that don't work as well as they could yet, the perspective from inside the development team is that we have an enormous focus on improving what we have, and do not do "jump on new feature, and quickly move on and forget about it".

@reitzensteinm, We would love to fix your crash! If it happens in Unity4 as well, it would be great if you could file a bug, or give us some way to reproduce the problem. While we think using our serialization system makes a lot of sense for most games, we will always support people wanting to do things in their own way, and serializing your data with json should not be a problem. obviously, you crash and there is a problem, so we'd love to get our hands on that and fix it!

Bye, Lucas Meijer

Is there a similar solution for mono develop / OSX? Common libraries remain one of our largest pain points. We tried git repos but it broke down constantly. Currently are using a series of scripts that copy files or create symlinks when needed.

Lots of impressive headline features. DirectX 11, detailed animation system, Linux support.

The trouble is, these come at the expense of the basics. Not so impressive is that the only supported method for sharing code between projects is copy and paste.

The engine is six years old. I'm not kidding.

Unfortunately, frustrations like that are common. I adopted Unity expecting to be there for the next few years at least; however my experience has been lukewarm.

It's a shame, because it could be a fantastic engine if they'd concentrate on polishing what they've got. But I don't get the impression that's the roadmap.

http://forum.unity3d.com/threads/148393-Unity-4-removes-supp...

On the other hand, Unity has implemented some basics, which are a real time sink in other engines, outstandingly well.

Lets compare the coding workflow in Unreal Engine 3 and Unity 3:

In UE3 you play the game, find something you want to change. So you shutdown the Game/Editor and go to the code. You code in some immature language called UnrealScript (I think there is a complicated way to use C++ too). Then you compile. Then you startup the Game/Editor again (this is slow).

In Unity you find something you want to change. Alt-Tab to your Code Editor. Change C#/Javascript code. Alt-Tab back to the game, recompiling the code and loading it into the currently running game is automatic and takes about 1-2 seconds.

Also the engine APIs are one of the best software designs I've seen in a long time.

On the other, other hand, if you don't use their serialization system (I prefer to stick with json), automatic reloading of the code causes a hard crash as your objects have been incorrectly reloaded.

And, naturally, there's no way to turn it off. Strictly speaking there is but it requires restart of Unity, not just the game, to reload code. Which is basically the UE3 workflow you describe.

You're right though; there are quite a lot of good parts of Unity - which is why I'm sticking around for now.

But I stand by my assertion that their focus on headline features is troubling.

Unreal Engine 4 will fix the workflow, though.

http://www.youtube.com/watch?v=MOvfn1p92_8

And by JavaScript you mean UnityScript

Our teams share code by not coding in Unity projects. All the assemblies are added as plugins with a build script. The games have very little code actually accessible from within Unity. You lose the nice edit and continue, but for a big project with a lot of assets the Unity IDE explodes under pressure anyway.

Interesting. Is this process - plugin based game development in Unity - documented anywhere? I assume you lose browser support, are there other major drawbacks?

You don't lose browser support, since what you're dropping into the project is still .NET assemblies (they just happen to have DLL extension). So they aren't any different than what would Unity compile your C#/JS/Boo scripts into.

The main reason I think it's really dumb for Unity to put more focus on high end features instead of polishing and improving what they have is because developers who want those high end features are probably using Unreal or UDK.

The way I see it, Unity's primary market are hobbyist developers or professional developers who are making casual / indie / 2d games, and usually those games are on Mobile. Those types of people want less headaches and they want to be able to do common stuff really really easily. They don't really care about the high end features.

Unfortunately, Unity has terrible built in support for 2d art. Unity also zero built in wrappers for common Mobile tasks like In App Purchases.

Jumping through hoops to get your source control setup properly is a huge knock against it as well. This type of thing should just work out of the box.

You can't cut and paste components between game objects. When importing sounds you have to change the import settings on each sound individually because they don't support multi-object editing.

I use Unity professionally as a casual / indie game dev and while it is the best game engine for me, I can't help but think it could be so much better.

Version control on Unity isn't as bad as you describe. Go to Edit > Project Settings > Editor, then set Version Control to Metafiles. If you have a Pro license, also set Asset Serialization Mode to Force Text. The downside is that this litters your project with .meta files, but that lets you work with external version control pretty easily.

Edit: You should also exclude the Library folder from your VCS, because with metafiles enabled the Library is just a local cache.

You're responding to an argument I didn't make. Version control works fine.

The problem is that there is no method to build libraries and share them between multiple projects, since all the code needs to be under the Assets folder of each project. There is no support for classpaths.

If you update the code in one project, you have to copy the file to the other. Or have some equivalent method of doing so outside of Unity.

Prior to Unity 4, people were using symlinks to accomplish this, but Unity 4 disabled them on Windows to match the OS X behavior (this is described in the post I linked).

Sorry about that, I thought by different projects you meant the same project on different machines. Sharing libraries between projects, now that's an interesting problem. I think I'll go have my morning coffee now.

Can you just checkout a subrepo into your assets?

Yes, this is the only way the handle it. Git subrepos make this a hassle though, in our experience. It's the one thing that SVN would do much better.

Have you tried git subtrees? They are so much nicer than git submodules in many ways.

http://news.ycombinator.com/item?id=3926683

Thanks for the pointer. I've read a few articles thanks you to. It still seems awfully complex and demands very proficient git usage to do even simple operations. I don't think that's suitable.. but I'm curious are you using it with Unity?

Not with Unity. One big advantage is that git subtree has is that not everybody has to be proficient with it, you can designate someone to set it up and to periodically push the subtrees, and everybody else can ignore it.

That's not quite true; they should split their commit so they don't span trees. But it's not a requirement, it just makes things a lot nicer.

This essentially seems like you're ticked off at one feature and everything else is beside the point. If you follow one of the links in this thread:

http://feedback.unity3d.com/unity/all-categories/1/hot/activ...

You'll find that the Unity folk disabled symlinks to avoid thorny edge-cases and are trying to figure out a way to give you what you want, including simply allowing sym links but generating a warning message (and Windows devs are suggesting using a junction link -- no clue what that is).

It seems to me that the best option would be for Unity to expressly support the inclusion of folders outside the project tree in projects.

The engine being "six years old" is somewhat beside the point. Major changes and improvements have been made to the engine have taken place, and in some cases these have been as dramatic as "from scratch" rewrites.

What I'm saying is that after six years, there is still no support for something as basic as classpaths, which I'd consider part of the MVP to be using something like this full time.

It seems you disagree, but many people have popped up in this thread with the same complaint, and workarounds they should not have to be making.

I have no problem with the 3D rendering part of Unity, it's fully featured and works well. Especially for the price tag.

Agreed that age being bad is a nonsense metric. I was saying the opposite - it should indicate polished workflow.

Ticked off at one feature is not an accurate assessment at all. If lack of classpaths were my only problem, I'd be in love with the product.

I don't think it's a bad engine either. I was just expressing my concern for where they're choosing to spend their effort.

If you complain about the lack of polish on existing features on the official forums you just get told to shutup by other users. It's sad.

The workflow I use is to have my library code in a folder outside of the unity project, and add a build target in visual studio that copies the produced dll into various unity asset folders. Definitely not ideal, but it works reasonably well.

And why is 'engine age' a problem again? Unless there are major architecture problems, one should not need to rewrite everything every 4 years.

It actually is normal practice in major game engines to do major rewrites every few years. id Tech 1, 2, 3, 4 etc. for example.

I'm not saying the engine is dated. The renderer is fantastic.

I'm saying that given the age of Unity3D, the basics should be 100% nailed.

I am an ex Web developer who got into game programming with Unity over the last 3 years. Its been amazing, i have learned a ton by using C# and actually needing to apply Math knowledge to a real world project. Unity is awesome but also has some issues, but as i havent really worked with the other big engines, i guess these have similar issues.

* Version control is a pain. We used Git (with Github) all the time but unitys meta files like to screw things up from time to time. Unity also uses alot of binary files (eg. prefabs) that could easily be replaced by some kind of JSON based format, making version control much easier

* its not cheap. If you want to use their killer multi platform features you will need licences for all platforms per seat, which adds up to quite a lot if you have several developers. When they release a new major version once a year, you will need to upgrade all your licenses (granted for a reduced price). Its a nice customer lock-in...

* its not very stable. At least under Windows it crashes alot on big projects

Project Settings/Editor/Asset Serialization/Force Text. I think this might be pro-only though.

Ever since unbuntu ruined their desktop with the same brand name, I flinch a little everytime I hear the word

By the time Unity for Ubuntu reaches version 4, it will include the following features:

-the ability to launch a command line will be gone, because the command line could allow accidental damage to your system

-it will not be possible to minimize or maximize windows (if you can still call what they have turned it into "windows"), those buttons will instead have been replaced by a shopping basket, and a helper assistant button, respectively

-because top left is not exotic enough, the window close button will now be in the bottom left

-launching more than one window of the same application will not work because this is confusing

-the menu of a program will be on the right side of the screen. You'll have to hover the mouse there first, then wait for a list of helpful suggestions to slide into view, scroll through it with an awesome fluent scrolling animation, and then finally at the end will be the menu options.

-the file system is abstracted away. Directories are confusing, so the concept of directories is hidden. Instead it presents the files as if they're in one large "basket". Extensions won't be shown because those, too, are not understood very well by most users.

-the scrollwheel, middle and right mouse button, and keyboard shortcuts, are ignored, to unify the desktop better with touch interfaces of mobile devices

Am I the only one that likes Unity ? I'm a die hard desktop user: KDE, XFCE, Tiling WMs... but I find Unity quite good.

You're not the only one. I like it too. But we're the only two.

Looks like fun. I've heard game development (for an employer) is quite the sweatshop though. What are the employment prospects and expected salary for someone proficient in this software?

Also, wondering if there any competitive open source game engines to aide in learning.

I can definitively say that where I work, at EA All Play's Sacramento studio, is not a sweatshop. We encourage eight hour days (plus lunch break, however long that ends up being), and every Friday afternoon there is free beer and fun presentations to end the week.

Right now, though, our only programming openings are for Java server engineers. Sorry.

I do recommend learning Unity though, if that's what you're interested in. As Unity improves, its easy cross-platform deployment becomes more and more attractive to larger companies.

Anyone know if Unity has any plans to support WebGL?

WebGL would be extremely tricky for them -- they'd first have to port their OpenGL render pipeline to JavaScript, which would be "doable I guess" especially since they could just port their GL ES (mobile) render paths, that's mostly identical to WebGL. But they'd also have to port their entire runtime library to JS, which would exceed a major rewrite in terms of effort I believe. And then they're calling .NET / Mono APIs everywhere in their own runtime/core code, I'm sure. And then there's the thousands of Unity projects out there calling said APIs. And then, and then, and then...

Next, asset loading but since you're on the web, ideally you'd have smarter on-demand streaming of compressed assets, rather than a 10-minute-long "Loading Game Assets" splash-screen page...

Next, user code. Uh-oh... I give up.

I remember seeing an interview with the Unity CEO and he said that they had someone who was looking into (evaluating) HTML5 as a Unity target platform. I guess that would include WebGL, but also things like the Web Audio API and WebSockets.

My impression is that the web browsers aren't quite there yet, in terms of support for all the necessary functionality required by a modern 3D video game. For example, IE doesn't support WebGL.

Take this with a grain of salt, but I vaguely remember some moment when everyone was talking about the announced ability to export to Flash, and a question mentioning HTML 5 or WebGL came up: their (unofficial?) response was something along the lines that they would do whatever it takes to be on any platform they need to if there is demand. I feel they have proven that they really care about wide multi-platform availability, with efforts like their "Union" program and availability on console and mobile platforms. This recent move to support Linux shows that also. If WebGL proves itself to have a large critical mass of developers asking for it, I bet they will very very seriously try to do something. I can't speak to the difficulty of such a move, or compare the actual results of their Flash exporting efforts, but I don't doubt they would do it if it was reasonably possible and there was demand.

Does anyone know if they updated their default GUI elements (they were pretty rudimental in v3), so you don't need to use custom GUI elements?

They are planning the GUI update for the later 4.x releases. At-least that's what i could guess from the forums.

Here's a blog post on the upcoming GUI-system revamp, from earlier in the year: http://blogs.unity3d.com/2012/06/29/the-new-gui/

Correct. I heard from a Unity rep that it's definitely coming in 4.x, but he made it sound like it was still about 6 months away.

Also, there is a video of it being early pre-release demoed at the Unite 2012 conference: http://unity3d.com/unite/archive/2012

I just ran a 32-bit build of "Angry Bots" for Linux on my Windows machine. It ran flawlessly on Linux machine (Ubuntu 12.04 LTS).

I love the scroll effect on the header of this website, gives it a depth perspective. Very cool stuff...off topic I know, just wanted to mention it =P

It's called parallax scrolling, just as an fyi. :) (I learned the term myself not too long ago, so I get excited to use it when I can, haha.)

Anyone knows how much the upgrade costs? Can't find it without login which I don't posses at the moment.

$750 for pro license and $125 each for iOS / Android

$125 is for upgrading "basic" iOS/Android. Pro upgrade is $750 for each. License comparison chart is here: http://unity3d.com/unity/licenses

Edit: Note that it is possible to upgrade just your Unity 4 Pro license without upgrading the individual platforms. For instance, I have Pro iPhone/Android licenses, but currently working on a PC/Mac game, so I upgraded my Unity 4 Pro license and left the platforms for a later upgrade.

I would be curious to see how Ouya will fit in there, yes Android is supported, but at what point will Ouya be supported or not by Unity 4?

How about never? The Ouya is a pig-in-a-poke at best. There's nothing compelling about it that you couldn't do with an ARM evaluation board (in fact, it's more limited), the average console gamer opinion regarding it is 'meh' and it will be obsolete the moment it arrives as what you can buy for $100~ in the ARM SoC space is getting crazier every minute.

The Mali-400 on http://www.hardkernel.com/renewal_2011/products/prdt_info.ph... is already posting better benchmarks than the Tegra3 on the Ouya and the CPUs are the same core, this one slightly lower clocked. Sure the price is a bit higher than the Ouya for a dev board, but that's something you can buy right now. And they're only going to be better and cheaper by the time the Ouya hits, which if I might remind is still five months away if everything goes to plan. Might as well be eternity at the rate cellphone hardware evolves.

Really, all they've done is sold a case and gave us some simple interface mockups. Even https://en.wikipedia.org/wiki/List_of_Ouya_software is completely underwhelming and resembles the total lack of commitment other DOA consoles like the NGage had going for them.

You can expect Asia to be cranking out a new Ouya-like every few months. It's the software stack on these devices that is significant, as the hardware is now practically free. Hell, it's even open source: https://www.olimex.com/Products/OLinuXino/ *

(* Mali-400 GPU still not fully reverse engineered. As usual, GPUs are the FOSS barrier -- still, there's hope: http://limadriver.org/)

There is rather a big difference between a board and a consumer product. Most people are not keen on building their own system from scratch - and so far there isn't another 99$ game console out which is pretty much what OUYA seems to be about. Not to mention a console specific software stack. The fact that there is really hardware already around for that price makes me rather optimistic that OUYA isn't just the dream that never can come true which was my biggest fear for it so far (although I worry more about it's software stack).

Maybe there will be Asia clones ones it's out and a success, but so far there aren't. Someone has to be first...

And if it can get even cheaper in the long run with that hardware - that's also not exactly something speaking against it.

You got maybe a point with the games, but even there I'm not too worried. I don't need lots of good titles for a console - give me a handful of fun titles and I'm fine. Even playing supertuxracer on TV would already be enough fun for me to consider getting it :-)

You don't seem to understand that Android already is first. This is a $100 Android box with an 'app store of its very own!' and not much beyond that. We've already got Android and it's not difficult to make a similar enclosure. We've already got better hardware! The cost of porting from Ouya to other Android consoles in general is almost assuredly trivial to possibly zero depending how lazy they are about their software stack (i.e. no real reason to deviate from typical Android practices). All they have to differentiate themselves with is what they've added to Android and so far it looks like 'not much'. There's no reason for exclusivity on Ouya.

No, it's not a $100 Android box - it's a 100$ Android console. And I don't know any other Android system specifically designed for that so far. You don't keep your mobile phone or tablet plugged in to your TV and neither do you plug in a game controller into either of them usually. Also generally tablets do not mainly care about improving performance specifically for games, which mean given the choice of faster 3D or improving other hardware parts a typical tablet will not go for 3D. And yes - easy porting games to/from other Android systems is one the big selling points. If you think a computer is a computer then there is pretty much no point for ever buying a game console, nearly everyone has a more powerful PC in the house already.

Presumably after they show some signs of actually shipping the thing.

Yes, yes, I'm a curmudgeony and perennial Kickstarter skeptic - but what other stance can you take when a team that has never shipped any consumer electronics before promise to ship a profoundly game-changing piece of hardware on an extraordinarily aggressive schedule, at a shockingly low price?

The price is realistic: http://www.isuppli.com/Teardowns/News/pages/Low-End-Google-N... gives a BOM cost for the Ouya sans controller at around $75. Add a year's worth of deflation, and it should be around $50. No, they're not making any profit at $99, but they hope to make that up on game sales and later sales to those who missed the Kickstarter. The point is that they're not losing money. A normal manufacturer would have to spend millions in advertising to get the exposure Ouya did.

The only thing that's hard about the schedule is that they're a new manufacturer and need to build relationships with all of their suppliers. NVidia would have given them a reference design that they could almost use unchanged.

I was under the impression that they have in fact shipped consumer hardware (nothing especially elaborate -- I think they do bluetooth speakers for iPod/iPhone).

Ouya is just stock android plus APIs for the controllers and UI. It will probably support Android games with little or no modification.

As I understand it, the only departure from standard Android UIs is that there's a sort of in-game menu, and games may need to be modified to support that.

The Unity people specifically endorsed the Ouya Kickstarter by saying that Unity will support the Ouya through their Android publishing.

Not sure to understand why I was downvoted here...?

Because no one on HN actually believes the Ouya is anything more than vaporware, despite their announcement of having working hardware in hand and initial units in manufacturing.

No OpenGL support at all? Isn't Unity used for mobile games, too?

On Windows Unity uses DirectX.

On iOS and Android OpenGL ES.

On Linux and Mac OpenGL.

There has to be, unless they have ported direct x to Linux.

They are just not bragging about it on the sales page.

What makes you think that? Unity uses: D3D9, D3D11 (new in 4.0) or OpenGL on Windows; OpenGL on Mac & Linux; OpenGL ES 1.1 or 2.0 on iOS, Android and NativeClient; libGCM on PS3; D3D-like API on Xbox360; Stage3D on Flash.

What is new in 4.0 is D3D11 support, which is kind of a big deal since it opens new GPU possiblities (compute shaders, tessellation etc.). But all the other rendering APIs are still there and fully supported.