两全其美：浏览器和桌面游戏？答案

【问题标题】：Best of both worlds: browser and desktop game?两全其美：浏览器和桌面游戏？
【发布时间】：2010-06-15 13:23:09
【问题描述】：

在考虑游戏平台时，我决定使用多平台（Win/Lin/Mac），但在浏览器与桌面方面无法下定决心。由于我的开发还不算太远，现在有第二个想法，我想听听你的意见！

使用 Java 小程序的基于浏览器的游戏：

市场渗透率相当高（对于第 6 版，我相信它在 60% 左右？）
使用 JOGL，3D 性能/质量不错；当然足以渲染我制作的蹩脚的 3D 图形
有可能将某些东西移植到 Android
非常适合经常更换电脑的游戏玩家；可以坐在任何计算机上，加载网页并播放它
也非常适合休闲游戏玩家或知识较少的游戏玩家，他们非常喜欢在浏览器中玩游戏，但不想在他们的计算机上安装更多东西
用我比 C++ 更熟悉的 高级语言 编写 - 但同时，我想提高我的 C++ 技能，因为这可能是我前进的方向一旦我离开学校，游戏行业......
更简单的更新过程：重新加载页面。

使用优秀的 C++ 和 OpenGL 的桌面游戏

100% 的市场渗透率，假设完全跨平台；但是，与仅仅浏览网页并点击“是”来发出安全警告相比，考虑到有多少人会下载和安装可执行文件，这个数字就会减少。
更多难以维护跨平台；但同样，出于学习目的，我会接受挑战并获得我将获得的知识
更好的性能全方位
真正的全屏，而浏览器游戏通常难以实现流畅的全屏图形（根据我的经验，尤其是在 Linux 上）
可以利用Steam等分发平台
更有可能被视为“真正的”游戏，而浏览器和 Java 游戏通常被认为不是真正的游戏，因此不被“铁杆游戏玩家”玩
安装程序可以很大；不必担心下载时间

有没有两全其美的方法？我喜欢 Java 小程序，但我也非常喜欢编写桌面游戏的原因。我不想在 Java 小程序项目和 C++ 项目之间不断移植所有内容；那将是两倍的工作！

Unity 选择编写自己的网络播放器插件。我不喜欢这样，因为我是不会为任何东西安装网络播放器的人之一，而且我认为自己无法说服我的观众安装浏览器插件。

我有哪些选择？除了 Unity 之外，还有其他具有浏览器和桌面版本的游戏的例子吗？我在上面的赞成/反对列表中遗漏了什么吗？

【问题讨论】：

100% 的市场渗透率非常看好你编写跨平台代码的能力。
如果你想写一个“硬核”游戏，你的时间最好花在一个平台上。如果不是这样，你不妨设定目标来吸引所有这些人。跨平台的大型游戏背后有大量资金。我还确定您是否检查了每个端口是否有大量自定义代码。
如果您的观众不愿意安装浏览器插件，他们肯定也不会安装独立游戏。这似乎回答了你的问题。它必须在浏览器中运行，带有 no 插件（我不知道为什么必须安装 Java 比必须安装 Unity 更容易接受）

标签： java c++ browser-plugin

【解决方案1】：

我建议先写一个游戏。

很容易陷入如何制作有史以来最好的游戏，它可以在从算盘到 SkyNet 的任何东西上运行，但现实是你将面临大量挑战在您刚刚完成在您自己的 PC 上运行的游戏之前。

首先为一个平台编写游戏（无论该平台是“带有 DirectX 的 Windows 原生”，还是“Java 小程序”，甚至是“浏览器中的纯 AJAX”）。如果你能做到这一点，那么你就可以开始考虑如何将它移植到其他平台上。但是尝试做所有事情肯定会最终一事无成。

或者换一种说法：

我决定使用多平台（Win/Lin/Mac）

所以你实际上已经决定什么都没有。决定开发平台。然后制作游戏。然后让它在其他平台上运行。

不要太担心你的“观众”会接受什么。如果您的游戏很有趣，那么是的，人们会很乐意安装 Unity。就像他们会安装你的游戏，如果它不是基于浏览器的。但重要的一点不是“我必须安装什么才能玩它”，而是“值得吗”。您的重点应该是制作一款值得安装的游戏。

除非您打算销售 2000 万份游戏并以此为生，否则您的“观众”并没有那么重要，不是吗？重要的是把游戏放在那里，让有兴趣的人可以尝试一下。

但是单平台游戏比未完成的跨平台nothing要好很多。

一个需要我安装 Unity 的游戏比因为你坚持重新发明轮子而需要你额外 3 年开发的游戏要好得多。

【讨论】：

在其他一些问题中，我可能会喜欢这样的答案，但这根本不是我想要的；我相信您在 SO 上对游戏开发社区进行了刻板印象。我想你是从“在开发中还不算太远”来判断我的经验——我的意思是我有一个原型 Java 小程序，我已经开发了几个星期（而且，嗯，它肯定是使用一个 jar 的跨平台文件，然后由 JOGL 的 JNLP 文件自动选择适当的 JOGL 本地库）。我很欣赏这个励志演讲，但在这种情况下，它显得有点冒犯。

【解决方案2】：

是的，您可以两全其美。

完全可以编写一个 Java 应用程序，该应用程序既可以在小程序中运行（供您的在线用户使用），又可以作为下载形式的独立应用程序运行。

关键技术有：

JNLP
JOGL 用于图形，其中也有一些不错的demos
我不太熟悉它，但我认为如果您想要更多功能齐全的游戏引擎，jMonkeyEngine 看起来很有前途

如果有任何用处，我写的一个名为Tyrant 的旧游戏支持作为applet 和作为独立下载的.jar 文件运行，如果你想查看它，所有源代码都是开放的。这使用了简单的 AWT 而不是 3D 图形。

最后是another example 将一个小程序转换为一个代码量非常少的应用程序。

【讨论】：

另外值得注意的是，在线游戏 RuneScape 是一个 Java 小程序（并为 OpenGL 和 DirectX 使用自定义绑定）现在有一个开源的可执行应用程序，在可执行文件中包含 JVM（Java 没有'不需要预先安装），并且不仅仅是一个裸露的浏览器窗口。我打算尽快查看源代码，看看他们是如何做到的。
作为这个已接受答案的更新：如今“Unity”可能是正确的选择，因为它可以在浏览器中播放（基于插件），但也可以编译成本机代码。

【解决方案3】：

如果你真的想要那种渗透，那么我建议根据你需要的性能使用 HTML 5 + javascript。

【讨论】：

我经常认为浏览器为游戏开发提供了一个很棒的平台，其中包含许多内置功能 - 网络和图形布局/精灵动画小菜一碟。 html 5 可以进行异步处理，而 chrome v8 使性能不再是问题。
HTML5需要多长时间才能有好的渗透？有多少人会/不立即升级到较新版本的 FF/IE？尤其是 IE 用户是一个问题，因为 IIRC IE9 不支持 XP 并且很多人仍在使用 XP。说“他们应该使用其他浏览器”并不是一个真正的选择，不会安装插件的人不太可能安装全新的浏览器。
好吧，如果我们谈论的是桌面出版/生产力应用程序，我会说你有道理 - 但对于游戏，人们会在 XP 上安装 Chrome 之类的东西来玩游戏。

【解决方案4】：

首先你从错误的问题开始。您对技术的决定应该由游戏背后的概念驱动。看起来你对编写游戏的想法很确定——所以问问你自己对游戏的要求是什么。这将引导您了解您的技术。如果它不知道你想做什么。

致你的赞成和反对：不要专注于你永远不需要或无法使用的东西。对于爱好开发者来说，考虑 Steam 平台并不有趣。如果您真的不想为 android 发布您的应用程序，那么 android 也不有趣。这个专业人士实际上永远不会成为现实中的专业人士。

总结一下：让这个决定由您的想法驱动，而不是技术本身。如果你对自己想要做什么有一个清晰的想法，你就会得到答案。

（顺便说一句：想想浏览器游戏意味着什么。 Browsergame背后有一个巨大的服务区，仅用于保持游戏运行。在这些领域工作的公司基本上是服务提供者。）

【讨论】：

【解决方案5】：

您可能想查看 Google 的 Native Client，它允许您使用 C 或 C++（或任何其他编译为本机代码的东西，真的）编写您的应用程序。 SDK 的一个新功能是 LLVM 支持，这将（希望）允许 NaCl 软件针对运行 Google 的 Chrome 浏览器的任何平台（或 NaCl 插件使用的任何浏览器 - 目前支持 x86 和 ARM，IIRC）。

【讨论】：

【解决方案6】：

您在问题中提到了 Android - 您是否考虑过纯粹为 Android 开发游戏？

实际上，您可以两全其美，易于维护，易于发布新版本，易于获利并获得少量收入，而且您也无需编写自己的安装程序或更新机制。

【讨论】：

【解决方案7】：

是的。你可以做一些对两者都有效的东西。基本上，让您的程序在 JPanel 中运行。小程序可以显示JPanel，桌面版只是一个窗口，里面有你的JPanel。

您还可以拥有一个完整的 Swing（或其他）GUI，当他们单击您的小程序上的小“开始”按钮时，小程序会在新窗口中启动它。

您还必须考虑其他一些差异，例如可能会加载资源，但我以前为我制作的简单游戏做过。

【讨论】：

【解决方案8】：

我认为您无法真正将两者进行比较：

在我看来：

Applet、flash 和其他基于浏览器的游戏通常是小型“玩具”游戏，要么免费编写，要么附有广告。例如，查看Addicting Games 网站。
C++ 游戏更有可能是重量级的工作室编写的游戏，依赖于专用的物理引擎、图形引擎等（尤其是我认为在 Steam 上分发的游戏）。学习曲线可能会更加陡峭，因为 C++ 本质上是一种比 Java / Flash 更难的语言。

如果您不熟悉 C++，我的建议是使用 JOGL 转向 Java。这样一来，您就可以在学习 C++ 之前扩展 OpenGL 学习曲线。

编辑

要解决关于以浏览器和桌面形式实现游戏的问题的另一部分，您可以考虑在 Java 中实现游戏并部署小程序和独立版本，其中独立版本可以利用 Java 的全屏独占模式 API。您可以将两个应用程序基于相同的代码库。您还可以考虑通过在服务器端保留数据文件（例如游戏关卡）并在需要时动态检索它们来缩小小程序的占用空间。

【讨论】：

【解决方案9】：

虽然 WebSense 不允许我直接浏览该站点，但出于显而易见的原因，阅读此问题时首先想到的是像 Wurm Online 这样的游戏。它是用 JOGL 用 Java 编写的，实现了内容流和本地缓存，并且似乎触及了很多你感兴趣的点。它是一个桌面 Java 应用程序，而不是真正的“浏览器内”，但我认为你可以仍然可以从它的实现中学到很多东西。

浏览器内的游戏总是处于关闭或刷新窗口的危险中，导致它突然失去状态，除非一切都保持在服务器端。这意味着您要么拥有可以使用呼叫/应答模型保持同步的非常简单的游戏（例如无数的 Facebook“Mob Wars”基于文本的游戏），要么冒着F5 无意中撞到某人的风险“保存的游戏。”

【讨论】：

当前所有浏览器都支持 JavaScript 的“onbeforeunload”属性，它允许您询问用户“您确定吗？”在他们离开页面之前（无论是通过单击链接、F5 键还是关闭窗口，或任何其他离开页面的方法）。如果您开始写一个问题然后尝试离开页面，它甚至会在 SO 上使用。这几乎涵盖了您的第二段。
@Ricket：虽然它阻止人们刷新或点击离开，但它不包括浏览器崩溃或无响应的情况；例如。如果另一个选项卡决定挂断并且用户的浏览器没有在单独的进程中启动每个选项卡，那么无论是否使用 JavaScript，您的应用都会关闭。客户端和服务器都需要能够优雅地处理这个问题，尽可能接近状态停止的地方。

【解决方案10】：

我不确定因为您个人不喜欢它而拒绝使用插件是一个明智的选择。此选项允许您编写可安装为桌面应用程序或浏览器插件的应用程序（无需太多额外工作），您仍然可以使用 C++/GL 编写它。你说你不认为你的用户会安装插件......为什么不呢？如果他们会安装一个应用程序，那么为什么不使用一个基本上归结为同一件事的插件呢？

您也可以查看 Flash，它收集了一些 3D 功能，可以在浏览器中运行或作为 AIR dektop 应用程序运行。但是用户可能需要一个 Flash 插件，而你可能也没有。

【讨论】：