4

假设您是一家大公司，并且正在制作一个针对 PC、Mac、Xbox 和 PS3 的巨大、轰动一时的游戏。假设您选择了 C++，大多数工作室都倾向于这样做。您将它的哪些部分编写为可移植代码？真的可以写出便携游戏吗？如果你去一个新的平台，你是否必须重写渲染引擎和用户界面？

4

4 回答 4

2

有根据的猜测是，除了硬件相关代码之外的所有内容都被编写为可移植的。即游戏逻辑、矢量图形、声音（？）是（相当）可移植的，图形输出、内存管理、计时不是（总是）。

有了一个好的库选择，您可能可以最大限度地增加可移植代码的数量。

于 2012-07-29T15:25:15.647 回答
1

您当然不能要求您的 PC 游戏玩家使用 360 控制器。

至少必须从头开始重新完成渲染和用户界面。此外，其他依赖操作系统的功能（如网络）很可能必须进行改革。毕竟，boost::asio可能无法在 PS3 上运行。其他一些特定于处理器的东西，比如矢量化

然而，理想情况下，游戏会使用尽可能多的可移植代码。

于 2012-07-29T15:21:56.130 回答
1

通常，我会假设如果有一个物理引擎，那将是可移植的。玩家系统，例如健康、库存、NPC 行为等也将是独立于平台的。您很可能必须重写渲染引擎，具体取决于游戏的用途。由于必须与不同的控制器进行交互，因此用户交互可能会进行一些重写，而这些控制器很可能在每个控制台中以不同的方式访问。

一般来说，如果代码与控制台的 API 交互，则必须重写渲染、矢量化、用户界面、输入等。物理、基本行为、人工智能和健康库存管理等基本代码实际上不需要重写。

所以最后：如果它依赖于硬件，则必须重写或重构。

于 2012-07-29T15:22:08.733 回答
1

坚持 DRY 原则也会导致代码更加可移植，因为任何不可移植的代码都是本地化的。

例如，避免在代码中多次这样做：

#if defined(PC)
  // create a network connection PC-style
#elif defined(XBOX)
  // create a network connection XBox-style
#elif defined(MAC)
  // create a network connection Mac-style
#elif defined(PS3)
  // create a network connection PS3-style
#endif

相反，做一次并创建一个函数

createNetworkConnection();

您在多个地方使用。

于 2012-07-29T15:24:31.837 回答