如何学习跨平台游戏开发？
像 Valve 这样的公司如何设法将游戏发布到所有三大游戏平台？ 我对有关 Windows、Xbox360 和 PS3 之间的代码共享的最佳实践感兴趣，因为理想的解决方案是重用尽可能多的代码，而不是为每个平台重写整个代码。
How do companies like Valve manage to release games to all three major gaming platforms? I am interested in the best-practices regarding code sharing specifically between Windows, Xbox360 and PS3, since the ideal solution is to reuse as much code as possible instead of rewriting the whole thing for every platform.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
这与在其他上下文中编写独立于平台的代码没有任何不同。 将特定于平台的详细信息（输入、窗口交互、主事件循环、线程等）隐藏在通用接口后面，并在您打算支持的所有平台上定期进行测试。
请注意，Cell 的线程模型非常不寻常，因此“一般”执行线程需要小心。 我不是 Valve 员工，也不知道他们的任何秘密，但据我所知，大多数想要针对 PS3 的游戏开发人员都使用一个作业队列，各个单元处理器根据需要从中获取任务。 这不一定是使用 Cell 的最佳方式，但它可以很好地推广到更传统的线程模型（例如 frex，PC 和 360 都使用的模型）。
It's not any different than writing platform-independent code in other contexts. Hide platform-specific details (input, window interaction, the main event loop, threading, etc) behind generic interfaces, and test regularly on all the platforms you intend to support.
Note that the Cell's threading model is unusual enough that doing threading "generically" takes some care. I am not a Valve employee and I know none of their secrets, but it's my understanding that most game developers who want to target the PS3 use a job queue that the individual cell processors grab tasks off of as needed. This isn't necessarily the best way to use the Cell, but it generalizes nicely to more conventional threading models (like, frex, the one that thet PC and the 360 both use).
游戏开发者杂志上有很多关于这个主题的文章和 GDC 演讲。 事实上，自从您提到 Valve 以来，他们发表了一次演讲，描述了他们的方法 GDC08。
这确实是一个巨大的主题，我可以（并且已经）谈论几个小时，但电梯总结是：
There's a bunch of Game Developer Magazine articles and GDC talks on the subject. In fact, since you mentioned Valve, they delivered a talk describing their approach at GDC08.
This is really a huge subject that I could (and have) talk about for hours upon hours, but elevator summary is:
这个问题可以分为两个单独的问题。 “我怎样才能编写可移植的代码？” 以及“主流游戏平台的不同需求是什么？”。
第一个问题相对容易回答。 编写可移植代码中介绍了抽象不可移植代码的最佳实践：
http://books.google.ca/books?id=4VOKcEAPPO0C&printsec=将
理论转化为实践，Quake 3 源代码在将不同平台划分为 C 代码库的单独区域方面做得非常好，可从
你的问题的第二部分“主流游戏平台的不同需求是什么？” 更难。 然而，值得注意的是，最大的变化领域仍然是渲染器、音频子系统和网络。
每个控制台平台都有一系列认证要求，可根据与各自控制台所有者的协议获得。 这些要求推动了用户体验的一致性，而不是关注游戏玩法或定性的高级问题。 例如，您的游戏可能需要显示相当有趣的动画加载屏幕，而黑屏是不可接受的。
尽快掌握本文档是在针对特定控制台平台进行开发时做出正确选择的关键。
最后，如果您无法获得控制台开发套件，我建议您将代码从 Windows 移植到 Mac。 Mac 为您提供了一个操作系统端口，确保您不受 Windows 的束缚；如果您支持通用二进制文件，还可以为您提供一个处理器端口。 这可确保您的代码与字节序无关。
如果您同时支持 PC 和 Mac，那么您将能够很好地支持第三个平台（如果您将来能够访问它）。
附录您写道：
在许多游戏移植场景中，理想的解决方案不是重用尽可能多的代码，而是为每个平台编写最佳代码。 代码可以在项目之间重用，并且与引擎接收的内容相比相对便宜。更合理的目标是实现在所有平台上运行而无需修改的最低公分母内容（将内容打包为媒体的构建阶段）没关系）。
This question can be divided up into two separate questions. "How can I write portable code?" and "What are the divergent requirements of mainstream gaming platforms?".
The first question is relatively easy to answer. Best practices for abstracting your non-portable code are covered in Write Portable Code:
http://books.google.ca/books?id=4VOKcEAPPO0C&printsec=frontcover
Turning theory into practice, the Quake 3 source code does a pretty good job of dividing out different platforms into separate areas for a C codebase, available at http://www.idsoftware.com/business/techdownloads/ However, it does not demonstrate C++ patterns such as abstract interfaces, implemented once per platform.
The second part of your question, "What are the divergent requirements of mainstream gaming platforms?" is tougher. However, it is notable that your largest areas of change are still your renderer, your audio subsystem and your networking.
Each console platform has a series of certification requirements, available under an agreement with the respective console owners. The requirements drive consistency in user experience and are not focused on gameplay or qualitative, high level issues. For instance, your game may need to display a reasonably interesting animating loading screen, and black screens are unacceptable.
Getting your hands on this documentation as soon as possible is key to making the right choices in developing for a specific console platform.
Finally, if you can't get your hands on a console devkit, I suggest you port your code to the Mac from Windows. The Mac gets you an OS port ensuring you are not tied to Windows as well as a processor port if you support universal binaries. This ensures your code is endian agnostic.
If you support both PC and Mac, you will be well positioned to support a third platform, should you gain access to it in the future.
Addendum You wrote:
In many game porting scenarios, the ideal solution is not to reuse as much code as possible, but to write the optimal code for each platform. Code can be reused between projects and is relatively inexpensive as compared to the content that the engine takes in. A more reasonable goal is to aim for lowest common denominator content that runs on all platforms without modification (a build phase that packs the content for media is okay).
同步开发真是太好了。 您会发现仅在一个平台上找不到的各种错误。
我记得 DOS 中的程序员一直使用空指针，因为写入低内存不会立即使它们崩溃。 当您移植到 Amiga、Atari ST 或 Macintosh 时，繁荣！ 我记得告诉一位 DOS 程序员，他在一款已发布的游戏上有几个空指针。 他想了几秒，笑道：“这可以解释一些事情。”
既然游戏有如此大的预算，那么同时发布所有游戏就很重要，这样您就不会浪费营销和广告预算。
我对同步开发的建议是选择一个领先平台，但永远不要让其他平台落后超过一周。 当您编程时，代码的哪些部分对于所有平台都是通用的，哪些部分是不同的，这一点将变得显而易见。 将差异引入一个或多个特定于平台的区域。
我的经验是C/C++。 如果您必须针对不同的语言（例如 Java 和 Objective-c）进行移植，那就是一个更大的问题。
It's great to do simultaneous development. You find all kinds of bugs you wouldn't find doing just one platform.
I remember that programmers in DOS had null pointers all the time because writing to low memory didn't immediately crash them. When you ported to an Amiga, Atari ST, or Macintosh, boom! I remember telling a DOS programmer that he had a couple null pointers on an aready-shipped game. He thought for a couple seconds and grinned, "That explains a few things."
Now that games have such large budgets, it's important to ship them all at the same time so you don't waste marketing and ad budgets.
My advice on simultaneous development is to pick one lead platform, but never let the other platform(s) get more than a week behind. It will become obvious as you program which parts of the code are common to all platforms and which are different. Pull out the differences into one or more platform-specific areas.
My experience is in C/C++. It's a bigger problem if you have to port against different languages (say, Java and Objective-c).
几年前，Opera 首席执行官在接受采访时表示，独立平台开发的关键是摆脱任何单一操作系统/平台库。 他接着说，他们开发了自己的库来提高操作系统性能。
我的假设是，大公司会有一个共同的、Xbox、PS、Windows、FooOS、独立的团队。 每个平台都需要进行不同的调整，并且需要不同的实现方法。 我不认为他们为所有平台提供单一来源； 相反，他们为每个操作系统构建一个操作系统，从而提高效率。 我记得 EA 曾经比 PC 版本更早发布一些主机游戏，反之亦然。
另一个问题是不同的控制台具有不同的硬件，因此需要不同的编程技术。
有两个极端，构建一个适合所有情况的源代码（例如 java），但你会冒着效率低下的风险，或者编写 40 个版本； 针对每个平台进行了优化
A few years ago the Opera CEO said in an interview that the key to developing for independent platforms is to move away from any single OS/platform libraries. He went on and said that they developed their own libraries that improve OS performance.
My assumption is that big companies will have a common, Xbox, PS, windows, FooOS, separate teams. Each platform needs to be tweaked differently and requires different implementation methods. I don't think they do one source for all platforms; rather, they build one for each OS thereby, improving efficiencies. I remember EA used to release some console games earlier than the PC versions and vice versa.
Another issue is that different consoles have different hardware thus requiring different programming techniques.
there are two extremes, build one source that fits all (java for instance) but you run the risk of inefficiency or write 40 versions; one optimized for each platform
当我有一个朋友进入教育电脑游戏时（在 The Learning Company 彻底摧毁这个领域之前），他非常热衷于创建跨平台库来完成所有事情。
对于游戏来说，这比其他应用程序更容易。 例如，如果您有一个文字处理应用程序要在 Mac 和 Windows 上运行，那么它确实需要在 Mac 上看起来像 Mac 应用程序，在 Windows 上像 Windows 应用程序一样。 编写一个游戏，它不必符合本机行为、外观和感觉。
Back when I had a friend into educational computer games (before The Learning Company gutted the field), he was a great fan of creating cross-platform libraries for doing everything.
This is easier for games than other apps. If you have a word processing app to run on the Mac and Windows, for example, it really does need to look and behave like a Mac app on the Mac, and a Windows app on Windows. Write a game, and it doesn't have to conform to the native behavior, look, and feel.
如果您想要开源示例，您可以查看 Quake 1、2 和 3 引擎的源代码。 它们的结构非常便于移植。 （当然，不支持 ps3 或 xbox360，但适用相同的原则）
http://www.idsoftware。 com/business/techdownloads/
If you want open source examples, you could look at source code of Quake 1, 2 and 3 engines. They are structured quite portably. (Of course, no ps3 or xbox360 support, but same principles apply)
http://www.idsoftware.com/business/techdownloads/