Web games without JavaScript?

[monster]

Hi all.

I've mentionned before that my main interest in JActor was to create multiuser online games in Java. Now, I wanted to create data and processing heavy games, and therefore was looking for way to do efficient multi-tasking, and clustering. But lately my family have been trying to convince me to make more lightweight (ideally, HTML5) 2D web games instead. So I decided to have a look around, and report what I've found.

From the ground up, one assumption was, that I would not be programming them in JavaScript, because making games in HTML5 and JS is a well-known nightmare, due to the fact that no browser is fully compatible with any other. Also, I did not have the time to start learning a completely new platform and API before being able to produce anything, and wanted to reuse the knowledge and API experiences I gathered so far.

First, I stumbled on PlayN which is a game engine that sports compatibility with:

1. Desktop Java
2. HTML5 Browsers
3. Android
4. iOS
5. Flash

Which sounds impressive, although I found out that the Flash platform is called a "red-headed stepchild", which implies that it is not well supported.

But generally speaking, the website was minimal, the doc non-existent, and the forum rather quite. I followed a link suggesting I checked out the PlayN questions on Stack-Overflow, and one of the top question was: "PlayN vs libGDX", and all answers said the same thing: use libGDX instead of PlayN. So I went to look at libGDX, and found the website much more impressive and professional, including a slideshow of multiple commercial games made with it.

LibGDX supports the following platforms:

Desktop/Android/iOS/HTML5

So, no Flash. But even PlayN doesn't really seem to like Flash. And before I start considering Flash, I'd probably go for JavaFX (btw, they had a good demo site too, but it seems Oracle killed it). JavaFX moving forward, and even have plan for 3D. Since JavaFX is now bundled with Java, that means it is available everywhere where Java is, and your app can start faster since part of the engine code is already installed.

But back to LibGDX.They, like PlayN, offer a game engine API. What this gives you, is that it accelerates creating games, compared to having to integrate yourself OpenGL, sounds, 3D object format loaders, physics engines, ... All the important parts are already there, and welded together. And libGDX has already support for 3D, although currently limited. But there are multiple other Java game engines out there. In fact I was planning to use jMonkeyEngine myself, since it is specialized for 3D games (but also support Android). So what does libGDX do? If you do a desktop game (applet also falls in this category, I think), then it just runs you Java code, as we are used to. If you do an Android game, it must translate your Java classes to Android, but since this seems to be how most/all development is done for Android, there are no big surprises there. There are a few quirks, which I'll explain later. For iOS, I haven't fully followed, but the steps are approximately that your Java classes are turned into a .NET app, and then that .NET app is run in a .NET emulator on iOS. This sounds terrible, IMO, and I can't expect good reliability or performance, considering the steps involved. Also, to develop for iOS, I would need to buy a Mac, buy an iPhone, and then pay 400USD for some commercial IDE/platform license, without which it doesn't seem possible to deploy to iOS, at least not with this stack. Finally, for HTML5, they use GWT. I think PlayN uses GWT too for HTML5.

So, since the desktop side of things is business-as-usual, the Apple side of things look grim, and too expensive, this leaves us with two interesting choices: Android and HTML5.

Android seems to be an obvious choice for Java devs, and has few real limitations. You can use most of the normal JDK. This include threads, reflection, ... But there are a few limitations. You need a special version of Googel Guice, if you want that, and dynamic class loading is a bit difficult, and there is no class unloading, and runtime bytecode generation was until recently impossible. But now there are alternatives. Someone ported ASM to Android. But since Androind has it's own instruction set, the would be somewhat involved, even for an ASM pro. The other, but much less efficient, way of doing runtime bytecode generation, works as follow: create your JVM bytecode as usual in RAM, save it to a local storage, use some Android DEX program to translate the JVM bytecode to Android bytecode, and then load the Android bytecode. This works, but it's slow. My impression is that over time, most issues Java devs have with Android will be dealt with, making it the perfect mobile platform for Java devs. But the biggest limitation is most likely going to be the limited resources. You can't just allocate multiple GBs for your game, and Android OS is well-known for killing apps that consume too much resources. I've also seen people claiming it *randomly clears static variables (large arrays, ...)*, to save resources, but I'm not sure if I can believe that.

Compared to GWT, Android seems to be a paradise. GWT is at it's heart not much more then a Java-source-to-JavaScript translator. It's neither an API nor a framework. Here are the packages from the JRE that GWT supports:

1. java.lang
2. java.lang.annotation
3. java.math
4. java.io
5. java.sql
6. java.util
7. java.util.logging

This isn't much IMO. There are literally 100s of packages in the JRE. But for modeling data, and processing data, this is mostly what is needed. Be aware that not all classes from these packages are available, nor are all methods/fields of the available classes present in GWT.

Now for the more specific limitations:

• No reflection (because the JS code is normally obfuscated)
• No dynamic proxies
• No runtime bytecode generation (ASM)
• Partial dynamic class loading support
• No network API
• No multi-threading

On the plus side, there are many projects out there that partly solve those issues. I have seen the following:

• An implementation of Google Guice for GWT (GIN).
• An other DI framework similar to Spring, including even some AOP
  
• Some API that allows to do reflection and bean introspection.

The build-in support for dynamic class loading work as such: using some API method, you specify that this part of the code will only be "accessed later". And so GWT works out with actual part of those classes are not directly referenced from the booting class (entry-point), and saves them in a separate JS file, which is loaded later, on demand. This allows the fast start of large applications. But the real limitation, is that the whole application *must be compiled in one go* (and it is said to be pretty slow, as multiple implementations are generated for the different platforms and browsers). So you can't really split your application into several jars, that are build and deployed independently. But at the code level, you can split it in modules, and reuse the modules in multiple application, with the downside that each module is re-compiled for each application. I think that to do rally modular applications, you would have to do separate applications, and wrap them up together by a front-end application. They could talk to each other on the server side, but not sure how they would do that on the client side. But not all is bad; there are multiple good sides to GWT, compared to traditional AJAX development. GWT apps are very portable to all browsers, without much changes, if any, and are optimized at compile time. Still, I think they should work on getting real dynamic class loading, since this is basically possible in JavaScript.

Under GWT, an actor framework would not make much sense, since we are not multi-threaded, but I think that if we had an implementation that was made like an event-bus, using the same API, we could still reuse it in GWT, and that could allow reusing the same code on the client and server.

So far I haven't made up my mind, but I think I'll just try to do a desktop version first, and check out Android later. I doubt I'll try to do an iOS, Flash, or HTML5 version.

[monster]

And I forgot to say that you can use Xtend to program with GWT or Android, which I find is pretty cool too.

[Raoul Duke]

haxe + nme is not perfect, but does actually work, if you are willing
to fight with it enough.

[monster]

Oh, I had totally forgotten about Haxe. I found the language syntax rather ugly, but the general concept and implementation is really great. Unfortunately, translating the language is only half the problem. The biggest issue is not having all your beloved APIs. But I suppose each and every API class and method in Haxe is available in all supported languages, so once you have adapted to Haxe's API, then things get smooth. I've got to look up what NME is ...

[monster]

NME sounds pretty cool. :) At least if you come with a Flash background, which seems to be there target dev audience. But it wouldn't be anything for me, because at the core of my game concept, is the idea that "fans" should be able to easily write their own game extensions, so that an ecosystem can evolve around my games. This is only really possible if the same "extension code" works both on the client and the server. I would have to drop Java entirely, and write the server in Haxe too. And since Haxe translates to things like C++, I don't think dynamic loading of plugin/extensions would be possible with it. But for a dev who is not interested in that, it supports even more platform then any Java game engine I have seen. :)

[monster]

OK. I think I might have seen that before, but forgot it. You can use multiple threads in JavaScript, in more recent browsers: Web-Workers
So in theory, that means it might be possible to actually use actors in a GWT application, if we created JActor implementation that used them instead of Java threads. :) (JSActors?)

A subsequent search revealed that some attempts have already been made in that direction: WebActors

[William la Forge]

If you are going to implement mailboxes over a pool of web workers, you are going to need concurrent data structures. And that does not look possible, as memory is not shared. 

Apparently there is no way even to implement semaphores. So you are stuck with the heavy-weight web workers--there is no way to implement pseudo threads. You will need to severely limit the number of mailboxes/web workers. Fortunately though, with the jactor model you can have any number of actors sharing the same mailbox.

Bill

--
You received this message because you are subscribed to the Google Groups "AgileWikiDevelopers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to agilewikidevelo...@googlegroups.com.
To post to this group, send email to agilewiki...@googlegroups.com.
Visit this group at http://groups.google.com/group/agilewikidevelopers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[William la Forge]

One thing that is important is that the actors under each web worker are named or have an index value. Messages (requests) will need to name the target actor and be sent to the appropriate web worker. The web worker then will need to route the request to the appropriate actor or process the response object.

Responses will be interesting. Request messages must include the index or name of the request context. So when sending a request that is not a signal, the name or index of the request context must be sent. And that name or index must be returned with the response. The request context is created when a request is received and must be registered for subsequent use in subsequent requests/responses to other actors.

The reason for all this complication of course is that web workers have only a very simple means of handling responses. Fortunately, a lot of this is just a matter of reworking the jactor messaging logic. The interesting thing here will be defining a usable API of course.

[monster]

Oh, I see you have taken more of an interest in this as I had expected. :)

I must admit I have not looked at the Web Working API in details, but it was my understanding that it's something similar to having a thread tied to a thread-safe queue. When it gets messages, it processes them, and when the queue is empty, it goes to sleep (blocks until new messages come). So we actually probably can't have something like a thread-pool, but rather need one Web-Worker per Mailbox instead. That is heavier, but if the number of Mailboxes is limited, might be workable.

I might not have thought this through, but I think a request-response cycle with a response handler could be simulated on top of simple one-way messages.

And while I have no intension of even trying to do that kind of stuff in the near future (mainly because you can't load code dynamically at runtime with GWT), the realization alone that it seems possible is quite exciting, I think. :)

[William la Forge]

What would make it a lot more interesting would be if web workers could run on the graphics card. It is ideal for it, since web workers do not share memory.

I had a lot of fun last night and this morning identifying implementation issues and solutions. But it is all academic at this point. :-)

[monster]

On Monday, May 27, 2013 3:38:04 AM UTC+2, Bill wrote:

What would make it a lot more interesting would be if web workers could run on the graphics card. It is ideal for it, since web workers do not share memory.

I had a lot of fun last night and this morning identifying implementation issues and solutions. But it is all academic at this point. :-)

I've actually spent quite investigating what could be done on the GPU; I even read an OpenCL book last year. It sounds really great in theory, and so many devs have a go at it, but the sad truth is, that few uses-cases actually benefit from running on the GPU. The cost of getting data there and back, and the fact that there are significant restrictions one what GPU programs can do, outweigh the benefits. A good use case is one where:

1) The algorithms lend themselves to the GPU architecture. That means lots of tasks, or data-streams, that can be processed in parallel *and do NOT require inter-task coordination*.
2) The amount of processing is very large (password-cracking, molecular simulation, ...)
3) The amount of data itself is not to huge, and the processing time largely outweigh the transfer time.
4) The amount of code to do the processing is also not too large.
5) You don't have much "branching" (IFs)
6) You don't need to use any third party API to do your work, because it's just not going to run on the GPU (or you have to do a total refactoring of that API first yourself).

Most of the GPU programs out there are more proof-of-concept, then something really useful.

[William la Forge]

Actually I wasn't thinking of GPU. Apparently there is a card available that contains 1,000 processors that can be plugged into the PC.

But it is unlikely that any browsers would support its use in running web workers.

--