Slick+Eclipse Tutorial

By Paul Gestwicki

This page provides information on how to create a simple project using Slick, a free 2D Java game engine built on LWJGL, using the Eclipse IDE.

Download the software

You will need to download the following software. It is all free and cross-platform.

Java SE Development Kit (JDK), which is needed to write your own Java programs. Download the latest release for your operating system. (Unfortunately, last I checked, not all of Java's features work properly on 64-bit Linux distributions. I recommend Linux users doing Java development stay with 32-bit for now. This will supposedly be fixed in Java 1.7.)
Eclipse, an integrated development environment. Install Eclipse by extracting all the files in the archive.
Slick, a library for 2D game development. Be sure to download the full distribution, not just the Slick library. Extract the archive file to some convenient location on your drive; for the rest of this tutorial, this location will be referenced as SLICK_HOME.

Create and configure your new project

Launch Eclipse, select your workspace, and create a new Java project. In recent versions of Eclipse, the default behavior is to separate your bin and src directories. If you are using some custom configuration for new projects, make sure you choose to separate these directories; it will save you trouble later.

We need a place in the project to store all of the libraries we will need, so create a new folder within the project called lib. The first libraries we will put in there are the Slick and LWJGL libraries, which are in the lib folder of the full Slick distribution. There are two ways to copy files around:

From within Eclipse, right-click on the lib folder, select "Import", and then navigate to your SLICK_HOME's lib folder. Select slick.jar and lwjgl.jar and these will be imported.
Use one of your operating system's tools to copy the files outside of Eclipse. After you do this, you must refresh your Eclipse project so that Eclipse is notified of the change. "Refresh" is one of the options in the context menu if you right-click on your project.

Just putting these two jars into your lib folder does not allow your code to use them yet. You must first add the jars to your project's Build Path: this ensures that when the program is compiled or executed, both jars are in the classpath. You can add each jar to your Build Path through the context menu. However, note that when you add a jar to the Build Path, it will seem to disappear from the lib folder. This is a bit of an Eclipse oddity: in the Java perspective, Eclipse will now show a "Referenced Library" area in your project. The jar you just added to the Build Path will now look like it is in the Referenced Library area. In fact, only the project configuration has changed, but the filesystem has not. To verify this, you can use your operating system's file browser, or switch Eclipse to Resource View; you will see that the jar is still actually in the lib folder, and it is just the Java perspective that has tried to be helpful.

Once you have added these jars to your Build Path, you are ready to write your first Slick application. However, there is one more step that I recommend: you can attach the javadoc documentation for Slick to the Slick jar in your Build Path. Doing this allows you to see the javadoc while developing, such as through code completion boxes. To do this, navigate to your slick.jar in Referenced Libraries and edit its properties through the context menu. One of the tabs allows you to specify the Javadoc Location. From here, point to the javadoc folder in SLICK_HOME. The Validate button will confirm that you have chosen the right location.

Write a Slick Test Application

There is a bit more configuration required to run a game, but what good is configuration without a game to test? In this step, you will make a very simple Slick test application.

Start by making a package for your project. According to Java's naming conventions, this should start with the reverse URL of your institution. For example, as a Ball State University employee, I put all of my projects into a package called edu.bsu.XXX, where XXX is the name of the project.

The simplest way to make an application in Slick is to extend BasicGame. Create a new class called SimpleTest, with the content as specified below.

package edu.bsu.slicktest; import org.newdawn.slick.BasicGame; import org.newdawn.slick.GameContainer; import org.newdawn.slick.Graphics; import org.newdawn.slick.SlickException; import org.newdawn.slick.AppGameContainer; public class SimpleTest extends BasicGame { public SimpleTest() { super("SimpleTest"); } @Override public void init(GameContainer container) throws SlickException {} @Override public void update(GameContainer container, int delta) throws SlickException {} @Override public void render(GameContainer container, Graphics g) throws SlickException { g.drawString("Hello, Slick world!", 0, 100); } public static void main(String[] args) { try { AppGameContainer app = new AppGameContainer(new SimpleTest()); app.start(); } catch (SlickException e) { e.printStackTrace(); } } }

Keeping in mind that Eclipse should recompile your work every time you save your file, you can now try to run your application. However, you will receive an UnsatisifedLinkError. (If you get other errors, such as ClassNotFoundException, make sure that you added lwjgl.jar to your Build Path.) The reason this has not worked is that LWJGL, on which Slick depends, requires native libraries. That is, it links at runtime to libraries that are specific to the host operating system. These system-dependent libraries are also distributed as part of Slick, so it's only a matter of putting them in the right place and configuring the runtime environment.

Configuring Native Libraries

Now we will configure the project to support Microsoft Windows, Linux, and Apple Mac operating systems, the three supported by LWJGL. If you want to keep your project size slim (such as if you're using source code versioning software on a low speed Internet connection), you could skip the steps for foreign operating systems.

It is important to note that you can install these libraries system-wide, so that all of your projects and applications have access to them. However, this can cause problems if you want to test different versions of libraries, or if you want to simulate the environment of a user who has not installed the libraries system-wide. Hence, we will install these libraries only for this specific project. Once you have one project set up, it's a simple matter to copy it within Eclipse and keep all of the library configuration.

If you look in SLICK_HOME's lib folder, you will see three jars, one for each supported operating system. We will copy the contents of these jars (not the jars themselves) into your project's lib folder. One easy way to do this from within Eclipse is to right-click on the destination folder, choose Import, and then Archive File; this will pull the contents of an archive file right into the target directory.

UPDATE: As of this writing, the Slick distribution does not include the 64-bit native libraries for LWJGL. You can download these as part of the LWJGL distribution. Just plop these into your lib folder and you should be all set.

Once you have imported all of the native libraries into your lib folder, you can associate this folder with lwjgl.jar. If you are in the Java Perspective, then this jar will be located in the "Referenced Libraries" section. Bring up the properties dialog for lwjgl.jar by right-clicking on it. In the "Native library" page, select "Workspace..." and choose your project's lib folder.

Now, run your application again, and you should be greeted with a friendly message and a FPS count. After basking in the glory of your application, depending on your platform and configuration, you may not be able to close your application's window using the normal method (probably an "X" in the corner); you would need to manually add this behavior, but that's the subject for another tutorial. For now, you can use the square red button in Eclipse's console to force the process to exit. Keep this trick in mind as you are writing your masterpiece, since everyone introduces an infinite loop or a synchronization error sometime.

Note that because all of your native libraries are in one folder, the approach outlined above will work regardless of whether you are on a Linux, Windows, or Mac machine. Furthermore, if you put your project into a repository and share that repository among operating systems, the program should still run properly without changing anything... but that's the topic for another tutorial.