What is it?

An end-to-end multiplatform solution for Unity!

Battle-tested during the development of the quadruple-platform game Snuggle Truck, and used extensively in multiple shipped titles, this tool allows for configuration of specific per-platform settings for all types of devices. Need to change button sizes for iPhone Retina and swap a texture for iPad? Not a problem. Need to replace text on a per-platform basis or change fonts based on the platform? Easy. Need to create a resolution-independent UI that works on all major aspect ratios, with edge/corner pinning? It's a breeze!

Note that the toolkit allows for both runtime detection of platform and build-time detection of platform, as well as emulation of platform within the Unity Editor. That that means is that Universal builds can detect platform on the fly and make changes on Awake(). Additionally, assets you would like to be removed from one build but included in another build can be stripped at build-time.

Tell me more!

The idea of ‘Code Once – Deploy Everywhere’ has been a Unity development mantra since its inception. With most of the tough porting work handled under the hood by Unity Technologies, porting games has become largely about producing a great user experience. Maintaining a quality product across multiple platforms means resolution independence and support for major aspect ratios.

It means an understanding that writing “Click here” in a mobile game is a huge turn-off for users. It means that standalone users need a quit button while Android users use the hardware back button and iOS users don’t need a quit button.

It means that the play button on Retina iPads needs to be scaled up 2x compared to non-retina devices. It means handling all of these platform-specific changes in a graceful, simple way, with a live preview of each platform right in the Unity Editor.

THAT is what Multiplatform Toolkit does best!

So how does it do all of this? Well, lets walk through a quick example.

Example Scenario 1:

Let’s say you wanted to scale up a button 2x on iPhone to be large enough to hit with our big fat human fingers. The first thing we need to do is attach the PlatformSpecfics component to the button’s transform. See below! (Fig. 1)

Fig. 1

Then, in the inspector we can choose to tag the object with the appropriate platform-specific data. In this case we want to pick Scale by Platform. (Fig. 2)

Fig. 2

Hit the plus sign and choose iPhone as your platform. In our example, the button already has a (1,1,1) scale, and on iPhones we want it to be (2,2,2). You can manually input the target scale for iPhone or use the get and set buttons to either grab the current value from the transform or apply the selected value to the transform. These help avoid having to copy paste values manually, especially when using the scale tool to eyeball sizes. Make sure to apply the (2,2,2) scale to iPhone Retina as well! It’s up to you whether you want this to apply to iPhone 5. It’s as simple as adding it as a third option. (Fig. 3)

Fig. 3

Now our button will scale up 2x on iPhone platforms. What? You don’t believe me? Well then, let’s test it within the Unity editor with our handy platform emulator. Go to the Window menu -> MultiPlatform Toolkit -> EasyPlatform. An editor window will appear. Dock it for easy access. This tool does one thing: lets you pick which platform you’d like to emulate in the Unity Editor. In our case, we want to pick iPhone and then hit Play in the Unity Editor. (Fig. 4)

Fig. 4

The platform-specific changes will occur on Awake() and you won’t need to spend minutes doing actual builds to the hardware to test out your changes. It only takes seconds! (Fig. 5)

Fig. 5

This is one tiny example of the ways MultiPlatform Toolkit saves hours upon hours when dealing with platform-specific changes. Let’s quickly dig into another code-centric example.

Example Scenario 2:

Let’s say you wanted to load, at runtime, a small, compressed texture for use as a backdrop in your menus on iPhones, while you wanted to load a huge, 2048x2048px screen backdrop for your Retina iPad and Standalone PC/Mac builds. Easy! The quickest, most seamless way to do this is to Resources.Load() your texture from disk and pick the right one. MPTK makes it as simple as this:

if(Platforms.platform == Platform.iPadRetina || Platform.platform == Platform.Standalone) { //iPad 3, iPad 4, and PC/Mac/Linux
  //load the huge texture
  myRenderer.sharedMaterial.mainTexture = Resources.Load("backgrounds/hugeTexture");
} else { //All other platforms
  //load the tiny texture
  myRenderer.sharedMaterial.mainTexture = Resources.Load("backgrounds/tinyTexture");

Just remember to un-reference your Texture2D from your Material asset in the scene so the scene doesn't try to load the high res texture on a low-end device. Easy!

Customers have told us that the more they use MultiPlatform Toolkit, the more they wonder how they got by without it. If you’re doing any kind of Unity project that involves publishing to multiple targets, feel free to check out our product. We developed it because we needed it for our own games and realized it would be useful for others!

Tutorial Video / Demo!


What do you get?


A component that stores all per-platform information and applies it with ease. All stock platforms are supported (iPhone, iPad, Android, Standalone, Webplayer) as well as custom platforms (Demo build, Press-only build) and major aspect ratios. Also includes a helper tool called EasyPlatform that allows you to simulate/emulate different platforms within the Unity Editor without needing to build to the device.


An automated granular build process. Operates as a one-button menu item for building to different platforms. It scans scenes for platform-specific changes and assets and applies them at BUILD TIME to achieve optimal stripping! If you're trying to stay under 20mb for iPhone, you'll appreciate the flexibility of having PlatformSpecifics and BuildProcess working to your advantage.


Also included are a couple of dependencies and usability extras that are needed for this pipeline's operation, such as AspectPerfect - A tool that automates the process of scaling quads to the proper aspect ratio of a texture, making working with sprites very simple... And RenderQueueSorter - A tool that helps avoid sorting issues in 2d games by adding the ability to hand specify render order.

Any requirements?

Unity Pro is required for BuildProcess support! We utilize a custom BuildPipeline, which is a Pro-only feature. If you're not using the BuildProcess but only want to use PlatformSpecifics, Unity Pro is not required. The functionality that is lost with Unity Free is the ability to build from code, which powers the BuildProcess class, but is not required to run Multiplatform Toolkit!

*Fully tested with Unity 3.5 and 4.0!


Getting Started (General)

So you've got a sweet game, and now you need it to work on multiple devices or at multiple resolutions. You've purchased the MultiPlatform ToolKit and are wondering how to get started. Here's what you do:

  1. Import the MultiPlatform ToolKit into your project by installing via the Unity Asset Store.
  2. Find an object in your scene that needs to be positioned, scaled, or changed in some way depending on the platform.
  3. Select the item in the Heirarchy and go to the menu bar and choose "Component -> Scripts -> Platform Specifics". This will add the PlatformSpecifics component to your object. This is the container that stores all per-platform information.
  4. Fill in the details of the change you'd like to make and assign them to the platform of choice.
  5. Go to the menu bar and choose "Window -> MultiPlatform ToolKit -> Easy Platform"
  6. A small window will appear. This is the EasyPlatform platform emulator. It lets you emulate a certain platform from within the Unity Editor. Dock this window somewhere on-screen for handy access.
  7. Choose the platform you'd like to preview from the pulldown list in EasyPlatform and hit the Play Mode button in Unity to test out your game and preview the changes you've made. You can also use the "Apply To Scene" button to preview the changes without needing to be in Play Mode.
  8. At this point, your changes are complete and will take effect in your build.

Important! Per-aspectratio vs Per-platform

iOS devices use scale and position "per platform" while every other platform uses "per aspect ratio"! That's because there's a very limited number of iOS device resolutions / aspects and we've broken down iOS into very distinct platforms for you (iPhone, iPhoneRetina, iPad, iPadRetina, iPhone5)

See tutorials 1 and 2 below for more info.

Setting up PlatformSpecifics

PlatformSpecifics does quite a few things and has lots of buttons. What do they all mean? Well, let's investigate:

  • Upon adding a PlatformSpecifics component to a GameObject, you'll see the options available. There's Restrict to Platforms, Materials, Local Scale per Platform, Local Scale per Aspect Ratio, Local Position per Platform, Local Position per Aspect Ratio, Fonts, and Text mesh text. Lots of options!
  • Opening up one of these options, you'll see an "Add Default Entries" button that will pre-populate one of these options with a standard set of platforms. You can set these default platforms on the line that defines 'defaultPlatforms', near the top of PlatformSpecificsEditor.cs
  • Hitting the blue (+) sign button will add a single entry to the list and further clicks on the blue (+) sign button will add additional platforms.
  • The gray up and down buttons will move an entry vertically up and down the list of platforms.
  • The red (-) sign is used to delete an entry from the list of platforms.
  • The 'Get' and 'Set' buttons allow for easy swapping of values in the options fields of a platform. For example, you can position an object in the scene view exactly as you'd like it for iPhone and then hit the 'Get' button to retrieve the value from the Transform component in the inspector and auto-load it into the field you've selected. 'Set' on the other hand will apply a value to the Transform so you can apply that data to the selected GameObject.

Tutorial 1 - Positioning a UI element on iPhone vs iPhone Retina vs iPad

Let's say you wanted to position a box in the upper left corner of your screen on your iOS game which runs on iPhone, iPhone Retina displays, and iPad. Here's how you'd do it:

  1. In Unity, switch your Game view resolution to 'iPad Wide (1024x768)' assuming we're working in a landscape orientation.
  2. Position your UI element into the upper left corner of screen space. Note that the exact world coordinates to position the element into the upper left corner depends on your camera settings.
  3. Add a PlatformSpecifics component to the UI element GameObject by going to the menu bar and choosing "Component -> Scripts -> Platform Specifics".
  4. In the Inspector, under PlatformSpecifics, open the Local Position per Platform section and hit the blue (+) button to add a new entry.
  5. Choose iPad from the platform pulldown.
  6. Hit the 'Get' button to store the position data for iPad.
  7. Hit the blue (+) button again to add an additional platform.
  8. Choose iPhoneRetina from the platform pulldown.
  9. Change your Game view resolution to 'iPhone 4G Wide (960x640)'.
  10. Re-position the UI element to be in the upper left now that we've changed the aspect ratio by showing the iPhone Retina screen size in the Game view.
  11. Hit the 'Get' button next to your iPhoneRetina entry to store the position data.
  12. Lastly repeat the steps above to add your third and final platform, which would be iPhone. Make sure to change your Game view resolution to 'iPhone Wide (480x320)' when positioning.
  13. Feel free to use EasyPlatform to test out your individual changes per platform, which saves testing iteration time by skipping the step of building to all 3 devices just to test if your positioning is correct. See #5 of Getting Started for more information on how to use EasyPlatform.
  14. Note: The default scene that ships with the MultiPlatform ToolKit shows this exact example in action, with the green square in the upper left of the screen.

Tutorial 2 - Scaling a background to the correct width on Android or Standalone

Let's say you wanted to have a background plane behind your non-iOS game (Android or Standalone for example) and it should stretch from the left edge to the right edge of the screen, but your game could be played at 320x240, or 640x480, or 800x600, or one of a million other resolutions. Well, most resolutions fall under 5 different aspect ratios:

16:9, 16:10, 3:2, 4:3, or 5:4 - (Check out this handy resolution chart!)

Thankfully we provide support for those 5 aspect ratios as well as some really wonky Android resolutions that Unity Android lists as common resolutions. We've also made it super easy to add additional custom aspect ratios in case you're working with offbeat hardware. So, let's walk through the process of setting up resolution-independent positioning, very similar to Tutorial 1 but outside of the iOS space.

  1. In Unity, switch your Game view resolution to the '16:9' resolution.
  2. Position your UI element into the upper left corner of the 16:9 screen space. Note that the exact world coordinates to position the element into the upper left corner depends on your camera settings.
  3. Add a PlatformSpecifics component to the UI element GameObject by going to the menu bar and choosing "Component -> Scripts -> Platform Specifics"
  4. In the Inspector, under PlatformSpecifics, open the Local Position per Aspect Ratio section and hit the blue (+) button to add a new entry.
  5. Choose Aspect16By9 from the pulldown.
  6. Hit the 'Get' button to store the position data.
  7. Hit the blue (+) button again to add an additional aspect ratio.
  8. Choose Aspect16By10 from the platform pulldown.
  9. Change your Game view resolution to the '16:10' resolution.
  10. Re-position the UI element to be in the upper left now that we've changed the aspect ratio to 16:10 in the Game view
  11. Hit the 'Get' button next to your Aspect16By10 entry to store the position data.
  12. Lastly repeat the steps above for any additional aspect ratios, including the 1024x600 and 800x480 custom sizes if you are trying to support those sizes specifically for Android.
  13. In order to emulate the visuals for each aspect ratio, just change the Game view resolution to an aspect ratio of your choice and hit Play mode in Unity, and the changes will take effect. Note that EasyPlatform should be set to Standalone or Android in order to emulate the different aspect ratios.

Preparing the Build Pipeline

You've set up your scene to use different PlatformSpecifics and are ready to do a real on-device build. You'd like to try out your Mac build, your PC build, your iPhone build, your Android build, etc. We first need to edit BuildProcess.cs so it can cater to your specific needs.

  1. Open up BuildProcess.cs
  2. Follow the comments within the document and look for areas noted with "CHANGE ME!" Let's outline some of the details below.
  3. The first mandatory change involves filling in the paths to the scene files used for each build. Near the top of the file is a static string array called standaloneScenes. This is the array of scenes that is passed through the build pipeline during a Standalone build. Normally the Build Settings dialog (under File -> Build Settings) holds this information, but since we want to automate the build process from end-to-end, we need to manually set up these lists of scenes in case we'd like certain scenes to be included on certain platforms and not on others. Note that the data stored in the Build Settings dialog will be disregarded.
  4. Next, fill in the bundle identifier if deploying to Android or iOS.
  5. Below the bundle identifier, set up the name of your game and how you'd like it displayed on that certain platform. For example, your game might be called "GameName" but on iPad, it's "GameName HD"
  6. You're all set! Save and close BuildProcess.cs
  7. In order to run a build, go to the menu bar and choose Window -> MultiPlatform ToolKit -> Build -> Build Android or whatever specific platform you're looking to build. You can also choose a Debug build from the Debug menu under the Build pulldown.
  8. Builds are placed by default in your project folder, along side the Assets folder, or inside a Builds folder if it exists in the project folder. Feel free to change this directory by modifying what is returned by GetBuildDirectory() in BuildProcess.cs.
  9. Note: During the build process, temporary scenes are created as the scenes get modified before sending through the build pipeline. If an error occurs mid-build, you may see some scenes that haven't been cleaned up since the process was halted in the middle. If you see any scenes named scenename_temp, these are your original, untouched scene files and should not be deleted. In case of an error during the BuildProcess, the safest thing to do is revert via AssetServer or any other versioning system you might be using (SVN, Perforce, etc). If you're not using any versioning on your project, remove the scenes that don't end with _temp and rename the scenes to their original names, removing the _temp suffix.

Tutorial 3 - Removing elements from your game and changing text based on platform

Let's say your Standalone PC/Mac game contained a level editor, but due to time or scope reasons, you wanted to leave the level editor out of your mobile versions. We'll need to make sure the button in the main menu is removed and that the scene itself is not included in the mobile versions of the build. In addition, there's some text in the game that talks about the level editor, but instead of removing it, we want to swap that text to say that the level editor is available *only* on the PC and Mac, to avoid any confusion. MultiPlatform ToolKit to the rescue! Here's how we do it:

  1. In Unity, select your GameObject that acts as a button to load up the Level Editor.
  2. Add a PlatformSpecifics component to the button GameObject by going to the menu bar and choosing "Component -> Scripts -> Platform Specifics".
  3. In the Inspector, under PlatformSpecifics, open Restrict to Platforms section and hit the blue (+) button to add a new entry.
  4. Choose Standalone. Now the item will remain only if the platform is Standalone, and will be destroyed if it's any other platform.
  5. Find the text that talks about the level editor functionality. Make sure that the text object being used is a TextMesh. If the text is being presented to the screen using a different type of text class, see the Custom Text Compatibility section for more information.
  6. Add a PlatformSpecifics component to the text GameObject and open the Text Mesh Text section.
  7. Add an entry for each of your supported mobile platforms and copy in your explanation text, such as: "Sorry, the Level Editor is only available on PC and Mac!"
  8. Lastly we'll want to ensure that the level editor scene is not included in the mobile builds. Assuming your level editor was built as a separate scene file, we're going to edit our BuildProcess.cs file to specify the exact scenes to be included per-platform
  9. Open up BuildProcess.cs and navigate to the static string arrays near the top of the file, under standaloneScenes. If you're doing an iPhone build, edit the iPhoneScenes array to be something like:
    static string[] iPhoneScenes = new string[] { @"Assets/Scenes/gameScene.unity" };

    In this case, we're assuming that the iPhone scenes array should not include the level editor scene, while the standaloneScenes array contains it.
  10. That's it! Now Standalone builds will contain the level editor scene, the level editor button, and text specific to the level editor, while the mobile versions will contain no level editor scene (and thus have a smaller build size), no level editor button, and text explaining that fact to the user gracefully!

Tutorial 4 - Preventing certain code from executing on one platform

Let's say you wanted to have a class that only ran on iOS, for example. Let's see how we'd do that:

  1. Unity actually supports this out of the box and part of the code within the MultiPlatform ToolKit actually depends on this functionality. See the Platform Dependent Compilation section of the documentation for details.
  2. Specifically for our example, any code wrapped in the following code will be stripped at compile time unless it's an iOS build or being run in the Unity Editor:
    //code goes here
  3. Note that the UNITY_IPHONE and UNITY_ANDROID defines exist when in the Unity Editor. If you want to exclude the editor from running the code, use a define statement like the following:
    //code goes here

Tutorial 5 - Material/Texture swaps per-platform

Let's say you wanted to use a high resolution texture on your Standalone PC/Mac build but use a smaller version for your iPhone build. Let's investigate how to swap textures, as well as some notes on ways to optimize memory usage.

Texture swapping using linked Materials

Below we will investiage a way to swap simple materials based on platform:

  1. In order to do a texture swap per-platform, add a PlatformSpecific component to your GameObject that contains the Renderer component.
  2. Open up the Materials option and click the blue (+) button to add a new platform. Choose iPad.
  3. Drag in your iPad material with the iPad texture linked into the material.
  4. Hit the blue (+) button and add a new platform. Choose iPhone.
  5. Drag in your iPhone material with the iPhone texture linked into the material.
  6. You can test the texture swap by using EasyPlatform to emulate the platform and entering Play mode in the Unity editor. See #5 of 'Getting Started' for more information on how to use EasyPlatform.
  7. Known Unity quirk: Unity doesn't currently support a way to ensure that a linked texture is *not* loaded into memory upon loading a scene. All textures/materials linked to an active resource in a scene will be loaded upon scene load or instantiation of a prefab. If you're using MultiPlatform ToolKit, for example, to swap from iPad textures to iPhone textures and you're using a universal build, both textures will be loaded into memory if you use this method. See the "Memory conscious texture swapping using Resources" section below to solve this issue.

Memory conscious texture swapping using Resources

Since Unity loads in all resources linked into an asset through a public reference, any Texture2D linked to a Material file will get loaded on scene load. In order to pick which texture we want BEFORE the textures load (and thus, memory/RAM is used up, we must load textures on demand using Resources.Load(). We use this extensively for large backgrounds and major art pieces of the game (title screen, backgrounds of level select, etc). Here's how to do it:

if(Platforms.platform == Platform.iPad) { //ipad 1 and 2
     //load a new texture specific to ipad1/2
     myRenderer.sharedMaterial.mainTexture = Resources.Load("images/ipadTexture");
} else if (Platforms.platform == Platform.iPadRetina) { //ipad 3
     //load a new ipad3 texture
     myRenderer.material.mainTexture = Resources.Load("images/ipad3Texture");

Finally, you'll want to make sure your material has no texture linked into it, so when the scene loads, on awake, this code runs and picks the proper texture to link in.

Atlas swapping

Sometimes you can't get away with simply swapping Unity Materials and need to change around which sprite atlas you're using. Since MPTK doesn't particularly know about your specific atlassing setup, we do not have a generic way to swap atlasses. We do however recommend you use 2D Toolkit, which provides an easy platform-based atlas swapping mechanism.

If you are using NGUI, it appears that a package called Retina Pro will add similar support for atlas swapping. If you are using a different atlassing/GUI system in your project, it's up to you or the tool's creator to add support for atlas swapping, as these are 3rd party solutions with very specific, proprietary solutions, which MPTK could not begin to generalize across all situations.

Tutorial 6 - Anchoring elements to the screen

Let's say you wanted to have a UI panel anchored to the left side of your screen and didn't want to reposition it for every platform or aspect ratio. The latest version of MPTK added a pinning feature to accomplish exactly this.

  1. In order to anchor a transform to and edge or corner, add a PlatformSpecific component to your Transform.
  2. Open up the Anchor Position option and click the blue (+) button.
  3. Drag in your primary camera into the Camera field
  4. Go down to the Alignments section and choose your pinning options. For upper left, pick Left, then Top.
  5. Test out your positioning and adjust from there. Feel free to modify the position offset field to offset your object a certain number of pixels or percentage of screenspace from its default location. Note that percent is a float from 0 to 1. The CenterX and CenterY checkboxes can also be turned off to let MPTK auto-position your element into the corner/side based on a radius calculation.

Compatibility and Known Issues with 2D Frameworks

The MultiPlatform ToolKit has been tested with SpriteManager2, NGUI, 2D Toolkit, and EZGUI with minimal friction. If your 2d framework works with Transforms in the scene hierarchy that can be scaled and positioned at any time, then it's definitely compatible with the MultiPlatform ToolKit. If you are still trying to work with the cumbersome UnityGUI system (GUITextures, GUITexts), you will have a tough time with multiplatform development, and this package will not help you with that. UnityGUI is unfortunately beyond repair for multiplatform deployment without rewriting your GUI for each platform and aspect ratio. Here are a few things to consider when dealing with 2d:

  • Known Issue: The custom Text classes in 2D frameworks such as SpriteManager's SpriteText are not supported out of the box. For more information, please read the Custom Text Compatibility section.
  • Known Issue: Watch out for swapping materials when using atlasted textures! Depending on the atlasing software and how the atlas is generated you might not be able to use MultiPlatform ToolKit to do the swapping.
  • Known Issue: Using things like EZLayout or checking Pixel Perfect in SpriteManager2 will of course override any positioning or scaling done by the MultiPlatform ToolKit. Same goes for the "Normalize Scene Sprite Scales" box in the ex2D sprite toolkit.

Compatibility with NGUI

Since I get a ton of support requests asking specifically about NGUI compatibility, I figured I'd address that specifically.

MPTK works great with NGUI. There are a few items that both MPTK AND NGUI handle, so you don't want to have a value being overridden in both tools, and then one overrides the other, like telling NGUI to pin a GUI element to the left side of the screen but you have MPTK telling it to move to the right side. Just obvious stuff like that - the two products are totally compatible.

NGUI uses quads and transforms and avoids the use of UnityGUI, therefore it is compatible with MultiPlatform ToolKit. I've just tested it and found that there are no errors with having both toolkits in one project. The following is a list of features that will overlap with functionality that NGUI handles:

  • Using the UIAnchor script will override MPTK position changes
  • Using PixelPerfect will override the MPTK scale changes
  • MPTK cannot change text of UILabels directly
  • MPTK cannot change materials on a quad directly due to the fact that UISprites don't use a unique material, they choose a subsection of a texture atlas.

Compatibility with text replacement

The MultiPlatform ToolKit supports replacing text contents on TextMesh objects as well as swapping fonts and font materials. For example, if you want your mobile versions to say "Tap Here!" and your Standalone platforms to say "Click Here!", the Text Mesh Text field will allow you to swap out text for any platform. Or if you want to swap from 60pt font to 24pt font depending on your screen resolution, the toolkit supports that.

Out of the box, the toolkit only supports changes to the TextMesh class, but it could be easily extended to have another text class in its place, such as GUIText, SpriteManager's SpriteText class, 2D Toolkit's BMTextMesh class, or ex2D's SpriteFont class depending on what you're using. Feel free to extend PlatformSpecifics to support it.

In order to extend PlatformSpecifics to support custom text solutions, take a look at PlatformSpecifics' function ApplyFont() and ApplyTextMeshText(). Change these to edit your custom class' text field and material/font field. Then, swap out the instances of "<TextMesh>" within the PlatformSpecificsEditor.cs class to your custom class to ensure proper editor functionality of the PlatformSpecifics class. That's pretty much it.

Compatibility with AutoPilot for TestFlight SDK

AutoPilot takes control of the build process and automatically uploads iOS builds to TestFlight for adhoc testing. PlatformSpecifics is fully supported and compatible with AutoPilot. MultiPlatform ToolKit users are free to use AutoPilot's build process to auto-upload to TestFlight and can safely disregard the BuildProcess class included in the toolkit, so long as they aren't depending on material stripping. If you're unsure if you need material stripping, read item #7 of Tutorial 5 for more information.

Compatibility with Prime31 plugins or other plugins which modify the build process

The MultiPlatform ToolKit is fully compatible with Prime31 plugins which modify the build process. Prime31's postprocess scripts are handled after the MPTK BuildProcess takes effect, so everything just works. In fact, we used 3 Prime31 plugins with Snuggle Truck on iOS.

Details on extensibility

Asset Settings supports importing all types of content and the BuildProcess is highly customizable to fit your needs, but what about PlatformSpecifics, you may ask! Out of the box, PlatformSpecifics allows for material swapping, scaling, positioning, font swaps, and text replacement because we found these features to be particularly important when building our own projects. If you have needs beyond this, it is entirely possible to modify any arbitrary property of any arbitrary component per-platform and enjoy the benefits of the automation of the MultiPlatform ToolKit.

See the Custom Text Compatibility section for more information on how to extend that particular are of the MultiPlatform ToolKit.

Note: The aspect ratio calculations currently are based off of landscape orientation. Changing the aspect ratio calculation to divide height by width would allow for support of a portrait-only game. This customization would be near the top of AspectRatios.cs, where aspect4By3Ratio is defined. This would be changed to aspect3By4Ratio and the division would be reversed.

Unsure of how to extend the MultiPlatform ToolKit to your own needs? Shoot us an email! (see below)

Support and Contact!

Your purchase includes friendly email support. We are a very small indie company and try to respond to all support as soon as possible! Feel free to contact us at:

support -at- owlchemylabs [dot] com