Unity3D说明文档翻译-Cross-Platform Considerations

Cross-Platform Considerations

跨平台注意事项

Most of Unity’s API and project structure is identical for all supported platforms and in some cases a project can simply be rebuilt to run on different devices. However, fundamental differences in the hardware and deployment methods mean that some parts of a project may not port between platforms without change. Below are details of some common cross-platform issues and suggestions for solving them.

大部分Unity的API和项目结构在所有支持的平台上是相同的.在某些情况下,一个项目可以简单的重构为运行在不同的设备上.然而,在硬件和部署方法上的本质上的不同意味着项目的某些部分不做改变会在平台间移植.下面是一些常见的跨平台问题和解决它们的建议.

Input

输入

The most obvious example of different behaviour between platforms is in the input methods offered by the hardware.

平台间不同行为最明显的例子就是硬件提供的输入方式.

Keyboard and joypad

键盘和手柄

The Input.GetAxis function is very convenient on desktop platforms as a way of consolidating keyboard and joypad input. However, this function doesn’t make sense for the mobile platforms which rely on touchscreen input. Likewise, the standard desktop keyboard input doesn’t port over to mobiles well for anything other than typed text. It is worthwhile to add a layer of abstraction to your input code if you are considering porting to other platforms in the future. As a simple example, if you were making a driving game then you might create your own input class and wrap the Unity API calls in your own functions:-

Input.GetAxis函数非常方便在桌面平台作为一种固定键盘和摇杆的方式.然而,这个函数在依赖触屏输入的手机平台没用.同样,标准桌面键盘输入不能很好的移植到手机上除了输入文本.如果你正在考虑在未来移植到其他平台,添加一个抽象层到你的输入代码是值得的.作为一个简单例子,如果你正在制作一款驾驶游戏那么你可能会创建你自己的输入类和包装UnityAPI调用到你自己的函数:

// Returns values in the range -1.0 .. +1.0 (== left .. right).

//返回值在-1.0(左)到+1.0(右)

function Steering() {

    return Input.GetAxis("Horizontal");

}

 

 

// Returns values in the range -1.0 .. +1.0 (== accel .. brake).

//返回值在范围-1.0到+1.0间(=加速...刹车)

function Acceleration() {

    return Input.GetAxis("Vertical");

}

 

 

var currentGear: int;

 

// Returns an integer corresponding to the selected gear.

//返回一个整数相当于选定的装置

function Gears() {

    if (Input.GetKeyDown("p"))

        currentGear++;

    else if (Input.GetKeyDown("l"))

        currentGear--;

    

    return currentGear;

}

 

One advantage of wrapping the API calls in a class like this is that they are all concentrated in a single source file and are consequently easy to locate and replace. However, the more important idea is that you should design your input functions according to the logical meaning of the inputs in your game. This will help to isolate the rest of the game code from the specific method of input used with a particular platform. For example, the Gears function above could be modified so that the actual input comes from touches on the screen of a mobile device. Using an integer to represent the chosen gear works fine for all platforms, but mixing the platform-specific API calls with the rest of the code would cause problems. You may find it convenient to use platform dependent compilation to combine the different implementation of the input functions in the same source file and avoid manual swaps.

在类中包装API调用的一个优点是它们都集中在一个源文件,因此容易定位和替换.然而,最重要的主意是你应该根据输入在你游戏中的逻辑意义设计你的输入函数.这将有助于隔离游戏的其他用于特定平台的特定输入方法.例如,上面的Gears函数可以被修改,结果是实际的输入来自手机设备的触屏使用一个整数来表示选择装置正常工作在所有平台,但混合特定平台API调用和其他代码会导致问题.你可能发现平台依赖编译结合输入函数的不同实现在同一个源文件很方便,且避免手动调换.

Touches and clicks

触摸和点击

The Input.GetMouseButtonXXX functions are designed so that they have a reasonably obvious interpretation on mobile devices even though there is no “mouse” as such. A single touch on the screen is reported as a left click and theInput.mousePosition property gives the position of the touch as long as the finger is touching the screen. This means that games with simple mouse interaction can often work transparently between the desktop and mobile platforms. Naturally, though, the conversion is often much less straightforward than this. A desktop game can make use of more than one mouse button and a mobile game can detect multiple touches on the screen at a time.

设计Input.GetMouseButtonXXX 函数的一个明显的解释在手机设备上即使”鼠标”也可用.一个触屏被报道为一次左点击且Input.uousePosition属性提供触摸位置.这意味着鼠标交互常常可以透明的工作在桌面和移动平台之间.不过,转换通常比这更简单.一个桌面游戏可以使用多个鼠标而一个手机游戏可以一次检测多个触摸在平面上.

As with API calls, the problem can be managed partly by representing input with logical values that are then used by the rest of the game code. For example, a pinch gesture to zoom on a mobile device might be replaced by a plus/minus keystroke on the desktop; the input function could simply return a float value specifying the zoom factor. Likewise, it might be possible to use a two-finger tap on a mobile to replace a right button click on the desktop. However, if the properties of the input device are an integral part of the game then it may not be possible to remodel them on a different platform. This may mean that game cannot be ported at all or that the input and/or gameplay need to be modified extensively.

使用API调用,可以由输入逻辑值表示输入部分地管理问题,然后使用剩下的游戏代码.如缩放手势在移动设备上可能会取代桌面上的+/-按键,输入函数可以简单的返回一个浮点值指定缩放因子.同样,可以在手机上使用双指轻敲取代桌面上的右键点击.然而,如果输入设备属性是游戏的一个不可分割则它可能不能重构到一个不同平台上.这意味着游戏再也不能移植,或输入和/或游戏需要大量的修改.

Accelerometer, compass, gyroscope and GPS

加速计,罗盘,回转仪和GPS

These inputs derive from the mobility of handheld devices and so may not have any meaningful equivalent on the desktop. However, some use cases simply mirror standard game controls and can be ported quite easily. For example, a driving game might implement the steering control from the tilt of a mobile device (determined by the accelerometer). In cases like this, the input API calls are usually fairly easy to replace, so the accelerometer input might be replaced by keystrokes, say. However, it may be necessary to recalibrate inputs or even vary the difficulty of the game to take account of the different input method. Tilting a device is slower and eventually more strenuous than pressing keys and may also make it harder to concentrate on the display. This may result in the game’s being more difficult to master on a mobile device and so it may be appropriate to slow down gameplay or allow more time per level. This will require the game code to be designed so that these factors can be adjusted easily.

这些输入来自手持设备的移动所以可能在桌面上没有任何.然而一些用例简单的镜像标准游戏控制能很容易的移植.例如,一款驾驶游戏可能从一个手机设备的倾斜(视加速计而定)实现转向控制.在这种情况下,输入API调用通常相当容易替换,所以加速计输入可能会被替换为键击.然而,可能需要校准输入或者甚至困难到要考虑另一种不同输入方法.倾斜一个设备是比较慢的最终比按键更费劲,并且可能也让它难以集中精力到表现上.这导致游戏在一个移动设备上更难以掌握,因此可能要适当减缓游戏或允许每个级别更多时间.这需要游戏代码设计以便能更容易调整这些因素.

Memory, storage and CPU performance

内存,存储和cpu性能

Mobile devices inevitably have less storage, memory and CPU power available than desktop machines and so a game may be difficult to port simply because its performance is not acceptable on lower powered hardware. Some resource issues can be managed but if you are pushing the limits of the hardware on the desktop then the game is probably not a good candidate for porting to a mobile platform.

移动设备不可避免的比桌面设备有更低的存储,内存和cpu功能因此一款游戏会难以移植仅仅因为它的性能不适合在低功率硬件上.一些资源问题可以管理但如果你推动硬件限制在桌面平台则游戏可能不适合移植到手机平台.

Movie playback

视频回放

Currently, mobile devices are highly reliant on hardware support for movie playback. The result is that playback options are limited and certainly don’t give the flexibility that the MovieTexture asset offers on desktop platforms. Movies can be played back fullscreen on mobiles but there isn’t any scope for using them to texture objects within the game (so it isn’t possible to display a movie on a TV screen within the game, for example). In terms of portability, it is fine to use movies for introductions, cutscenes, instructions and other simple pieces of presentation. However, if movies need to be visible within the game world then you should consider whether the mobile playback options will be adequate.

当前,手机设备在视频回放是严重依赖硬件支持.结果是回放选项被限制且当然不能提供视频材质资源在桌面平台那样的灵活性.视频可以在手机上全屏播放但在游戏中使用它们到材质对象上将没有任何视野(所以例如在游戏内不能显示一个视频到电视屏幕上).依据可移植性,视频很适合于介绍,场景,说明,介绍和其他简单的表现.然而,如果游戏需要在游戏世界内可见则你需要考虑手机回放是否能胜任.

Storage requirements

存储需求

Video, audio and even textures can use a lot of storage space and you may need to bear this in mind if you want to port your game. Storage space (which often also corresponds to download time) is typically not an issue on desktop machines but this is not the case with mobiles. Furthermore, mobile app stores often impose a limit on the maximum size of a submitted product. It may require some planning to address these concerns during the development of your game. For example, you may need to provide cut-down versions of assets for mobiles in order to save space. Another possibility is that the game may need to be designed so that large assets can be downloaded on demand rather than being part of the initial download of the application.

视频,音频和甚至贴图可能要使用大量存储空间,在你想移植你的游戏时你可能需要考虑.存储空间(通常相当于下载时间)在桌面机器通常不是问题但手机上不是如此.此外,手机app商店通常强制一个最大大小限制到你的游戏.例如,你可能要提供缩减版的资源给手机以便节约空间.另一个可能性是游戏可能需要设计以便大资源能能即时下载而不是作为初始程序下载的一部分.

Automatic memory management

自动内存管理

The recovery of unused memory from “dead” objects is handled automatically by Unity and often happens imperceptibly on desktop machines. However, the lower memory and CPU power on mobile devices means that garbage collections can be more frequent and the time they take can impinge more heavily on performance (causing unwanted pauses in gameplay, etc). Even if the game runs in the available memory, it may still be necessary to optimise code to avoid garbage collection pauses. More information can be found on ourmemory management page.

从”死去”对象恢复不用的内存由Unity自动处理且通常在桌面机器上不会被察觉.然而,更低内存和cpu功能的手机设备上垃圾收集可能会更频繁且它们带来的时间会加大对性能的影响(导致在游戏中不想要的停顿等).即使游戏运行在可用内存上,条可能依然需要优化代码以避免垃圾收集停顿.更多信息可在”内存管理”页面找到.

CPU power

CPU功率

A game that runs well on a desktop machine may suffer from poor framerate on a mobile device simply because the mobile CPU struggles with the game’s complexity. Extra attention may therefore need to be paid to code efficiency when a project is ported to a mobile platform. A number of simple steps to improve efficiency are outlined on this page in our manual.

一个在桌面机器上运行很好的游戏可能在手机设备上遭遇低帧速率仅仅是因为手机CPU在与游戏的复杂性在做斗争.因此当一个项目移植到手机平台上时要额外注意代码效率.一些用于提高效率的简单步骤概括在手册”这里(Optimizing Performance in iOS.)”