Posted by & filed under Game Development.

Project 9-Volt is the game development project that I’ve been working on for the last few weeks. If you didn’t already know, I love lighting in games. I wanted to put together some mechanics for a game that would use lighting as it’s core mechanic. The Project 9-Volt video in this post aims to show off some of the features I’ve implemented into a little project.

This tech demo aims to show off some of the features that I have implemented so far. A full list of features implemented in Project 9-Volt so far are as follows:
– Dynamic Lighting
– Torch/Flashlight shaking
– Different lighting colours
– Player movement
– A* Pathfinding
– Tiled maps

At the moment this is just a bunch of ideas that are slowly starting to come together to form something bigger. I hope to be able to work on this from time to get something solid together.

I’d also like to say a big thank you to Escape Theory from for undertaking the stressful task of video editing with me in the room.


Posted by & filed under General.

After three years of studying computer science at Aberystwyth University, my time in the tiny remote town has come to an end. I felt that instead of creating the usual social update on Facebook or Twitter stating how much I would miss the town, I would instead transform my thoughts into a video. Hopefully you will be able to gain a sense of my love for the town.

So without any further ado I present to you, Aberystwyth; A Reflection.

Posted by & filed under Dissertation.

I really need to get back into the habit of writing updates. It’s going to help a lot when it comes to starting the write up for this project.

Most recently I have been working on the game AI. I have pathfinding implemented in a basic form and I wish to upgrade this to A* in the future. When I first tried to implement A* over Christmas it went horribly wrong, I didn’t really understand what I was doing. I feel that I have better grasp on how that works now so I feel it is achievable.

I have also been working towards some sort of genetics for the AI. This means that the AI will effectively evolve during the time you play the game, the longer you play the more evolved the AI will get.  The code for this is very rough at the moment but I do plan to expand upon it greatly as I feel it makes for interesting and unique game play.

Here are some links I am using for references:
Machine Learning : Genetic Algorithms part 1
Machine Learning: Genetic Algorithms part 2

Posted by & filed under Dissertation.

Wow, haven’t posted an update in a while. My bad. So a quick summary of how my exams went and then I’ll talk about what I’ve been working on since then.

I had three exams to get through for last semester, this time they where all quite nicely spaced out which makes a change to previous years. I was feeling pretty confident about all of them until I contacted the flu the night before my first exam. I really feel like this will have lowered my overall marks for each exam I sat, for the first exam I nearly didn’t sit it I was that bad. I asked my department about this and I basically got the line “Since it was on the day it isn’t really an excuse”. So what they are saying there was if I had the flu a day earlier and gone to the doctors, obtained a sickness note it would have been okay for me to resit. But because it was on the day/night before I don’t get the same treatment. Pretty lame if you ask me.

Anyway, I got over the flu after my last exam and have since managed to catch two separate colds. This is something that was mentioned in my Major Project lectures “Always allow time for illness”. I didn’t allow for this in my project plan as I hardly ever get ill, and when I do it’s not that bad. So in short, I was ill quite a lot, I tried to work as much as I could through it all, so it set me back as little as possible.

So what have I actually been able to do? Well I have implemented path finding for my enemies.  I wanted to implement A* as from the research I did, it was the best type of path finding around. In the end this was not the algorithm I implemented, this was due to two main reasons. The first being I don’t use tiles for my game world, the second being a lack of clear and understandable tutorials. Every single one I found was along the lines of “This is easy to implement, just do this” with no explanation.  The algorithm I did implement can best be described as a brute force method, it uses the collision detection method I have already implemented to check if non-passable objects are in the way. The entity will then attempt to move to certain location while avoiding these objects. It works fairly well, there are a few cases of where the entities get stuck and just seem to sit there for a while, but this can be improve easily.

The next step I plan to undertake is vast improvement of my documentation. I have my mid-project demonstration coming up next Monday and I know a lack of documentation is going to be brought up. After that I plan to implement some new types of enemies as well as a general clean up of my code. I am sure there are lines of code I have that are no longer needed.

Posted by & filed under Dissertation.

I’ve not been able to write any more updates as to what I managed to achieve over the Xmas break due to my exam schedule. I have my first exam tomorrow and my last one on the 23rd January. This means that I have been spending a lot of my time revising and I have done little work on my dissertation game. While I only have three exams in total (“E-commerce: Implementation, Management And Security”, “Agile Methodologies” and “Space Robotics”), I find that revising is taking up a lot of my spare time. Revision is going well , but I do find it annoying that it’s getting in the way of my dissertation, I’ve tried to work on it a few times but every time that I do I feel like I should be spending that time revising and this stops me from concentrating.

I did manage to get a little bit done a few days ago when I demo’d what I have done to a friend and noticed that there was a bug in the level generation code. Basically the game wasn’t remembering the layout of previously visited rooms; this means that when you entered a room that you have already been in, it would randomly load another layout. I managed to fix that by applying tag to each loaded room and added them into an array. When the player exits a room it now checks that array to see if the player has been in that room before (based on the co-ordinates of the room), if the player has then it loads in the previous room saved in the array. The array also keeps track of whether the player “cleared” the room or not, if the player has left the room without clearing it, all the enemies are loaded back in again. If the player has cleared the room then it does not load them at all.

Speaking of demo’s I found out that I will be performing a mid-project demonstration during the second week of February. This gives me around two weeks after my last exam of solid work on my dissertation, bar the lectures that I have to attend. Hopefully I can polish up the game a little bit and get some original artwork in. I’ve put a lot of effort into this project so far and I really hope that it gets appreciated by the people I am demonstrating it to, I understand that a game isn’t as impressive as an algorithm that solves Hilbert’s 16th problem but I am not the world’s best coder. I took a coding project to help me improve on that and I hope it is this that they keep in mind when deciding if they like what I’ve done so far.



Follow my blog with Bloglovin

Posted by & filed under Dissertation.

Another area of the game I managed to work on over xmas was collision detection. At first I tried to get Box2D to work with my game, while I liked what all the test examples achieved; I was not able to get the same quality from my own implementations. Further to this I felt that Box2D wasn’t quite right for this style of game. The idea of having entities bouncing off of each other doesn’t quite fit into how I imagine the final game to look and feel.

With Box2D out of the window I was left to implement my own unique version. When I was looking up what other game developers recommended a lot of people suggested creating a rectangle around the entity and using this as its ‘hitbox’. Then you simply run checks against other entity hit boxes to see if there is any overlapping.

This is the route I went down, while it feels like a crude way to achieve things it does get the job done to a standard that makes the game fund and enjoyable.

So when any entity in my game is created it takes a few parameters, the three most important for this are;

  1. A string for the location of the image.
  2. The entities X position.
  3. The entities Y position.

In the entities constructor it runs a method called “setTexture” and this takes the String that has the location of the image inside of it. We won’t worry about the code that sets the image for now, the important thing is that this method sets the height and width of the entity based on the size of the image.

After this method is completed another method called “setHitBox” is run. This takes four parameters, the first two are offsets for the X and Y coords and the second two are the height and width. The reason I have the offsets is so it allows me to create the hitbox bigger than the entity. This method also sets a boolean to true that states whether or not the entity is collidable. This is then checked by the update method in the game world to see whether or not it should check for collisions between this entity or not.

As well as setting the hitbox an entity has to declare in its parent class what other entities it can collide with. Each entity has a “name” such as; “player”, “block” or “bullet”. I refer to this in my code as the entities “type”. You declare these other entities in a String array such as the following;

String[] collidable = { "ENEMY", "BULLET", "BLOCK"};

The above example is from the player class. This means that the player can collide with any entities that have the name “ENEMY”, “BULLET” or “BLOCK”. In order to perform the check I have the player entity have a conditional statement run before it moves. If no collisions are detected then it is allowed to move. This is the same for all other entities, the only downside to this is I have to manually code what entities collide with other entities. While this isn’t a big issue, I have had issues where collisions where not working because I forgot to code in a new entity type for collisions.

if(collide(collidable, position.x, position.y) == null){

Above is an example of the conditional statement that surrounds the players movement. It calls the collide method from the superclass and gives it the String array and the players current coordinates. The collide method that loops through all the entities on the screen at that moment in time, it then checks their hitbox against the players hitbox and sees if there is any overlapping. It only does this for entities that are in the String array; this means it’s not wasting time checking every entity in the game. For example if I had a flying monster that could hover over blocks, I wouldn’t want it to check blocks for collision on every update.

I should also point out that I’ve added in a neat little entity response method, should the player collide with another entity then that entity calls this response method. By default it is an empty method but its nice to have, for example if the

That’s pretty much it for collision response, it’s not a the worlds best way of implementing it but it does the job. When stress testing my phone with a lot of entities it does slow a lot, but the amount of entities I had on the screen is not anywhere near the number I would expect to have in the final game.

Posted by & filed under Dissertation.

Projectile implementation took me about two days. I had a projectile firing in about two hours, but tweaking the code and testing different ways of how the user can fire took the extra time. Furthermore it turns out I had forgotten quite a bit of my GCSE maths and therefore had to learn that all over again.

Before implementing firing I had to think about how I wanted the player to fire. Since I am using a mobile screen there is a lack of space for complicated controls. Therefore I only really had two options, do I use the touch input or do I use a simple onscreen control?

Since I already had an onscreen control for movement I thought I’d just add another for firing to see how it worked. Personally I feel that this would be a good approach as it would keep the users hands in one place. However I ran into a bit of issue using the input library in Libgdx. When you use a touchpad/joystick you have two ways to gather the X and Y coords of the touchpad, you can either use a set of methods which return the position of the knob relative to the centre of the widget, or return the position of the knob as a percentage from the centre of the touchpad to the edge of the circular movement area. Using either of these turned out to be massive headaches as I couldn’t get the maths to work correctly. For example if I wanted to fire directly upwards I would hold up on the touchpad, and if I wanted to fire downwards I would hold down, but when firing in between it was like the angle wouldn’t calculate correctly and not be straight. Ideally I should have taken some screenshots but the best way to describe it was that it didn’t feel right when using. The other issue I had with this is when I tested on the desktop version of the game, it would work in a certain way, but when testing on the mobile it was different. This definitely added to the time it took to implement projectiles overall.

This lead me onto the second possible implementation, using the whole screen as the input device. I found this a lot easier to implement, but this could purely be down to the fact that I learned a lot from implementing the previous method. The way I implemented this method was quite simple, during the render/update method of the main game loop I have a conditional statement that asks whether or not the screen has been touched, if it has then take those coordinates and pass them into the player’s fire method. It also turns out that I had to call the ‘unproject’ method from the camera class on these coords, otherwise their values would be affected by the camera and therefore be incorrect when given to the player class.

So let’s get into some maths, how did I manage to get the angle of where the player is and where the user has touched? As mentioned above, we first need to get the touch input.

screenTouchPosition = new Vector3(Gdx.input.getX(), Gdx.input.getY(), 0);
  camera.unproject(screenTouchPosition);, screenTouchPosition);

So as you can see ‘screenTouchPosition‘ is a Vector3, this is a variable that I declared globally in the class. The reason for this is I didn’t want Java creating a new Vector3 every time it went through this loop, this was an optimisation tip I picked up from the Android website. So why I Vector3 you ask, when all we need are the X and Y coords? Well it’s simple, the camera.unproject method can only take a Vector3. Since I am not making a 3D game or using depth in anyway, I don’t really have to worry about what goes into the Z position of the Vector3, so I just added a zero in there. The last step is to call the method and pass in the delta time and the coords where the player has touched the screen. As a side note, adding this into an if statement that first checks to see whether the screen is touched or not is a good idea, otherwise this method will constantly run all the time!

The next step is to work out the angle of where we need the projectile to traverse.

public double calculateAngle(float x, float y, float a, float b) {
     return (Math.toDegrees(Math.atan2(y - b, x - 1)) - 90);

In the above example the X and Y variables that are parsed in are the players position while A and B are the coordinates of where the player touched the screen. Java then does a lot of work for us by providing the Math.atan2 method. This method neatly gives us the direction between two vectors and therefore the angle.  After working this out I then create a new projectile object and add it to my game world. This projectile object then has its own update method that calculates how to update its position in the game based on the angle that we just worked out.

public Vector2 calculateVector(double angle, float speed) {
  vector = new Vector2();
    vector.x = Math.sin(Math.toRadians(angle));
       vector.x *= speed;
    vector.y = -Math.cos(Math.toRadians(angle));
       vector.y *= speed;
   return vector;

So what is happening above? First we create a new Vector2 (I’ve called it ‘vector’ in this example to keep it simple), this is going to hold the distance as to how far the projectile will move during the next game loop. Again Java does a lot of work for us here by providing us with relevant methods that we need. Hopefully you’ll remember sin and cos (we don’t like tan) from your maths classes at school so I won’t go over what they are doing. The Math.toRadians method is pretty cool as it converts the angle we worked out earlier from degrees into radians. A radian can be worked out by the following: Start at the centre of the circle, move along the radius until you hit the edge. Then move along the circumference of the circle the same distance that the radius was. Then move in a straight line back towards this centre point. This creates you a segment of the circle and a radian is the angle of that segment.

The method returns a Vector2 and we simply add this to our projectiles current X and Y position during each update of the game. I should also point out that we parse in a float variable called speed. This is quite simply how far you want the projectile to move per update. Setting it to a 100 will result in you not being able to see the projectile at all as by the time the game has updated it, its moved off the screen. I have mine set around 10, but I do like the patterns that you can make when you set it lower and spin your character around!

So that’s it for this blog post. I’ve learnt quite a lot from implementing projectiles in Libgdx, the camera.unproject was a particularly tricky moment as at the time I had no idea the camera was changing the input variables. Ideally I would have liked the player to fire the first way I tried to implement, but time is not on my side and I felt it was better to have an implementation of firing than not at all. Should I have time towards the end of my project I will revisit this and see if I can get the touchpad method to work.


Posted by & filed under Dissertation.

I’m going to keep this one short and sweet as I have done quite a lot since my last update. Writing one post on everything that I’ve implemented and changed in my dissertation to date will be too long, I also want to do an individual post on some topics as I want to go into more detail on them. I wish I had wrote them as I done them as I would be able to right more accurately on the topic, I really need to start doing that. I also need to start committing to my git more often. I might force myself to do a commit everyday, at least.

As I said, I’ll keep it short and sweet. I’ll just do quick bullet point list on what I have done since my last post and then write a post on each of the bullet points.

  • Projectile Implementation
  • Improved Entity Collision
  • Simple Dungeon Generation & Navigation
  • Improved Performance & Optimisation


Posted by & filed under General.

Predicting the future is tricky business, last year I said that we would see the rise of Windows 8, the death of boxed software and the evolution of the television.

While we did see the release of Windows 8 it wasn’t to the critical acclaim that Microsoft was hoping for. Its radical new design has come under fire for being too different and we all know people don’t like change. I personally quite like the new interface, I found it easy to use and get along with.

The death of boxed software is an interesting one; while you can still buy software in stores throughout the world it is becoming less and less frequent. I for one didn’t buy any physical software last year, whether it be actual software or games. With platforms like Steam, I really don’t see the point in owning physical copies of things anymore.

Finally, I said that we would see the evolution on the television. This is something that happened, a lot of TV’s have Ethernet ports built into them now and if your TV doesn’t, I bet one of the boxes under your television does.

So what can we expect to see from 2013? Here are some of the things that I’ve singled out.

Firefox OS

This year we will see the release of Mozilla’s first OS which will be for mobile platforms. What is quite interesting about this is that it is implemented using HTML5, the same language you use to view websites on the internet. One of the good things about this OS is that developing applications for it will be relatively easy as you now don’t need to learn any specific API’s like Android or iOS. While the OS will be easy to develop for and offer the mobile OS market is already a crowded one. Will any mobile phone carriers pick this up? Only time will tell.

Willow Glass

Remember the Nokia Morph? If not check it out here. It’s a concept phone that seems to have been around forever. If Willow glass is really as good as scientists say it is, we may start to see the rise of devices like the Morph this year. So what is so special about Willow glass? Well it is as thin as a piece of paper and, more importantly, can be bent and wrapped around objects. The technology was first shown off in June 2012; hopefully we’ll start to see devices using this new technology this year!

3D Printing

3D printing has been around for awhile now, but at the end of last year it went through leaps and bounds. An example of how far 3D printing has come is that an entire house was built using only 3D printing; this wasn’t something possible a few years back. I really feel that 2013 will be the year we start to see affordable 3D printers in the home. Obviously the next logical step for this is for them to turn into replicators from Star Trek…

Posted by & filed under Dissertation.

Over the holidays I have learnt quite a bit about optimising performance when using Libgdx on Android. I felt like it was a good subject to write a blog post about as it might be helpful to others who are starting out with Android development. Further to this it may well end up being a section in my final report.


One such way to optimise performance in Libgdx is to use the SpriteCache class. This class draws 2D images like SpriteBatch; however this class is more optimised for images where their geometry doesn’t change. The class caches any sprites/textures with a given ID which it then uses later to draw the image. Once the image has been cached its size, colour and texture region cannot be modified. This is a bit like the ‘final’ modifier in Java.

The way the optimisation works is that it stores the cached information in video memory, this means that it does not have to be sent to the GPU each time it’s drawn like it does with SpriteBatch. When designing games for Android devices you want to limit the calls to the GPU as much as possible, in an ideal world you’ll want to only have one call per frame update, however as your game grows this becomes more and more unlikely. Utilising SpriteCache to draw all your objects that won’t be doing anything other than sitting there is good practice.

Java Lists

Stay away from these. Java lists create a lot of unwanted garbage which your device will have to deal with. This means that your device will have to put aside some of its resources to clean up after the lists. ArrayLists are a little better but they still create some unwanted garbage. If an unordered list is what you want then you’ll want to implement the Libgdx Array class. This class has some nifty optimisations like not performing a memory copy when removing elements; instead it moves the last element to the removed elements position.

While the Array class is pretty cool, it still isn’t the most optimised. If you can you will want to initialise an array with a fixed size, like most things in programming a fixed size array will get you the best performance.


When performing any loops in your program you should be aware not to create any new operators. This also means that you should be aware of any classes that Libgdx (or Java) has that generate new objects.

When it comes to for loops you have three different options to choose from.

  1. for (int x = 0; x < myArray.length) {}
  2. for (int x = 0; x < length; x++) {}
  3. for (Foo x: myArray) {}

The first loop is the slowest as the compiler has to get the size of the array for every iteration of the loop.  The second loop uses a local variable called ‘length’ and this does offer a slight performance increase but not much. The third loop is the fastest type of loop as it uses the enhanced for loop syntax first implemented in version 1.5 of Java.

Prefer Static Over Virtual

If accessing an object’s isn’t something you need to do, then make your method static. Invocations will be around 15%-20% faster. This is also helps you understand from the method signature whether or not the method can or cannot alter the object’s state.

Use Static Final For Constants

If you have a variable without the final constant, when the compiler generators a class initializers called <clinit>. This method stores the value of your variables into whatever you have named them. Then when you access these variables later on they are accessed with field lookups.

Using the ‘final’ keyword helps improve this as the class now no longer requires the <clinit> method because the constants go into a static field initializers in the dex file. When you refer to your variables they will now be referred to directly rather than using field lookups.

Avoid Internal Getters/Setters

This was something that came as a surprise to me as I have always been encouraged to use these at university.

In native languages like C++ it is common practice to use these types of methods because the compiler can inline the access and it allows you to restrict access to certain variables from the rest of your code.

On Android this is a bad idea. Virtual method calls are more expensive that instance field lookups. It makes sense in my head to follow the common object-orientated programming practices but you should get out of this habit when programming in Android and start accessing fields directly.

If you are not using a Just-In-Time compiler then accessing fields directly is about three times faster than using a getter. If you are using a Just-In-Time compiler then direct access is seven times faster.


Floating-point is roughly twice as slow as integers on Android devices. If you can you will want to use integers instead of floating point variables.

If you find yourself needing to use something heavier than an integer, you may find yourself looking at floats and doubles. There isn’t much difference between the two apart from doubles are twice as large as floats. In terms of speed there is no difference, therefore if space is not an issue you’ll want to use doubles.


There we have it, a quick summary into what I have found about optimising the performance of your code when writing for Android.

I would like to point out that this is not a definitive list; it is merely what I have discovered in the Christmas period. If you disagree with something I have said then I encourage you to comment below and say why, I’m always interested in learning more about code optimisation. Also, if you feel that you have a neat trick to share then please comment with that.

Sources: Libgdx Forum Post & Android Performance Tips