独立开发者谈跨平台移植游戏所面临的挑战

标签: 资讯频道 平台差异 挑战 跨平台移植游戏 | 发表时间:2012-02-09 18:13 | 作者:fanbinzhen
出处:http://gamerboom.com

作者:Amos Laber

对于在休闲、社交或手机领域里从事游戏项目制作的独立开发商而言,最先需要确定的是目标平台。多数情况下这都不是个问题,因为团队或工作室会根据已经拥有的游戏开发经验来决定目标平台,但团队向其他平台扩张时总是会面临诸多问题。

手机还是网页,抑或两者兼顾?

在选择休闲2D游戏的主要目标平台时,通常会纠结于手机和网页这两个选择,更具体地说,就是选择Facebook还是iOS。两个平台都有数亿用户,支持微交易和社交功能,所以潜在市场都很大。

从传统上说,两个平台上的成功游戏的题材有所差别,但是现在这种差别正在迅速减少,主要的差别多数在于技术层面。

手机平台之间也是如此。iOS是目前最大的市场,Android和Windows Phone市场也有发展潜力。在同时考虑多个手机平台时,总要选择一个侧重平台,其他平台作为辅助。

有些游戏实现了在手机和网页间相互渗透,比如《植物大战僵尸》(游戏邦注:先从C++转变为Flash,随后被移植到iOS平台上)和《愤怒的小鸟》,后者从iOS移植到几乎所有的手机平台上,现在也有Flash版本,该游戏不久还将在Facebook发布。

植物大战僵尸(from gamasutra)

植物大战僵尸(from gamasutra)

但是,这些游戏都取得了很大的成功,所以开发商才有更多的资源将其移植到各个平台上,而多数独立开发商无法做到这一点。

移植产生的问题

将现有游戏从一个平台移植到另一个平台上,这是个乏味且漫长的任务。在AAA游戏领域中,往往可以使用跨平台引擎以单个代码为基础构建多个平台的版本。但是对休闲和手机游戏而言,移植往往意味着需要完全重新编写游戏代码。

移植会增加项目制作资金和游戏项目的开发时间,这迫使独立开发商不得不将游戏限制在单个平台上,这样他们才能有足够的精力来不断提升游戏质量。

开发商当然希望往更好或更大的市场发展,但是通常在游戏发布之时,并没有足够的资源用来将其移植到其他平台上。我们会看到手机开发商将他们的游戏限制在单个平台上,这便是缘由。

最好的情况是,如果游戏获得成功并流行起来,在6个月到1年的时间内该游戏会在另一个平台上发布,但是多数情况下不会出现本轻利厚的现象。

我是个程序员,所以更加专注于技术层面。

预先考虑移植问题

有个可行的方法,就是在计划新游戏的代码构建时,设计便于移植的代码和资产。从理论上说,这应当不是个问题,优秀的框架不会依赖于平台的特别功能,模块化设计可以用来减弱主游戏模块同平台特别组件间的联系。

但是,在实际操作中这会面临诸多挑战。硬件(游戏邦注:手机设备间存在差异,网页和手机之间也存在差异)、操作系统处理能力、工具和编程语言都存在不同之处,每个平台都需要用不同的语言来编写本地应用。

在这些差异化中,某些差异可以通过精心的计划和使用交叉编译器来弥补。Unity3D或Corona等工具都可以在不同的平台上编译,但这样做需要付出代价:开发商被局限于工具能够支持的功能上,失去了本地代码的灵活性。对于某些游戏,这种方法确实很合适,但是我觉得能够这样做的游戏极其有限。

简单地说,使用这种方法依然有一定的风险,这样的产品可能无法针对特定平台进行最优化设计。

从单个平台开始

理想情况下,我们可以针对每个平台使用其本地工具和库来编写代码,这样我们才会有更高的灵活性。重点在于,选择你或团队熟悉且符合代码风格和框架的工具。

虽然技术选择是主观行为,我认为需要以某些关键要求为基础,这些要求是:

1、使用普通资产类型(游戏邦注:比如位图和精灵层次等)

2、提供强大工具用于美术和设计

3、提供带有漏洞修补工具的面向对象语言

4、以已证实有效的框架为基础,可以提供可靠的核心功能

这样看来,适合Facebook的是Flash和AS3,适合iOS的是Cocos2D和Objective-C。要先选择其中之一作为主要平台,然后根据次要平台来调整代码。我们可以利用AS3和Objective-C间的相似性,这样两个平台间的移植就会变得更加容易。(本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转载,如需转载请联系:游戏邦)

Jumping from web to mobile: Challenges of cross-platform game development

Amos Laber

For an indie developer working on game projects in the casual/social or mobile space, one of the earliest decisions to make is what platform to target. In most cases it’s a no-brainer, since the team or studio already gained experience developing a game for platform X, but then there is always the question of branching out to more platforms.

Mobile, web, or both?

In choosing the primary target platform for a casual 2D game, the typical dilemma is choosing between mobile and web – or to be more specific: Facebook or iOS. Both platforms offer access to hundreds of millions of users with solid support for micro transactions and social features, which in turn translate to a huge potential market.

Traditionally there are differences in genres that are successful on each of the platforms, but they are quickly shrinking, and the differences become mostly technical.

The same goes for other mobile platforms. iOS is currently the biggest market, with Android and Windows Phone (XNA) being just as good as potential targets. Whenever multiple mobile platforms are considered, one should always be the first, with the assumption that the rest of the mobile platforms will follow.

Real life examples of games that jumped from/to mobile and web are Plants vs. Zombies (ported to Flash from C++ and later to iOS) and Angry Birds, which jumped from iOS to almost any other mobile platform, available now as a Flash game, and is soon to be released on Facebook.

Both of these games, however, where successful enough to allow the developer fund the extra resources for porting – something that most indie developers don’t have.

The problem with porting

Porting an existing game from one platform to another can be a tedious and lengthy task. As opposed to the AAA game space, where often cross platform engines are used that enable a single code base to build for multiple platforms, in casual and mobile games, porting often means a complete rewrite of the game.

The prospect of stretching the budget and timeline of a game project in order to accommodate porting is forcing indie developers to limit the game to a single platform, since they rather spend that effort on making the game better.

Business dictates going for the better or bigger market, and usually by the time the game ships, the resources for porting are simply not available. This is the reason we see mobile developers limiting their games to a single platform.

In the best case, if the game gained success and popularity, it could take between six months to a year to release it on a different platform, but in most cases its simply not cost effective.

Being a coder, I’d like to focus on the technical aspect. With careful design and mindful planning, it is possible to provide the ability to budget for two or more platforms for the cost of one. Well, OK, not really for the same cost but with minimal overhead.

Can one size fit all?

A possible approach when planning building a new game code, is to plan ahead for the code and assets to be easily portable. In theory, it should not be a problem – good architecture does not rely on platform specific features, and modular design can be used to decouple the main game modules from platform specific components.

In practice, however, many challenges arise. There are differences in hardware (between different mobile devices and between web and mobile), in operating system capabilities, and finally in tools and programming languages – since every platform has a different language that is used to write native apps.

Some of these differences can be bridged by careful planning and using cross compilers. Tools like Unity3D or Corona will compile for different platforms, but that comes with a price – the developer is limited to whatever the tool supports, and it does not offer the flexibility of native code. For some cases these are a good fit, but I find them to be very restrictive.

As the saying goes: one-size-fits-all never fits. In short, the risk remains that we end up with lowest common denominator product that may not be fully optimized for any of the specific platforms.

Start with just one

Ideally we would want to be able to code for each platform using its native tools and libraries in order to give us flexibility. It is important to choose tools that you (or your team) are familiar with, and fits our coding style and architecture.

The choice of technologies, although subjective, is based on a set of key requirements that I identified as important for smooth development. These are:

Use common asset types (i.e. bitmaps, sprite sheets, etc)

Provide strong tooling for art and design

Strongly typed object-oriented language with decent debugging tools

Proven framework as a foundation, that can provide solid core features

In this case: Facebook – Flash / AS3, iOS – Cocos2D / Objective-C. One would have to come first and serve as the primary platform, while the secondary will adjust later. Right from the start we take advantage of the similarities between AS3 and Objective-C, so jumping between them will be easier.

Next time, on part 2, I will lay out a plan for a code framework that aims to offer a solution for the problem of portability across web and mobile platforms. ( Source: Gamasutra)

相关 [独立 开发 跨平台] 推荐:

独立开发者谈跨平台移植游戏所面临的挑战

- - GamerBoom.com 游戏邦
对于在休闲、社交或手机领域里从事游戏项目制作的独立开发商而言,最先需要确定的是目标平台. 多数情况下这都不是个问题,因为团队或工作室会根据已经拥有的游戏开发经验来决定目标平台,但团队向其他平台扩张时总是会面临诸多问题. 在选择休闲2D游戏的主要目标平台时,通常会纠结于手机和网页这两个选择,更具体地说,就是选择Facebook还是iOS.

跨平台开发工具Qt SDK 1.1.3发布

- tinda - Solidot
chinakr 写道 "Nokia于本月1日发布了Qt SDK 1.1.3,更新内容包括功能改进和软件质量提升. Qt SDK 1.1.3下载链接:Windows版,Linux版(32位),Linux版(64位)和Mac OS X版.

Moscrif:用JavaScript进行跨平台移动开发

- - InfoQ cn
Moscrif是构建在定制虚拟机上的跨平台移动开发环境. 尽管该平台提供了访问原生设备的功能,但编程语言却是JavaScript的一个定制版本. 据公司联合创始人Michal Habalcik所说,Moscrif已支持iOS、Android、Symbian、Windows Mobile和Bada等平台,而且还将在微软发布API之后,添加对Windows Phone 8的支持.

跨平台移动框架iMAG开发入门

- - IT技术博客大学习
iMAG是一个非常简洁高效的移动跨平台开发框架,开发一次可以同时兼容Android和iOS平台,有点儿Web开发基础就能很快上手. 当前移动端跨平台开发的框架有很多,但用iMAG还有一个好处,就是用iMAG开发出的App是原生的. iMAG采用XML + JavaScript(配置 + 脚本)的开发方式,它的原理是将符合iMAG开发规范的XML文件解释成对应的原生应用代码来执行.

聊聊移动端跨平台开发的各种技术

- - FEX 百度 Web 前端研发部
最近出现的 React Native 再次让跨平台移动端开发这个话题火起来了,曾经大家以为在手机上可以像桌面那样通过 Web 技术来实现跨平台开发,却大多因为性能或功能问题而放弃,不得不针对不同平台开发多个版本. 但这并没有阻止人们对跨平台开发技术的探索,毕竟谁不想降低开发成本,一次编写就处处运行呢.

使用 Vagrant 打造跨平台开发环境

- - Linux - 操作系统 - ITeye博客
参考地址1: http://segmentfault.com/blog/fenbox/1190000000264347. 参考地址2: http://blog.phpor.me/2014/10/12/vagrant-%E6%9C%AC%E5%9C%B0%E5%BC%80%E5%8F%91%E7%8E%AF%E5%A2%83.html.

App跨平台开发方案与抉择

- - CSDN博客推荐文章
内心强大才敢于承认错误,但是首先你要敢于去试错. 现在做客户端开发的公司都会面临一个巨大的问题,那么就是跨平台. 对于目前上市面上的移动设备来说. Android、IOS、WindowsPhone、BlackBattery等等移动设备系统,让我们在开发适配上都很头痛. 但是由于Google与Apple公司的竞争,现在创业公司主要关注的就只有是Android和IOS应用程序了.

移动端跨平台开发的深度解析

- - IT瘾-dev
  跨平台一直是老生常谈的话题,cordova、ionic、react-native、weex、kotlin-native、flutter等跨平台框架的百花齐放,颇有一股推倒原生开发者的势头. (事实上更多是共存发展)看完本篇,相信你会对于当下跨平台移动开发的现状、实现原理、框架的选择等有更深入的理解.

跨平台开发技术年终盘点

- - SegmentFault 最新的文章
一直以来,效率都是互联网企业的生命线. 而 “通过技术升级实现三个人干五个人的活,赚四个人的工资”是企业和个人一直渴望达到的双赢局面. 随着行业竞争加剧,为进一步提升开发效率,跨平台开发逐渐的成为了互联网行业的刚需. 这样的大趋势下,一些头部互联网公司基于自身技术背景和当时技术条件,推出了不同类型的跨平台解决方案.

Electron+Vue开发跨平台桌面应用

- - SegmentFault 最新的文章
虽然B/S是目前开发的主流,但是C/S仍然有很大的市场需求. 受限于浏览器的沙盒限制,网页应用无法满足某些场景下的使用需求,而桌面应用可以读写本地文件、调用更多系统资源,再加上Web开发的低成本、高效率的优势,这种跨平台方式越来越受到开发者的喜爱. Electron是一个基于Chromium和 Node.js,使用 HTML、CSS和JavaScript来构建跨平台应用的跨平台开发框架,兼容 Mac、Windows 和 Linux.