I’m starting a new project that is intended to be developed as a PC Mac standalone, and eventually for iPad.
Aside from some obvious things like hardware limitations and different method of input, are there any particular scripting things I need to be aware of so that when we come to do the iPad version I don’t need to adjust lots of code?
Things like strict typing when using UnityScript?
I understand I also have to develop for the iPad on a Mac. So if the scripts are strictly typed and some care is taken, is it possible for me to open the project on a Mac and publish it for iPad without requiring many changes?
i.e can identical scripts be used for PC Standalone as well as iPad?
Strict type for UnityScript, or just switch to C# to be on the safe side
All the other things have to do with graphics (you have to be insane with fillrate).
Avoid using onGUI at all cost.
And you will probably have to spend some time to re-do the UI and input functions.
But I think you are going about it wrong. Start with ipad as target platform. Then after you are done, just add some bells and whistles and release it on PC Mac. It makes more sense that way.
Yes as long as you do everything you mentioned above (static typing, changing Input methods and so on).
Also make sure your build is resolution independent, but I’m guessing you already take care of that when developing for stand-alone.
The iPad isn’t very strong compared to desktop platforms so you may need to decrease your graphics quality a bit and do some optimizations in order to run at a stable frame rate, but that will show in playtesting.
Unfortunately no. You need to get a developer account (around 100 bucks a year).
As for the GUI alternatives, you CAN use 2D Textures instead of OnGUI but depending on the type of game you’re going to make, it can vary from hard to impossible. Search for GUI managers on the internet, they offer some decent help if you don’t feel like setting up one of your own.
However, regarding iPad and iOS in general, I’ve seen after a year of development that even though OnGUI is heavy, it’s not OnGUI itself, as much as the textures used in it.
Every OnGUI call makes 2 drawcall passes, but if the texture rendered is a power of 2 or at least 16bits and doesn’t cover the entire screen you’re set to go.
The biggest problem on iOS devices is overdraw. If you manage to find a work-around on overdraw, your game will run relatively smoothly.
3 tips on iOS :
When you import models from other programs like maya or 3DS Max, check their properties on the inspector. Change their “normal” setting from Import to Calculate, and increase the Smoothing Angle to 180. This effectively reduces the vertices of your model by 50-75%.
When you import images that you are going to use as GUI, never use the default “True Color” or “16-bit” formats. Either go with power of 2, or if your texture doesn’t look good, go to advanced, and tweak each and every setting till you achieve the lowest size possible with the best quality possible. More often than not you’ll have to disable Mip Map generation, since it’s a completely useless feature for GUI elements.
Don’t set your goal to running at 30fps. Even if your game “usually” runs on 30fps but drops at times to 20 or lower, set your kFPS on your XCode settings to 20. (this is for iPhone, for iPad that syncs at 60, you have the option of setting a much higher kFPS limit, around 40-50).Running a little less smoothly with a constant frame rate is a lot better than having jump cuts from 30fps to 20fps that feel like lag spikes.
Thanks for the info. 2D Textures could be tricky since we need dialog popups that allow you to enter data into fields.
The “game” will essentially allow you to rotate the camera around a 3D object and click parts of it to enter information about it, saving changes to either a local or online database.
So what do you normally do for text inputs, buttons and things like that if you don’t use onGUI? (Aside from using 3D mesh “buttons”)
I don’t think you have any other alternatives in Unity besides OnGUI, 2D Textures and 3D meshes when it comes to GUI elements, although I’d be happy if anyone would correct me in this, cause I’m dying for an alternative.
Unity will be providing an upgrade on the GUI system, but it won’t happen until 3.5 so we’re waiting on that one.
What if we target iPad2 only? It has a little bit more grunt.
I guess if we are careful with the GUI it should be okay, there won’t be a lot going on with the 3D model in terms of textures etc, they will be very basic.
unfortunately , I believe most o people expect that a game be available on both ipad1 and 2, plus I think there is quite a bit of iPad 1 around still
if you optimize your asset you can push the iPad 1 pretty far , but well as other suggested you better start dev your app form the less capable device > ipad1, if you get a working version on this one the rest of platform will be no problem at all…
also perf are not cause of only One and unique behavior, but generally come form a cumuls of various things all together that cause lag or hiccup etc , so if you do have some heavy things , get them to fire up at a time in game where you are not in need of full perf can also help
well this is a wild adventure anyway ^^…but usually gfx asset will be where you get problem rather than code logic , unless you are doing very very bad things ^^
Sorry I didn’t really mention that this is more being used for an internal application than a game, so we can probably have control over whether iPad2 is a system requirement.
If we were able to do that, the extra performance of the iPad2 would be a significant benefit for things like onGUI wouldn’t it? It has the dual cpu, but the GPU performance seems improved as well.
(Talking worst case here, if possible I would like it to work on both, but I can see onGUI being required)
There won’t actually be heaps of things going on like you might get in a game (no AI, no enemies etc etc), so it might workout okay anyway.
