On Java game programming

This post is from an older site of mine, at least one person found it interesting, so I’m keeping it.

A simple platformer game running as a Java applet, without the use of premade 2d game libraries. This is a self-directed project to help me learn how to use Java’s Applet class, as well as learning to organize many separate classes. Working revision at bottom.

There are many 2d Java game and graphics rendering/animation libraries, such as LWJGL, Slick (I highly reccomend this one if you want the best experience making 2D games in Java), PlayN, and so forth, but I decided to program this game without the support of any special libraries simple for the purpose of learning Java.

Applet Programming

The foundations of a game made in an applet are based in the idea of threads (a constant loop running the game logic) and image double buffers (though this is something specific to languages like java, which aren’t meant to handle drawing lots of images). Reference link.

This game basically has all the games objects stored in a data structure. When the applet is run(), the data structure is traversed and each object within runs its update() method, which updates position, and so forth. The applet redraws the current game state, and the process is repeated.

Notable classes:

GameObject.class

Sort of the umbrella class that handles all the objects (ground, player, etc) in the game’s properties (position, dimensions, collision box, gravity), as well as methods to update individual objects’ states. Every relevant class extends GameObject.

Level.class

Builds a level based off a self-defined file format. Level files include two sections: a section for grid-based placement, and a section for non-grid-based object placement. Commented lines //like this and blank lines are ignored.

SpriteSheet.class

A class designed to handle loading and drawing a sprite sheet (a single image containing multiple images used in a game, like this one I made for my game). It also handles animations contained in sprite sheets (like the player animations).

Viewport.class

Overrides the default drawing commands (draw to viewport, rather than image buffer) and allows for the player to only see a fraction (viewport) of the level at one time.

A demonstration of how the viewport code works. Objects outside of the viewport (outlined in yellow) and padding (not shown, 32px) are marked as inViewport = false, and not drawn. In the figure above, these non-active objects are shown as black squares simply for illustration.

Level Editor

To quickly deploy testing levels and to add new game objects, I created a level editor class, which handles loading/saving/editing of level files.

Custom level editor made to specifically handle the game’s objects.

Level file format

The editor saves in .tang format (which is entirely arbitrary, simply to discourage people from opening the files). Eventually, a Huffman encoding of the level will be implemented, with a secret tree. Here is an example of the raw level data:

Level file format example

The file is split into two sections, metadata and objectdata, by a colon (:). The metadata contains level information, and is expandable. The object data contains the objects in the map, separated by semicolons (;), with data within each object separated by commas (,).

6/22

changed the way the editor loads objects, decreased level load time 10x

6/21

added viewport panning to level editor

added multiple objects to level editor

added export/load functions to level editor

cleaned up level editor code

added metadata section to level format

changed the way the game loads objects, decreased level build time 10x (update: as more build times are logged, the trend shows that level construction times are around 200ms, with very little dependance on object count)