Making a LibGDX Roguelike Survival Game Part 1 #gamedev

After failing to complete the 7 Day Roguelike challenge I was left with some working code for a simple pixel art game that had the basics that might help new game developers.

I plan on developing this game further, demonstrating some basic techniques and hopefully motivate people to make their own games.

* source code for this post is available on Github

7DRL Game

To start you will need to download LibGDX setup application and generate a new project, there is information on getting setup on the LibGDX website. I will be using Eclipse Luna as my editor.

Here is my project setup, to keep this less complicated I am only launching this application on the desktop, I used a random name generator which came up with EvoScape.

Once you have created and imported your project into Eclipse (Gradle Porject) or your preferred editor run the application as a Java App, you should see this:

If you have worked with LibGDX previously I am sure you have seen this screen many times! There are only three files changed / created for this first part of the tutorial:

DesktopLauncher.java

Add these two lines to the launcher so the game height and width are set:

config.width = 800;
config.height = 600;

gameclass.java

Apart from the standard Texture and Spritebatch variables that LibGDX add as default these class variables are defined:

OrthographicCamera camera;
Control control;

// Display Size
private int displayW;
private int displayH;

// Temp x and y co-ords
int x, y;

// For Movement
int direction_x, direction_y;
int speed = 3;

Control is our own class used to handle keyboard input, the Orthographic-camera will handle the viewport, other variables are used to hold the screen size and some temporary values to track the position of the camera.

// CAMERA
displayW = Gdx.graphics.getWidth();
displayH = Gdx.graphics.getHeight();

// For 800x600 we will get 266*200
int h = (int) (displayH/Math.floor(displayH/160));
int w = (int) (displayW/(displayH/ (displayH/Math.floor(displayH/160))));

camera = new OrthographicCamera(w,h);
camera.zoom = .4f;

// Used to capture Keyboard Input
control = new Control(displayW, displayH, camera);
Gdx.input.setInputProcessor(control);

Gdx.graphics is used to get the width and height of the screen, we have set the screen size to 800 by 600 but we can allow the user to resize the screen or go full screen, these values can later be updated when the screen size changes.

There are many ways to set up the OrthographicCamera, depending on the type of game you may want different sized viewports, check the LibGDX wiki for additional information. It is also worth looking at the viewport options but for the moment this simple setup is fine. The camera also has the ability to zoom in/out.

Before looking at the render loop of the main game class lets take a look at Control.java:

public class Control extends InputAdapter implements InputProcessor {

It is important the class that handles keyboard input extends and implements the above classes, the editor will ask us to add the unimplemented methods after we change our class to extent and implement the LibGDX classes, keyDown and keyUp are what we will use at this point. Using a simple switch statement the class booleans can be set or functions called when certain buttons are pressed/released:

switch (keycode) {
  case Keys.DOWN:
    down = false;
    break;
  case Keys.UP:
    up = false;
    break;
....

WASD and the arrow keys set the up,down,left, right values to true on press and false on release, these boolean values can be used to determine if movement should occur. Backspace is used to toggle debug, this will be useful for displaying collision hit-boxes and displaying debug info later on and esc key is set to exit the application. The other functions already added will be explained in another post.

Looking back to the gameclass.java file and the render funciton:

// GAME LOGIC
// Reset the direction values
direction_x=0;
direction_y=0;

if(control.down) direction_y = -1 ;
if(control.up) direction_y = 1 ;
if(control.left) direction_x = -1;
if(control.right) direction_x = 1;

camera.position.x += direction_x * speed;
camera.position.y += direction_y * speed;
camera.update();

// GAME DRAW
batch.setProjectionMatrix(camera.combined);
batch.setBlendFunction(GL20.GL_SRC_ALPHA, GL20.GL_ONE_MINUS_SRC_ALPHA);

batch.begin();
batch.draw(img, 0, 0);
batch.end();

The render function is called 60 times every second, LibGDX defaults to 60 FPS. Here we reset the current direction in x (horizontal) and y (vertical) to 0, then given up, down, left, right are pressed (checked via the Control Class) the direction variables are set accordingly, the camera x and y positions are added to using the value and a speed multiplier. After changing the camera in anyway we have to call .update() for the changes to be applied to the camera.

The SpriteBatch projection is then set to that of the camera before drawing the default LibGDX logo, running the application you should be able to move the camera arond and exit using esc:

In part two we will look at creating a small island, using a simple chunk system.

 

 

 

Advertisements

Zero Hour Gamedev

I have been toying with Java game code for a few years now, entered a few game jams and started multiple projects that are all on hold, this has all been a learning expereince but it is time to create a game how ever long that takes! With a young baby to care for I only find the odd hour to write code.

I would like to make a top down shooter, inspired by retro games such as Chaos Engine, Universal Warrior, Micro Machines, GTA 1 but also newer titles like Nuclear Throne. At the moment I have the start of some systems; vehicle (7 types), lighting, chunk/map, player, inventory and time.

All the Gifs!

Box2D is a great 2D physics engine ported to LiGDX, I followed this tutorial to make a vehicle, well a box with 4 wheels that sort of acted like a car. Here you are seeing two scenes being rendered, Box2D’s debug renderer showing the outlines of bodies and also a separate 3D camera overlaying 3D objects:

I then created some vehicles to replace the debug lines, these are just concepts at the moment and need work:

I have never really played with 3D but as I only really need to use 3D as a visual overlay its not too difficult. I implemented a cube builder which creates a cube made up of many other smaller cubes, the function shown here generates a cube split by a random number, I considered a Minecraft style method of building the environment, tested out culling/caching models so this would run for large cities. Once I have a clearer vision for the style of the game then I can create some 3D objects and texture/skin them.

Damage is not currently visible but I have deferred the Box2D listener events to the car class collision object, this captures what was collided with and the speed of the collison. I then got carried away with Box2D joints and started to make all sorts of weird trailers and trains but only shared the caravan, it handles terrible but will have some purpose in the game:

Next I experimented with lighting, Box2D lights is simply to use and works well with Box2D objects had some fun revisiting trig to calulate the position of the light in relation to the car:

Not sure the lighting suits a pixel art game, I posted on Java Gaming for some advice with Nuclear Throne style lights, Orange Pascal the developer behind so many great games (orangepixel.net) linked me to a tutorial he had posted, I have not really experimneted much with this but it works. There is a day/night cycle in place at the moment, I have to keep the 2D and 3D lighting in sync to achive this but that is pretty straight forward.

This is all I have at the moment, had a lot of fun prototyping, a long way to go but feel this is worth this is the type of game I would like to commit too.