Refactoring

I’ve been slacking off a bit lately, but not long after my previous update, I did add some improvements to the existing code.

The first thing I did was to apply a sort of MVC pattern to the code structure. For this, I’ve created a Level class and paired it with LevelRenderer and LevelController classes. The Level class is the base model in this situation. It contains all the properties required to represent a single level in my future game. As such, it’s always instantiated first.

The Level class contains the player, which is an instance of a Tank, which, in turn, contains a Weapon. Since Tank and Weapon are still relatively simple, they don’t have dedicated Controllers or Renderers yet.

Once an instance of a Level is created, the LevelRenderer and LevelController are created by passing in this instance to their constructors. The renderer is in charge of drawing the level, while the controller handles updating everything related to the level. This means I actually took out part of the code in the render method and placed it into a new update method. This makes the game loop more akin to the standard loop I’m familiar from my stuff in XNA. There’s initialization/creation, updating, drawing and destruction.

I decided to make my level Orthographic camera much simpler. Since levels should be sized in tiles, I  made it’s inner coordinate system an 8×8 grid, simply to avoid dealing with complex calculations in the future. The level is also drawn in a separate gl viewport, again, to make things simpler. This way, I can draw the level without worrying about drawing the interface or anything like that – the interface will be drawn within the global viewport.

With that, resizing is now working much better. The graphics scale with window size and resolution and follow an internal, virtual resolution to keep things simple.

Shooting

I’ve also added basic shooting to the basic weapon. My initial plan was to make a bullet factory/manager which would be initialized at level creation and handle all the bullets currently live within the level. After some time spent badly implementing this, I realized there’s no need for that. Since the game will be turn based, it would probably be much better to simply have each weapon handle their own ammo. Firing will simply be an effect to show on the screen, while the actual damage dealing, aiming, hitting and missing will be handled by math in the background.

Of course, there’s no real turn based system implemented yet, so the basic weapon now simply shoots on whichever part of the screen I double-tap. The double-tap is actually faked to. The controller simply keeps track of how long it’s been since I last tapped the screen, and fires a bullet if conditions are set. Because of that, it’s possible to spam bullets if you just keep tapping.

Screens

Finally, I started using the screen system libGDX offers through the com.badlogic.gdx.Screen namespace. This is done by creating the initial GameScreen class and setting it to implement the Screen class from this namespace.

All the bottom-tier logic was moved from the main Game class to this one, making the Game class extremely simple now:

import com.badlogic.gdx.Game;

public class PucajGame extends Game {

	@Override
	public void create() {
        setScreen(new GameScreen());
	}
}

setScreen will allow me to switch from main menu, to options menu, to game, etc. very easily, so I’m glad I started using it this early.

GameScreen also implements the  InputProcessor class, which brings with it methods required to handle user input, such as keyDown, keyUp, keyTyped, touchDown, touchUp, touchDragged, mouseMoved and scrolled. Since GameScreen is supposed to be the screen where the currently active level is handled, these methods communicate with LevelController to delegate the input to the level. On the other hand, Screen methods (render, resize) communicate with LevelRenderer to handle the drawing.

The Result

The game now scales as I resize the window, I can move and shoot and it looks pretty cool (at least from my point of view). Here it is in action…

As usual, you can see every line of code in my repository – Pucaj on GitHub.

I’ve been thinking about what Pucaj should actually become and I’ve decided on a turn-based RPG with tanks/robots. The vehicles would have parts you can upgrade, or buy, or collect maybe, and you’d move and fight on a grid based map. None of it is really completely decided on and it’s all a blur right now, but one thing I can be pretty sure of – I need grid based movement.

I ditched Box2D, because there really isn’t any need for it, and also ditched the “rotate the tank towards touch coordinates feature I had.

Instead, I implemented the movement based on a grid system.

The first thing I needed to do was to set up scaling of coordinates, so I can work with what are basically integers, instead of screen coordinates.

Since the current map size is 10×10, the player’s position can be stored in a [0..9][0..9] vector. Based on the provided input, it then changes . Since it needs to also look nice, I added a class with static easing methods to interpolate between the new and the old position. The easing methods will be very universal, so I can use them for other things as well. They will require the initial value, the amount that value needs to change for, the duration of the entire process and our current position in the process, as in elapsed time.

Basically, we have something like this:

newValue = easeFunction(elapsedTime, initialValue, totalChange, totalDuration);

For now, all I have is a quadratic easeIn function, but I will be adding more as I need them.

I’m having trouble on deciding how to detect the player’s desired action via touch. For now, I determine the four rectangles the player can move to from the current position and then look if the player has touched a coordinate in any of these rectangles. This works, but it might not be the best approach.

A possible alternative would be to calculate the centers of these four rectangles and then move into the rectangle with the closest center to the touch coordinates.

The first option has the advantage of precise movement, but it also feels a bit stiff. On the other hand, the second approach allows for more freedom, but could also cause unwanted movement.

With the keyboard, this is much more straightforward. You use arrow keys to move and that’s it.

Also, since I don’t want diagonal motion, direction is prioritized in the order of UP, LEFT, DOWN, RIGHT. In the context of the keyboard, this means that if you push UP and LEFT at the same time, you will go up, etc.

In any case, I made a video of what I have and uploaded it on my painfully slow connection. Here it is:

My laptop is complete crap, so it stutters even with this. I promise that if I ever have anything substantial to show, I will use my more powerful PC.

You can see in the video that both touch/mouse and keyboard support exists. When the mouse cursor isn’t moving, but the tank is, it means I’m using keyboard keys.

Impressive, right? /s