跨平台独立开发


34

几年前,如果您使用C和C ++的某些子集编写并使用了足够多的平台抽象(通过SDL或其他方式),则可以在独立的平台上运行的每个平台上运行-Linux,Windows,各种版本的Mac OS ,诸如BeOS之类的晦涩难懂的内容,以及GP2X和死亡后Dreamcast之类的开放式控制台。如果您在某个时候获得了一个封闭平台的合同,那么您也可以通过“最少”的代码更改将游戏移植到该平台上。

今天,独立开发人员必须使用XNA才能安装Xbox 360(以及即将推出的Windows Phone)。不得使用XNA在Windows以外的其他任何地方工作;直到最近不得不在Android上使用Java;Flash无法在手机上运行,​​HTML5无法在IE上运行。与DirectX vs. OpenGL或Windows vs. Unix不同,这些是对您编写代码所用的核心语言的更改,并且基本上没有编写编译器就无法改写。您可以将一些游戏逻辑移到脚本中并包括一个解释器-除非您不能这样做,因为iPhone SDK不允许这样做,并且由于没有人允许JIT而导致性能下降。

那么,如果您想要一款真正的跨平台便携式游戏,甚至只是大量的引擎和逻辑代码,该怎么办?

这是不是一个问题,因为平台从根本上存在分歧-尝试使用任何共享代码同时针对iPhone和Xbox 360定位是不值得的,因为这样的游戏会很糟糕吗?(我觉得这不太可能。我很容易看到想要在Windows Mobile手机和Android或Xbox 360和iPad之间共享游戏。)现在接口如此高级,以至于移植时间可以忽略不计吗?(我可能认为这适用于业务应用程序,但不适用于对性能有严格要求的游戏。)

将来会变得更加明显吗?分裂会在某种程度上还是仍然在厂商线下吗?我们是否都将依靠Flash或Unity等高级中间件来完成跨平台的任何工作?

tl; dr-移植有问题吗,将来会成为更大的问题吗?如果是的话,我们如何解决呢?


2
《 iPhone Developer程序许可协议》的第3.3.2节允许现在编写游戏脚本,尽管仍然有些复杂。-“尽管有上述规定,但在得到苹果公司事先书面同意的情况下,如果应用程序仅可用于提供与应用程序的预期和广告目的一致的次要特征或功能,则可以有限的方式使用嵌入式解释代码。”
巴克斯(Bachus)2010年

3
苹果昨天再次更改了许可协议,现在游戏脚本完全可以了。-“如果所有脚本,代码和解释器都打包在应用程序中且未下载,则解释后的代码只能在应用程序中使用。上述内容的唯一例外是由Apple内置WebKit框架下载并运行的脚本和代码。”
巴克斯2010年

我想说的是,您将一堆不属于您的东西混在一起-移动设备,游戏机,PC 基于Web的游戏?控制台和PC当然应该能够通过一些调整共享一个代码库。移动设备与专用计算硬件的功能(在原始图形功能,存储,线程性等方面)有很大不同,因此您甚至无法使用相同的解决方案。网页游戏就是网页。你想要什么?这里的碎片跨越了设备范式,而不仅仅是计算架构。
ChrisE 2011年

实际上,我对网络游戏一无所知。我认为要在所有设备上运行某些相同的代码(输入映射或抽象的图形API或实体系统,文件解析,联网)是合理的,而与平台无关,它们都是相同的基本范例。但是这个问题也有8个月了,并且因为NDK在Android上获得了更多支持并且苹果停止了其愚蠢的政策而引起的担忧并没有太大用。

我的意思是,您确实提到过HTML5 ...是针对网络游戏的,对吧?
克里斯(ChrisE)2011年

Answers:


14

Unity引擎为您提供了很大的帮助。只需编写一次,就可以使用Mac / Windows Standalone和基于Webplayer的软件。调整输入,并注意绘图调用,并且您使用的是iOS / Android。


12

对于资金/时间有限的小型独立开发人员(也许更多地关注“使事物变得有趣”而不是“使事物变得有利可图”),从一开始就尝试跨平台可能会适得其反。设计可靠的跨平台工具和技术(不同的图形API,字节序,输入设备等)需要花费大量的精力-这些时间可能花费在游戏开发的更具创意的方面。

但是您可能要确保自己在一款平台上能很好地运行一款出色的游戏,然后再担心将其投放到尽可能多的平台上!如果游戏是翻牌圈,那么浪费时间和精力使它成为多平台翻牌圈是没有意义的,是吗?

如果您是从头开始使用C / C ++进行编码,则只要保持代码相当模块化并就数据格式和中间件/库做出明智的决定,那么以后支持其他平台就不会太痛苦。

如果您的项目选择了第三方跨平台技术/工具(例如Unity),那么当然值得考虑。

独立开发者的主要“问题平台”似乎是Xbox360独立游戏(仅C#,有限的网络访问等),可能还有Android(设备性能/屏幕尺寸/输入设备的巨大差异)。如果您决心支持这些,请期待更大的移植工作,或计划专门专注于它们。


是的,Unity3D摇滚。www.unity3D.com
BerggreenDK,2010年

我同意@bluescrn-更好的是几乎几乎什么都不知道,而不是几乎什么都不知道:具有所有特征的杰克,没有大师。
rodrigo-silveira

3

您说的是跨平台的独立开发。那时最大的障碍是资源,这意味着大部分时间都没有时间,但是也缺少专业知识和可能的财务(许可证费用,购买设备等)。

无论独立与否,最大的障碍实际上是设计。就像您说的那样,可以在Xbox360和iPad上运行的游戏可以运行,但在设计方面也需要根本不同。360具有一个控制器,iPad具有触摸屏。另外,360的开发是在Windows中使用C#作为语言完成的,iPad只能在Mac OS计算机上使用C,C ++或Objective-C。如果您愿意,也可以使用Javascript。无论您做什么,有些事情并不能很好地融合在一起。

您对不同平台的看法在今天仍然适用。使用C / C ++和SDL,您可以在类似PC的计算机上跨平台编写程序,这可能比几年前更加顺利。但是,将游戏从PC移植到游戏机再到移动设备始终是一个问题,反之亦然。近年来,通过允许独立开发人员为游戏机编程(或开发人员对其进行访问以创建自制游戏)进行黑客编程,以及功能强大的可运行游戏的移动设备的兴​​起,它变得更加明显。

移植遇到了同样的问题,但是有更多的设备要移植。如果不重新设计游戏核心,某些端口就没有意义。这不是一个可以解决的问题,这是您甚至在编写第一行代码之前就必须考虑的问题。然后它将是可管理的,不多也不少。


实际上,我想说,移植时间是一个独立的开发人员/团队比大型发行商驱动的工作室更可能拥有的一件事。

在所有平台上都有许多有意义的游戏设计-例如,基于回合的虚拟棋盘游戏在所有平台上一直很受欢迎。因此,许多掉落/匹配的块益智游戏。从传统意义上讲,这些甚至都无法“移植”-将游戏从例如XBLIG移植到iPhone可以保证重写所有代码。

3

我认为确实需要一个简单,可移植和开放的接口框架。一些沉思:

当前似乎有四种常见的游戏输入法:键盘,鼠标,控制器和多点触控表面。(我将暂时解决游戏手柄和操纵杆之间功能不同的问题,尽管最终应解决这些问题。)

理想情况下,我们的开发人员将能够以一般方式指定一些不同的UI,这些UI对编写的游戏类型有意义。(作为一个任意示例,他们可能决定提供键盘和鼠标UI,仅鼠标UI和多点触控UI。)

然后,该框架负责在平台和游戏代码之间进行IO中介,类似于QT和GTK等跨平台GUI框架的功能。

拥有这样的框架并不能解决不兼容的语言需求问题,但是至少可以将所有特定于系统的调用封装在一个通用API的后面,这应该使语言移植更加直接。

好吧,既然我已经写了所有这些内容:有人知道这样的框架是否已经存在吗?


3

对于像MonoTouch和XNATouch这样的项目,看起来XNA可能会在大多数平台上进行一些调整。不幸的是,Apple改变了他们的条款,以限制您可以使用的语言。Unity现在几乎涵盖了所有内容,尽管在XBOX上它可以带您进入XBLA,但不能带XBLIG,因此对于较小的独立游戏来说不是一个选择。

一种方法可能是创建一个在多种语言/平台上使用相同约定的框架,然后只需调整语法以移植游戏即可。您可能想在Flash中启动游戏,该游戏可以快速开发并吸引大量用户,然后成功移植到iPhone,XNA等。这样一来,您就可以在过度投入游戏之前就拥有一款有趣的游戏。


愚蠢的苹果,谁限制编程语言!谁?!?!
FreshJays 2011年

2

我认为这是一个经济问题,而不是技术问题。诸如xbox360之类的平台具有被排斥的强烈动机,因为它们试图让用户选择他们的平台而不是其他平台。“我们拥有这些很酷的独家游戏”比“我们也可以玩其他所有人都拥有的这些游戏”更有趣。生态系统由硬件制造商主导。

我怀疑随着社交网络游戏的成熟,这种情况会改变,因为将所有人带入同一个社交游戏系统可能比制作又一张带有性感图形的第一人称射击游戏有更多的钱。


2

我刚刚发现了Haxe和NME。它声称是一个跨平台应用程序,可从一个代码库支持所有主要的台式机和移动设备以及 Flash。值得一看。


1

http://www.monkeycoder.co.nz/是一种非常新的跨平台开发工具,我不一定推荐它

它遍及您提到的每个平台。

尽管它还太新以至于无法真正判断,但它有一个很好的血统:它的创建者以前制作了Blitz3D和BlitzMax,它们是独立游戏开发人员的出色开发工具。


0

我对airplay SDK感到幸运-至少在x86上,并且显然可以很好地定位iPhone(尽管我还没有在iPhone上安装应用程序)。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.