Its more about the internals of bitmapfont that makes you go insane
Anyway a browser based game can easily just use a normal html div and css stuff for any font and overlay it.
Its more about the internals of bitmapfont that makes you go insane
I am personally a bit heartbroken about this, given that an MMO I grew up on uses in-browser java, and one has to admit it’s a good marketing stunt to make your game so easily available, without a traditional download/install process.
Though, to be fair, it doesn’t REALLY affect me, as they have a downloadable client option, so that’s alright.
What grinds my gears is the astounding amount of security concern against java in recent times. Sure I understand it might be vulnerable, but to completely block off users from running un-certified apps on their own risk is rather annoying. It’s one of the reasons I’ve not “upgraded” to Java 8 yet.
I even had to switch firewall at one point because it completely and utterly blocked all networking done by java (even outside a browser), purely because the JRE version seemed unkown to it (too new I guess?)
The funny part is, my firewall was not showing any sign of blocking it. Even when I temporarily “disabled” it, Java was blocked from the net. Closing the firewall app suddenly made it work. Huh. Screw Agnitum!
Besides, it’s not just my pet-peeve, my brother works as a computer-handyman (forgive my terminologic inaccuracy) at a big company, and has a lot of trouble getting old (but functional and essential) java apps to run because of the security nonsense.
yep, same issues in my company. There are ways to get around this though. tell him to look for " java Deployment ruleset".
That’s basically a white list of URL, telling what JRE to use for what URL, and that automatically promote any applet coming from these urls to secure applets, so you don’t have any security warnings.
Has anyone had a look into Dukescript yet? (http://dukescript.com/)
Yes it was one of the alternatives to GWT, @Momoko_Fan was talking about.
Yes I looked into bck2brwsr as well as TeaVM (both are Dukescript VMs). They have two primary issues:
- Lack of support for core Java APIs like Thread, EnumMap, etc.
- Require Maven based build to work. Our build system is based on ANT / Gradle which doesn’t integrate with Maven
Is Thread “really really” needed to make JME work in a browser? Our team currently working on extracted concepts which are useful for a game in browser and rewrite parts of JME that doesn’t fit, so utilities in Asset system and Timer should be rewriten, and eh… other parts… I’ve tried DukeScript, and GWT.
Of course we only focus in a prototype that use a 2D (possible 3D) gui elements, but write in JME concepts and library in netbean. We not aim to a full 3d game and in fact I don’t have a clear view of what we can do and what already there. To make sure it’s practically possible, we look into cocos2d-x and libgdx (both with a mistery x at the end) which bring 3d to android, web and ios at the same time.
I don’t think theres much use to try and squeeze the engine in such a context, simply using some engine/API thats made for these kinds of contexts makes much more sense. You wouldn’t be able to make games “jME-Style” anyway, so why try and fit a square peg into a round hole?
Of course threads are not needed. It is possible to make jME3 completely single threaded … but the assumption that threads are supported by the OS is integrated deep within many parts of the engine - it requires going into each end and adding a check like
if (HAVE_THREADS) createThreadsAndDoOtherThings(); else doSingleThreadedThingy();
In some places it can make the code unnecessarily complicated. So yes, it is possible, but it would be a pretty big project (maybe could be good for GSoC 2015?)
The point is: JME become not just an engine but libraries and tools written for them. For the goods of writing “good games” I would like to save some of my effort not to write “code” again and again. That’s why I want to use Java, JME, and its tools. If I have to rewrite some parts, bear with me. At least, I know it’s possible to do it. It’s only worth depends on your team and your company decision about the picked technologies.
Exactly and most of the stuff won’t work anyway, especially your very extensive stuff which uses all kinds of libraries. Porting each and every one of them would not make much sense compared to just writing your app or whatever with the tools that are made for the target platform.
Those libs which interfere with low level will not work of course.
Those which use Shader and GLSL will have to convert part by part.
Those just build around concepts like Control and State will survive.
The AI lib for example will survive.
Tonegod gui work after modify those nasty anonymous classes and modify the shader source. We have to use another XML loading routines but for small example, it’ve worked also.
It will be silly or even non sense to port a big game already written in one source to another. But with some company (such like mine), they do it for living It called porting. It’s the most saccrified job in the world. You be blamed for other’s codes, twice…
P/s: Note that it’s also a common job to rewrite shader code for developer like me. It’s a sad and obvious true that even if OpenGL sounds like cross platform is not work in all devices the same. So we ALWAYS have to re write packs of shader for each profile of devices with one kind of processors and memory. So write another dozen of GLSL sound simple for us, at least if the deadline still far to reach…
This is more like trying to make a desktop windowing system work on a mobile device.
Sounds like you would like to have a better Abstraction of Gaming Logic type Library to run off of.
jMonkeyEngine seems to be in the odd transitory state to you, then. It has several nice game abstraction libraries that have been developed to increase functionality for this situation: Java and OpenGL/OpenAL’s abstraction of low level graphics/audio. The situation’s level of abstraction relies upon Java’s own ability to cover multiple platforms. I don’t think that you are so much requesting additional functionality of jMonkeyEngine, itself, but a clearer definition between the abstraction layers of jMonkeyEngine’s collection of High-Level modules and jMonkeyEngine, itself. That way you could take the collection of High-Level modules and form a game around a different Base-Functionality engine, like WebGL… or [BS Warning] even Assembler (should you wish to program for the latest stuff in DOS… I <3 x286 chipset, VESA rulez!).
But that’s not my call, I’m just enjoying the engine for what it is, atm. It would be up to Nehon n’ the Crew to make that call. The engine is in that cute Gosling stage, and feathers are flying everywhere. I know that I’m having fun playing with it, though. Yay!
Only thing that would be complicated would be to synchronize threads.
Also HTML5 spec has something called Web Workers, that are basically threads for HTML. Not sure it’s supported on every browser, but I bet most of them do.
I would go so far and say that most smaller jme games dont need any multithreading at all.
Even many current Desktop games (like 90% produced with unity) have no multithreading at all.
So if you know about this limitation while writing the game there shouldn’t really be any problem.
I’m thinking about cases like Adventure Box
@roleary made this awesome voxel engine in JME3 Procedural voxel terrain and vegetation generation but his web-based voxel engine http://adventurebox.com/play-here/ is using Goo engine.
Due to the algorithmic nature of voxel worlds they don’t need huge client side data stores necessarily, but it would still be nice to be able to use the same code that natively targets desktop and mobile clients to run a browser version.
OK WebGL is limiting, but as we’ve already mentioned, a lot of the big name engines already do run in the browser, so the limitations can’t be insurmountable. For example: http://beta.unity3d.com/jonas/DT2/ and Mozilla and Epic Preview Unreal Engine 4 Running in Firefox - The Mozilla Blog
The announce of WebGL support by unity and UE4 are one year old, and nothing new since. And support of web is like a lie, because there are lot of restriction (like some linux support in unity) because some feature are made for DirectX or for xxx. And downgrade to web is too costly for a bad result.
@nehon, web worker can access DOM and they are restricted, you can communicate with them by message passing (like actor) where you have to copy data.
To be back to the original question, my suggestion is to not use java for webclient. But you can use jme on server side to serve data (or image) for a 3D webgl client a “simple” viewer.
As Momoko_Fan suggested, I have checked the GWT library for some days. But the WebGL integration into JME3 using GWT seems to be a really big task… too much big for me !
Currently, I use JME3 to generate complex 3d scenes, with other libraries like JTS and Geotools. But, when the generation process is finished, the rendering step is really simple: just draw lots of triangles, without physic, audio or AI. Moreover, generated scenes are static.
So, I think I will keep my current development into the server-side and just use GWT + parallax to display data in the Web-browser (to continue with the Java language). These data (about 500 Ko to 4 Mo) will be sent during the initialisation step, for example using a personal JSON format. And that’s all for the renderer. For the GUI, I will use the GWT widgets.
Again, thanks for your responses…
and I think the discussion is not really finished !
We have also been using applets for the past three years to visualize our 3D world and it seems to become harder every year. Which is unfortunate.
From a technical perspective I agree that normal desktop applications are much better, but from our user perspective (gouvernments, large businesses) applets are easier/lighter to use and often do not require administrator approval to install them.
So I would no be happy to stop using applets, as for WebGL I have also seen a lot of demo’s but it is not jet as complete. Anyway, I am currently at the GDC in SF and I will keep an eye open for discussions relating to this subject.