两全其美：浏览器和桌面游戏？
在考虑游戏平台时，我决定选择多平台（Win/Lin/Mac），但无法决定浏览器还是桌面。由于我的发展还不算太远，现在又开始考虑了，我想听听你的意见！
使用 Java 小程序的基于浏览器的游戏：
- 市场渗透率相当高（对于版本 6，我相信约为 60%？）
- 使用 JOGL、3D 的 强> 性能/质量不错；当然足以渲染我制作的蹩脚 3D 图形，
- 将某些东西移植到 Android 上的可能性（很小？）
- 对于经常切换电脑的游戏玩家来说非常有用；可以坐在任何计算机前，加载网页并玩它，这
- 也非常适合休闲游戏玩家或知识较少的游戏玩家，他们非常喜欢在浏览器中玩游戏，但不想在他们的浏览器中安装更多东西 用我比 C++ 更熟悉的高级语言编写的计算机
- - 但同时，我想提高我的 C++ 技能，因为这可能是我在游戏中的发展方向一旦我离开学校，行业...
- 更简单的更新过程：重新加载页面。
使用良好的 ol' C++ 和 OpenGL 的桌面游戏
- 100% 市场渗透率，假设完全跨平台；然而，当你考虑到有多少人会下载和安装可执行文件，而不是浏览网页并在安全警告中点击“是”时，这个数字就会减少。
- 跨平台维护比较麻烦；但同样，出于学习目的，我会接受挑战并接受知识，我将
- 方面获得更好的性能
- 在真正的全屏 ，而浏览器游戏通常难以流畅的全屏图形（尤其是在 Linux 上，根据我的经验）
- 可以利用 Steam 等发行平台
- 更有可能被视为“真正的”游戏，而浏览器和 Java 游戏常常被忽视由于不是真正的游戏，因此不被“铁杆玩家”玩，
- 安装程序可能会很大；不必太担心下载时间
有没有办法两全其美？ 我喜欢 Java 小程序，但我也很喜欢这样做的原因编写一个桌面游戏。我不想不断地在 Java applet 项目和 C++ 项目之间移植所有内容；那将是事倍功半！
Unity 选择编写自己的网络播放器插件。我不喜欢这样，因为我是那些不会安装网络播放器做任何事情的人之一，而且我不认为自己能够说服我的观众安装浏览器插件。
我有什么选择？除了 Unity 之外，是否还有其他具有浏览器和桌面版本的游戏示例？我是否遗漏了上面的赞成/反对列表中的任何内容？
When considering a platform for a game, I've decided on multi-platform (Win/Lin/Mac) but can't make up my mind as far as browser vs. desktop. As I'm not all too far in development, and now having second thoughts, I'd like your opinion!
Browser-based games using Java applets:
- market penetration is reasonably high (for version 6, it's somewhere around 60% I believe?)
- using JOGL, 3D performance/quality is decent; certainly good enough to render the crappy 3D graphics that I make
- there's the (small?) possibility of porting something to Android
- great for an audience of gamers who switch computers often; can sit down at any computer, load a webpage and play it
- also great for casual gamers or less knowledgeable gamers who are quite happy with playing games in a browser but don't want to install more things to their computer
- written in a high-level language which I am more familiar with than C++ - but at the same time, I would like to improve my skills with C++ as it is probably where I am headed in the game industry once I get out of school...
- easier update process: reload the page.
Desktop games using good ol' C++ and OpenGL
- 100% market penetration, assuming complete cross-platform; however, that number reduces when you consider how many people will go through downloading and installing an executable compared to just browsing to a webpage and hitting "yes" to a security warning.
- more trouble to maintain the cross-platform; but again, for learning purposes I would embrace the challenge and the knowledge I would gain
- better performance all around
- true full screen, whereas browser games often struggle with smooth full screen graphics (especially on Linux, in my experience)
- can take advantage of distribution platforms such as Steam
- more likely to be considered a "real" game, whereas browser and Java games are often dismissed as not being real games and therefore not played by "hardcore gamers"
- installer can be large; don't have to worry so much about download times
Is there a way to have the best of both worlds? I love Java applets, but I also really like the reasons to write a desktop game. I don't want to constantly port everything between a Java applet project and a C++ project; that would be twice the work!
Unity chose to write their own web player plugin. I don't like this, because I am one of the people that will not install their web player for anything, and I don't see myself being able to convince my audience to install a browser plugin.
What are my options? Are there other examples out there besides Unity, of games that have browser and desktop versions? Did I leave out anything in the pro/con lists above?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
我建议先写一个游戏。
人们很容易陷入如何制作有史以来最好的游戏的困境，该游戏可以在从算盘到天网的任何东西上运行，但现实是您将面临大量挑战刚刚完成在您自己的 PC 上运行的游戏。
首先为一个平台编写游戏（无论该平台是“带有DirectX的Windows本机”，还是“Java小程序”，甚至是“浏览器中的纯AJAX”）。如果你能做到这一点，那么你就可以开始考虑如何将其移植到其他平台。但尝试做所有事情最终肯定会一事无成。
或者换句话说：
所以您实际上什么也没有决定。决定开发平台。然后制作游戏。然后让它在其他平台上运行。
不要太担心你的“观众”会接受什么。如果您的游戏很有趣，那么人们会很乐意安装 Unity。就像如果您的游戏不是基于浏览器的，他们会安装您的游戏一样。但重要的一点不是“我必须安装什么才能玩它”，而是“它值得吗”。您的重点应该是制作一款值得安装的游戏。
除非你打算卖出 2000 万份游戏并以此为生，否则你的“观众”其实并不那么重要，不是吗？重要的是把游戏放出来，让有兴趣的人可以尝试一下。
但单平台游戏比未完成的跨平台什么都没有要好得多。
一款需要我安装Unity的游戏比你坚持重新发明轮子而额外花3年时间开发的游戏要好得多。
I'd suggest writing a game first.
It's easy to get caught up in how to make the best game ever,which can run on anything from an abacus to SkyNet, but the reality is that you're going to have plenty of challenges ahead of you just finishing a game that runs on your own PC.
Write a game first, for one platform (whether that platform is "Windows native with DirectX", or "Java applet" or even "pure AJAX in a browser"). If you can do that, then you can start thinking about how to port it to other platforms. But trying to do everything is a sure way to end up achieving nothing.
Or to put it another way:
so you've actually decided nothing. Decide on a platform to develop on. Then make the game. Then make it work on other platforms.
Don't worry so much about what your "audience" will find acceptable. If your game is fun, then yes, people will happily install Unity. Just like they'll install your game if it's not browser-based. But the important point is not "what do I have to install to play it", but rather "is it worth it". Your focus should be on making a game that is worth the installation.
And unless you're planning to sell 20 million copies of the game and live off it, your "audience" doesn't really matter that much, does it? What matters is putting the game out there so those who are interested can try it.
But a single-platform game is a lot better than an unfinished cross-platform nothing.
A game that requires me to install Unity is a lot better than something that takes you an additional 3 years to develop because you insisted on reinventing the wheel.
是的，您可以两全其美。
完全有可能编写一个 Java 应用程序，该应用程序既可以在小程序中运行（对于在线用户），又可以作为下载形式的独立应用程序运行。
关键技术是：
如果有什么用的话，我写的一个旧游戏叫做 Tyrant< /a> 支持作为小程序和独立下载的 .jar 文件运行，如果您想查看，所有源代码都是开放的。这使用了简单的 AWT 而不是 3D 图形。
最后，这是另一个示例，以极小的数量将小程序转换为应用程序的代码。
Yes you can have the best of both worlds.
It's perfectly possible to write a Java application that will run in both an applet (for your online users) while also running as a standalone application in downloaded form.
The key technologies are:
If it's any use, an old game I wrote called Tyrant supported running both as an applet and as a standalone downloaded .jar file, all the source is open if you want to look at it. This used simple AWT rather than 3D graphics.
And finally here's another example of converting an applet into an application with a pretty minimal amount of code.
如果你真的想要这种渗透，那么我建议根据你需要的性能使用 HTML 5 + javascript。
If you really want that kind of penetration then I suggest HTML 5 + javascript depending on the performance you need.
首先，你从错误的问题开始。您对技术的决定应该由游戏背后的概念驱动。看来您对编写游戏的想法很确定 - 所以问问自己游戏的要求是什么。这将引导您了解您的技术。如果它不知道你想“做什么”。
对于您的优点和缺点：
不要专注于您永远不需要或无法使用的东西。对于业余开发者来说，思考 Steam 平台并不有趣。如果您并不真正想为 Android 发布应用程序，那么 Android 也没什么意思。这个专业人士实际上永远不会成为现实中的专业人士。
总结一下：让这个决定由你的想法驱动，而不是技术本身。如果您清楚地知道自己想做什么，您就会得到答案。
（顺便说一句：
想想浏览器游戏意味着什么。浏览器游戏背后有一个巨大的服务区，仅用于保持游戏运行。从事这些领域的公司基本上都是服务提供商。）
First of all you start with the wrong question. Your decision for a technology should be driven by the concept behind the game. It seems that you are sure about the idea to write a game - so ask your self what the requirements for the game are. This will lead you to your technologie. If it doesn't get an idea of "what" you want to do.
To your Pro's and Con's:
Don't focus on things you will never need or be able to use. Thinking about the steam platform isn't interesting for a hobby developer. Also android isn't interesting if you are not really want to ship your application for android. This Pro's will actually never be a pro in reality.
To sum it up: Let this decision be driven by your idea, not the technology itself. If you have a clear idea of what you want to do you will get your answer.
(And btw.:
Think about what browsergames imply. Behind a Browsergame there is a huge service-area, only for keeping the game running. Companys working in such areas are basically service-providers.)
您可能需要研究一下 Google 的 Native Client，它允许您用 C 语言编写应用程序或 C++（或者任何其他可以编译为本机代码的东西）。 SDK 的一项新功能是 LLVM 支持，这将（希望）允许 NaCl 软件针对运行 Google Chrome 浏览器的任何平台（或 NaCl 插件使用的任何浏览器 - 目前支持 x86 和 ARM，IIRC）。
You might want to look into Google's Native Client, which allows you to write your application in C or C++ (or anything else that compiles to native code, really). A new feature coming to the SDK is LLVM support, which will (hopefully) allow NaCl software to target any platform that Google's Chrome browser runs on (or any browser that the NaCl plugin works with - currently x86 and ARM are supported, IIRC).
您在问题中提到了 Android - 您是否考虑过纯粹为 Android 开发游戏？
实际上，您可以两全其美，易于维护，易于发布新版本，易于货币化并获得一些小额收入，而且您也无需编写自己的安装程序或更新机制。
You mentioned Android in your question - have you thought about developing the game purely for Android?
In effect you get the best of both worlds, easy to maintain, easy to release new versions, easy to monetize and get some small income and you don't have write your own installer or update mechanisms either.
是的。你可以做出一些对两者都适用的东西。基本上，让您的程序在 JPanel 内运行。小程序可以显示JPanel，桌面版本只是一个窗口，里面有你的JPanel。
您还可以有一个完整的 Swing（或其他）GUI，当他们单击小程序上的小“开始”按钮时，小程序会在新窗口中启动。
您还必须考虑其他一些差异，例如可能加载资源，但我之前已经为我制作的简单游戏做过这些。
Yes. You can make something that will work in both. Basically, make your program work inside a JPanel. The applet can display the JPanel, and the desktop version is just a window with your JPanel in it.
You could also have a full Swing (or whatever) GUI, which the applet launches in a new window when they click the little "start" button you'd have on your applet.
There are a few other differences you'll have to take into account, like possibly loading resources, but I've done it before for simple games I've made.
我认为你无法真正比较两者：
在我看来：
如果您不熟悉 C++，我的建议是使用 JOGL 转向 Java。这样您就可以在学习 C++ 之前扩展 OpenGL 学习曲线。
编辑
为了解决有关以浏览器和桌面形式实现游戏的问题的其他部分，您可以考虑用Java实现游戏并部署小程序和独立版本，从而独立版本可以利用Java 的全屏独占模式 API。您可以将这两个应用程序基于相同的代码库。您还可以考虑通过在服务器端保留数据文件（例如游戏关卡）并在需要时动态检索它们来缩小小程序的占用空间。
I don't think you can really compare the two:
In my opinion:
If you're unfamiliar with C++ my advice would be to steer towards Java with JOGL. That way you can scale the Open GL learning curve before having to tackle C++.
EDIT
To address the other section of your question regarding implementing a game in both browser and desktop form, you could consider implementing the game in Java and deploying an applet and standalone version, whereby the standalone version can take advantage of Java's full-screen exclusive mode API. You could base both applications on the same codebase. You could also consider shrinking the applet's footprint size by retaining data files (e.g. game levels) on the server-side and retrieving them dynamically when required.
虽然 WebSense 不允许我直接浏览该网站，但出于显而易见的原因，在阅读这个问题时首先想到的是像 Wurm Online。它是用 Java 和 JOGL 编写的，实现了内容流和本地缓存，并且似乎触及了您感兴趣的很多点。它是一个桌面 Java 应用程序，而不是真正的“浏览器内”应用程序，但我认为您可以仍然可以从其实现中学到很多东西。
浏览器内游戏始终面临窗口关闭或刷新的危险，导致其突然失去状态，除非所有内容都保留在服务器端。这意味着您要么拥有非常简单的游戏，可以使用呼叫/应答模型保持同步（例如无数的 Facebook“Mob Wars”基于文本的游戏），要么冒着无意中按下
F5弹射某人的风险回到他们最后一个“保存的游戏”。While WebSense won't let me browse directly to the site, for obvious reasons, the first thing that came to mind when reading this question is a game like Wurm Online. It's written in Java with JOGL, implements content streaming and local caches, and seems to have touched on a lot of the points you're interested in. It's a desktop Java application rather than being truly "in-browser" but I think you could still learn quite a bit from its implementation.
The in-browser game is always in peril of having its window closed or refreshed, causing it to abruptly lose state unless everything is being kept server-side. This means you either have very simple games that can maintain synchronization using a call/answer model (such as the myriad of Facebook "Mob Wars" text-based games) or risk an inadvertent bump of
F5catapulting someone back to their last "saved game."我不确定因为您个人不喜欢而拒绝使用插件是一个明智的选择。此选项允许您编写可安装为桌面应用程序或浏览器插件（无需太多额外工作）的应用程序，并且您仍然可以用 C++/GL 编写它。你说你不认为你的用户会安装插件......为什么不呢？如果他们会安装一个应用程序，那么为什么不安装一个基本上可以归结为同一件事的插件呢？
您也可以看看 Flash，它收集了一些 3D 功能，可以在浏览器中运行或作为 AIR 桌面应用程序运行。但是用户需要一个 Flash 插件，而您可能也没有。
I'm not sure that refusing to use a plugin because you personally don't like it is a sensible choice. This option lets you write you app installable as a desktop app, or a browser plugin (with not much extra work) and you still get to write it in C++/GL. You said you don't think your users will install plugins... why not? If they will install an application then why not a plugin which basically boils down to the same thing?
You could look at Flash too, which is gathering some 3D functionality and can run in-browser or as an AIR dektop app. But then users would need a Flash plugin, which you presumably don't have either.