为什么只有少数视频游戏是用 Java 编写的?

为什么很多商业的3D 视频游戏(不是随机的开源2D 游戏)没有用 Java 编写?从理论上讲,这很有意义: 你几乎可以免费获得生产力提升和跨平台应用程序,还有其他一些东西,比如大量的 Java 库和内置的垃圾收集(尽管我承认我不确定后者是否是一件好事)。那么为什么它很少被使用呢?我只能想到几个为 Java 平台编写的流行商业游戏。

这是因为性能吗? 如果是这样,难道大部分繁重的工作不会由 GPU 来完成吗?

220674 次浏览

我觉得。NET 有很多和 Java 相同的问题。微软刚刚在用 XNA 向开发者营销方面做得更好: -)

首先,Java 缺乏运算符重载,这使得你必须处理的所有数学问题才能得到一个工作绘图管线,这非常非常烦人,而且难以阅读。

你需要处理的所有矩阵乘法和仿射向量,如果它们是在结构良好的数学表达式中,而不是像

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

太可怕了,数学不应该是这样的。

.NET 在3D 性能方面肯定和 Java 有一些相同的问题。微软还投入了大量的时间和金钱在开发图书馆时,涉及到3D 繁重的操作。

(... 就我个人而言,我也认为他们在 DirectX 和.NET 之间的魔力方面占了上风)

  • 有没有好的游戏引擎/库端口?
  • 许多 C/C + + 开发人员,特别是那些在 Windows 上(大多数商业游戏都是在 Windows 上编写的)的开发人员都熟悉 Visual Studio。IDE 中没有比较。
  • 一般来说,Java 已经被出售给企业,因为它是可靠的输入,并且它有一种没有内存管理问题的感觉。
  • 是的,Java 仍然被认为速度慢,内存管理差,而且对于游戏来说,它可能不适合这项任务。正如在其他一些答案中所述,当您处理实时高性能需求时,垃圾收集不会减少它。视频游戏将 CPU 和 GPU 推向极限。

我想速度还是个问题。跨平台将是一个问题,是不是因为你不知道什么3D 卡可用时,你写的代码?Java 有什么支持自动发现3D 功能的东西吗?而且我猜有一些工具可以简化在 wii,xbox 和 ps3之间移植游戏的过程,但是我敢打赌它们很昂贵。

Ps3有 java,通过蓝光支持。请检查 bd-j 站点。

一个很大的原因是视频游戏需要对底层硬件的直接了解,通常情况下,对于许多架构来说,确实没有很好的实现。正是对底层硬件架构的了解,使得开发人员能够从游戏系统中榨取每一盎司的性能。为什么要花时间把 Java 移植到游戏平台上,然后在这个移植上写一个游戏呢?

编辑: 这就是说,这不仅仅是一个“速度”或“没有正确的库”的问题。这两件事与这个密切相关,但它更多的是一个问题“我如何让一个系统像 cell be 一样运行我的 Java 代码?”?没有任何好的 Java 编译器可以像我需要的那样管理管道和向量。."

性能问题是第一个原因。当你看到 Quake 引擎(http://www.codemaestro.com/reviews/9)中那种超级优化的 C + + 代码时,你就知道他们不会把时间浪费在虚拟机上。

当然可能有一些。NET 游戏(哪些?我很感兴趣。真的有 CPU/GPU 密集型的吗?)但是我猜更多的是因为许多人是微软技术的专家,当微软发布他们的新技术的时候,他们跟随着微软。

哦,而且跨平台游戏公司根本不会考虑这个问题。Linux 只占市场的1% 左右,Mac OS 则多了几个百分点。他们肯定认为不值得放弃只使用 Windows 的技术和像 DirectX 这样的库。

Java 和其他虚拟机语言不能用于游戏的最大原因之一是垃圾收集。同样的道理。NET.垃圾收集已经取得了很大的进展,在大多数类型的应用程序中都能很好地工作。但是,为了执行垃圾收集,您确实需要暂停并中断应用程序以收集垃圾。这可能会在收集发生时导致周期性延迟。

Java 对于实时应用程序也有同样的问题。当任务必须在特定时间运行时,很难让垃圾收集等自动化任务尊重这一点。

不是 Java 慢,而是 Java 不擅长处理实时任务。

我在玩模拟人生3我四处打探了一下。 图形引擎是 C + + ,而脚本和行为引擎是 C #/Mono。 因此,虽然 C + + 有时间关键位,其他东西像。交互,游戏逻辑,人工智能是在一个面向对象的管理语言。

你可以问为什么 web 应用程序不是用 C 或 C + + 编写的。Java 的强大之处在于它的网络栈和面向对象的设计。当然 C 和 C + + 也有这样的功能。但是在一个较低的抽象层面上。这没什么不好的,但你不想每次都重新发明轮子吧?

Java 也没有直接的硬件访问权限,这意味着您只能使用任何框架的 API。

我认为约翰•卡马克(John Carmack)说得最好:

最大的问题是 Java 真的很慢。在纯 CPU/内存/显示/通信水平上,大多数现代手机应该是比 Game Boy Advanced 更好的游戏平台。使用 Java,在大多数手机上,你的 CPU 处理能力只有原来的4.77 mhz IBM PC 的水平,而且对所有事情的控制都很糟糕。 [ ... 剪... ] 写-一次-运行-任何地方。哈。哈哈哈哈。我们现在只在四个平台上测试,没有一个平台有完全相同的怪癖。所有的商业游戏都是针对每个(通常是100 +)平台单独进行调整和编译的。便携性并不是糟糕表现的理由。

(来源)

当然,他谈到的是移动平台,但是我发现 Java 整体上也存在类似的问题,这些问题都来自于 C + + 背景。 我怀念能够按照自己的方式在堆栈/堆上分配内存的日子。

游戏开发世界是一个有趣的世界: 一方面,他们往往很快接受新的想法,另一方面,他们仍然在石器时代。

事实上,除了 C/C + + ,很少有人愿意切换到.NET/Java/其他任何东西。

大多数游戏公司从其他公司授权游戏引擎的部分。这些部分是用 C + + 编写的,尽管您可能有权访问源代码以便移植它,但是这需要付出很多努力(当然,许可证需要允许这样做)。

此外,C + + 中已经存在许多遗留代码。如果以前项目的代码可以重用(比如说,如果你正在写续集) ,那就更有利于坚持使用相同的语言,而不是用新的语言重写(因为你可能会重新引入大量的错误,而这些错误需要花费时间来消除)。

最后,用100% C + + 编写游戏是很少见的——很多游戏都是用脚本语言编写的,不管是自定义的还是集成了现有的语言(Lua 是当今最流行的语言之一)。

就垃圾收集而言,这可能是个小问题。问题不在于它是否存在,而在于它是如何工作的——垃圾收集器必须是非阻塞的(或者至少保证只是非常短暂地阻塞) ,因为当它扫描所有分配的内存以查看哪些内存可以释放时,让游戏暂停10秒是完全不可接受的。我知道 Java 在内存即将耗尽的时候会在 GC 中出现相当多的问题(对于一些游戏来说,这是必然的)。

您还受到一些限制: 由于运行时开销,无法完全利用硬件。想象一下,Crysis 是用 Java 编写的... ... 即使这是唯一可见的区别,它也不会是一样的(我也非常肯定,你需要一个 Core i7来运行它。).

这并不意味着这些语言不能在游戏开发中占有一席之地——不,我指的不仅仅是工具编程。对于大多数游戏来说,你不需要从 C + + 中获得额外的性能,包括3D 游戏,如果你从头开始编写,使用类似 XNA 的东西是非常有意义的——事实上,它很有可能会这样做。

就商业游戏而言,RuneScape算吗?这可能是最成功的 Java 游戏了。

我猜是对性能的误解和糟糕的 JVM 优化。我之所以说对性能有误解,是因为有些 C + + 游戏的 Java 端口比 C + + 游戏的性能更快(参见 Jake 2)。恕我直言,真正的问题在于,许多 Java 程序员并没有过多地关注前沿性能,而是关注代码的易用性和可理解性/可维护性。在 C/C + + 方面,您基本上使用稍高级别的汇编语言编写代码,而且它与硬件非常接近,不需要使用汇编语言或直接的机器代码。

  1. Java 很慢,大部分繁重的工作都不是由 GPU 处理的。还有动画,物理和人工智能对中央处理器的冲击,所有这些都非常耗时。

  2. Java 不存在于控制台上,而控制台是商业游戏的主要目标。如果您在 PC 上使用 Java,那么您将在合理的时间和预算内丧失移植到控制台的能力。

  3. 在 Java 流行之前,游戏行业中许多经验丰富的程序员就已经在使用 C 和 C + + 了。上面的两点可能对此有所贡献,但是我认为许多专业的游戏编程人员并不真正了解 Java。

  4. 其他人关于上述中间件的观点是好的,所以我把它加入到我的答案中。有很多遗留代码和中间件是专门编写来链接 C/C + + 的,而且我上次检查 Java 没有很好的互操作性。对于大多数公司来说,使用 Java 需要扔掉大量代码,其中大部分代码都是以这样或那样的方式支付的。

Jagex 的 Runescape 是用 Java 编写的,“ video game”标签可能不会明确地将其应用于在线游戏,但是它确实有一个不错的追随者。

第一点:

  • 任何来自 Java 的生产力提升都是 假设,句法几乎是 和 C + + 一样,所以你真的 就指望着从记忆中省钱 管理及标准图书馆。 图书馆没有什么可以提供的 游戏开发者和内存 管理是一个有争议的问题 到垃圾收集

  • 跨平台的“免费”并不像 正如你所想的那样,因为很少有人 开发人员希望使用 OpenGL 和 一些关键平台可能缺乏 好的 Java 实现或包装器 为他们的本地图书馆,是否 用于图形、音频、网络等

但主要的问题是向后兼容性。游戏开发人员从 C 语言迁移到 C + + ,从汇编语言迁移到 C 语言,纯粹是因为迁移过程很顺利。每个代码都与之前的代码紧密互操作,它们之前的所有代码都可以在新语言中使用,通常是通过单个编译器。因此,迁移的速度可以按照您喜欢的那样慢或那样快。例如,我们今天使用的一些旧头文件中仍然包含 # ifdef WATCOMC,而且我认为在过去的十年或更长的时间里,没有人在这里使用过 Watcom 编译器。在旧代码中有大量的投资,每个位只在需要时被替换。如果您更改为一种不与现有代码进行本机互操作的语言,那么从一个游戏到下一个游戏替换和升级零碎内容的过程就远远不切实际。是的,C + +/Java 互操作性是可能的,但是与简单地编写“ C with a bit of C + +”或在 C 中嵌入 asm 块相比,这是非常不切实际的。

要想正确地取代 C + + 成为游戏开发者的首选语言,它必须做到以下两点之一:

  1. 易于互操作 现有的遗留代码,因此 保存投资及 维持对现有 库和工具
  2. 显而易见 表现出足够的预见性 生产力提高了,生产成本提高了 重写所有你自己的代码(或 将接口修改为 可重用的组件 从那种语言)比 盖好了。

主观上,我不认为 Java 符合这两者中的任何一个。如果有人足够勇敢成为先驱者,一门更高级别的语言可能会遇到第二种语言。(EVE Online 可能是我们拥有的 Python 可用性的最好例子,但是它使用了主要 Python 语言的分支,许多 C + + 组件来提高性能,甚至对于一个相当简单的现代游戏来说也是如此

甚至游戏写在。网络平台通常高度优化了速度,比如直接访问内存和总线。.Net 允许使用 C/C + + 并将其与 C # 等高级语言混合使用。

游戏开发工作室通常与硬件供应商紧密合作,这些供应商确实提供了对其产品的低级接口的访问。这是一个必须使用 ASM 和 C 进行设备通信的世界。虚拟环境会减慢这些程序部分的速度。

无论如何,现代3D 游戏实际上使用更高级的语言。通常,您会发现用 Lua 或 Python 等语言编写的游戏逻辑。但是典型的3D 游戏的核心(I/O、线程、任务调度)将在未来25年内用低级语言编写,或者因为长设备不允许自己进行抽象和虚拟化(这将会出现)。

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

我想补充的一点是,很难通过虚拟机使用讨厌的 DRM 技巧。

另外,我认为还有一个傲慢的成分,项目经理认为他们可以用 C + + 编写稳定/可靠的代码,并且拥有绝对控制他们的工具和资源的所有好处,但是没有那些使他们的竞争复杂化和停滞不前的负面因素,因为“我们比他们更聪明”。

实际上,托管代码做3D 游戏是很有可能的,问题在于后台引擎。和。Net,在一个短暂的时期内,微软向 DirectX9提供了一个托管 DirectX 包装器。这是在现在是 XNA 的抽象之前。

被授予对 DirectX API 的完全访问权限。网络游戏是一种享受。我所知道的最好的例子是 www.entombed.co.uk ,它是用 vb. net 编写的。

不幸的是,在 Java 方面,它严重缺乏——主要是因为 DirectX 不能用于 Java,而且游戏程序员知道并理解 DirectX api ——为什么要在返回 DirectX 时学习另一个 api 呢?

这已经被谈论了很多,你可以找到甚至在维基的原因..。

  • C/C + + 的游戏引擎和所有密集的东西。
  • Lua 或 Python,用于在游戏中编写脚本。
  • Java-非常糟糕的性能,大的内存使用 + 它不能在游戏控制台上使用(它被用于一些非常简单的游戏(是的,Runescape 计数在这里,它不是战场或 Crysis 或其他什么) ,只是因为有很多程序员知道这种编程语言)。
  • C #-大内存使用(它用于一些非常简单的游戏,因为很多程序员都知道这种编程语言)。

我听到越来越多的 Java 程序员试图说服人们 Java 并不慢,在屏幕上绘制一个小部件,在小部件上绘制一些 ASCII 字符,通过网络接收和发送数据并不慢(建议在这种情况下使用它(网络数据操作)而不是 C/C + +) ... ... 但是当涉及到严肃的事情,如数学计算,内存分配/操作和很多这样的好东西时,它是非常慢的。

我记得麻省理工学院网站上的一篇文章,他们展示了如果你使用 C/C + + 语言和编译器功能,C/C + + 可以做什么: 一个矩阵乘法器(2个矩阵) ,一个 Java 实现和一个 C/C + + 实现,C/C + + 功能和适当的编译器优化被激活,C/C + + 实现比 Java 实现快约296260倍。

我希望你现在明白为什么人们在游戏中使用 C/C + + 而不是 Java 了,想象一下在 Java 中的 Crysis,世界上没有任何一台计算机可以处理这个问题... ... + 垃圾收集对于那些只是破坏了一个图像的 Widgets 来说是可以的,但是它仍然被缓存在那里,需要被清理,但是对于游戏来说不是这样,当然,你在每一个垃圾收集激活上会有更多的延迟。

编辑 : 因为有人要求这篇文章,在这里,我在网络档案中搜索得到这个,我希望你满意... ... 麻省理工学院案例研究

另外,Java 对于游戏来说仍然是一个糟糕的想法。就在几天前,一个我不愿透露名字的大公司开始重写他们的游戏 客户,从 Java 到 C + + ,因为一个非常简单的游戏(在图形方面)延迟和加热 i7笔记本电脑与强大的 nVidia GT 5xx 和6xx 代显卡(不仅 nVidia,这里的关键是这个强大的卡可以处理最大设置的大多数新游戏,不能处理这个游戏)和内存消耗约2.5-2.6 GB 内存。对于这样简单的图形,它需要一个野兽的机器。

维基百科上的游戏引擎列表 列出了许多游戏引擎以及它们所使用的编程语言。

列出了几个 Java 游戏引擎。

单击其中的一些链接,您将看到用 Java 编写的游戏和演示示例。这里有一些:

对于某些游戏和情况,Java 的权衡可能是可以接受的。

游戏营销是一个商业过程,出版商希望获得可量化的低风险投资回报。 因此,人们关注的焦点通常是消费者为了获得可靠回报而购买的技术噱头(除了一些例外)——这些往往是表面的视觉效果,如镜头眩光或更高的分辨率。 这些效应是可靠的,因为它们只是利用了处理能力的提高——它们利用了硬件/摩尔定律的提高。 这意味着使用 C/C + +-Java 通常是从硬件抽象出来的,无法利用这些好处。