Packaging gotchas

You have your game running fine in the editor, and you finally come to start testing it on a platform. Life is good and surely you must be ready to deploy; sadly, this is just the point where your next journey begins.

Actually, shipping your title brings to light a whole raft of new challenges. What follows is a list of tips, tricks, and gotchas I've encountered while working with many different teams and events:

Just because it runs in the editor DOES NOT mean it will run on a platform

I've come across too many teams that finish their game in the editor without even trying to run it on at least one target platform. This can cause serious rework later on as you may find that the code will simply not run on some platforms.

Another issue that can sometimes rear its head is when you have written code that depends on the editor but you have not placed it in the Editor folder. When you run it in the editor, it will work fine, but on a platform it will either crash or give you a spurious message (worse on some platforms than others.)

If you are targeting the Web, then beware of the limitations of deploying to that platform.

The best advice is to build to a platform at regular intervals, and make sure that it actually compiles and will deploy to a device.

Just because it works for one platform DOES NOT mean it will work for all

Unity obviously supports many different platforms, and each has its own peculiarities. If you mean to target multiple platforms, always check periodically whether you can build and deploy to the various platforms. It doesn't have to be too often, just find the right balance for you. See whether you can automate it through the Unity command-line tools.

What is often missed is how each platform behaves; Windows/Windows Phone/Windows 8 all run on the NET platform directly; however, iOS/Android/Mac/BlackBerry all run using the mono framework (which is an interpretation of .NET for those platforms). They are both different in their own ways and handle similar situations differently. Don't assume just because it works for one, it will work for all. This is true for both JavaScript and C#.

As stated already, the Web is just different from everything else.

For maximum exposure, try to focus on the lowest common denominator

It's always attractive to build to the highest resolution and target really high spec'd machines; however, this is going to really limit your target audience.

When working with mobile projects, it is better to test and target minimum specifications or devices, and make it run acceptably on that device. Any higher spec device, and it will just fly.

If you are feeling adventurous, then build your game to switch on higher spec features/assets when a high spec machine is detected. However, this will also potentially increase the size of your final download, which may also put your game out of budget for low spec devices.

It is a hard challenge and requires a different approach to tackle for each game you make, so think hard about it.

A last resort (which most developers shy away from) is to build two versions (a PRO HD version and a Basic low res version). There is no one right answer, so just pick a path that fits your game, budget, and time.

Assets from the store can be your savior; they can also be your downfall

Be aware of what assets you are downloading in the scope of your title; check what platforms it supports and make sure it's maintained.

There have been quite a few horror stories about not being able to move to platform X because the plugins won't even compile, and finding an alternative is very difficult because of the particular plugin that is integrated in a project.

It all comes down to balance—ask why you are using a certain asset, make sure you understand why you are using it, and assess its long term fit before committing yourself to it.

Beware of the platform requirements

Certain platforms have very specific requirements when it comes to games and/or apps. Some have limits on project sizes, others (such as Windows Phone) have certain operating restrictions (Windows Phone has a hardware Back button, which must always "go back" for example).

Others have restricted device capabilities or require enforced policies to be in place before you can target certain markets.

In the end, it comes down to assessing your titles fit for a certain device/market or operating system, and making plans before you go all-in to adopt it. Make a plan, understand what you are getting into, and then move forward.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
13.58.121.8