This is for the UT iPhone crew…
We’ve just finished registering with Apple, the process took weeks and can only be described as “ridiculous” (an understatement). It then took me an entire day to get the certificates and provisioning and shit, then to install the Unity Remote, and finally the demo application. That’s way too much time.
I’m a little frustrated right now so pardon me for venting, I’ll try to keep it as constructive as I can.
I’ve never used XCode nor made an iPhone app before, but I’ve used Unity for a year and a half now, and to be honest I’m disappointed; I bought the iPhone version, someone dropped a package on my lap with just about no instruction manual, I had to fiddle through it to find the “getting started” doc, then stumbled upon the Unity Remote folder, then had to dig in the forum to figure out what to do with it, how to change the identifier, etc etc.
It all feels half-baked. I suppose lots of users were already setup, already making iPhone games, and are only switching to Unity, so of course, piece of cake for them. But first-timers seem to have been left out.
Yes, maybe I’m asking a lot, but hey I’m using Unity because I love being pampered and yes, I want Unity to hold my hand through this, and no, I don’t want to setup any crappy complicated stuff. Having to deal with Apple is bad enough, setup is the one thing that you have control on, so at least be thorough.
Rambling complete. I’m not mad, I just wanted to pass this on so you guys can do better next time and make a noob-friendly 1.1 release ;).
I know UT’s had a crazy year, you’re juggling with who knows how many deadlines at once, and frankly I’m amazed; just don’t forget that your strength is in the polish you bring to your products. Which are awesome. I come in peace. Please don’t hurt me.
Admittedly our iphone-specific documentation is not integrated extremely gracefully. We want to improve this in the future, but to do it right requires restructuring all the documentation, which is too large of a task to take on right now.
For now, I can point you (and other Unity iPhone users) to the documentation installed locally alongside Unity. These pages are not viewable online (yet).
Now, we are totally open to feedback and suggestions for the iPhone docs. The best way to communicate with us is to log a bug report, using the Documentation issue type. That way it’ll be entered into our system and tracked. Feedback posted to the forum is not entered into our system and runs the risk of being forgotten! So anyone who has feedback about iPhone docs, log those bugs!
Thank you Sam, I did find those docs, it just wasn’t as obvious as it should have been IMO.
I just wanted to convey this general feeling of “unfinished”, which you seem to confirm: “yes the docs should be better but we don’t have time so we deliver them half done”… again, I get it, but don’t keep this up for too long.
Also, I don’t feel like what I said fit well in a bug report… although I do have some more precise points: docs not updated for player settings, GameObject (what does that static checkbox do??), and GUI sliders that actually crash the iPhone… how did that pass the beta?
I did my homework and logged those, but honestly, I’m a bit fed up with bug reports (fed up with lots of things these days ;)), I can be as precise and thorough as possible, every time I get asked for a demo project and I feel like I’m doing UT’s job for them! I’m well aware that you probably process hundreds if not thousands of bug daily, but we shouldn’t feel the pain (except for beta products of course, which is pain we actually asked for :lol: ).
I can understand part of your grumpiness - but really have a heart!
We expect UT to have the bugs fixes and new versions, hot fixes and Windows versions out as soon as possible.
If, by submitting a project which causes a crash, the bug can be fixed, you get TWO for the price of ONE, so don’t complain.
One: The bug gets fixed and you get “one on one” attention, by the experts, and everyone else benefits (including you when its someone elses bug).
TWO: You get it fixed quickly, rather than say oh them spending - sorry wasting - two days trying to recreate a very in frequent bug in some cases. This means they do the work more quickly, gettig through more bugs and fixes, so you can develop your game/app more quickly too.
So be happy and if you want the bug fixed help them out a little. Imagine calling the AAA and saying “Help - Im broken down in my car. I bet you can’t find me but I want rescuing now!”. Lol.
I appreciate that bugs are blumming annoying but give the chaps a break, they are working hard. I agree that we shouldn’t feel the pain, but no pain no gain.
That’s one way to look at it… another one is to think the bug shouldn’t be there in the first place, and that I paid a steep price for a beta product (yes, that’s over-harsh but you get the point).
You’re over-generalizing. Not all bugs are uber-complex game-dependent things that require your very specific scene to be reproduced.
Often times I just say “hey this API feature doesn’t do what it says”, with a script demonstrating the problem (you’ll notice that I specifically said I was thorough in my reports). So in these cases, to follow on your metaphor, including a demo project would be like calling AAA and saying “hey here’s my GPS position”, and them asking you to snail-mail them a map.
You’re forgetting Unity’s motto: “we take the pain so you don’t have to”.
And again, I did say “I get it guys you have a lot going on”, but I’ll complain if I want to, thank you very much.
The real issue here is I’ve been on board a year and a half, and in the past 6 months or so (around after 2.1 I’d say), I really noticed a change of pace. I’m pretty sure the amounts of users, and thus bugs, must have grown exponentially, but that only means they need more staff to handle the load.
If the quality of service or product decreases, it’s bad for everyone, so if you want to get emotional I’d even say it’s our duty to complain. Being supportive of an amazing team is thrilling, being a fanboy helps no one.
One thing that might help developers is a litle bit more transparency on the bug reporting side…
I understand that going public with priorities or announcing bug fixes is a real can of worms, but just acknowledging a list of known issues would go a long way so we don’t have to search the forums and start multiple discussions to figure out why something is not working.
OK - well I’m glad you’re complaining nicely anyway. I was just trying to keep you positive about it all.
But you cannot seriously expect the known bugs list to be listed! I think that just the maintenance of this would be a waste of their time and resources. If you want to see what bug fixes were made for 2.1 then look on the 2.1 feature list - they are all listed.
I haven’t been around Unity as long as you so I shouldn’t really comment any more, as my experience is clearly less than yours.
I must admit I have no idea where you’d post a bug so perhaps there should be a forum listing for it, this would keep them all together in one place, so saving hunting.
There are a lot of reasons for a private company to be against this, but I don’t think resources is a valid argument. Many open source products do this (for example).
My point was resourcing it alone was enough of a reason not to embark on such a task. With an ever increasing suite of complex products such as Unity is becoming, it would be increasingly time consuming for members of staff to be alloctaed the task of simply keeping it all upto date on a day by day basis for the benefit of public viewing.
I’m sure internally UT have a full featured system for bug listing, its just not public facing.
IPete, indeed please pass on the fanboy comment, I hesitated while writing and intended it “in general”. This forum does have fanboys, it’s sometimes hard to know who you’re talking to ! What I meant was, being too nice doesn’t help if it keeps people from facing the facts.
Also, I didn’t intend to play a veteran card or anything, and the fact you’ve used Unity less doesn’t mean you can’t share your opinion.
You can report bugs using the “Help/Report a problem” menu or just open the report app from Applications/Unity. Try reporting one, you’ll see they do have a bug-tracking system in place, that you can access but only to view your own reports (I have 150+ myself, lots of them still open).
I believe a good part of Sam’s day is reading the reports, and probably for 90% of them just link them to a similar report. Then they say “hey this bug has been reported 100 times, we’ll make it a priority”. So I agree with Matthew, it’s not an organizational problem as much as a management decision.
Whether it’s Unity or any other software, testing and reporting is first a service users provide to the software developer. There are a lot of professional testers out there… we do it for free.
Of course everyone’s glad that they fix the bugs, because hey it’s a community and we’re all friends here, and being part of a beta-test is commonly regarded as a privilege, even amongst gamers.
Fine by me, the system work, but we should never forget that in the end, they’re the ones selling the product and making a living out of it. The fact that we use it, enjoy, maybe also make a living off of it, doesn’t change a thing.
I disagree on part of this… I don’t really want UT to be documenting how to provision a phone or set up certificates as part of the official documentation for Unity – that is Apple’s process. There is a lot of frustration in the original post that seems to be misplaced, in my opinion.
That said, it doesn’t diminish from the more legitimate complaints (like sliders, to pull one from this thread) where there is an actual issue with the product UT is shipping.
Just my opinion, for what it is worth – UT has nothing to do with the fact that a development certificate needs to be created and that a phone needs to be provisioned to test software on it. If Apple isn’t making that clear in the iPhone Dev Center, this should be a conversation aimed at Apple (in which case, I have more than a few complaints about what seems to be an unnecessarily complicated and fragile process). UT has everything to do with sliders that didn’t work and other bugs on shipping products.
I may not have been clear enough: I wasn’t talking about documenting the Apple process, but Unity’s setup.
The Apple process did induce my frustration, but Unity nailed the coffin. It’s as much a general feeling than specific points (the worst one being that I had to fiddle with the Unity Remote project in XCode without any indication how to do it).
Well if it’s that simple, why isn’t it documented?
Plus, it didn’t work for me, I had to change the app identifier (from com.unity.something to my company’s identifier), which wasn’t obvious for me. I said it from the get-go: I don’t know squat about XCode.
Because its trivial.
Its the same you did with all the sample project for XCode when you started toying with your iPhone.
This is part of the XCode and iPhone Development stuff related to the Dev Program from Apple.
Knowing this aspects is your duty as developer you signed for the iPhone Dev Contract, who signed the NDA, not duty of Unity and its documentation.
Because you will have to read it, you MUST (not can) know that stuff as you will need it to sign and certificate your project to get it onto the AppStore.
so if you don’t know how to use XCode, how certificates work etc, then you are clearly a few steps behind what you should know before starting Unity iPhone.
As long as you read the help files and tutorials in the iphone developer center/portal your golden. It took me maybe an hour or so to port my game and get it setup with a few code changes, the dev certs, app ids, registering my iphone, and provisioning file, but once its setup it literally is apple-b.
I never used xCode before too, Unity makes it so you don’t really half to, except when you actually distribute your product. But their are directions from apple on how to make a distribution build.
I set up a second app and got it working in just a few mins…
Thank you so much for calling me stupid, I enjoy this. Unity IS trivial, see? That’s the point of Unity.
You really aren’t listening, are you? I never used XCode before. I never toyed with the iPhone. The official party line was: “just buy Unity and start making games”. I sat through hours of conference demonstrating how easy and trivial is was. And you know what, it is pretty good, but I don’t see why that should mean that is perfect, and we can’t expose its flaws.
You dreamora I have noticed before, and unlike IPete I have no qualms calling you a fanboy. You and all the fanboys around are the reason I come less and less to this forum: every time one is trying to have a conversation about an issue, your only goals seems to be refuting every single argument to protect The God Unity.
I’ve lost all interest in this topic, I can only foolishly hope it will just stop right here right now.
I am no fanboy.
Otherwise I likely wouldn’t own the full set of Torque Engines as well including iTGB, one (of not the) Unity iPhone’s direct competitors.
What I wanted to explain there is that, while building your game in Unity might be simple, this will not free you from the requirement to understand how XCode and the iPhone deployment works. Because you will have to understand it to get your game onto different devices for testing and especially to get it onto the AppStore.
I don’t see why Unity Documentation needs to cover that therefor, its the developers duty to know the basics on the technology he uses and you intend to use the iPhone so XCode and deploying to it, at least to me, is part of the very first things that should be looked into before even starting Unity iPhone.
Apple wrote extensive documentation on a serious large amount of things related to it, its just needed to look into it.
For Unity iPhone developers, one of the first things to look at as early as possible is the Lander Sample Game that you can download. It will help you understanding many of the basic things. Naturally after you read the starter docs on how to create a provision and install it + the world certificate to be able to deploy at all.
iPhone development requires that you know a bit what you do, Unity can not change that. So the earlier you start, the less problems you will run into during development and testing.
Unity iPhone definitely requires a developer to know what he wants to do and where to go and that the developer has at least basic knowledge of iPhone development when it comes to certificates and working with XCode (far less than iTGB just to mention that as well).
If you expect any technology to magically just work, then any mobile platform is likely the wrong development platform for you at the time.
Perhaps the iPhone development will get less “strange” at some point than it is now, but I don’t think that the certification aspect or “know how to compile something with XCode” will ever change.
! What I meant was, being too nice doesn’t help if it keeps people from facing the facts.