为什么只有几个用Java编写的视频游戏？

为什么没有很多用Java编写的商业3D视频游戏(不是随机开源2D游戏)？从理论上讲,它很有意义:几乎免费提供生产力提升和跨平台应用程序,其中包括大量的Java库和内置的垃圾收集(尽管我承认我'我不确定后者是不是一件好事.那为什么很少使用它？我只能想到为Java平台编写的一些流行的商业游戏.

是因为性能？如果是这样,那么大部分繁重的工作都不会由GPU完成吗？

1> Michael Mads..：

---

游戏开发世界是一个有趣的:一方面,他们经常快速接受新的想法,另一方面,他们仍然处于石器时代.

事实是,在转换到.NET/Java/C/C++以外的任何东西时,很少有这么大的动力.

大多数游戏公司从其他公司获得游戏引擎的部分许可.这些部分是用C++编写的,尽管您可以访问源代码以便移植它,但这需要花费很多精力(当然,许可证需要允许它).

此外,C++中已存在许多遗留代码.如果以前项目中的代码可以重复使用(例如,如果你正在写续集),那么更重要的是支持使用相同的语言,而不是用新语言重写它(更多的是因为你可能会重新引入大量的虫子,你需要花时间熨烫.

最后,用100%C++编写游戏很少见 - 很多是使用脚本语言完成的,无论是自定义语言还是只是整合现有语言(Lua是目前比较流行的语言之一).

就垃圾收集而言,这可能是一个问题.问题不在于它存在,更多的是它如何工作 - 垃圾收集器必须是非阻塞的(或者至少保证只能非常短暂地阻塞),因为让游戏冻结10秒是完全不可接受的它会扫描所有已分配的内存以查看可以释放的内容.我知道当Java接近内存耗尽时,Java往往会在GC中窒息(对于某些游戏,它会).

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

这并不意味着这些语言在游戏开发中没有自己的位置 - 不,我不只是指工具编程.对于大多数游戏来说,你不需要从C++中获得额外的性能,包括3D游戏,如果你是从头开始编写它,那么使用像XNA这样的东西是完全合理的 - 事实上,有一个很有可能.

就商业游戏而言 - RuneScape是否算数？这可能是那里最成功的Java游戏.

---

显然你不会在JVM上运行Crysis; 地狱,如果你用汇编语言编写游戏,你仍然需要一台超级计算机才能在完全设置下运行它.但是对于出色的洞察力+1,谢谢.

---

你无法将虚幻竞技场3或孤岛危机与Runescape进行比较.如果需要考虑图形质量,则需要尽可能少地使用低级语言.当然,对于Indy或图形不是主要卖点的游戏,Java是C/C++的绝佳替代品.

---

@JulianR准备和维护要高效渲染的场景可能会有很大的工作量,因此语言和相关的语言开销对图形很重要.

---

@GuiSim:对于大多数游戏来说,图形质量不是主要卖点.我只能想到一些用图形创建的游戏(我正在考虑"孤岛危机",当时也考虑"半条命2").我不认为大多数游戏开发者都非常关心图形,只要它们"足够好"(与大多数其他游戏相当).

---

图形与语言几乎没有关系.物理,AI,是的.图形,没有.

2> Marc..：

---

我认为John Carmack说得最好:

最大的问题是Java真的很慢.在纯cpu /内存/显示器/通信级别上,大多数现代手机应该是比Game Boy Advanced更好的游戏平台.使用Java,在大多数手机上,您只能获得原始4.77 mhz IBM PC的CPU功率,以及对所有内容的糟糕控制.[...剪辑...]一次写入任何地方.哈.哈哈哈哈哈.我们现在只测试四个平台,而不是一对具有完全相同的怪癖.所有商业游戏都针对每个(通常是100+)平台进行了单独调整和编译.可移植性不是可怕性能的理由.

(来源)

当然,他在谈论移动平台,但我发现Java的整体来自C++背景也存在类似的问题.我错过了能够按照我自己的条件在堆栈/堆上分配内存.

---

约翰卡马克说.案件结案.

---

这个引用是从2005年开始的.自那时起,Java技术和手机功能都有了很大改进.手机游戏与PC游戏的比较是将苹果与橙子进行比较.

---

当我读到"Java真的很慢"时,我感到很不安.这就像说价值5万美元的跑车比10万美元的跑车慢.当然,它的速度较慢,但​​90%的时间,它所做的工作仍然很好而且成本只有一半;)没有火焰战争的意图.我同意上述原因是为什么孤岛危机和喜欢游戏不是用Java编写的.

---

@Chris Dail,这强调了Java性能的整个问题.Java性能有所改善吗？不,手机变得更快.游戏应该突破现实主义的极限,因此在你编写一行代码是不可接受的之前,突破了硬件的极限,并且丢掉了30%-40%的性能.

---

我发现这个争议很奇怪.Java ME与Android中的Java不同,也与PC上的Java不同.Java ME通常依靠手机制造商提出JVM.有些人做得很好,有些人做不到.难怪Carmack抱怨他们.Android拥有自己的VM,而不是JVM.它有一些严重的问题(从我的角度来看).Oracle的HotSpot VM与这两种情况完全不同.如果人们比较所有这些事情,我唯一能得出的结论就是他们不知道他们在谈论什么.

---

引用来源可能是一件好事

---

我会说在解释(可能是文章似乎暗示它)J2ME和在Sun VM上运行的JIT或静态编译的Java之间存在相当大的差异.

---

为John Carmac参考+1.:)

---

都很好.另一方面,当人们开始引用那些有缺陷/偏向的Java vs C基准并声称C/C++时代已经死亡时,我可以得到(如果不是更多)防御.很高兴我们可以满足中途= P.

3> Welbog..：

---

首先,Java缺乏运算符重载使得您必须处理的所有数学运算都非常,非常烦人且难以阅读.

如果它们处于格式良好的数学表达式而不是像面向对象的表达式中那么你需要处理的所有矩阵乘法和仿射向量都要容易得多.

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

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

---

我记得早在96年我就认为是,Sun的一些设计师正在伯克利发表关于Java的演讲.William Kahan(http://en.wikipedia.org/wiki/William_Kahan)正在就此问题向他们致敬.:)

---

惩罚其他人一些坏苹果？这是我更喜欢C#的一个原因.如果我真的需要运算符重载它就在那里.

---

我认为有充分的理由不允许操作员使用某种语言进行重载:防止人们使用它.它是一个强大的工具,非常适合数学,但对其他一切都很危险.作为编码人员,他们倾向于错过用于缩短代码的时间,以及人们开始执行地图将迭代与函数相乘的时刻,或者甚至在为函数定义所有算术运算时,代码可读性将达到0.是的,我花了相当多的时间来移植这样的代码.: - 这是一个设计选择.而设计选择往往是有争议的.

4> Joel Martine..：

---

我认为.NET有很多与Java相同的感知问题.微软刚刚用XNA向开发人员做了更好的营销工作:-)

---

XNA还可以将.NET应用程序部署到XBox.我还没有看到任何与Java相当顺利的东西.

---

@JoelMartinez另一个更新:不可能为Windows Phone 8编写XNA游戏.

5> Kylotan..：

---

小点首先:

Java的任何生产力提升都是假设的.语法与C++几乎完全相同,因此您只需要节省内存管理和标准库.由于垃圾收集,图书馆几乎没有提供游戏开发人员和内存管理是一个有争议的问题.

跨平台"免费"并不像你想象的那么好,因为很少有开发人员想要使用OpenGL,而且几个关键平台可能缺乏良好的Java实现或其本机库的包装,无论是图形,音频,网络等.

但主要是,问题是向后兼容性.游戏开发人员从C转移到C++,从组装转移到C,纯粹是因为迁移路线很顺利.每个代码都与之前的代码密切互操作,并且所有以前的代码都可以在新语言中使用,通常通过单个编译器.因此,迁移速度与您喜欢的一样慢或者快.例如,我们今天使用的一些旧标题仍然包含#ifdef WATCOMC,我认为没有人在十年或更长时间内使用过Watcom编译器.对旧代码进行大量投资,每个位只在需要时替换.如果您更改为与您的现有代码本身不能互操作的语言,那么从一个游戏到下一个游戏中替换和升级碎片的过程就不那么实用了.是的,C++/Java互操作性是可能的,但与简单地用C语言编写"C"或在C语言中嵌入asm块相比,这是非常不切实际的.

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

可轻松与现有遗留代码互操作,从而保留投资并维护对现有库和工具的访问,或者

显而易见地显示出前期足够的生产力提升,即重写所有自己的代码(或将接口重新编写为可从该语言使用的可重用组件)的成本超出了覆盖范围.

主观上,我认为Java不符合其中任何一个.如果有人勇敢地成为先锋,那么更高级别的语言可能会达到第2级.(EVE Online可能是我们可以使用Python的最好例子,但它使用了主要Python语言的分支,许多C++组件用于提高性能,甚至是现代术语中相当低要求的游戏.)

6> cgp..：

---

有没有好的游戏引擎/图书馆端口？

许多C/C++开发人员,特别是Windows上的(大多数商业游戏都是编写的)熟悉Visual Studio.在IDE中没有比较.

一般来说,Java已经被出售给企业,因为它具有可靠的输入,并且它具有不存在内存管理问题的感觉.

是的,Java仍然感觉它很慢,并且它的内存管理很差,而对于游戏来说,它可能不适合这项任务.正如其他一些答案中所述,垃圾收集只是在处理实时高性能要求时不会削减它.视频游戏将CPU和GPU推向极限.

---

我认为在这一点上我比过去更有可能同意.JVM的优化得到了改进; 然而,鉴于JavaScript等松散类型语言的性能改进,Java的性能相当不可原谅.有很多关于Java性能的辩护者.(但最终的感知表现才是最重要的)''

7> John Simon..：

---

我正在玩模拟人生3,我做了一些探索.图形引擎是C++,而脚本和行为引擎是C#/ Mono.因此,虽然C++是时间关键位,但其他东西,如.interaction,游戏逻辑,AI,都是面向对象的托管语言.

---

Wine不是虚拟机,它是一个模拟Windows运行时库行为的运行时库.因此名称(Wine Is Not a Emulator).

---

然后对于Mac版本,他们将整个内容推送到修改后的Wine虚拟机中.我认为仍然比直接Java更快:-)

---

只是侧面说明,即使在优秀的计算机上,模拟人生3也因表现不佳而臭名昭着.

---

这在游戏中很常见，通常不是很紧要的逻辑是用某种脚本语言（通常是lua或python）编写的。

8> Chris Dail..：

---

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

Java对于实时应用程序也存在同样的问题.当任务必须在特定时间运行时,很难有一个自动化任务,如垃圾收集方面.

Java不是很慢.这是Java不擅长处理实时任务.

---

这不是20世纪90年代.当调整为低暂停时,垃圾收集器现在相当不错.

9> San Jacinto..：

---

一个很大的原因是视频游戏需要直接了解下面的硬件,而且很多时候都没有很好的实现.它是底层硬件架构的知识,允许开发人员从游戏系统中挤出每一盎司的性能.为什么你会花时间将Java移植到游戏平台,然后在你可以编写游戏时在该端口上编写游戏？

编辑:这就是说它不仅仅是"速度"或"没有合适的库"问题.这两件事与此相辅相成,但更多的是"我如何使像像单元格一样的系统运行我的java代码？"实际上没有任何好的java编译器可以管理管道和向量就像我需要......"

10> Ksempac..：

---

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

当然可能会有一些.NET游戏(哪些？我很感兴趣.是否有一些真正的CPU/GPU密集型游戏？),但我想这更多是因为很多人都是MS技术的专家并且在他们推出时跟随微软他们的新技术.

哦,跨平台只是不是视频游戏公司的想法.Linux只占市场的1%左右,而Mac OS则高出几个百分点.他们肯定认为不值得倾倒仅限Windows的技术和DirectX等图书馆.

---

"跨平台只是不在视频游戏公司的脑海中" - 这就是为什么我完全尊重那些公司.:)