Professional looking games: bundling JREs and making native executables

Hello, everyone.

This article is about making your game look more professional to the average user.

It can’t be denied that there is a certain stigma around Java for use in games. Working on We Shall Wake, both me and other members have encountered people refusing to help or talk with us because we’re using Java. I’ve even written blog posts about why our choice is a good one, but obviously it doesn’t help. Obviously, the average gamer doesn’t know exactly why Java is bad for games, but if they know a game is made with Java and anything at all goes wrong, some people are sadly likely to blame it on Java, and these people are loud.

There are some obvious giveaways for games made in Java. The requirement of a JRE and starting the game using an executable .jar files are both dead giveaways that the game is made in Java, and most importantly they both depend on the player’s computer. Being unable to start a game because Java isn’t installed without a proper error message, or not being able to start it because the Java HOME variable isn’t set properly will cost you quite a few players. More importantly, players shouldn’t have to even care that your game is made in Java, and they definitely shouldn’t have to install separate programs. In addition, many players are not used to .jar files, bat files and other formats often used to launch Java, so we want to give the player an executable file that they are familiar with. We also want these files to have the icons we specify. Thirdly, we don’t want the game to open up with an ugly console/terminal window.

One option is to create an installer which automatically installs a JRE on the client computer and then installs the game. There are many freeware programs that allow the player to create installers. Personally I’m heavily against installers in the first place since the game installation file is just a glorified compressed folder with automatic extraction, and once installed many games are hard to uninstall and may leave files in weird folders all over your computer. I prefer my games portable and confined to a single folder, so an installer is out of the question.

To ease in development, the native executable should not need to be updated for each new build. Preferably it should simply launch the game’s executable .jar file for you so the .jar file can be easily updated without having to remake the native executable files. As a bonus goal, the game should pop up as . in the task manager instead of javaw..

Summary of goals:

  1. Being able to run the game without an installed JRE.
  2. Being able to run the game without the JAVA_HOME environment variable.
  3. No console/terminal window should pop up when the game is started.
  4. The game should be started with native executable files on Windows, Linux and OSX.
  5. The executables should have custom icons.
  6. The native executables should not need to be regenerated when the game is updated.
  7. (Bonus): The game should be listed in the task manager by its name instead of javaw.

The goals are achieved by:

  1. Bundling a JRE with the game.
  2. Directly specifying the relative path to the bundled JRE instead of relying on the environment variable.
  3. Using a program to generate OS-specific executables that supports this.
  4. Using a program to generate OS-specific executables that supports this.
  5. Using a program to generate OS-specific executables that supports this.
  6. Having the executables simply launch an OS-independent .jar file that can be updated independently of the native executables.
  7. Renaming the bundled JRE’s executable javaw file to the game’s name.

Getting JREs for all operating systems and architectures

JREs for all operating systems can be found on Java’s website (DUH). From there on, go to the JRE download page and download the .tar.gz version of the JRE you’re interested in. .tar.gz files can be opened using for example WinRAR, but at least using Chrome the file is somehow renamed to .gz only when downloaded, making it impossible to see the contents of the file. In this case, manually changing the extension to “.tar.gz” solves the problem. Once you have the file opened, it’s simply a matter of extracting the jar to you a folder and you have a portable JRE. The javaw executable is located in the bin/ folder. It’s also possible to get server JREs for 64-bit architectures.

Windows

Generating an executable for Windows is easy. To generate a .exe file, we simply use Launch4j which supports everything we need except the bonus goal.

  1. Download and install =http://launch4j.sourceforge.net/Launch4j.

  2. Launch Launch4j. :stuck_out_tongue:

  3. Enter the path to your game’s executable .jar file. Note that this should path is relative to the .exe file you’ll generate.

  4. Check “Don’t wrap the jar, launch only” so that the .jar file can be updated or replaced later without having to regenerate the .exe file.

  5. Specify your .ico icon for the .exe file (link to online .ico converter).

  6. Head to the JRE tab and enter the relative path to the bundled JRE. Assuming the bundled JRE is in a folder called jre\ in the same folder as the .exe file, this is simply “jre”.

  7. Save the configuration because Launch4j hates you if you don’t.

  8. Generate a .exe file.

  9. Profit!

Note: Since Launch4j does not allow you to specify the javaw.exe file in the JRE manually, you can’t rename it to the game’s name, so Launch4j does not fulfill the bonus goal. Most likely this could be worked around somehow. Suggestions are welcome!

TODO:

Linux

  • Shell script file without an extension for launching? Should be able to launch bundled JRE instead.
  • .desktop entry? Goes against my hate for installers?
  • Other way of setting icon directly of the executable file?

OSX

  • .app package for easy “installation”?
  • Would your average OSX user know what to do with a file the same as for Linux? Not sure what the standard is.

There’s an ongoing thread at here for people interested in helping out with expanding the Linux and OSX sections.