为什么只有少数几个用Java编写的视频游戏？[关闭]

为什么没有很多用Java编写的商业3D视频游戏（不是随机开放源2D游戏）？从理论上讲，这很有意义：您几乎免费地获得了生产力的提高和一个跨平台的应用程序，其中包括大量的Java库和内置的垃圾回收器（尽管我承认我我不确定后者是否是一件好事。那么为什么很少使用它呢？我只能想到为Java平台编写的几个流行的商业游戏。

是因为性能吗？如果是这样，GPU难道不是大部分的繁重工作吗？

游戏开发世界是一个有趣的世界：一方面，他们通常很快就会接受新的想法，另一方面，他们仍然处在僵局。

事实是，切换到.NET / Java /除C / C ++之外的任何东西的动机很少。

大多数游戏公司从其他公司获得游戏引擎的部分许可。这些部分是用C ++编写的，尽管您可能可以访问源代码以便移植它，但是这需要很多工作（当然，许可证需要允许它）。

同样，C ++中已经存在许多旧代码。如果以前项目中的代码可以重复使用（例如，如果您正在编写续集），则更重要的是坚持使用相同的语言，而不是用新的语言重写（因为这样您可能会重新引入）大量的错误，您需要花费一些时间来解决。

最后，无论如何，用100％C ++编写游戏都是很罕见的-使用脚本语言可以完成很多工作，无论脚本是自定义的，还是只是集成现有的语言（Lua是当今最受欢迎的语言之一）。

就垃圾回收而言，这可能是个问题。问题不仅仅在于它存在，还在于它的工作原理-垃圾收集器必须是非阻塞的（或者至少保证仅非常短暂地阻塞），因为将游戏冻结10秒钟是完全不可接受的，它会扫描所有已分配的内存，以查看可以释放的内容。我知道Java在接近用尽内存时（在某些游戏中，它会）会在GC'ing中阻塞很多。

您在操作上还受到更多限制：由于运行时的开销，您无法充分利用硬件。想象一下Crysis是用Java编写的……即使这是唯一可见的区别，也不会是一样的（我也很确定您需要Core i7来运行它）。

这并不意味着这些语言没有在游戏开发中占有一席之地-不，我不仅指工具编程。对于大多数游戏，您不需要从C ++获得的额外性能（包括3D游戏），而且如果您是从头开始编写所有内容，那么使用XNA之类的东西就很有意义了-实际上，很有机会。

就商业游戏而言-RuneScape算在内吗？那很可能是最成功的Java游戏。

我认为John Carmack最好的说法是：

最大的问题是Java真的很慢。从纯cpu /内存/显示/通讯的角度来看，大多数现代手机应该比Game Boy Advanced更好的游戏平台。使用Java，在大多数电话上，您只剩下大约4.77 MHz原始IBM PC的CPU能力，并且无法控制所有内容。[... snip ...]写一次即可在任何地方运行。哈。哈哈哈哈哈。目前，我们仅在四个平台上进行测试，没有一个具有完全相同的怪癖。所有商业游戏都针对每个（通常为100多个）平台进行了调整和编译。可移植性并不是令人敬畏的性能的理由。

（来源）

当然，他在谈论移动平台，但是我发现Java整体上也存在类似的问题，这些问题都来自C ++背景。我想念能够按照我自己的意愿在堆栈/堆上分配内存。

一方面，Java缺乏运算符重载使得获得工作图形管道所需的所有数学工作变得非常非常烦人且难以阅读。

如果您要处理的所有矩阵乘法和仿射矢量都采用格式正确的数学表达式，而不是诸如面向对象的表达式，则易于遵循

product = vector.multiply(projectionMatrix).dotProduct(otherVector);

那太可怕了。数学看起来不应该那样。

我认为.NET具有与Java相同的许多感知问题。微软在使用XNA开发人员的市场营销方面做得更好：-)

次要分数：

• Java带来的任何生产力提升都是假设性的。语法几乎与C ++相同，因此您实际上只是在依靠内存管理和标准库的节省。这些库几乎没有提供给游戏开发人员，并且由于垃圾回收，内存管理是一个有争议的问题。

• 跨平台“免费”并不如您想象的那样好，因为很少有开发人员想要使用OpenGL，并且几个关键平台可能缺少良好的Java实现或本机库的包装，无论是图形，音频，网络等。

但主要是问题是向后兼容。游戏开发人员从C迁移到C ++，而从汇编迁移到C，纯粹是因为迁移过程很顺利。每个版本都与先前版本紧密互操作，并且它们先前的所有代码通常都可以通过单个编译器以新语言使用。因此，迁移的速度和您想要的一样快。例如，我们今天使用的某些旧标题仍具有#ifdef WATCOMC，而且我认为十年甚至更长时间都没有人在这里使用过Watcom编译器。对旧代码进行了大量投资，并且只有在需要时才替换每个位。如果您更改为一种不会与现有代码进行本机互操作的语言，那么从一个游戏到另一个游戏的零碎替换升级过程实在不切实际。是的，C ++ / Java互操作性是可能的，但是与简单地编写“带有一点C ++的C”或将asm块嵌入C中相比，这是不切实际的。

要适当取代C ++作为游戏开发人员的首选语言，它必须执行以下两项操作之一：

1. 与现有的旧代码轻松互操作，从而节省投资并保持对现有库和工具的访问，或者
2. 可以证明，它充分显示了生产力的提高，以至于重写所有您自己的代码（或将接口重新构造为可从该语言使用的可重用组件）的成本远远超过了。

从主观上讲，我认为Java不能满足这两种要求。如果有人足够勇于成为先驱者，那么高级语言可能会遇到第二种语言。（《 EVE Online》可能是我们拥有的Python可用的最佳示例，但它使用了主要的Python语言的分支，许多C ++组件来提高性能，甚至就现代而言，这对于一款要求不高的游戏也是如此。）

我在玩《模拟人生3》，还玩了一些。图形引擎是C ++，而脚本和行为引擎是C＃/ Mono。因此，尽管C ++具有时间紧迫性，但诸如交互，游戏逻辑和AI之类的其他东西却是面向对象的托管语言。

• 游戏引擎/图书馆有什么好的港口吗？
• 许多C / C ++开发人员，特别是Windows（大多数商业游戏都在其中编写）的开发人员熟悉Visual Studio。IDE中没有比较。
• 通常，由于Java是可靠的输入，并且已经感觉到没有内存管理问题，因此已经将Java卖给了企业。
• 是的，Java仍然感到它运行缓慢，并且内存管理很差，并且对于游戏来说，它可能不适合该任务。正如在其他一些答案中所述，当您处理实时高性能需求时，垃圾回收将不会减少垃圾回收。电子游戏将CPU和GPU推向极限。

Java和其他虚拟机语言未用于游戏的最大原因之一是垃圾收集。.NET也是如此。垃圾收集已经走了很长一段路，并且在大多数类型的应用程序中都非常有效。为了进行垃圾收集，您确实需要暂停并中断应用程序以收集垃圾。发生收集时，这可能导致周期性的滞后。

Java对于实时应用程序也有同样的问题。当任务必须在特定时间运行时，很难像垃圾回收这样的自动化任务来做到这一点。

不是说Java速度慢。Java不能很好地处理实时任务。

一个很大的原因是视频游戏经常需要直接了解其下面的硬件，并且对于许多体系结构确实没有很好的实现。正是底层硬件体系结构的知识使开发人员能够从游戏系统中挤出每一盎司的性能。您为什么要花时间将Java移植到游戏平台，然后在只编写游戏的时候在该端口上编写游戏？

编辑：这是说它不仅仅是一个“速度”或“没有正确的库”问题。这两件事与此并存，但更多的是“如何使像单元格这样的系统运行我的Java代码？实际上没有任何好的Java编译器可以管理管道和向量就像我需要的。”

性能问题是首要原因。当您看到Quake引擎（http://www.codemaestro.com/reviews/9）中的一种超优化C ++代码时，您会知道它们不会浪费时间在虚拟机上。

当然，可能有一些.NET游戏（哪些？我很感兴趣。是否确实有一些CPU / GPU密集型的游戏？），但我想它的原因更多，因为很多人都是MS技术方面的专家，并且在发布时就跟随Microsoft他们的新技术。

哦，跨平台只是不在视频游戏公司的脑海中。Linux仅占市场的1％，Mac OS仅占市场的百分之几。他们肯定认为不值得抛弃仅Windows技术和DirectX之类的库。

您可以问为什么Web应用程序也不用C或C ++编写。Java的强大之处在于其网络堆栈和面向对象的设计。当然，C和C ++也有。但是在较低的抽象上。那没什么消极的，但是你不想每次都重新发明轮子，是吗？

Java也没有直接的硬件访问权限，这意味着您被任何框架的API所困扰。

我对性能和错误的JVM优化有误解。我说出关于性能的误解，因为C ++游戏的某些Java端口的性能要比C ++游戏的性能高（请参阅Jake 2）。真正的问题，恕我直言，是许多Java程序员并没有把注意力集中在尖端的性能上，而是因为它们易于使用和易于理解/可维护。在C / C ++方面，您实际上是在使用稍微更高级别的汇编语言进行编码，而无需编写汇编或直接的机器代码，它就可以与硬件尽可能接近。

Wikipedia上的游戏引擎列表列出了许多游戏引擎以及其编写的编程语言。

列出了几种Java游戏引擎。

单击某些链接将带您进入用Java编写的游戏和演示示例。这是一对：

• Ardor3D
• 拜顿软件

对于某些游戏和情况，Java的权衡取舍是可以接受的。

当涉及到强大的3D性能时，.NET肯定会遇到与Java相同的问题。在处理3D繁重的操作方面，微软还在库的开发上投入了更多的时间和金钱。

（...就我个人而言，我还认为他们在DirectX和.NET之间的魔术方面有优势）

1. Java很慢，大部分繁重的工作不是由GPU处理的。仍然有动画，物理和AI冲击CPU，所有这些都非常耗时。

2. Java在控制台上不存在，控制台是商业游戏的主要目标。如果在PC上使用Java，则将消除在合理的时间和预算内移植到控制台的能力。

3. 在Java流行之前，游戏行业中许多经验丰富的编码人员已经使用C和C ++。以上两点可能有助于做到这一点，但我希望许多专业游戏编码人员真的不太了解Java。

4. 上面关于中间件的其他人的观点是一个很好的观点，因此我将其添加到我的答案中。有很多专门用于与C / C ++链接的遗留代码和中间件，最后我检查了Java是否具有良好的互操作性。对于大多数公司而言，使用Java会涉及抛出很多代码，其中许多代码已经以某种方式付了钱。

实际上，托管代码很可能会做3D游戏，问题是后台引擎。使用.Net的时间很短，Microsoft提供了DirectX 9的托管DirectX包装器。这是在现在是XNA的抽象之前。

拥有对DirectX api的完全访问权限，.Net游戏可以享受很多乐趣。我知道的最好的例子是用VB.Net编写的www.entombed.co.uk。

不幸的是，在Java方面，它严重缺乏-主要是因为DirectX无法用于Java，并且游戏程序员了解并理解DirectX api-为什么当您要返回DirectX时又要学习另一种api？

游戏营销是一个商业过程；出版商希望获得可量化的低风险投资回报。因此，通常将重点放在消费者会购买的技术头上（例外），以产生可靠的回报-这些tend头往往是表面的视觉效果，例如镜头眩光或更高的分辨率。这些效果是可靠的，因为它们仅使用处理能力的增加-他们利用硬件/摩尔定律的增加。这意味着使用C / C ++-Java通常过于从硬件中提取出来，无法利用这些好处。

我想速度仍然是问题。跨平台将是一个问题，不是因为编写代码时不知道可用的3d卡吗？Java是否有任何东西可以支持3d功能的自动发现？而且我猜想有一些工具可以轻松在wii，xbox和ps3之间移植游戏，但是我敢打赌。

ps3具有通过蓝光支持的Java。检查bd-j网站。

即使是在.Net平台上编写的游戏，也经常对速度进行高度优化，例如直接访问内存和总线。.Net允许使用C / C ++并将其与高级语言（例如C＃）混合使用。

游戏开发工作室通常与硬件供应商紧密合作，后者确实提供对产品低级界面的访问。在这个世界上，您必须使用ASM和C进行设备通信。虚拟环境会使这些程序部分变慢。

无论如何，现代3D游戏实际上确实使用高级语言。通常，您会发现用Lua或Python等语言编写的游戏逻辑。但是在接下来的25年中，典型的3D游戏的核心（I / O，线程，任务调度）将以低级语言编写，或者只要设备不允许它们自己进行抽象和虚拟化（将会出现）。

我同意其他有关利用现有/许可代码库，性能等要素的文章。

我想补充的一件事是，很难通过虚拟机获取讨厌的DRM技巧。

我还认为，有一个傲慢的组件，项目经理认为他们可以使用C ++编写稳定/可靠的代码，并具有对工具和资源的绝对控制权，但是没有所有不利因素，因为“我们”比他们聪明”。

Jagex的Runescape是用Java编写的，“视频游戏”标签可能没有专门应用于在线游戏，但确实有不错的关注者。

已经讨论了很多，即使在Wiki上您也可以找到原因...

• 用于游戏引擎和所有密集内容的C / C ++。
• 用于在游戏中编写脚本的Lua或Python。
• Java-非常糟糕的性能，占用大量内存，并且在游戏机上不可用（它用于某些非常简单的游戏（是，Runescape包含在这里，它不是《战地风云》或《孤岛危机》或其他东西），只是因为很多了解这种编程语言的程序员）。
• C＃-占用大量内存（用于一些非常简单的游戏，只是因为有很多程序员都知道这种编程语言）。

而且我听到越来越多的Java程序员试图说服人们Java并不慢，在屏幕上绘制窗口小部件并在窗口小部件上绘制一些ASCII字符以通过网络接收和发送数据并不慢。建议在这种情况下（网络数据操作）而不是C / C ++使用它。）但是在涉及诸如数学计算，内存分配/操作之类的重要工作时，它确实非常慢。

我记得在MIT网站上有一篇文章，其中展示了如果您使用语言和编译器功能，C / C ++可以做什么：矩阵乘法器（2个矩阵），Java中的1种实现和C / C ++中的1种实现以及C / C ++特性并激活了适当的编译器优化，C / C ++实现比Java实现快296 260倍。

我希望您现在能理解为什么人们在游戏中使用C / C ++而不是Java，想象一下Java中的《孤岛危机》，在这个世界上将没有任何计算机可以处理此问题……+垃圾收集对于仅破坏了图像的小部件来说还可以但它仍被缓存在其中，需要清理，但对于游戏来说不需要清理，可以肯定的是，每次垃圾回收激活都会有更多的滞后。

编辑：因为有人要这篇文章，在这里，我在网络档案中搜索了该内容，希望您满意... MIT案例研究

而且，不，用于游戏的Java仍然是一个糟糕的主意。几天前，一家我不愿透露姓名的大公司开始将他们的游戏客户端从Java 重写为C ++，因为一个非常简单的游戏（就图形而言）落后并给配备强大nVidia GT 5xx和6xx代显卡的i7笔记本电脑供热（不仅是nVidia，关键是这种功能强大的卡可以处理大多数新游戏的Max设置，而不能处理该游戏），并且内存消耗约为2.5-2.6 GB Ram。对于这样简单的图形，它需要一台机器。