9

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

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

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

使用良好的 C++ 和 OpenGL 的桌面游戏

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

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

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

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

4

10 回答 10

7

建议先写个游戏。

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

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

或者换一种说法：

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

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

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

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

但是单平台游戏总比没有完成的跨平台游戏要好很多。

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

于 2010-06-15T14:39:12.293 回答
5

是的，您可以两全其美。

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

关键技术有：

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

最后，这是另一个使用极少代码将小程序转换为应用程序的示例。

于 2010-06-15T15:00:59.203 回答
5

如果您真的想要这种渗透，那么我建议您使用 HTML 5 + javascript，具体取决于您需要的性能。

于 2010-06-15T13:54:55.920 回答
4

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

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

总结一下：让这个决定由你的想法驱动，而不是技术本身。如果你清楚地知道你想做什么，你就会得到答案。

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

于 2010-06-15T14:31:41.337 回答
2

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

于 2010-06-15T14:08:41.530 回答
1

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

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

于 2010-06-15T13:35:51.707 回答
1

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

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

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

于 2010-06-15T14:35:12.080 回答
0

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

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

于 2010-06-15T14:29:40.440 回答
0

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

在我看来：

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

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

编辑

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

于 2010-06-15T13:37:04.967 回答
0

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

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

于 2011-01-15T16:46:39.480 回答