Now that our user base on Urban Galaxy Online has grown, we felt “right” to share with you some statistics.
Note that UG is designed to be played within the user’s web browser, as an applet-based browser MMO (similar to Runescape), so here we go:
Now on the hard facts coming from users trying to play the “alpha version” which is live:
60% of the registered users, passed the login screen and managed to play the actual game
40% were not able to run the java applet (linux+osx users maybe?)
LWJGL Applets were broken on OSX, so we offered an “alternative” option to have them run the game through Java Web Start (temporar solution as to not exclude Mac users from the game)
OSX Java7 update broke both applets and java web start, so Mac users were not able to run the game without downgrading their java to v6
Latest OSX “update”, removed and disabled java by default, killing the OSX user base.
Linux users would have to use Oracle JDK, as OpenJDK usually fails to run properly with LWJGL.
Firefox/Chrome sometimes complain that Java is a security hole and suggests to remove Java plugin.
We had feedback from “casual” users that did not want to get java installed into their OS
Some users suffered by BSOD when closing the applet window, probably due to crappy video drivers
What I am trying to point out here, is that the “trend” tries to kill Java Applets from the browser. Trying to make a game that will be profitable by the masses, should be able to be working without or at least with minimal effort from the user’s point of view.
JME is a marvellous engine but I think it should be reconsidered whether a WebGL/javascript implementation is possible (I know it was already mentioned in a couple of previous threads). I believe that GWT-WebGL could make it possible, so that we keep java on the server side (and/or Desktop apps/Android), while having web games run out of the box on the browser.
Another issue is the localisation of a project. I am not sure whether nifty supports unicode text or not (maybe it does, so problem solved!), but a JME-GWT could handle unicode text more properly as well, without having to deal with textured fonts, as the UI could be build with straight HTML/CSS on top of the WebGL canvas. In UG, unicode is very important, as people should at least be able to chat in their native language, even if the game’s interface itself is not localised yet.
When WebGL becomes powerful enough, why not. But atm its not an option at all and not worth putting effort into. Not powerful enough, no support among browsers, no support among users etc. jME is for powerful 3d games and not for flat shaded boxes in an iframe.
Personally I hope browser games will generally die a quick death soon, it never made sense to me to have the clumsy browser involved in games or applications and the future platforms will be Android and iOS anyway, these will always work better with compiled code and proper applications.
So, for your general issues, thats why we move to JOGL and for the applet issue: Just don’t do browser games, they suck Start from the browser with a link or if necessary embed the browser using javascript instead of doing the whole game in the browser. Zynga only plays as if users wanted to play in a browser ^^
About GWT-WebGL, the old jMonkey devs create an engine like that, where you use GWT in the backend and WebGL in the frontend. To me its like going back to the stone age but the idea is kinda nice, yeah.
Actually there is a massive market for casual games out there and those players are far more likely to play browser games than install something so while for more serious games normen is right it isn’t true for all cases.
Actually there is a massive market for casual games out there and those players are far more likely to play browser games than install something so while for more serious games normen is right it isn’t true for all cases.
I bet the new platforms *will* change that ^^ Even WebGL will allow you to "pop out" the applications, I don't think that inline applications will be used much more in the future, especially not 3d ones. For simple 2d effects and games AJAX is sufficient. When you have a 3d space that you navigate a browser theres always compromises to be made. As I said, most casual gamers will have iOS or Android in the future.
Well the usual casual gamer probably wont mind suing webstart vs using a applet, at least thats my guess, from all the free mmo stuff that works with a simple one click launcher. However webgl is really becoming usefull. All browsers except ie support it acceptable enough , (yes even opera, but there you have to enable it in the about:config, wich probably scares casuals users away), so on the long term, it is quite intresting.
If i where you i would keep the client as loosly coupled as possible, so that i can use applet, webstart, and mobile devices antive deployment methods.
Well the usual casual gamer probably wont mind suing webstart vs using a applet, at least thats my guess, from all the free mmo stuff that works with a simple one click launcher. However webgl is really becoming usefull. All browsers except ie support it acceptable enough , (yes even opera, but there you have to enable it in the about:config, wich probably scares casuals users away), so on the long term, it is quite intresting.
If i where you i would keep the client as loosly coupled as possible, so that i can use applet, webstart, and mobile devices antive deployment methods.
Its not about the general compatibility, its about the scope of the GL implementation, jME is simply on another level. But as said, it should be no problem whatsoever to do a renderer for jME thats based on WebGL, its just not going along with the aim of jME. jME is aiming at the steam boxes, the powerful desktops and tablet/phone computers. This is what I see in the future, I think the browser already hit its limits. Given all the different input types alone the technology would have to make up for another ten years of existing development in those areas, just like AJAX just about arrived where Java was 1995
The way it works is always diversification, the unification thing is something the people always regard as practical and they try to implement that but the technology diverts. Just like Apple thwarted the “browser revolution” as planned by google by giving us beautiful and easy to use touch interfaces, exactly because they did not use web tech. Or valve putting PCs in their steam boxes. According to unification that would be one device, as valve (and I) think, having a box that “just works” for games makes a lot of sense, no matter if its something you could hack together on your linux box too, you can always do that but only geeks have the time to do so ^^
Like I said, for facebook games where you have to interface with their JS api, your standalone app can do that too, and it can blow away people with performance and stability too
Well, I can say you something: that part of the users that failed to play the game, they are now lost market. All you can do is to point them to install the Oracle version of the JVM. You could do a check if it’s not the Hotspot, and then tell the user to download the HotSpot. If they don’t want to do that then it’s lost market. Javascript is not stable on browsers, different browsers has different speeds of processing the Javascript, and different memory management for each tab, and so on. I remember that there was a game called Lord of Ultima, that would play incredible well on Opera, but on Google Chrome multiple clicks would be deadly slow, and on Firefox the dragging part was the problem. IMO, non-casual MMOs don’t play well into browsers. You could create a non-installer executable to run in all platforms that has an embed JRE that would solve this issue if you want to (I’ve seen many applications doing this).
Yeah, thats basically what I am saying. And that we plan to integrate JDK / JRE deployment in the SDK and apps is also no secret ^^
Its the same with the Unity plugin as well btw, they only started and already suffer the same issues as java in these regards (updates for ne game breaking another).
So, yes, a distributed JVM or even cross-compiled native code for each application makes most sense to me. If you look at browsers, better look at the native execution APIs that e.g. Chrome now introduce. Also a possible renderer target for jME. At any instance all of this will not change the scope of jME.
GWT/WebGL is not part of our scope. The “Goo” engine however is made for this purpose. http://www.gootechnologies.com/
Applets are indeed being phased out. Personally I think its most suitable successor is Google’s “Native Client”. Unfortunately there is no Java API yet (ask them about it! The more demand the better).
As an alternative to your Applet, in place of WebStart, I’d suggest looking into Getdown. For the “doubters” who can’t easily “plug and play” with the applet version of the game, make your game work with Getdown and bundle it with the most suitable version of Java (bunch of other games do this with C++ redistributables and people certainly don’t seem to care about that) and your users will have a much higher chance of successfully running your game on the first try.
Although the downloadable game client could be an option (with bundled Java etc), it is not part of our design to provide one for the following reasons:
The game is an MMO, so we should figure out a way to patch the game in case of a downloadable bundle (although JWS does that already)
Downloadable games compete with the big boys, so we couldn’t stand a chance competing companies with huge backing. Browser games are “lighter” and more “casual” by nature (less download size etc), so you might have more opportunities to stand out and tap a market as an indie with a clever idea.
SaaS business model!
Have your game free and back it with Ads or micro transactions or integrate with existing game portals or Facebook
Integrate more web services with the game, such as complex leaderboards, player profiles etc.
My proposal about GWT was about giving options to the developers. For example Unity3D lets you publish games for mobile devices, standalone executables and browser games (both Flash11 + their custom plugin). UDK added support for browsers through Flash11, although it is a hardcore engine, aiming to the high-end. Its all about giving more power/options to your developers. What they are planning to do with your engine, its up to them. It was just a humble proposal. Of course its up to you to decide how you would like JME to shape
For the time being we will stick to the applet and we might do some research next year on HTML5 technologies. If you are interested I can keep you posted.
@erlend Goo looks very interesting! I doubt whether there will ever be a java API for native client… it is out of its purpose anyway…
It could be nice to have a webGL endpoint.
It would not be has stone age as android IMO. Android is slow because of the VM that suck and because the fill rate of the hardware suck.
Javascript would be the bottleneck here I guess but at least decent hardware could pull that up.
It’s based on opengl ES2 so our android renderer could be adapted, and once the Jogl Renderer is done we’ll have a wrapper over it…It worth the try IMO
Only thing that would get my feet cold is that WebGL is not yet very wide spread and looks more like an experimentation for now…
Also there is some hardware that is not compliant apparently…(Blocklisting/Blocked Graphics Drivers - MozillaWiki)
I can’t promise anything considering the amount of things to do for JME, but I have fairly good knowledge of GWT as I use it at work, so i guess I could give it a try…
@kinix If we look into this though it will be for JME3, if I remember correctly you use JME2 right?
@nehon Yes, we still use JME2, but of course a GWT port would only make sense for JME3 anyway, since shaders are a requirement for WebGL. I do not want to get you into any trouble messing up with GWT just for us, as it would require a lot of our time to port our client from JME2 to JME3 anyway, which cannot happen right now as we focus on adding more content to the game. It was just food for thought for the future roadmap of JME and whether you would like to address the browser space in a more modern way.
Yes of course, but I like my though being fed
I guess a lot of people could benefit this feature. Of course it’s not priority ONE, and I have to make sure it’s not an overwhelming endeavor, but I’ll keep it in my mind.
Start from the browser with a link or if necessary embed the browser using javascript instead of doing the whole game in the browser. Zynga only plays as if users wanted to play in a browser ^^
