I am on the last few days of my unity iphone trial and in short there are many things I love about the platform but a few things that are “show-stoppers.” First I will deal with the show-stoppers because once those are overcome I am on my way to a long happy relationship with the unity platform. Then I will go over some of the great things about the platform but they can be pretty much summed up in one word “polished!.”
Overall Contrivances:
Unity-iPhone should be it’s own product. I think this is a big enough deal to merit it’s own gripe. More harping on this is in other issues but the hardware, display, and input limitations warrant a product specifically designed for games, optimized for the device itself. It’s a serious pain to compile-build-deploy in the iphone SDK itself let alone something that emits generated code. This marriage of technologies needs to be much more seamless. I don’t think that unity iphone projects or scenes should be confused with other unity projects, I think this separation has to be much more deliberate. The iphone warrants it’s own compression, has it’s own color profile, and has specific limitations on graphics hardware that are currently allowed when compiling another unity scene for the iphone. This is a problem, I will state again that the separation of projects, assets, scenes and so on needs to be much more deliberate, it should warrant it’s own pricing model and should specifically not be confused with other unity products. I think once we are on that path everyone is going to be much happier.
! Show Stoppers !:
Compliation wierdness in iPhone 2.2 SDK - when I build the exported project I occasionally get stack-trace dialogs in xcode. This is unacceptable, I think it is possible to have compilation issues or things of that sort but completely breaking SDK compatibility is a ‘no-go’ and that is the same for anomalous behavior when compiling / deploying to device. I know that 2.2 was recently released so I would expect some lead time to get those quirks worked out.
Input performance sucks - the input performance is simply unacceptable, perhaps this is due to all the runtime overhead but input should be first priority in the game and everything else second. There should not be a noticeable lag when input is detected and the scene responds. Even if this means cutting out some scripting runtime, input performance must be improved. I realize that on the desktop input is acceptable and even though any ‘specific’ input lag may be miniscule this is a cumulative effect in a game where the user will be providing lots of input or the outcome of a game may be directly associated with the user input. I will try and find apple’s touch fighter demo which provides a concrete example of how input response should feel. There’s also some other great things about the touch fighter demo like color crispness that I will address later. I know this is a qualitative thing and not a quantitative thing but this all gets back to streamlining the runtime and maybe even product itself for a more optimal iphone experience.
Annoyances:
Colors appear murky - the colors on the iphone device seem a little washed out and blase by the default rasterizer. Maybe this could be improved with custom shaders but I can only discover so much in a 15 day trial of the platform. In the touch fighter demo the colors seem much more crisp and vibrant, the blacks really pop and the blues and yellows are very bright. Perhaps this could be easily fixed with offsetting the light hues a little for the iphone but this goes back to a product with settings specifically optimized for the iphone.
Scenes / Assets / Projects in one version of unity do not directly translate to iphone. This should be expected by anyone who is using unity-iphone that some desktop project won’t translate even with a little intervention to the iphone platform. For example I was following the lerpz 3d platformer demo and fixed a few things but when I tried to build the game for the iphone I found every texture had been imported with an unsupported compression scheme. That’s no problem but how do I fix it? By re-importing every texture with the correct compression scheme. Wow this is a massive annoyance. Again projects in one platform should probably just be incompatible with the iphone version of the product (see the first gripe).
Game settings should probably be in a preference dialog - currently all the important settings in the game like resolution are managed in the ‘inspector’ which can be a little ambiguous. This is the kind of thing you usually only set once and should probably be associated with a “project” notion. This is just a preference thing but hiding important settings like that in an inspector pane seems like a point of pain for the user.
UI is very nice but still a little wonky. Overall I think that unity is awesome platform but the UI is pretty darn annoying to work with long term. For example runtime settings are not persisted. Why not persist every setting and keep then in an undo chain? If i drop some prefab or object in the hierarchy it sometimes gets dropped miles away from my scene. Small annoyances like this need to be evolved but overall this is unfair to unity to throw blanket enhancement requests like this but games take hundreds if not thousands of hours to complete. It would be nice if these kinds of things were put on the fast track.
Things I love:
Overall the platform is highly polished. Again I don’t think you need to have every scripting runtime like Boo, JS, and Moo especially when distributing apps for the iphone over edge. It just makes the runtime footprint way too large when you throw in compressed textures, game logic an d the like. But it’s by far the best and only game platform with a UI designed to see and interact with your game in real time.
Conclusions:
I just don’t know if this platform is ready for prime time. I’ve seen app listing on the app store and I think the apps speak more to the skill level of the developers than the platform itself. Right now i’m more tempted to wait for Torque 3D for iphone or just use some code based engine like oolong. But I have some titles that are much earlier in the pipeline and I could see starting those projects in unity and seeing what happens.
Torque 2D (iTGB) is not even running very well on the iphone, based on my experience, so I wonder how long it will before their 3D engine is running well?
Unity is far and away the best game engine out for iPhone.
Maybe you can write your game in Oolong instead if you have some seriously good C++ programmers on your team.
Good luck with Torque, it isn’t up to Unity’s current standard.
Honestly, your complaints are pretty minor and a bit illogical. If you want Unity and Unity iPhone to be separate then simply don’t import any Unity projects into Unity iPhone if you can’t handle the port work. They can be as separate as you want. Of course if you deliberately open a project file initially created to run on a desktop there’s going to be some work involved.
As for the stack trace dialogs, they’ve already stated that’s a bug in Xcode. I’ve experienced them as well but they aren’t show stoppers. Simply click continue and your apps will compile just fine.
You complained about colors being murky which just sounds like you haven’t experimented enough with the lighting and shaders. Ideally, you don’t want to use many lights and I chose to use the vertex lit shader which produces vibrant colors conducive to a mobile environment. Other than that the only difference I’ve noticed is that my iTouch is brighter than my iPhone but I attribute that to the fact that I have an anti-glare cover on the phone. The iTouch is quite vibrant however.
The biggest issue you complained about is input and quite frankly I don’t know what you’re talking about. Perhaps you aren’t implementing it correctly but the input works like a charm. Whether you’re using touch or accelerometer everything’s responsive. At least in comparison to other apps for the device.
You’ve stated that you used Unity for 15 days and to be honest it just sounds like you need more time. I’m not sure what your previous game development experience is but it sounds like you’ve been around the block a few times. I suppose your history determines how you interpret a tool’s behavior.
I think the overwhelming majority will agree that Unity is head and shoulders above the rest. Of course we can never expect everyone to agree. Good luck finding a solution. Obviously, many people are very happy with Unity and I personally haven’t seen a better solution either in Torque, ShiVa, or the standard iPhone dev kit. You always have the option to write your own tools but personally, with something as functional as Unity it seems pointless. Almost anything you want to do is literally a click or line of code away with Unity. I found ShiVa to be a close 2nd and Torque to be a distant 3rd as far as tools I would consider using for iPhone development.
I have to say I disagree with much of the original post. Right now Unity iPhone is its own product with its own pricing model. However there’s been talk of eventually incorporating it into normal Unity, which I’d agree with (though iPhone publishing would remain an additional license like Pro is now). Since they are 99% the same, I don’t think it really makes sense to have two separate products, because that’s a huge amount of redundancy. It’s up to the developers to understand the limitations of the iPhone hardware, and imposing artificial restrictions and incompatibilities is not the way to do that.
There’s actually some crossover possibilities between iPhone and desktop (look at Pangea’s ports of OS X games for example), and I think many Unity iPhone performance problems are down to developer inexperience. Because desktops are so fast, someone can write lousy code and have inefficient setups and still have it run OK, but that doesn’t work on the iPhone. Learning how to make things fast and efficient on the iPhone also translates to things running even better on the desktop. Even with good experience on the desktop, it would still take some time to learn all of the iPhone ins and outs.
That’s really up to your source material and/or lighting. Personally I don’t want Unity fiddling with that; I expect it to display what I’m giving it.
No, because preference dialogs apply to Unity globally, for every project. Game settings are different for every project and should be treated consistently.
Nor should they be. When I’m experimenting with a number of different changes, I don’t want to have to remember what I had originally, or undo a whole bunch of times. It would be nice to have some kind of “snapshot” button or something, for those occasions when I do want to keep the changed settings, so indeed it could be improved. This has been discussed a lot.
The Unity editor is scriptable, so many problems like this can be made to disappear, like with this script. (I think that should be on the wiki so it’s more easily found.)
When the upcoming hotfix fixes the current problems (the Application.LoadLevel leak is what I’m mostly concerned with), I think it will be.
Like I said a lot of these issues are “qualitative” probably even including the 2.2 SDK issues I had. I have experienced flakiness with the iPhone SDK since it was first released so no big suprise there. But the code that gets generated is pretty scary looking (at least at first).
I might have come off as saying that torque or some other 3d engine was somehow better than unity and i certainly did not mean to imply that. Apologies for any implication that unity sucked or something else was better. It may have come across as unfairly harsh on unity and I tried to note ‘qualitative’ (translation: your mileage may vary) observations.
Regarding the washed out look on the colors, there’s a lot of really nice ways to work around that in the unity environment like tweaking the colors etc but it just means that there’s going to be a set of tweaks (aka “profile”) specifically for the iphone platform which is why I was thinking that the unity-iphone should be its own product. With color tweaks specifically dialed in for the device.
Unity is by_far the most polished and feature rich platform I have seen to date on the iphone and probably will ever see. But what I am saying is that you are leaving a lot in the hands of the generator and for a game with a limited feature set (i.e. some arcade style shooter game) one might be better off trying to get the minimum constructs going (i.e. skybox, particles, textured meshes) but at least you could focus on the important things which is input and the compile, build, deploy cycle which leaves one with a feeling of ‘drive by wire’ in unity.
To me the SDK problems and input lag I had are “short term” show stoppers. Right now I would rather spend the 100+ hours of developing a highly responsive input mechanism than lose control of that because that is one of the most important elements of the game play of the current title I am working on. The key is having control of something I feel is a critical deliverable where I feel that is something lost on unity (at least right now).
Which input is non-responsive, in your mind? I haven’t seen any response issues. So, I’d like to know if I’m just not hitting them yet or if a little help can be rendered.
I know one issue is with the UI, but it is less-so with the upcoming hotfix. In my current game I use 1 poly mesh colliders for my UI elements and get great responses on that. For another prototype I made there was a ton of physics using ragdoll. The accelerometers were accurate as long as we kept the framerate up (as expected).
One thing about iPhone accelerometers: If you move too fast then the iPhone itself will miss the movement. I haven’t tested at which G-force it starts missing, as it is well above the max-out point of the accelerometers. Simple test: gravity is 9.8m/s^2, an office carpet does not absorb much of the energy.
First off, thanks for the many responses. This is very cool indeed. I think someone pointed out in the 13 or so days i’ve had to mess with unity I realize there is much I need to learn. I didn’t look at the .mm generated files to tweak accelerometer settings so that’s very cool. I checked out the tunnel example and the accello input was horrible. Also every other example I’ve been able to get my hands on and run on the device (occlusion, match, etc.) the input had just enough lag to raise a flag to me as unacceptable (in the cumulative performance sense). I will find the touch fighter demo and upload it to this thread and it would be cool to see how input performs on TouchFighter vs. Unity engine with similar # of polys.
In any case I’m with unity for the long haul. At first it was a little disappointing that I couldn’t use it for my first title which is a 2D style shooter with 3d meshes and skybox. But this was based on my experience with the input lag. It seems maybe this has a lot more to do with the implementation which is a good thing.
When I saw the generated code I hit the panic button and didn’t really start digging into it to see what was going on, there was just a bunch of generated code and running subsequent builds my fear was that changes to code in the generated xcode project would get destroyed. (Is there such a thing as a rational fear?) So fearing any outward control of the input mechanics is what left me with the impression that input was laggy and I had no control of it.
The annoyances are clearly a flavor thing and maybe I need to spend more time getting used to it which I will do.
I don’t think everything should fall on the shoulders of the developer for figuring out the appropriate use cases for their tools. We purchase tools in order to save time, all the scripts and community input I am sure will continue to evolve and drive this product. I still think that there are so many differences between a desktop platform (even through a web browser) and a mobile device like the iphone that it should be in it’s own product with performance (and flavor) tweaks already set for that platform. I think that making it incompatible with other scenes and assets would put the developer on a path of optimization and import tools could be implemented that optimize desktop or web based projects for the device. I think it’s great there is a uniform underlying model but it’s important to note to the developer that a prefab or a texture is not the same citizen on an iphone. That’s just my (not so)humble opinion there. My experience going down the path of Lerpz is that it’s just too easy to bring something into your iphone project that’s not optimal for the device or even supported so why allow it?
Most people won’t do that, I’m just kind of messed up that way.
As I understand it, this fear is entirely rational. Unity didn’t intend for us to edit the Objective-C++ code. Not sure how they will handle this going forward, but you should plan accordingly. There’s ways around it – maybe add a build phase script that restores your edits with a patch or something.
I don’t have an opinion about that. Certainly I can imagine a tool can handle both cases optimally, but I’ve been drinking.
It’s a 1.0 product. That’s pretty much the answer to everything. If you can’t use it, by all means don’t. If it will help you get a product in the app store sooner, you’d be crazy not to use it. My first game in the app store was all Objective-C. Later, after spending a week with Oolong and after talking to GG about TGE, I’m happy I spent the money on Unity for iPhone. It’s like a mecha exoskeleton for 3D game development, you just become faster and stronger and able to beat larger problems into submission.
not to bash on josgraha but i couldn´t agree more with what Eric said here:
And hanging out on the chat several days and reading all the iphone forum threads i´m totally sure the majority of people using iphone unity totally agree with Eric´s view. Unity and iPhone unity should be more integrated, ideally the same product, not seperated more than they are now.
It would be a nightmare to integrate features in two seperate products and would slow down further enhancing the unity platform A LOT.
Also one of the key strengths of unity is that one can develop for several platforms so nicely (and when one looks at the big differences of the platforms in comparably nicely seamles transition), this is a big strength that should be further enhanced, cross platform development and deploy should be pushed as much as possible, not reduced.
Ideally unity and unity iPhone should be one app, but even if not cross platform development and deploy could be pushed further in various ways.
Like in your case the problem seems to be you want to use a project made in Unity in Unity iPhone, would be cool if when importing it in unity iPhone it would do more to translate as much as possible automatically, to take your mentioned problem: Would be great if it would automatically convert the import settings for all textures.
What would be cool would be if the manual would automatically exclude things that are not supported on the iphone or would mark em in some way when one chooses iPhone as deploy target and also have more export/player settings specific for the iPhone when choosing it as target platform (like choosing an icon and splash screen there, setting the default orientation etc there, but yeah, that´s almost another topic.
Well, yeah, had to write this cause i can´t let it stand like that when someone requests reducing the integration between unity and unity iPhone while the majority of users wants the opposite.
the problem is that you can not develop for the iphone + another platform at the same time.
Even the Wii is considerable more powerfull.
So you will feel the nightmare of trying to manage a iphone + x deploy project in a single project and likely understand pretty fast that you will waste a lot of time trying to get it right for both by either degrading the x to nowhere or overloading your iphone one.
I would love to see them work the same, but I definitely don’t see the point of a full unity integration as it makes it look like a “1 click from pc to iphone” technology, which will definitely not help to create the right assumptions on what can and can not be done.
also to work right, Unity would need to learn about “projects” which it does not do right now, to assign projects to a given deployment technology, which would be required to remove stuff like terrain etc from the editor and others, that just don’t exist on the platform used for example.
the problem is that you can not develop for the iphone + another platform at the same time.
Even the Wii is considerable more powerfull.
So you will feel the nightmare of trying to manage a iphone + x deploy project in a single project and likely understand pretty fast that you will waste a lot of time trying to get it right for both by either degrading the x to nowhere or overloading your iphone one.
I would love to see them work the same, but I definitely don’t see the point of a full unity integration as it makes it look like a “1 click from pc to iphone” technology, which will definitely not help to create the right assumptions on what can and can not be done.
also to work right, Unity would need to learn about “projects” which it does not do right now, to assign projects to a given deployment technology, which would be required to remove stuff like terrain etc from the editor and others, that just don’t exist on the platform used for example.
so what you say is its difficult to develop for both so we shouldn´t make it easier but more difficult just so it doesn´t give the wrong impression that it would be easy?
Even if everything is perfectly integrated and there is as much automatic conversion and guidance help as possible to make transitioning between platforms as seamless as possible sure it will never be the case that every project is suited to run on all platforms.
Some game types that are for example quite ressource demanding would always have to be dumbed down to the lowest common denominator (weakest deploy target) but for other game types, let´s say 2D puzzle games for example, with a good integration it should be possible to quite nicely get em going on different platforms even if they have very different capabilities.
In such cases i´d like an as seamless transition as possible and use already made project parts as much as possible in both.
If both unity ide´s are combined one thing i´d like to see would be that one could choose deploy targets and set which assets to use on which deploy target, like for example for iphone deploy set lower poly models and only those get exported.
Maybe when selecting an asset one could choose for which deploy target it is and choose other assets which are used instead of this one for deploy target y export.
If the ide´s are not merged i´d like to see it that i can open a project in both ides, now i feel like when opening it in one it then doesn´t work in the other anymore maybe even if i haven´t changed anything in the project myself yet.
Even if you don’t share projects between iPhone versions and desktop versions, having two different products which are really 99% the same is somewhat wasteful IMO. And I wouldn’t necessarily recommend trying to make a monolithic “one size fits all” project, but even being able to duplicate a project and use it as a starting point for another version is a big time-saver. Someone got the Lerpz demo running amazingly well on the iPhone, as you can see here.
All of this isn’t to say that Unity is perfect; Unity iPhone 1.0 seems like it was probably released too early, but it looked like there was quite a bit of pressure to release at that time so it’s understandable, even if the results weren’t ideal.
I thought about the point if unity iphone was released too early a bit a few days ago when some others and myself,too experienced various quirks, flaws and limitations. At the end i think its still awesome i can work on unity iphone stuff now and with unity´s great support i feel pretty safe that i can just work on my game and actual bugs on unity side will be fixed while i´m busy getting into unity/unity iphone and progressing with my game on other ends.
Sure it would have been ideal to get it more bugfree, have access to more of the iphone´s specific features etc but at the same time i´m also happy i can use it now instead of having to wait 1-2 months longer.
Sorry but this really doesn’t sound like it’s going to be a problem for Unity. I thought you were going to say you wanted like 40 ragdolls on screen : )
So what games have you made in the past and what platforms/engines have you used. I don’t jut mean dicked around with either, I mean actually finished and published projects. Just curious. I’m sure you will learn to love Unity because hey iPhone or not what engine that cost less than $100,000 US doesn’t have a few problems. It’s called software… bugs are part of the territory.
This is pretty awesome discussion. But I think I will end my piece with stating that I will have to agree to disagree with Tommosaur and the like.
I’ve been doing this long enough to try and come up with a ‘process’ that gets me through the fray and to shipping the code/app/feature. That means setting up an asset pipeline that makes sense, something where I can tweak the assets for richness or performance or even remove features that might sacrifice performance.
My interest is to develop game titles for the iphone that use some of the cool features of the iphone like the powerVR GPU (3d etc), nice audio, and cool input features (multi-touch etc.). I’m not interested in other channels right now because it was hard enough getting apps out on the iphone channel. It’s become a ‘line of business’ if you will. I’ve spent my time in obj-c land and other languages and i couldn’t dream of implementing something as feature rich as unity even if I started back in 96 like these guys. but i would rather give up features for more stars in the feedback system if what features did get delivered performed great and made the user feel important because they were not ignored.
I think it’s great to be able to set up prefabs and have one place to manage all those assets but they obviously don’t translate 100% from one device to the next and rather than worry about what % of those features are portable I would much rather have a product that’s tuned for my platform (the iPhone) that has dark blacks and bright color contrast and is tuned for performance on the device even if a dialog pops up and says “you think you are adding more polys or colliders to this scene??? sorry buddy that’s gonna suck!” If the tool can catch those kinds of things for me earlier on in the pipeline then I don’t have to waste time finding the performance killers further down the pipeline presumably closer to ship date. That’s reducing risk, tools that decrease risk are far better than tools that promise more features.
That’s my argument for making it a separate tool, push the assets through the performance gauntlet up front before you discover the performance sucks and it’s too late.
One thought on the colors: what’s your ambient light set to? Sounds like maybe it’s too high and should be turned down.
About performance tuning: it’s pretty obvious by now that Apple doesn’t feel any obligation to keep a stable platform, and any time spent on performance warnings and the like goes out the window when Apple releases a new model and it’s clocked faster or has a new 3D chip or whatever. (Not to mention being annoying to work with: I don’t want to see any popups unless they’re critical.) I think it’s more useful to keep informed as to what is currently considered reasonable as far as polygons, draw calls, etc., and you can very quickly come up with prototypes or demo scenes that will tell you what to expect as far as performance goes, before you have artists spend weeks or months on building assets.
That is not really related to Unity, but a problem of XCode itself. I’ve seen those dialogs occasionally with non Unity generated projects (even with standard samples, once you change them couple of times). You can file bug on Apple site, if you’re annoyed (though I suppose it was done like 1000 times already). On other hand those dialogs are pretty harmless, just skip it and everything should work just fine.
That is one of the tradeoffs we’re looking at - and it’s a hard one.
On one hand we have people who are very used to Unity, have great experience and know the tool. They want to get started. Now. Yesterday. Especially with the iphone there’s been a lot of gold rush mentality.
On the other hand, every new release we do attracts a lot of attention; and we naturally want that attention to be as good as it can possibly be. However, polishing and re-polishing things just takes forever (I should know, I’m doing it on the 2.5 editor rewrite right now).
With the iPhone we wanted people to get working. No need why you guys should be kept passive while we were fiddling with polishing. There’s always updates to come. And seeing how people have shipped games already, it seems to me we made the right choice.
And looking ahead, we want to tie the different platforms closer together; there’s more mobile phones than the iPhone, after all. The way we see it, Unity should make the cross-platform porting as simple as it can possibly be (without being ridiculously limiting) - example: in iPhone UnityGUI touch events gets translated into mouse events so your gui will just work.
As we expand to more publishing platforms we want to keep them close (and closer than we have now). There is no reason why Occlusion Culling could not be useful in some web games - but again; we didn’t want to delay the iPhone for that. So look towards better and closer integration rather than having things be more separate.
