Java游戏引擎
我最近一直在研究游戏开发，我的第一个编程语言是Java。 在玩了很多以c ++开发的精彩游戏后，我想知道为什么Java在游戏行业中没有大量使用。 我查看了jMonkeyEngine 3和其他一些游戏引擎环境，但我看到的屏幕截图远不那么令人惊叹。 来自ubisoft的极品飞车追逐formsEA和刺客信条等标题传达了这种真实感。 为什么Java不能生产这样的行业实力游戏？ 这是艺术作品吗？
Java和C＃具有自动垃圾收集function，而c ++则没有。 程序员必须更加关注内存使用情况，以及avoud悬空指针等。
多谢你们。
Java和C＃具有自动垃圾收集function，而c ++则没有。 程序员必须更加关注内存使用情况，以及avoud悬空指针等。
你自己已经回答了你的问题。
在游戏编程中，垃圾收集不是一个优势。 即使Java的性能或多或少与大多数任务的C ++相当，JIT甚至可以进行非常积极的优化，超过静态分析期间可以完成的优化; 垃圾收集可以使帧率在最糟糕的时刻下降。
此外，对于图形密集型任务，Java不是很合适，因为运行时有许多东西被认为是不安全的，因此被禁止（比如转换指针来重新解释数据）。
另一个重要的问题是业内已经解决的知识。 C ++在游戏产业中的惯性是巨大的。 今天所有的游戏开发者都知道C和C ++。 拥有一个庞大的开发人员库来减少管理危害之一，这是关键人员离开公司。
但尽管如此，还是有一些成功的游戏，其中一些部分是用Java编写的，比如Vampire：The Masquerade – Redemption 。
像Minecraft这样的最新游戏完全用Java编写; 但它并没有采用最先进的图形，因为重点更多地放在虚拟环境的动态性质上。
许多其他游戏和引擎都有一个运行时，它支持基于高性能渲染和网络平台（用C / C ++编写）构建的托管（安全自动内存分配和集合）脚本语言，例如虚幻引擎 。
一般来说，这里所说的一切都是为了不将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中进行渲染，而模块化设计正在以前所未有的方式推动它。 （请注意，微软试图通过垄断Windows 8的分发来解决这个问题）。
-
3）Java支持在JVM内部进行线程化，这使得它可以在不使用任何第三方库的情况下充分利用多核处理器。 目前，这是所有其他语言（特别是为手机开发的语言）的障碍。
尽管JVM确实存在延迟问题，但应该注意的是，这些问题可以通过线程来消除。 我也不会太担心Windows 8和微软的推动。 谷歌股票每股720美元，苹果股票每股526美元，微软股价迄今为27美元。 虽然苹果很可能受到微软的推动，主要是因为使用了C＃，但另一方面谷歌很可能从中受益。 微软在与Google竞争时从未有过多的幸运，谷歌/ Android大量使用Java。 “愤怒的小鸟”最初是用Java FYI设计的，并且移植到C＃用于iPhone。 如果Google / Android强制实施标准化，那么微软就会像苍蝇一样堕落，将Apple带走。
您的问题的答案是艺术品和财务资源。 最初的Minecreft是由java中的一个人开发的。 而作为AC或NFS的标题是由数千人的团队开发的。 比较资源。 此外，育碧使用了custrom游戏引擎。 如果你是唯一的开发者，你应该专注于这个想法，因为缺乏资源。 如果你有一个想法，garbege收集器在普通的单一开发者游戏中是不可用的。 作为唯一的开发人员，您应该选择最快速的开发技术。
我想解决这个问题的一个主题，但垃圾收集对于创建AAA类游戏引擎的低级，性能关键方面没有必要帮助。 实际上，避免使用这种对象的引用和收集系统是有帮助的。 您甚至希望用户定义的类型在内存中是连续的，并且适合缓存中的相邻对象等。
除了定期收集垃圾和在内存中散射物体的性能问题之外，游戏不能因其庞大的资源而泄漏，垃圾收集器会阻碍那里的事情。 是的，我只是说GC阻碍了避免泄漏的能力 。
垃圾收集不是防止资源泄漏的银弹。
听起来反直觉，看看今天最漏洞的应用程序：使用它们的时间越长，内存使用量越来越多。 通常它们不是C或C ++应用程序。 C / C ++应用程序可能因崩溃而臭名昭着，但对于泄漏而言并非如此。 那些漏洞的通常用垃圾收集的语言编程。
例如，参加Flash游戏。 有许多不仅仅是完整的业余软件，它们使用越来越多的资源，并且游戏时间越长越慢，迫使您有时重新启动浏览器以再次快速恢复游戏。 然而，它们是用ActionScript编写的，ActionScript是一种具有垃圾收集function的语言。
从理论上讲，垃圾收集应该减少泄漏。 在实践中，它通常会消除更便宜，更容易修复和现场的物理泄漏（哎呀我忘了删除这个字符串）以换取更昂贵且难以隔离的逻辑泄漏（哎呀，逻辑系统会导致庞大的资源徘徊，直到整个游戏关闭为止。
这是因为在GC语言中，如果要创建新资源的共享所有权， R ，您只需在另一个对象A存储对它的句柄/引用。 B和C也可能存储R的句柄，现在R有三个所有者，只有当所有三个所有者都释放引用时才会释放。 用户只能查看和使用A商店，因此游戏逻辑涉及定期从A删除R ，但是对它的引用在B和C静静地停留在代码忘记释放的地方。 在C / C ++中， B和C的悬空指针实际上可能是更可取的，因为它会在游戏测试期间导致立即可检测和可纠正的问题，运行调试器的开发人员将很快发现并修复问题。 在GC语言中，检测起来非常困难，虽然程序不会崩溃，但它可能会开始大量泄漏。
所以GC肯定避免悬空指针，但是如果C / C ++中存在悬空并且不会悬浮在GC语言中，那么它就是GC语言中的逻辑资源泄漏和C / C ++中的段错误。 换句话说，GC交换悬空指针悬挂永远存在的资源。 它将一个明显的崩溃交换成一个无声的泄漏，这可能是一个发现的调试噩梦（甚至可能在发布产品后很长时间没有注意到）。 因此，对于类似于创建大量动态世界和图形和物理对象等的游戏而言，可能在每一帧，逻辑资源泄漏都是一个大问题。
当资源泄漏不是什么大问题时，垃圾收集是最好的。
不幸的是，在使用GC的大规模团队环境中，这个前一个场景非常常见，特别是如果每个程序员都不是非常谨慎垃圾收集的缺陷和对弱引用的强烈需求。 因此，GC并不一定能成为制作游戏的优势，除非你只是谈论最高级别的人类逻辑。 没有它，即使在避免泄漏方面，必须不断创建，访问和销毁资源的低级，精细系统逻辑通常会更好。
垃圾收集在游戏行业中未被使用并不完全正确。 虚幻引擎3为“脚本”类实现了垃圾收集。 对于他们来说，轻轻使用时表现是可以接受的; 繁重的工作由管理自己内存的C / C ++代码完成。
正如Fortran所说，Java并没有真正用于游戏行业，因为担心速度问题（Java在VM上运行代码，而不是本地……大部分时间），并且因为已经有大量有才华的游戏程序员在C和C ++中编写了许多经常使用的代码。 这并不是说你不能利用Java来制作游戏，因为那里有一些Java游戏，但“主流”游戏行业已经在C / C ++后端投入了大量资金。
fortran和James已经很好地覆盖了它，但是我想提到的另一件事，就是在讨论惯性时强调的那种，是C ++中可用的巨大库库。 拥有多个C ++库几乎可以想到的任何东西都是不切换到Java的重要原因。 这并不是说现在没有Java库，但是C ++已经成熟并拥有大量经验丰富的开发人员。 不必重写你之前完成1000x的同样的事情是节省大量时间。
你可以找到用java编写的游戏（jmonkey引擎完全用java编写）。
在这里 – >“ http://www.indiedb.com/engines/jmonkeyengine/games ”。
世界。
2.minecraft。
3.mynthurana。
所有在jmonkey引擎。 他们的图形质量很强，挑战也很好。
我想说游戏开发的要求是至少有两个人。 Java没关系。