The PlayN Experience

In an online discussion, a student asked me the following with respect to Equations Squared:

How does PlayN compare to say Slick2D? Is development with it straightforward? Did you have any major issues along the way? Most of the example games listed don't even work in Firefox, but I noticed Equations Squared does. Was this extra work or are others just lazy? Answers to any of these questions would be greatly appreciated.

My summary of the design and development of Equations Squared mentions little about its technical architecture aside from the fact that I used PlayN. Briefly, PlayN is a game programming library that allows you to write games using a standard Java toolchain and then cross-compile them to several different platforms, including HTML5, Android, and iOS. It is based on the same fundamental technology as Google Web Toolkit, which permits development of AJAX Web applications from pure Java source; GWT is used to implement such powerful Web applications as GMail.

I got interested in PlayN because of the potential to build HTML5 applications while leveraging my knowledge of Java. I've done very little Javascript, and I know from personal and vicarious experience that browser-specific quirks are a special kind of hell. Yet, the browser is the common modern networked operating system, and I figured that a pure HTML5+JS solution would improve the chances of both longevity and adoption for a math assessment game. As much as I love standard Java and Unity3D, both require third-party plug-ins; my experience working with schools is that very often, if a teacher wanted to use such software, they often do not have permission or knowledge to install and configure it. The fact that PlayN is based on GWT was an easy sell for me, as I've been telling students for years that GWT represents the state-of-the-art.

Getting started with PlayN requires you to dive into Apache Maven. It took me some time to wrap my head around Maven, but now that I've used it, it's hard to imagine life without it. In a nutshell, it manages project dependencies and build lifecycles. Previously, I was used to this sequence:

1. Find a library I want to use in a project.
2. Download the binaries and documentation jars.
3. Put these into lib and doc folders in my project.
4. Adjust the Eclipse build path and, if necessary, native library locations.

Now, with Maven, the process looks like this:

1. Find a library I want to use in a project.
2. Edit my POM file.

Nice. While I was working on my game, new versions of some of my dependencies were released. Getting the new versions into my project was literally as easy as changing a version number in the POM.

It's not all milk and honey with Maven. The Eclipse integration allowed me to import my project without too much trouble, but I found the integration imperfect, and I ended up doing a combination of developing and compiling in Eclipse while building release candidates on the command line. Fortunately, you don't have to start by mastering all of Maven: the PlayN Getting Started Guide provides just enough to get you started. As with anything, follow those steps, and then take some time to look at what really happened with your project.

Perhaps the biggest non-technical hurdle to getting into PlayN is the rendering model. There is a complex system of layers, and I found myself having to refer to the documentation time and time again to ensure that I was using each properly. I ended up making extensive use of GroupLayers to handle the hierarchical nature of the game. For example, each of the dashboards is a group layer consisting of nested layers, and moving a digit from the right-hand side tray to the board ends reparenting it from one layer to another. Once I got into the flow, it was no trouble at all, but I'm not confident I could sit down right now and whip up a demo without re-reading the documentation again. Contrast Slick, for example, where I know I could whip up a little demo that makes a guy dance on the screen in almost no time; more on Slick later.

Screenshot of the game

I used the excellent TriplePlay, Pythagoras, and React libraries along with PlayN, along with my old favorite, Guava. All the logic of the game was written using test-driven development, which saved me several times from introducing regression defects, particularly in the parsing of various kinds of arithmetic expressions.

While TriplePlay made handling text much easier, I did find uncover cross-browser problems when using this library—some of which have been fixed since then. There are subtle problems with text alignment, which caused me trouble when the main tiles of my game were being dynamically generated. To avoid having to write krufty browser-specific code, I ended up replacing the dynamic tiles with static images from a sprite sheet. I'm guessing that the failure of some PlayN projects to work in Firefox is due to similar issues combined with lack of QA. Once again, thanks to all my testers!

The sprite sheet that replaced dynamically-generated tiles

The student's question asks about a comparison of PlayN to Slick2D, the latter of which was used to develop Morgan's Raid. All the important technical aspects of Morgan's Raid could have been done in PlayN; in fact, some may have been easier if I had known about Maven at the time, since we used a build server with continuous integration and test-driven development. Neither Slick nor PlayN save you from having to do some fiddling with project configurations and native libraries. Slick is almost certainly faster to get up and running, assuming you don't run into LWJGL version problems—which you almost certainly will at some point. Slick+Maven may be worth my investigating.

The real decision between PlayN and Slick2D comes down to target platform and choosing where you want to fight with it. Slick will always require the client to have Java installed, or you'll have to heavily invest in making custom installers. Remember that installing Java—or anything—is seriously scary or impossible for some people.  With PlayN, you can deploy straight to HTML5+JS, but in my experience, you still need to do platform testing even if you do everything the documentation tells you: some things still won't work right. You can also build to recent versions of Android: I tried this and it worked well for me, but I didn't have time to design the game for the various mobile screen sizes. I cannot comment from personal experience on the Flash or iOS support in PlayN, though there seem to be some problems with the Flash compiler based on discussions I've seen on the mailing list.

I hope that this summary of my experience with PlayN, and the comparison to my Slick experience, is useful to you. Feel free to leave comments below and I'll do my best to get back to you.