While developing my current iPhone game I've encountered many design decisions and limitations that are important to consider for this platform. Some of these are obvious, such as needing to design around the iPhone's weaker memory and graphical power compared to a desktop computer, but others may not be so obvious. Even though my game is not yet finished or released I've already learned some good lessons including how I would do some things differently next time around. I decided to do a quick write-up here about some of the things I've learned so far. If you're interested in developing a game for the iPhone with the Unity3D engine you might find this useful. This write-up is mainly focused on game design considerations including some details of how I dealt with technical limitations.
One of the great things about the powerful Unity3D engine is that you can develop a game and build it for multiple platforms including the PC, Mac, Wii, iPhone and soon the Xbox 360 and more. But just because you can build the same game for all of these platforms doesn't mean it will run well on all of them, and it doesn't mean the gameplay and controls are designed well for each one. This may seem really obvious, but you need to design iPhone games differently from how you might design a PC or console game. First of all, I think the iPhone is best suited for casual games that people can pick up and play for only a few minutes at a time. There are some large scale and deep games for the iPhone, but really the platform shines for its casual games that can be played for 5 minutes while you wait for the bus.
1. Game Controls
Games with simple controls that don't take long to learn are ideal for the iPhone. I've aimed to do this with my Bank Shot game controls, but if I were designing it again from scratch I might reduce the functionality in order to have even less buttons. Because my game provides 4 different powerup abilities, I figured that 4 easy-to-click buttons would be the best way to activate those powerups. However, if I were going back I might design the gameplay so that those powerups are triggered in a different or more automatic way without requiring extra controls and GUI elements. I am a big fan of games that offer simple controls in general, but it is not always easy to provide a lot of functionality without using more complicated controls. Games with more compact gameplay and less functionality will likely require simpler controls that are not only easier to develop, but also easier for players to pick up and play without frustration. Does this mean you shouldn't make large feature-rich iPhone games with complex controls? No, but I think the iPhone is definitely better suited to games that have a very focused gameplay with simple controls that fit the device.
To further illustrate this point, consider that the iPhone doesn't offer you any standard controls that every player can use. There is no keyboard or mouse, and there is no controller. So for instance, a complicated RPG game that gives the player many abilities to use might normally provide keyboard shortcuts on a PC so the user can easily access each ability with 1 click. But with the iPhone you can't do this elegantly if there are too many options. The touch screen and tilt functionality are the developers main tools for building controls on the iPhone. While I'm not a big fan of the tilt-control style games, I do like the freedom of using a touch screen. The problem is that using your fingers on the touch screen takes up valuable screen space that could otherwise show gameplay. You also need to ensure the controls can be used by both large and small fingers and you need to take into account that the player's hands can get in the way of the display as they play. So clearly games with fewer controls are better suited for the iPhone. There is definitely an art to creating new and interesting ways to control games. This can be an interesting challenge that many developers enjoy, but it is not always easy. In my opinion simpler controls are a good goal for any iPhone game. At the very least, designing your control scheme and GUI layout with these considerations in mind should be a top priority when designing your game.
2. Performance Optimizations - Draw Calls
Of course performance is another important consideration when designing an iPhone game. While there have been some pretty graphically impressive 3D games released for the iPhone already, they definitely weren't easy to create. The developers would have been using as many tricks and shortcuts as they could to squeeze as much power out of the iPhone. And while the Unity3D engine does run quite well in 3D on the iPhone, there are definitely some tricks that are necessary for getting better performance. An obvious metric to keep low for better performance is the polygon count of 3D models, but even more important is the number of draw calls. Each object in Unity3D requires at least 1 draw call per frame to display it. Of course, if you are using some shaders or other fancy effects each object could require more than 1 draw call. This means that every button, ball, wall, 2D effect, text box, GUI element or other object that is visible to a game camera will add at least 1 draw call per frame. So it's easy to see how draw calls can stack up quickly. On a modern PC with a decent graphics card, you can have scenes with hundreds of draw calls per frame and have it run very smoothly. But considering that a good target for draw calls on an iPhone 3G is around 15-30 before the framerate starts to suffer badly, you can see why this is one of the main things to optimize for better performance.
Luckily there are a few standard tricks that can help reduce your draw calls while allowing more objects in your scene. In Bank Shot I have around 20 GUI HUD elements on the screen at all times. These include buttons, menu items, text boxes, containers and other 2D graphics. Most of these are dynamic elements that move or that are clickable and so they need to be individual objects in the game. By adapting a script that I got in the Unity3D forums called GUIManager (another great thing about Unity is its large and helpful community of developers) I can combine all of these GUI elements into a single quad object at runtime that requires only a single draw call. The trick is that each GUI element has to share the same material/texture. Using an old trick sometimes called spriting, I've put all of these GUI graphics into a single PNG image and assigned coordinates within that image for each GUI object. By doing this and using the GUIManager script I've turned 20+ draw calls into 1. Unity3D for iPhone also has a new feature that does something similar for 3D objects automatically as long as they share the same material/texture. So by using these tricks and grouping objects together with shared materials/textures you can greatly reduce draw calls.
Another thing to be aware of with draw calls is that using in-game lighting will add another draw call for each light affecting an object. Shining lights on objects makes them seem more 3D and adds more depth to them, but it can easily double the number of draw calls in a scene. So using dynamic in-game lighting on the iPhone is not recommended unless you have very simple game scenes. Luckily there is another trick familiar to developers that was used a lot with older hardware generations called texture baking. In any modern 3D modelling program (which you will be using to make your 3D models before exporting them into Unity3D) you can setup lights that shine on your models. When you've setup all your lights you can then use the texture baking functionality of that modelling program which will "bake" the lighting effect into the texture images of your model. Now you can export your 3D models and use them in Unity3D without any in-game lighting and they will still look shaded with light. The downside to this trick is that the lighting angles are static and can't move or change position in-game, but that's a decent compromise in order to make efficient and better looking 3D games for the iPhone.
3. Performance Optimizations - Gameplay Mechanics
While draw calls are a major focus for iPhone performance, complex code systems can also slow down iPhone framerates quickly. In general you should optimize all code modules and design things in the most efficient ways possible to ensure your game runs adequately. Games with really computational-heavy code can really slow down your game. Things like path-finding, complicated AI, complex procedural systems, or lots of interacting physics objects can eat up CPU cycles fast. So sacrificing functionality and complexity for a smoother gameplay experience are also important things to consider when designing your game. This is not to say you can't have complicated code systems on the iPhone, but it's definitely something to be aware of for performance reasons.
When I was first planning out Bank Shot I considered implementing a messaging system for objects to interact with each other by sending event messages. This is a common way to encapsulate different code systems while allowing game objects to interact easily without knowing about each other. This is a great way to organize code and maintain a large game system, but it is not especially efficient. First of all, you wouldn't use it for messaging events that are very time sensitive. Things like synchronizing states (for instance for network programming) or for polling a game weapon about how much time is left to finish reloading it (which could be milliseconds) are not going to be reliably maintained with messaging. But it is useful for things that aren't extremely time sensitive like telling a game object that the player has died, or in my game I could message a game controller when a ball is scored. If I were making this game only for the PC I would definitely use messaging because it makes things a lot easier code-wise and the resources it uses to broadcast messages to multiple objects is negligible for a powerful system. But on the iPhone messaging uses up valuable resources and can be wasteful. When developing for memory and CPU limited devices like the iPhone you want to be as efficient as possible. So instead of a messaging system I opted for a more direct approach of simply calling functions directly on my game controller. This means that objects need to know more about each other and maintaining the code becomes more complicated. Again, this doesn't mean that you can't use messaging on the iPhone. In fact, the GUIManager I am using in Bank Shot does use messaging to communicate with each GUI element. But this is just a small and confined part of my code, if you are thinking of using messaging for your whole game system you will likely be able to save resources and be more efficient by using alternative methods. In order to squeeze as much performance out of the iPhone it is worth considering such alternatives at the very least.
4. Download Size
Another issue to be aware of for iPhone games is the download size of the full game. Apple forces any App larger than 10Mb to be downloaded through WiFi (or through your computer and later transferred onto your iPhone device). This is not a huge issue, but it could make a difference in the number of people willing to buy and download your game. I personally don't have any detailed statistics proving to what degree this is true, but I have read a few articles suggesting the trend. If your game is below 10Mb in size, people can download it over their phone's cell network from anywhere. If they need a proper WiFi connection that just becomes one more step the person needs to take in order to get your game. It's not hard to see why this can make a difference, but I'm not sure how important it is overall. In the end it is just another issue to be aware of when considering your game design. More complicated or more graphically intensive games will likely be larger in size. If your goal is to make a game that is as approachable as possible to as many people as possible, you will want to keep your game size below 10Mb.
In the end these are not hard rules, they are just observations that I've made during the development of my first iPhone game. Even if you don't agree with some of my suggestions, or if you have a different approach, it is still good to be aware of the issues I've listed and consider them when designing an iPhone game. At the very least it is clear that developers will need to make some compromises and hard design decisions when planning an iPhone game. If you have any suggestions, corrections or other feedback please feel free to leave a comment below.