我最近一直在研究游戏开发,我的第一个编程语言是Java.在玩了很多以c ++开发的精彩游戏后,我想知道为什么Java在游戏行业中没有大量使用.我查看了jMonkeyEngine 3和其他一些游戏引擎环境,但我看到的屏幕截图远不那么令人惊叹.来自ubisoft的极品飞车热门追逐形式EA和刺客信条等标题传达了这种现实主义.为什么Java不能生产这样的行业实力游戏？这是艺术作品吗？
Java和C#具有自动垃圾收集功能,而c ++则没有.程序员必须密切关注内存使用情况,以及avoud悬空指针等.
多谢你们.
for*_*ran 21
Java和C#具有自动垃圾收集功能,而c ++则没有.程序员必须密切关注内存使用情况,以及avoud悬空指针等.
你自己已经回答了你的问题.
在游戏编程中,垃圾收集不是一个优势.即使Java的性能或多或少与大多数任务的C++相当,JIT甚至可以进行非常积极的优化,超越静态分析期间可以完成的优化; 垃圾收集可以使帧率在最糟糕的时刻下降.
此外,对于图形密集型任务,Java不是很合适,因为运行时有许多事情被认为是不安全的,因此被禁止(比如转换指针来重新解释数据).
另一个重要的问题是业内已经解决的知识.C++在游戏产业中的惯性是巨大的.今天所有的游戏开发者都知道C和C++.拥有一个庞大的开发人员库来减少管理危害之一,这是关键人员离开公司.
但尽管如此,已经有一些成功的游戏,其中一些部分是用Java编写的,比如Vampire:The Masquerade - Redemption.
像Minecraft这样的最新游戏完全用Java编写; 但它并没有采用最先进的图形,因为重点放在虚拟环境的动态性质上.
许多其他游戏和引擎都有一个运行时,它支持基于高性能渲染和网络平台(用C/C++编写)构建的托管(安全自动内存分配和集合)脚本语言,例如虚幻引擎.
小智 19
一般来说,这里所说的一切都是为了不将Java移植到游戏开发中; 是的.游戏行业目前正在进行范式转变.有三件事已经改变或正在改变游戏行业:
游戏不再完全依赖于自己.前者(低级语言)中存在的主要优点是减缓了C#和Java(高级语言)等语言中存在的优势所带来的影响.两个原始但无可否认的例子是在Facebook上运行的游戏,以及手机,平板电脑等远程媒体.
重要的是要说明在所有两种情况下,上面列出的所有三个问题都已解散.在没有服务器的情况下无法工作的游戏无需担心被复制侵权(不包括通过逆向工程进行私有托管).对网络相关游戏的需求需要一种能够平衡系统性能和网络性能的语言(通常是Java和C/C++之间的僵局,严格地说,由于大量已有的库而偏向于 C/C++).然而,在模块化网络程序模块中设计的游戏在诸如C/C++之类的低级语言中开发是不切实际的.有兴趣用C/C++为模块化网络程序模型设计游戏的公司必须创建一个完全专注于那个游戏的虚拟机,或者重新编程/重新编译游戏多次疯狂思考.虽然现在说哪种语言是首选可能为时尚早,但由于三个关键原因,我正在押注Java.
1)JVM允许基于Java的应用程序在任何平台上虚拟运行,无论是Apple,Android,Windows 8还是Linux/UNIX派生(在任何硬件平台上也几乎都支持).
2)Java使用OpenJL(OpenGL衍生产品,它将作为客户端在OpenGL上运行 - jMonkey是OpenJL中设计的引擎).重要的是要注意,只有Microsoft Windows使用DirectX,尽管它可能是好的,它只有一个缺点.事实上,每个可以运行游戏的操作系统都能够在OpenGL中进行渲染,而模块化设计正在以前所未有的方式推动它.(请注意,Microsoft正试图通过垄断Windows 8的分发来解决此问题).
3)Java支持JVM内部的线程,这使得它可以在不使用任何第三方库的情况下充分利用多核处理器.目前,这是所有其他语言(特别是为手机开发的语言)的障碍.
尽管JVM确实存在延迟问题,但应该注意的是,这些问题可以通过线程来消除.我也不会太担心Windows 8和微软的推动.谷歌股票每股720美元,苹果股票每股526美元,微软股价迄今为27美元.虽然苹果很可能受到微软的推动,主要是因为使用了C#,但另一方面,谷歌可能会从中受益.微软在与Google竞争时从未有过多的幸运,谷歌/ Android大量使用Java."愤怒的小鸟"最初是用Java FYI设计的,并且移植到C#用于iPhone.如果Google/Android强制实施标准化,那么微软将会像苍蝇一样堕落,将Apple带入其中.
小智 5
我只想解决这个问题的一个侧面主题，但垃圾收集对于创建 AAA 型游戏引擎的低级、性能关键方面并不一定有帮助。事实上，避免这种对象的引用和收集系统是有帮助的。您甚至希望用户定义的类型在内存中是连续的并适合缓存中的相邻对象等。
除了定期收集垃圾和在内存中分散对象的性能问题之外，游戏不能承受其庞大资源的泄漏，并且垃圾收集器会阻碍那里的事情。是的，我刚才说GC阻碍了避免泄漏的能力。
垃圾收集并不是防止资源泄漏的灵丹妙药。
尽管听起来有悖常理，但看看当今泄漏最严重的应用程序：这些应用程序使用的时间越长，内存使用量就会持续上升。通常它们不是 C 或 C++ 应用程序。C/C++ 应用程序可能因崩溃而臭名昭著，但泄漏却不那么严重。那些泄漏的代码通常是用具有垃圾收集功能的语言编写的。
以 Flash 游戏为例。有很多软件，不仅仅是完整的业余软件，它们使用越来越多的资源，并且玩游戏的时间越长，速度就越慢，迫使您有时重新启动浏览器才能再次加快游戏速度。然而它们是用 ActionScript 编码的，这是一种具有垃圾收集功能的语言。
理论上垃圾收集应该减少泄漏。在实践中，它通常会消除更便宜且更容易修复和发现的物理泄漏（哎呀我忘了删除这个字符串），以换取更昂贵且难以隔离的逻辑泄漏（哎呀，系统会导致大量资源徘徊，直到整个游戏关闭）。
这是因为在 GC 语言中，如果您想创建新资源 的共享所有权，R您所要做的就是将其句柄/引用存储在另一个对象 中A。B并且C还可能存储 的句柄R，现在R拥有三个所有者，并且只有在所有三个所有者都释放引用时才会被释放。用户只能看到并使用A存储的内容，因此游戏逻辑涉及定期删除R，但对它的引用却默默地A徘徊在代码忘记释放的地方。在 C/C++ 中，这里的悬空指针实际上可能更可取，因为它会在游戏测试期间导致立即可检测和可纠正的问题，运行调试器的开发人员将非常快速地发现并修复问题。在 GC 语言中，检测起来极其困难，虽然程序不会崩溃，但它可能会开始严重泄漏。BCBC
因此，GC 肯定会避免悬空指针，但如果某些东西在 C/C++ 中是悬空指针，而在 GC 语言中不会悬空指针，那么这就是 GC 语言中的逻辑资源泄漏和 C/C++ 中的段错误。换句话说，GC 将悬空指针交换为永远徘徊的悬空资源。它将原本明显的崩溃变成了无声的泄漏，这可能是调试过程中的噩梦（甚至可能在产品发布后很长一段时间内都未被注意到）。因此，对于像游戏这样创建大量动态世界、图形和物理对象等并且可能在每一帧都创建的游戏，逻辑资源泄漏是一个大问题。
当资源泄漏不是什么大问题时，垃圾收集是最好的选择。
不幸的是，前面的场景在使用 GC 的大型团队环境中太常见了，特别是如果每个程序员都不是非常谨慎地对待垃圾收集的陷阱和对弱引用的强烈需求。因此，GC 不一定是制作游戏的优势，除非您只是在谈论最高级别的人类逻辑。即使在避免泄漏方面，必须不断创建、访问和销毁资源的较低级别、微妙的系统逻辑通常会表现得更好。