:::: MENU ::::
Browsing posts in: Report

Pucaj Update – Shooting, Major Refactoring

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.

 


Pucaj Update – New Graphics and Basic Weapon

I didn’t do too much development, but this time, I’m aiming to add something noticeable with every update to keep myself motivated and keep at it, instead of abandoning the project like I did with every one of my previous ones.

I used Gimp to create a new set of sprites for the basic tank. This one looks slightly better than the last one, but isn’t anything amazing. In the end, I’m not artist. While I was at it, I also added a basic cannon/turret graphic and a weapon class. Each tank will have a weapon which is drawn right on top of the base. The weapon can rotate independently from the tank and for now, rotates based on where you click.

The idea is for the weapon class to become a base or even an abstract class from which all other weapons will inherit.

It took me a while to figure out the rotation math, mostly because I was confused with the camera. For some reason, I decided to position the (0,0) coordinate of the LibGDX orthographic camera in the center of the screen, but this just ended up giving me trouble. Because of that, I put it in the bottom left, which makes much more sense to me. I did it the following way:

camera = new OrthographicCamera(Gdx.graphics.getWidth(), Gdx.graphics.getHeight());
camera.setToOrtho(false, Gdx.graphics.getWidth(), Gdx.graphics.getHeight());

The false parameter indicates that the y-axis starts at the bottom. Setting this to true makes it start at the top, which might be more familiar to some people.

A slight issue here is that the y touch coordinate in Gdx.input.getY() starts from the top, but the fix here is simple. You simply subtract it from the camera height to make it go from the bottom.

Vector2 touchPos = new Vector2(Gdx.input.getX(), camera.viewportHeight - Gdx.input.getY());

I decided to calculate rotation not from the exact touch coordinate, but from the center of the tile nearest to the touch coordinate. This way, it’s more of a discreet feel and in the future, when I’m actually targeting enemies centered on that tile, it will look better.

I’ve noticed everything seems a bit too small, though, so I’ll see about increasing the size of everything. Maybe an 8×8 or a 6×6 grid would work a bit better. Ideally, I would have zoom functionality, but that’s a bit beyond me at this point.

Here’s the latest video:

In any case, the game is progressing and I’m still at it. I think my next goal will be to add a basic bullet factory/manager class and add shooting functionality. Either that, or I’ll work on increasing graphics size and maybe try to make the code a bit better. That’s putting me in danger of getting ahead of myself, though.


Pucaj Update – Grid Based Movement

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

 

 


Let Us Begin – Current Projects

First of all, hello!

I’m Nikola Begedin. I’m a software developer and I work and live in Croatia.

I have this dream/fantasy that I’ll finish some sort of amazing side project, get rich, retire early and then continue to play games and dabble in development until I die of old age. It’s never going to happen, but it doesn’t stop me from trying.

Unfortunately, my procrastinating personality does stop me from following up on any of my projects or ideas.

Luckily, I have people who at least try and sometimes succeed at pushing me into doing something. I now also have this blog, which I will use to keep track of my projects and ideas and hopefully do a better job ad working on them.

So here goes…

Current projects

Aside from work, where I’m right now learning a lot about JavaScript, SPA (Single Page Application) development and various modern JavaScript frameworks, in my spare time I also study for my Microsoft certification exams and, more importantly, dabble in game development.

Off the top of my head, I can list a couple of projects. I will try to make updates on each of them as soon as I have anything substantial to talk about.

Pucaj

Pucaj simply means Shoot in Croatian. The idea of Pucaj is for me to get to know LibGDX and Android Development Studio while making something that might one day be called a game. Right now, it’s just a bunch of code without a clear goal in mind.

Pucaj - Grid and player

This is what I have right now. The tank follows your finger/mouse and turns towards it.

LibGDX allows me to develop simultaneously on Desktop, Android, iOS and Web, but right now, I’m only using the Android and Desktop capabilities. With some tricks, I managed to import the project to Android Development Studio, so that’s great to.

You can track my Pucaj repository on GitHub.

Dice and Roll

Dice and Roll is a browser game I’ve been developing with a colleague from work, Ratko. If it weren’t for him, this project would not have existed, so he should get most of the credit. We’ve been working on it as a sort of presentation to show at a local conference, which my company is organizing every year – DevArena.

Ratko has his own blog where he mostly talks about Lync development, but who knows, it might mention games at one point to.

In any case, Dice and Roll, in spite being very basic, was quite well accepted, so we decided to keep up with it. We’d like to at one point transform it into a multi-platform game, running in browsers as well as a native C# Windows 8 App.

For now, you can even try it out. Our company is hosting it, but there’s no guarantee it will be there for long. Keep in mind, it’s only currently current. We will be pushing updates to our production version soon.

NESjs

NESjs could hardly be called a project. This guy called Alexander has this blog, where he is making a guide on how to create a Nintendo Entertainment System emulator in JavaScript. I’ve been basically doing the same thing he’s doing, hoping to learn something about how to properly structure JavaScript apps through the process, and maybe even learn a bit about emulation.

Really, you shouldn’t follow what I’m doing with it. Instead, follow the guide I’m following.

As with Pucaj, you can track my NESjs project repository on GitHub