Posted by & filed under Android.


Today I discovered Pushbullet and thought I would share as it’s going to change the way I use my phone/PC from now on.

Every time I’ve wanted to send something from my phone to my PC (or vice versa) I’ve had to either upload the file to Dropbox/Google Drive or email myself with the information, no longer do I have to do this fiddly way of sharing information with myself! Pushbullet makes getting information off and on your phone an easy task, a simple task; like how it should be. Using push notifications via your Google account you can easily share; links, quotes, pictures, notes and more between your PC and any Android device.

Without this sounding more and more like a sales pitch, I strongly suggest you at least check it out and see for yourself, With a nice looking API and Tasker support, this application is pretty powerful.

Posted by & filed under Web Development.

I’ve been working with the Twitter API once more, not on the Twitter Stats project I was working on a few months back but a new project. This one uses the Streaming API to gather real-time information about particular hashtags, words and any other data you can think of.

There really isn’t that much documentation for how to get started with the Streaming API so I ended up spending a lot of time writing trial and error code. Once I managed to figure it out and gain a basic understanding of how to consume data and keep the connections open I found that it was pretty much the same as using the REST API. Soon after I discovered Phirehose which is a really handy interface designed to help connect to the Streaming API, using this already written interface allowed me to focus on the next part of the project rather than creating the interface myself. I think that once I have a basic version of the project finished I will revisit this and re-write the interface and tailor it for my needs.

Using the filter-track.php class that comes with Phirehose I’ve been able to consume from the API and pull all sorts of data. I was surprised how quickly the data is pulled from Twitter, it appears to be pretty much instant. Now that I have the data being consumed the next step is to think about storing it in a database and then having a front end display it in an interesting format.

Posted by & filed under Web Development.

Spent the majority of the evening looking up how to improve Tumblr’s SEO. Long story short, you can’t do a huge amount without going into the HTML.

There are some themes out there which are SEO optimised but I couldn’t find one that I liked the look of. I found this handy guide which suggested some improvements. I’ve edited the code now and shall report back in about a week to see if it has improved anything.

One thing that a lot of people suggest to do is submit a sitemap to Google, this is something I’ve always done with my website in the past but had to use an external website to generate for me (the task of doing it yourself is to laborious). It turns out that Tumblr generates it’s own sitemap, problem solved! You can find it at This default sitemap should have links to others (sitemap1.xml, sitemap2.xml etc) which will contain all your posts!

In the meantime I’ve changed theme yet again, hopefully this one will stick…once I change the colours from the default setting…

Posted by & filed under Game Development.


Over the last few weeks I have been working on an idea for a game (Project 9-Volt). This tech demo aims to show off some of the features that I have implemented so far. A full list of features implemented 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.

Thank you to for undertaking the stressful task of video editing with me in the room.

Posted by & filed under General.

After three years studying computer science at Aberystwyth University my time in this town has come to an end. I felt that instead of creating the usual social update saying how much I would miss the town, I would instead transform my thoughts into video form.

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.



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.

Projectiles took me about two days to implement. 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.