64x64 icon dark hosting
Choose a hosting plan here and get a free year's subscription to Tuts+ (worth $180).

Make a Neon Vector Shooter in jMonkeyEngine: The Basics


Start a hosting plan from $3.92/mo and get a free year on Tuts+ (normally $180)

This post is part of a series called Cross-Platform Vector Shooter: jMonkeyEngine.
Make a Neon Vector Shooter in jMonkeyEngine: Enemies and Sounds

In this tutorial series, I'll explain how to create a game inspired by Geometry Wars, using the jMonkeyEngine. The jMonkeyEngine ("jME" for short) is an open source 3D Java game engine—find out more at their website or in our How to Learn jMonkeyEngine guide.

While the jMonkeyEngine is intrinsically a 3D game engine, it's also possible to create 2D games with it.

Related Posts
This tutorial series is based on Michael Hoffman's series explaining how to make the same game in XNA:

The five chapters of the tutorial will be dedicated to certain components of the game:

  1. Initialize the 2D scene, load and display some graphics, handle input.
  2. Add enemies, collisions and sound effects.
  3. Add the GUI and black holes.
  4. Add some spectacular particle effects.
  5. Add the warping background grid.

As a little visual foretaste, here's the final outcome of our efforts:

...And here are our results after this first chapter:

The music and sound effects you can hear in these videos were created by RetroModular, and you can read about how he did so here.

The sprites are by Jacob Zinman-Jeanes, our resident Tuts+ designer. All the artwork can be found in the source file download zip.

The font is Nova Square, by Wojciech Kalinowski.

The tutorial is designed to help you learn the basics of the jMonkeyEngine and create your first game with it. While we will take advantage of the engine's features, we won't use complicated tools to improve the performance. Whenever there is a more advanced tool to implement a feature, I'll link to the appropriate jME tutorials, but stick to the simple way in the tutorial itself. When you look into jME more, you will later be able to build on and improve your version of MonkeyBlaster.

Here we go!


The first chapter will include loading the necessary images, handling input, and making the player's ship move and shoot.

To achieve this, we will need three classes:

  • MonkeyBlasterMain: Our main class containing the game loop and the basic gameplay.
  • PlayerControl: This class will determine how the player behaves.
  • BulletControl: Similar to the above, this defines the behavior for our bullets.

During the course of the tutorial we will throw the general gameplay code in MonkeyBlasterMain and manage the objects on the screen mainly through controls and other classes. Special features, like sound, will have their own classes as well.

Loading the Player's Ship

If you haven't downloaded the jME SDK yet, it's about time! You can find it at the jMonkeyEngine homepage.

Create a new project in the jME SDK. It will automatically generate the main class, which will look similar to this one:

We'll start by overriding simpleInitApp(). This method gets called when the application starts. This is the place to set all the components up:

First we'll have to adjust the camera a bit since jME is basically a 3D game engine. The stats view in the second paragraph can be very interesting, but this is how you turn it off.

When you start the game now, you can see... nothing.

Well, we need to load the player into the game! We'll create a little method to handle loading our entities:

At the start we create a node which will contain our picture.

Tip: The jME scene graph consists of spatials (nodes, pictures, geometries, and so on). Whenever you add a spatial something to the guiNode, it becomes visible in the scene. We will use the guiNode because we're creating a 2D game. You can attach spatials to other spatials and therefore organize your scene. To become a true master of the scene graph, I recommend this jME scene graph tutorial.

After creating the node, we load the picture and apply the appropriate texture. Applying the right size to the picture is pretty is easy to understand, but why do we need to move it?

When you load a picture in jME, the center of rotation is not in the middle, but rather in a corner of the picture. But we can move the picture by half its width to the left and by half its height upwards, and add it to another node. Then, when we rotate the parent node, the picture itself is rotated around its center.

The next step is adding a material to the picture. A material determines how the picture will be displayed. In this example, we use the default GUI material and set the BlendMode to AlphaAdditive. This means overlapping transparent parts of multiple pictures will get brighter. This will be useful later to make explosions 'shinier'.

Finally, we add our picture to the node and return it.

Now we have to add the player to the guiNode. We'll extend simpleInitApp a little more:

In short: We load the player, configure some data, move it to the middle of the screen, and attach it to the guiNode to make it be displayed.

UserData is simply some data you can attach to any spatial. In this case, we add a Boolean and call it alive, so that we can look up whether the player is alive. We'll use that later.

Now, run the program! You should be able to see the player in the middle. At the moment it's pretty boring, I'll admit. So let's add some action!

Handling Input and Moving the Player

jMonkeyEngine input is pretty simple once you've done it once. We start by implementing an Action Listener:

Now, for each key, we will add the input mapping and the listener in simpleInitApp():

Whenever any of those keys is pressed or released, the method onAction is called. Before we get into what to actually do when some key is pressed, we need to add a control to our player.

Info: Controls represent certain behaviors of objects in the scene. For example, you could add a FightControl and an IdleControl to an enemy AI. Depending on the situation, you can enable and disable or attach and detach controls.

Our PlayerControl will simply take care of moving the player whenever a key is pressed, rotating it in the right direction and making sure the player does not leave the screen.

Here you go:

Okay; now, let's take a look at the code piece by piece.

First, we initialize some variables, defining in which direction and how fast the player is moving, and how far it is rotated. Then, we set the screenWidth and screenHeight, which we will need in the next big method.

controlUpdate(float tpf) is automatically called by jME every update cycle. The variable tpf indicates the time since the last update. This is needed to control the speed: If some computers take twice as long to calculate an update as others, then the player should move twice as far in a single update on those computers.

Now to the first if statement:

We check whether the player is going up and, if so, we check if it can go up any further. If it is far enough away from the border, we simply move it up a little.

Now onto the rotation:

We rotate the player back by lastRotation to face its original direction. From this direction, we can rotate the player in the direction we want it to look at. Finally, we save the actual rotation.

We use the same kind of logic for all four directions. The reset() method is just here to set all values to zero again, for use when respawning the player.

So, we finally have the control for our player. It's time to add it to the actual spatial. Simply add the following line to the simpleInitApp() method:

The object settings is included in the class SimpleApplication. It contains data about the display settings of the game.

If we start the game now, still nothing is happening yet. We need to tell the program what to do when one of the mapped keys is pressed. To do this, we'll override the onAction method:

For each pressed key, we tell the PlayerControl the new status of the key. Now it's finally time to start our game and see something moving on the screen!

When you are happy that you understand the basics of input and behavior management, it's time to do the same thing again—this time, for the bullets.

Adding Some Bullet Action

If we want to have some real action going on, we need to be able to shoot some enemies. We're going to follow the same basic procedure as in the previous step: managing input, creating some bullets and adding a behavior to them.

In order to handle mouse input, we'll implement another listener:

Before anything happens, we need to add the mapping and the listener like we did last time. We'll do that in the simpleInitApp() method, alongside the other input initialization:

Whenever we click with the mouse, the method onAnalog gets called. Before we get into the actual shooting, we need to implement a little helper method, Vector3f getAimDirection(), which will give us the direction to shoot at by subtracting the position of the player from that of the mouse:

Tip: When attaching objects to the guiNode, their local translation units are equal to one pixel. This makes it easy for us to calculate the direction, since the cursor position is specified in pixel units as well.

Now that we have a direction to shoot at, let's implement the actual shooting:

Okay, so, let's go through this:

If the player is alive and the mouse button is clicked, our code first checks whether the last shot was fired at least 83 ms ago (bulletCooldown is a long variable we initialize at the beginning of the class). If so, then we are allowed to shoot, and we calculate the right direction for aiming and the offset.

We want to spawn twin bullets, one next to the other, so we'll have to add a little offset to each of them. An appropriate offset is orthogonal to the aim direction, which is easily achieved by switching the x and y values and negating one of it. The second one will simply be a negation of the first one.

The rest should seem pretty familiar: We initialize the bullet by using our own getSpatial method from the beginning. Then we translate it to the right place and attach it to the node. But wait, what node?

We'll organize our entities in specific nodes, so it makes sense to create a node where we'll be able to attach all our bullets to. To display the children of that node, we'll have to attach it to the guiNode.

The initialization in simpleInitApp() is pretty straightforward:

If you go ahead and start the game, you'll be able to see the bullets appearing, but they're not moving! If you want to test yourself, pause reading and think for yourself what we need to do in order to make them move.


Did you figure it out?

We need to add a control to each bullet that'll take care of its movement. To do this, we'll create another class called BulletControl:

A quick glance at the structure of the class shows that it is pretty similar to the PlayerControl class. The main difference is that we don't have any keys to be checked, and we do have a direction variable. We simply move the bullet in its direction and rotate it accordingly.

In the last block, we check whether the bullet is outside the screen boundaries and, if so, we remove it from its parent node, which will delete the object.

You may have caught this method call:

It refers to a short static mathematical helper method in the main class. I created two of them, one converting an angle in a vector in 2D space and the other converting such vectors back in an angle value.

Tip: If you feel quite confused by all those vector operations, then do yourself a favour and dig in to some tutorials about vector math. It's essential in both 2D and 3D space. While you're at it, you should also look up the difference between degrees and radians. And if you want to get more into 3D game programming, quaternions are awesome as well...

Now back to the main overview: We created an input listener, initialized two bullets, and created a BulletControl class. The only thing left is to add a BulletControl to each bullet when initializing it:

Now the game is much more fun!


While it isn't exactly challenging to fly around and shoot some bullets, you can at least do something. But don't despair—after the next tutorial you'll have a hard time trying to escape the growing hordes of enemies!