Some of the Slick2D folks are organizing a new game contest on slick forums, here is the contest poster:

We are thinking in joining the contest, mainly because we want to test some new frameworks and libraries, and to make some new games too. Well, we also want those Magicka keys to play it :D.

Because some people asked, in this post we are going to explain in some detail how we do the balls movement in Zombie Rockers. All this work could be useful for other kind of games using paths like, for example, a tower defense.

For Zombie Rockers (we have to change that name), we defined a Path as an ordered collection of points. Simplifying our Path class, it could be something like this:

class Path {
ArrayList<Vector2f> points;
}


note: we are using Vector2f provided by Slick2D

To easily traverse a path, we created the class PathTraversal, which let us move forward or backward through the path. For example, we could start in the beginning of a path built by three points: (100,100), (200, 100) and (300, 100). Then, if we advance 50 units, then we are going to be on the coordinate (150, 100), between first and second point.

note: when we say units, could be anything you need, pixels, meters, etc, it is not important for the example.

The idea of the PathTraversal in the future is to support any kind of paths, for example, one made using Bézier curves instead only a list of points.

This shows the API of the PathTraversal:

class PathTraversal {
// the path we are traversing
Path path;
// the distance to the origin we are right now
float getCurrentDistance();
// go back the specified distance
void backward(float distance);
// go forward the specified distance
void forward(float distance);
// returns a point based on the current distance
Vector2f getPoint();
}


You can create the Path in the way you want, for Zombie Rockers we are using SVG files to store the paths for each level and we are loading it using SVG Salamander project. First we create a AWT Shape using the Path class provided by the SVG Salamander, then we use a PathIterator to build the points we need to create our Path.

public List<Vector2f> loadPointsFromSVG(URI fileUri) {
ArrayList<Vector2f> points = new ArrayList<Vector2f>();
SVGDiagram diagram = SVGCache.getSVGUniverse().getDiagram(fileUri);
SVGElement element = diagram.getElement(pathName);
List vector = element.getPath(null);
com.kitfox.svg.Path pathSVG = (com.kitfox.svg.Path) vector.get(1);
// get the AWT Shape
Shape shape = pathSVG.getShape();
// iterate over the shape using a path iterator discretizing with distance 0.001 units
PathIterator pathIterator = shape.getPathIterator(null, 0.001d);
float[] coords = new float[2];
while (!pathIterator.isDone()) {
pathIterator.currentSegment(coords);
pathIterator.next();
}
}


To create the SVG path, you can use any program you want, in our case we are using mainly Gimp, we tried using Inkscape too but as we are creating the levels using Gimp it was easy to do all the work using the same application. So, open Gimp, create a path and then export it to a SVG file. Then, it should be ready to be loaded by SVG salamander inside your code.

A working example of this technique is shown in the next video of Zombie Rockers:

### Conclusion

This solution works well while you avoid making the angle of two consecutive segments too sharp. For example, right now when balls traverse between two segments where the angle is too sharp, they will change the render direction too quickly and doesn’t looks so good.

Figure 1: The problem of SVG Path when the angle of two consecutive segments is too sharp.

One solution to reduce this, is to increment the points of the path when making a discrete version of the path, so you will have more intermediate points, then less angle brusque changes.

Another solution is to use a smooth change for the rendering direction, so when you change the value of the render direction, it will change smoothly over time.

Hope it could be of help.

Update: Added figure for the problem of the angles between segments.

Update2: Added links to the current implementation of Path and PathTraversal classes.

Update3: Fixed the path example.

Mavennatives project is composed by a Maven plug-in and an Eclipse plug-in we developed in order to simplify working with natives dependencies.

The Maven plug-in unpacks every dependency with a classifier beginning with “natives-“. By default its executed in the package phase, and unpacks in the target/natives directory.

The Eclipse plug-in automatically executes the Maven plug-in and configures the java.library.path for Eclipse projects with natives dependencies. This makes working with natives dependencies transparent and you can use the Run menu without having to set java.library.path manually for each run configuration. Right now this Eclipse plug-in only works with an outdated version of m2eclipse but a new version is in the works.

To work with LWJGL natives, we made custom releases of LWJGL jars with classifiers “natives-win”, “natives-linux” and “natives-mac” with corresponding OS natives each one. As the Eclipse plug-in is not working with current m2eclipse version, we added the goal nativedependencies:copy to Maven -> Life Cycle from Eclipse project properties, so each time you clean the project the maven plug-in executes and the natives are copied to target/natives folder, after that, we configure by hand the java.library.path to point to that folder.

 Mavennatives plug-in is [already on Maven central](http://mavencentral.sonatype.com/#search ga 1 mavennatives) and we are trying to get LWJGL and Jinput into Maven central too, using the natives format natives-\${os} we defined for this plug-in.

If you want to take a look at the project, visit googlecode at mavennatives.

UPDATE: maven natives eclipse plug-in is updated so it should be working for latest version of m2eclipse

UPDATE2: maven natives eclipse plug-in is not working with the latest version of m2eclipse hosted in eclipse.org.

UPDATE3: LWJGL is already on maven central.

Getdown is a deployment library like Java Web Start, which provides also an integrated update process for your game. It was started to replace Java Web Start based on the premise that using Java Web Start has a lot of downsides. Getdown is mainly designed to launch games in the desktop like Java Web Start does, aditionally, it creates an installation folder structure and a launch icon on your desktop if you want.

We’ve talked about it a bit on our deployment ways blog post, but now we are making a deeper article based on the experience from testing it a bit with one of our games.

You could use the getdown applet to perform all download and installation process from a web browser or you could create a platform specific installer and, after the game’s launcher is installed as a desktop application, derive to it the rest of the process.

It uses a text file named getdown.txt to configure all your application needed resources, natives, custom jvm parameters, etc, and a digest.txt file to check integrity of all downloaded resources before launching the game. If you deploy it as the getdown applet, then you need to sign the digest.txt file with the same certificate used to sign the getdown.jar in order to run the applet with privileges. Here is the getdown.txt of Puzzle Pirates as an example.

#### Pros

• It uses a single file to configure the application in a similar fashion Java Web Start does with the JNLP file, with some extra options. This is good because it is independent from the deployment option used, you can use the installer or the browser applet and use the same configuration file.
• Provides a way to specify platform specific resources to be downloaded only if you run the game on that platform.
• The loading screen is customizable like the LWJGL Applet Loader. Java Web Start provides a way to customize loading screen but you need at least Java update 18 (haven’t tried it yet).
• It validates all dependencies using the signed digest file. This is very interesting because you only need to sign one file with all the resources digests, without having to sign each file.
• It provides a way to update your game by downloading a patch and applying it in the client machine. It requires you work with versions to use that feature (docs about versions are not ready yet).
• Open source project with good documentation.
• It is being used by professional games.

#### Cons

• It only uses RSA for the certificate private key, so if you already own another type of private key it will not work.
• Doesn’t handle pack200-gzip encoding and stuff. It doesn’t even have a way to force to download a .pack.gz either, like the LWJGL Applet Loader does.
• It is very slow for checking files to download info, like the LWJGL Applet Loader it is not using concurrent HTTP requests for that. Java Web Start and New Generation Plug-in Applets does and it starts faster.

Note: we don’t know exactly how it is doing all the cache stuff, from the wiki page it seems like it doesn’t use Java Web Start cache, but from the practice it seems it is using it. It seems to be a bug, for that reason we didn’t want to comment the cache stuff in the pros/cons section.

The Getdown developers have a lot of other useful libraries for Games development, take a look at them at Three Rings code page. Some games using Getdown are Pets Vs. Monsters from Sweet Robot, Puzzle Pirates, Bang! Howdy, Spiral Knights from Three Rings and Tribal Trouble 2 from Oddlabs.

We have one game deployed using getdown to test it, however if you accepted our certificate before, it will ask to accept again as it is using a new one because the second cons we mentioned before. If you want to test it, click here.

## Conclusion

The user experience when playing a game deployed using Getdown with a customized loading screen is really professional and it feels like you are playing a non Java Game (hate to say that, but we can’t avoid bad Java preconceptions).

## References

UPDATE: added a new entry in the pros section about an update game feature by applying a patch

Now that we talked about the LWJGL Applet Loader, we want to talk a bit about the JNLP Applet Loader. In a quick description, the JNLP Applet Loader is an adapter of the LWJGL Applet Loader to make it work with JNLP files.

### Motivation

All of our games were previously released through Web Start and New Generation Plug-In Applets using JNLP files and we wanted to use LWJGL Applet Loader in an easy and seamlessly way.

### Solution

Our solution was to create an Applet to parse the JNLP file and with that information, create the parameters needed in order to run the LWJGL Applet Loader.

Right now, it works with two parameters:

• al_jnlp : an URL used for telling it where to find the JNLP file to use in order to launch the game. First, it downloads and parses the JNLP file and with the information provided, and with that, it creates all LWJGL Applet Loader parameters (al_jars, al_main, etc).
• appendedJarExtension : a String suffix appended to all jar and natives dependencies in order to let the LWJGL Applet Loader to download optimized with pack200 and gzip files while it doesn’t process the content encoding for pack200 and gzip stuff.

You can find the project on github with the name of jnlpappletloader. It is a maven project, and right now, as it depends on a custom distribution of the LWJGL, it will not compile for you at least you configure your local maven repo with the required dependencies. Once the LWJGL is on maven central repo, the idea is to depend on it directly.

The best part is that now we can run any of our already deployed games by making a simple applet like this:

<applet code="com.gemserk.jnlpappletloader.util.jnlp.applet.JnlpAppletLoader" archive="jnlpappletloader-full-0.0.4-jar-with-dependencies.jar" codebase="http://someplace.net/jnlpappletloader/" width="640" height="480">
<param name="al_jnlp" value="http://someplace.net/somegame/launch.jnlp">
<param name="appendedJarExtension" value=".pack.gz">
</applet>


Here is a working example of one of our games using the JNLP Applet Loader (it will look exactly as any other game using LWJGL Applet Loder).

One disadvantage of using the JNLP Applet Loader is the extra time consumed to make the JNLP file request and to parse it vs just using the regular LWJGL Applet Loader. However, using the JNLP Applet Loader lets you to use one centralised JNLP file for all your game’s launch configurations through different deployment options. Also, if you deploy your game in several portals like Games4j, GameJolt, your own page, etc, and you make a change of your game’s launch configuration, your change is automatically replicated because all of them use the same configuration file.

Note that the project is highly coupled to LWJGL Applet Loader, it will not work for any Applet (it should be named something like JNLP Adapter for LWJGL Applet Loader).