The Unity3D terrain engine is designed to work with platforms that can push high numbers of vertices. Soft bodies that would be used to simulate wind blowing in the trees and waving grass are available, but not recommended on the current generation iOS platforms with the exception of the iPad 2 (and later).

We can still create our own terrain using a 3D modeling program. If the 3D modeling program can programmatically create terrain, we need to make sure that it uses a relatively low number of polygons. If the 3D modeling program does not allow us to control the number of polygons, we can create the terrain object and then remove edges to reduce the triangle count.

An easy way to create a low polygon count terrain is to do the following:

Trees can be modeled quite easily in a cartoon or semi-cartoon style. If more realistic trees are desired, then we can use two intersecting (non-backface-culled) planes with an image mapped onto the faces, as shown in the following screenshot:

Tree and grass movements can be simulated on iOS using baked animation. Methods for creating foliage will be covered in more detail later.

It may sound easy, but we don't jump into making our level just yet; first, we need to review the information contained in the section, Planning efficient levels.

On the desktop PC platforms, Unity3D usually handles cutscenes through the use of a camera, facing a movie texture. However, movie textures are not supported on iOS devices. Instead, fullscreen streaming playback is provided. Unfortunately, the streaming playback suffers from a number of limitations, the worst of which does not support device orientation, so your cutscene may begin playing upside down.

This is clearly one area where Unity3D for iOS requires more work on the part of the Unity3D development team.

A potential alternative to using a movie for cutscenes is to use Machinima, which refers to the queuing of animations with the engine, rather than playing a pre-rendered clip. This is definitely not something for the faint of heart, as an effort was started in 2009 as a Summer of Code project to create a Machinima editor for Unity3D, but that project has definitely been stalled and may never be completed.

At this stage of Unity3D for iOS, we recommend using cutscenes only in games, where the addition of the cutscenes outweighs the cost of creating them.

iOS devices can play back only one compressed audio clip at a time. This means that if you want to play more than one sound simultaneously, you need to decide which of the clips should be uncompressed.

Given the limited memory available to games on iOS, it is likely that large uncompressed audio clips will cause our game to get memory warnings and even be forced to terminate by iOS. This kind of application crash can be very difficult to track down, so it is better to do some judicious planning and avoid it altogether.

Therefore, it is recommended that the compressed stream be used for the longest audio clip in a scene, such as background music, and all other audio clips be kept to the shortest duration possible.

The exception to this rule would be when doing Machinima (see cutscenes), where the entire sequence of audio will be consolidated into a single compressed track, where all of the events are queued to match.

iOS devices only support the forward rendering path. The Unity3D manual describes this path as follows:

As such, lights are relatively expensive to render.

For dynamic lighting, in the order of rendering cost from least to most expensive, we have the following:

In terms of shader lighting, in order of rendering cost, from least to most expensive, we have the following:

Lights can be configured as either lightmapped-only or as realtime-only with a configured degree of importance.

Configuring lights to lightmapped-only will cause them to appear only in the lightmap bitmap, and it will not have any dynamic lighting. This kind of lighting is appropriate where there is a requirement for an area to be lit, but not dynamically, such as those instances where a single dynamic light is the focus, or if we will be baking a scenery in the background (this methodology will be explained later).

Configuring lights to realtime-only is useful if you want to apply lighting to an object that will always be moving around. Moving objects should not be included in the lightmap, and they will never be marked as static.

Realtime lights can be assigned a degree of importance. They are as follows:

Important lights will always be rendered when visible. Unimportant lights are given lowest priority for rendering and may not be rendered. Automatic lights will also not always render, but are given higher priority than unimportant lights.

Rather than using dynamic lighting, lightmapping should be used, when possible, to render much higher quality effects with less bandwidth.

On desktop platforms, shadows would also be an important consideration, but on mobile platforms, dynamic shadows are supported. On mobile platforms, you will need to use lightmap textures.

Depending on their age, iOS devices can push between 10k and 30k vertices. The maximum number of vertices that the original iPhone can push is 10k, and the iPhone 4 can push 30k vertices. In addition, devices will slow down depending on the number of polygons that they need to render. Trying to push too many vertices or render too many polygons will result in degraded frame rates and choppy gameplay.

The FrameCounter, js script, shown as follows, can be attached to a game object that contains a guiText item to display a Frames Per Second (FPS) counter that can be used to gauge the performance of our game. Typically, gameplay is smooth until the FPS counter falls below 20. This is shown in the following code:

// Attach this to a GUIText to make a frames/second indicator.
//
// It calculates frames/second over each updateInterval,
// so the display does not keep changing wildly.
//
// It is also fairly accurate at very low FPS counts (<10).
// We do this not by simply counting frames per interval, but
// by accumulating FPS for each frame. This way we end up with
// correct overall FPS even if the interval renders something
// like 5.5 frames.
//
// You need to create a game object, add a GUIText to it
// and set the Pixel Offset so that the text appears on
// the screen
// This is the frequency at which the FPS are displayed
varupdateInterval = 0.5;
// This is the number of FPS accumulated over the interval
privatevaraccum : float = 0.0;
// This is the number of frames rendered over the interval
privatevar frames : int = 0;
// This is the time left time for current interval
privatevartimeleft : float;
function Start()
{
// Make sure a guiText exists on the game object
if(!guiText)
{
print ("FrameCounter needs a GUIText component!");
enabled = false;
return;
}
// Set the time remaining equal to the interval time
timeleft = updateInterval;
}
function Update()
{
// Subtract deltaTime from the time left
timeleft = timeleft - Time.deltaTime;
// Accumulate the FPS over the interval
accum = accum + Time.timeScale/Time.deltaTime;
// Add one to the number of frames rendered
frames = frames + 1;
// The interval ended, display the FPS and reset the
// counters
if( timeleft<= 0.0 )
{
guiText.text = (accum/frames).ToString("f2");
timeleft = updateInterval;
accum = 0.0;
frames = 0;
}
}

The following screenshots show how the game object will appear after you have added the Frame Counter (Script) in the Unity3D editor and what it would look like in a running game:

Characters animated using bones (skinned meshes) should have between 1 and 30 bones. A good compromise is to let minor characters have 10 to 15 bones, while major characters (such as the player character) have 20 to 25 bones. If only one skinned mesh is used, Unity3D has optimizations related to visibility culling and bounding volume updating. These optimizations are useful for games, where only one skinned mesh is needed for a player character (which is often the case).

Rendering performance can be optimized by atlasing textures that will commonly be rendered together. The following screenshot shows the image settings for a very small texture:

The small texture is used on all the spheres, as shown in the following screenshot. The spheres use different meshes with UVW-maps that project different sections of the same texture onto each sphere. In this case, the mapped texture would be referred to as the texture atlas:

This only works with static geometry or objects that are of the same mesh. Also, as previously mentioned in the section, Lighting, for pixel-lit models, if there are multiple lights illuminating the object, the number of draw calls required to render the objects will increase.

Cloth is unsupported on iOS devices, it can, however, be simulated through a baked animation. For example, using a reactor in 3D Studio Max will allow you to make a flowing cape for your character, but this cape will not collide with Unity3D rigid-bodies.

Using cloth on unsupported platforms is usually more trouble than it's worth the time spent figuring it out and adds only a marginal visual effect.

Having said that, one practical time to use a cloth animation is while making a flag blow in the wind, in an area unreachable by the player.

Unity3D can use code stripping to remove unwanted libraries from the engine. However, code stripping should be used with care. Stripping code may break your code, if you use certain functionality. Unity3D is not particularly careful when it comes to stripping, and it is assumed that you know what you are doing. If you set your stripping level too high, your game may simply crash when you run it on the iOS device.

The purpose of code stripping is to reduce the size of the application generated by Unity3D. However, using code stripping may limit your ability to use the .NET framework.

Because the built-in Unity3D support for writing to disk is limited, we make extensive use of the .NET framework for reading and writing game preferences. Therefore, we limit stripping code to strip byte code. If we re-implemented our preferences in a different manner that did not use .NET, then we could take advantage of additional stripping.

For legacy reasons, the classes and enumerations to access or describe specific iOS functionality begin with the prefix iPhone. It would be reasonable to expect that a future release of Unity3D will deprecate these items and replace them with iOS equivalents.

These classes and global variables are quite useful for determining which specific functionality is available on the device on which your program is running.

You can't have a game without at least one scene, even if you plan to make a very simple game such as a board game. Levels and their respective scenes should be planned ahead of time; nothing is more annoying than trying to retrofit sections into scenes.

Fourth consideration: Embellishment

Since, we want to keep the player interested, we can take advantage of several classic methods that require relatively little implementation effort. A great way to see how game developers use these classic methods on limited hardware platforms is to play older games.

Fog: Not such a great idea

Fog is one of the oldest tricks in the book. It is a classic that is used when game developers don't want to render something because it's too far away. It is also used when it may be obvious to the player that an object has vanished. The solution has been to obscure objects with fog.

Another factor that has led to the use of fog as an embellishment device is that fog adds ambience.

Particles make everything better

Particle effects will make your game seem more vibrant. They're great to:

• Add ambience

• Flag objectives

• Add sparkle

• Create explosions, vents, jets, even lasers

The following are two examples of how vibrant we can make our particles on iOS:

For performance reasons, there are several important things to note about particles on iOS platforms, which are as follows:

• There should be no more than 50 particles per system

• There should be no more than 50-200 particles on the screen at a time

• Particles should be small (because particle shaders use alpha testing, which itself has performance issues). For very small particle textures, it's best to use no alpha channel at all. We should also avoid additive shaders on particles as they contain large numbers of multiply operations

• Particle collisions should be limited; we can even write a script to disable the particle collider if the distance from the player is too far away for a collision to be noticeable or if there are too many particles on screen.

Atlas your textures: Share those materials

Textures that will be frequently rendered together should be consolidated into a single texture atlas.

A texture atlas is simply a single image file that contains multiple sub-images, such that different parts of the large image can be UV Mapped to texture different objects.

Typically related objects that should be atlased include terrain textures, foliage textures, and building textures.

Unity3D's static batching will result in meshes-sharing materials to be combined, so they can be rendered in one pass. In order to enable static batching, we need to make sure that the objects don't move and mark the objects as static in the editor.

The following is an example of a texture atlas that contains flowers and tree bark consolidated into a single image stored in a single file. This means that if trees and flowers that use this texture atlas are visible together, they will require only a single draw call to render. This assumes that they use the same material, which means they also share a shader:

We may also opt to add solid texture and alpha tested textures to larger atlases. This is practical if we have a building with lots of static windows, but also textures for the walls and floors that can all be rendered in a single pass.

Water makes things look bigger

Water features can be added quickly and easily.

The only thing better than water is water in motion, for example, waves on a beach or a flowing river.

To make a non-linear body of water (such as a river) flow, we simply need to give it a linear UVW map, as shown in the following image:

Once the texture is mapped, we can apply a UV offset to the texture of the object and the water will make it appear to flow smoothly, even around curved areas.

If an area looks bland, try adding a fountain or waterfall for some extra color. If water doesn't fit the level theme, we can add lava or radioactive ooze (or anything else that we can think of that flows).

You can fly

Giving the player the illusion of flying, makes your game environment more interesting. We could decide to grant the player a flying power with a time limit (there should always be a time limit, so that the power stays elusive and interesting). One way to make a power temporary is by adding trigger areas that cancel flying in zones that we have not prepared for flying. Using such trigger areas is ideal if there is something in the game story line that would cause the player to lose this special power (for example, the spell has only a small area of effect). Players always want to fly, but our game becomes too simple if they can do it all the time. So, it's a good idea to put a time limit on flights (15-40 seconds), and to only grant flying powers when the player reaches certain tokens.

In addition, the height at which a player can fly needs to be limited, such that they do not achieve a bird's eye view that would result in the frame rate dropping due to the amount of rendering needed or the scene being clipped due to the far clip plane. If we really want the player to achieve a great height with a bird's eye view of the world, we are going to need to implement some pretty fancy scripts to substitute parts of our scene, when the player achieves those lofty heights.

Broad views of great expanses are definitely not a strong point of Unity3D on iOS platforms.

Enough cannot be said about culling. Culling is so important that there are multiple ways to cull different objects and sophisticated software tools that include pre-processing of scenes to achieve maximum culling have been integrated into Unity3D.

Far clip

The far clip plane refers to the maximum distance away from the camera an object can be, before it will be clipped (not rendered).

It is important to adjust the far clip, so that it is far enough away that it does not clip your objects, however, it should be close enough that it does not do needless depth testing, which would slow down your processing speed.

Arguably, there is no reason to have a far clip plane because distance culling should take care of it but because, distance culling doesn't have to apply to every object in a scene, the far clip plane is the default.

The drawing library (OpenGL ES) also requires a far clip plane in order to process the image properly, an attempt to set the far clip to zero will result in only the background rendering. Conversely, setting the far clip to the constant INFINITY will result in a strange, cryptic, and unnerving internal error. It is, therefore, essential that the far clip be farther than the distance culling distances, but still reasonably close.

In the following image, items within the field of view are rendered. When item 3 exceeds the distance specified by the far clip plane, it is not rendered. If item 3 is viewed at an angle and part of it exceeds the far clip distance, part of item 3 will render and the rest of it will display the camera background. Imagine a parabolic dish where the center of the dish exceeds the far clip, the edges of the dish will still render, but the center will be clipped and show a background texture, color, or skybox as follows:

Distance culling is used to cull objects based on how far they are from the camera origin. Using layers in Unity3D, smaller, less noticeable objects can be culled before large objects. Distance Culling still complies with the far clip plane, so any culling distance farther than the far clip plane will always be culled. The far clip plane should be considered to be the absolute maximum distance any depth testing and geometry rendering should be done.

The following is a figure, demonstrating distance culling, when object 1 exceeds the culling distance set for its layer that it ceases rendering (It will not do anything fancy, it just vanishes. Therefore, it is crucial to make the distance far away, so the player doesn't notice the object disappear).

The following code should be applied to any camera we want to use with distance culling. Distances can be represented as any (floating point, >=0) number and should be less than the far clip plane: you cannot render any object farther than the far clip plane:

var distances = new float[32];
function Start ()
{
//Setting a value to zero will cause that layer to
// use the farclip
//User defined layers start at layer 8, which
// is distances[8]
this.camera.layerCullDistances = distances;
}
functionsetCullDistance(index : int, distance : float)
{
distances[index]=distance;
this.camera.layerCullDistances = distances;
}

Putting an object on the layer associated with the clipping distance will cause the camera to cull it, when it's far away. It is recommended that you use at least three distance culling layers: Near for pickups and enemies, Medium for scenery, and Far for objectives and terrain chunks.

Occlusion culling reduces the amount of required rendering computation time by caching the visibility of objects. While iOS devices have built-in dedicated vertex computation, hardware occlusion culling can still be beneficial because Unity3D can avoid passing invisible geometry to said hardware.

The following image demonstrates how occlusion culling is beneficial.

Imagine object 3 is a section of terrain and object 2 is a large wall that blocks the player's view of object 3. Finally, imagine object 1 is a small tree in front of the large wall. Since the tree doesn't obscure the wall, the wall is still visible. However, the wall is obscuring the block of terrain, so even though the terrain is in memory, it is not being rendered.

Occlusion culling is achieved by pre-computing PVS (Potentially VisibleSet), an array of bounds that cache the geometry, which should be rendered when a camera is facing a certain direction. Configuring and bounding zones and generating occlusion culling data should be the last step in making your game, as any change in the layout of your level will require that occlusion culling be computed again.

If you are experiencing problems with performance during testing, try reducing the far clip plane or adjusting your distance culling. You may also generate a quick preview of your occlusion settings by setting the view cell resolution very low.