Posted by & filed under General.

Today is a special day for some people, for others it’s just a normal day like yesterday. In any case I’m going to share the following song and you can all rejoice to it’s awesomeness (yes that is a real word).

Posted by & filed under Dissertation.

I realised I that I haven’t wrote  a blog entry in a while and the last one I wrote stated that I hadn’t done anything, which doesn’t look good on my behalf. But fear not, I have been working.

Since my last update I have changed a lot of my code. I found that the approach I was originally taking wasn’t going to allow me to make the game how I wanted to, I mean it may allow me to do it but due to a lack of documentation and working examples I was unable to understand how to get it to work. I had no idea how I was going to get collision detection to work nor how I was going to get any of the entities to do what I wanted them too. This meant I had a very stressful couple of days and I honestly felt like giving up. I also gained my first white hair from this. It was at this point that I knew I had some considerable refactoring to do.

I was originally using the Stage and Actor classes in my game but this is what I was struggling to understand, for example if I had a Rock that I wanted the player to collide with there was no way for me to make this collision happen. Therefore I started to look at other alternatives. One such way was to use Box2D as LIBGDX has a wrapper for it; I found a nice example of how to get it to work here. While this was some really nice code and visually it looked great, I was still unable to get it to work how I wanted to. This is a shame as Box2D has some really nice features. I do feel that what I learnt about lighting will be useful in the future and I may implement some features from this.

Since I was having no luck with Box2D and Stage/Actors I decided to attempt to create my own way to do this. So far I have been pretty successful with it. I am currently using ‘Screens‘ for each different section of my game, this includes the game screen. Each screen extends my own AbstractScreen class and in here is where I have put all the gubbins for my game to work how I want it to. This includes such things as an ArrayList of entities. Each time my game adds a new entity it gets added to this ArrayList, then in the render method (think of that as the update method) I have a loop that goes through each entity in the ArrayList, call that entities update method and then render it. Here is some pseudocode that should explain it a bit better;

 

 

 

 

So as you may have guessed from the above, I now have an ‘Entity’ class. Every object in my game will extend this class as it contains all the base information that I need in order for this game to work. This includes things such as a Vector2 containing the X and Y coords, boolean values to say whether or not the entity is visible, collidable and whether it’s active or not, textures for image rendering and arrays of what other entities the object can collide with. It contains a lot more as well but I don’t feel the need to go into it right now. Hopefully if I find the time I’ll do a separate blog update on this class.

Collision detection is another area that I now have working on. As I mentioned earlier each entity has an array of other entities that it can collide with. During the update method of each entity I can choose whether or not to make this entity check if it is going to collide with another object, if it does then it can do something like moving back a step rather than colliding with the object. At the moment the collision detection is a bit jumpy as I haven’t smoothed it out yet, however it is nice to know that it is working.

Further to the above I have also managed to get a nice debugger working within my game. If this option is enabled in the code then each entity renders a box around them showing their collision points, this has been really handy for getting my collision detection to work.

While I have managed to achieve quite a lot I’m not 100% happy with the way the project is going, I am now behind schedule with a fair amount of work to catch up on. Part of this was down to some family issues that happened around the start of the project which set it back a few weeks, but also part of it is was down to me neglecting the project. I am back into the swing of it now though as I have been working on it every day, all day, since I have been home. I had planned to have the dungeon generation code completed by Christmas, while this is still a goal I do feel that it will be harder to complete now as I have had to rewrite a lot of my code which has put me further behind schedule.

Further to this I have had some performance issues which I have been working on today. One of the good things about LIBGDX is it allows me to test all my code on my desktop in a Java application, then when I want to I can push it to my phone and test it on there. The code runs great on my desktop but on my phone it was quite laggy. This is obviously due to the hardware difference and is something I need to be thinking of at all times. I have managed to smooth it out a bit by making the game only render objects that are in view of the player, this helps save some resources but it still needs working on.

Posted by & filed under General.

Unfortunately I have not been able to make any progress on my dissertation project this week.

The lack of progress has been down to the fact that I needed to return home at the start of the week to attend a funeral, I was not able to take my laptop home with me during this time as I was travelling light, further to this I do not feel that I would have been in the right state of mind to continue with the project at that time.

I plan to get back on track this weekend where I hope to put into practice all the research that I did into procedural dungeon generation.

Posted by & filed under Dissertation.

Over the weekend (and Monday) I worked on the algorithm that will load a specific room based on a text file. I have already had experience in previous projects with this method to load in levels so implementing it into LibGDX wasn’t too difficult.

The code is mostly the same as previous projects expect for how the engine handles resources. Since LibGDX exports projects to Android, Desktop and HTML it has to handle the resources in a specific way so that all three implementations can work the same. It does this by using a class called ‘FileHandle’, you can then say where the files are located (internally or externally). I couldn’t find much documentation of this other than specific bits of code for basic implementation, therefore I had to play around with it for a little bit to get it to work the way I wanted.

The below to the right is an example of a simple level I designed for testing, it uses only three characters right now for the following purposes;

  • ‘#’ = Enemy
  •  ‘|’ = Block
  • ‘-‘  = Blank/Empty Space

The algorithm works by reading each line along the X axis and then each line across the Y axis in two for loops. Each time the algorithm reads in a character it parses it into a switch/case statement where it adds the entity associated to that specific character.

The other part of the project I have implemented is some simple AI. Each of the enemies added to the game screen at the moment move to a specific point in the game, once they arrive at that point they then move to another point on the map. I did this as I wanted to test the hardware of my phone to see if it could handle having a few enemies running at once. Right now there is no collision detection going on so they often move over each other or the player. Collision detection is obviously something I want to implement in the game but right now its not the next thing for me to do.

The next step is the level generator, by this I mean that the game will create a sort of maze based on a few rooms that I have made, the maze needs to be able to be navigated by the player so there should be no inaccesable rooms.

To see a short video clip of what I have implemented so far please click this link: http://youtu.be/oLi9PUPFa_8

Posted by & filed under Dissertation.

Wow it’s nearly been a whole months since my last blog post, I knew it had been a while but not that long…

I have done a ton of work since my last update in regards to my dissertation project. Last week was my work week and boy did I work! Every day I was up at 10am and apart from the odd break to eat food I worked solidly until midnight. Now you may think I’d be really far along with the game since I spent so much time working on it, well you’d be wrong but it was time I needed to spend on this project to get it sorted out.

My last post was about which Engine to use if to use one at all, in the end I have decided to go ahead with using Libgdx but this was not an easy choice. Over the last week I spent a day and a half using Libgdx and a day and a half using AndEngine. In the end I felt like I got on better with Libgdx and decided to push on with that, two days later I was pulling my hair out as I had no idea what I was doing, I decided at this point to go back and use AndEngine, two days later and I was once again pulling my hair out. The reason why I was having so many issues is that Libgdx was really hard to find examples of how the engine works on a basic level, therefore trying to understand how to use it was impossible. AndEngine on the other hand had quite a few good examples but it lacked serious documentation for the engine, it would literally have no documentation for any methods and I would end up sitting there without a clue as to what it did.

I’ve decided to return to Libgdx as it is at least well documented and while it lacks a large number of example projects, I have been able to implement far more into the game so far in comparison with what I did with AndEngine. Currently I have the following implemented to a basic level;

  • Splash Screen with fade in/out effects.
  • Main Menu.
  • Options Menu with the ability to turn sound fx/music on/off.
  • Character Selection Screen.
  • Game Screen with Accelerometer controls.
  • Orthographic Camera that follows player around the screen.

I do also have animations on the player sprite working but they are a bit buggy right now so I’ve removed them, animations is something aesthetic anyway and I’ll come back to it at a later date, right now I’m focusing on the core components of the game. The next thing for me to implement is the room loading algorithm which shouldn’t take me to long to implement (I hope) and then it’s on to some basic collision detection.  I do have a 5,000 word report due in on Friday which I have already finished but I do need to proofread it again and then update it with anything else I can think of so this next stage of development may have to wait until after that.

 

 

Posted by & filed under Dissertation.

Considering the scale of my dissertation and the relatively short period of time that I have to complete it, I feel that using an engine to help with some of the core mechanics of the game to be a wise decision. In an ideal world where I have infinite amount of time, I’d like to create my own framework to run the game on, this would mean that it would be tailored to my exact needs with me having a full understanding of how it works.

Alas, this is not an ideal world and time is really something that I lack to create my own framework, the other decision would be to not use an engine and perform all the tasks directly on the Android canvas, while this is a viable option, I can foresee many issues down the road that will affect the performance of the game. This is not something I want to happen as it would mean refactoring all my code at such a late stage of development.

There are a lot of engines out there for Android right now and after doing a small amount of research I have been able to single out a few for further investigation;

My aim to is investigate each of these engines, way up and the pros and cons and then write a small post about each of them, hopefully I’ll be able to choose one to move forwards with. If by any chance there are any Android game developers reading this, then I would love to hear from on what you think about engines and whether or not you have any preferences for them.

Posted by & filed under Dissertation.

Since I am not far away from starting to code for my dissertation, I felt that I would be a good idea if I tried to collect some information as to what Android versions are commonly used these days and which devices out of mobiles and tablets are most popular for gaming.

The reasoning behind this is that if more people prefer to play mobile games on tablets than mobile, then this will change the way I design the interface for the game. This means I will have more screen space to play with and also (but not in all cases) a higher resolution to play with, whereas if mobile is more popular than I’ll have the opposite and more care will need to be taken into utilising the smaller amount of screen space available.

Finding out what versions of Android are most commonly run will help me when it comes to programing the game, for example if the majority of people have Ice Cream Sandwich these days then is it really worth me making my game compatible for Gingerbread? Most likely I will be supporting Gingerbread but without the information to back up this decision, it is not one that can be made on a whim.

This weekend I set about undertaking this task, I came up with two options as to how to obtain the information required;

  1. Ask everyone I know personally, write it all down and tally it up.
  2. Make a webpage that allows people to enter in their data and submit it to a database.

In the end I went with option number two, and here is the end product; http://joshjordan.co.uk/dissertation/

I have posted this link and short explanation over all my social feeds and asked for it to be spread about as much as possible, I’ll keep allowing submissions for about a week or so before I start reading into the data at all.

Posted by & filed under Dissertation.

In my last post I stated that I would finish the tutorial series that I am following on by the weekend, that didn’t exactly happen. One thing leads to another and I’ll be honest, I procrastinated a fair bit. This is one thing that I am really going to need to keep in check as I’ll fail to meet my deadline of having most of the game built by the end of December.

I’m about halfway through the tutorial series right now and I can say that I’ve learnt a great deal about how Android works, the task is becoming less scary and I can start picturing how I’ll go about coding parts of my game now, whereas before I just sat there and cried, okay that’s maybe a little overdramatic but you know what I mean.

Since my last post the tutorial series as taught me quite a lot, mainly in the following four areas;

  • Graphics
  • Sounds
  • Tabs
  • Touch

While graphics are pretty simple to implement in Android, I’m still going to go down the route of utilising a framework to help with some of the workload. If  I don’t I’ll have to code a framework myself and that increases my workload, meaning the completion dates of everything else get pushed back, which can’t happen as I am already on a tight deadline.

I’m gonna skip the next two bullet points for now and go straight onto the last one; touch. Touch is a key concept for my game as it is most likely going to be the way the user either fires their weapon or controls their character, or maybe both; it all depends on user feedback. So far I’ve managed to utilise both single clicks, multi clicks and long clicks on the screen, all these are most likely going to be used in the game so it’s good to get this knowledge under my belt.

On a final note, I’m going to produce a small webpage over the next few days that will allow me to gather information on what devices people are currently using so I can get an idea of what level of Android I need to support, furthermore if any of the lovely people that fill in this form wish to be beta testers then this will help me get a better perspective of how the game is perceived whenever I release an update.

Posted by & filed under Dissertation.

I spent another good four to five hours last night on furthering my understanding of Android; so far I’ve managed to create an application that has the following features;

  1. Add or take away from an int variable using buttons and then output this to the display.
  2. Ask the user to fill in some forms, and then input these into an email and send it to a specified email address.
  3. Take a photo using the devices camera, display the thumbnail of the recently taken picture and then have the user press a button to save it as their wallpaper.

So in all its all pretty basic stuff, however I’ve been able to learn a great deal from how Android works and how you go about doing things with the language. Intents are really important for starting up new tasks, yesterday I was scratching my head for half an hour trying to work out why something wasn’t working only to realise I hadn’t started an intent for it. One thing I really like about programming in Android is the ability to send what I’ve made over to my phone in a matter of seconds, test it and then work on it some more.

The plan now is to finish up the tutorial series I am following by the weekend and then get cracking on doing some game development on Android. It’ll probably be simple stuff like what I am doing now to start off with and the plan is for it to get progressively more and more complicated.

Posted by & filed under Dissertation.

One of the key components of my dissertation is that my game works on a mobile platform; I have chosen Android to be my weapon of choice mainly for two reason;

  1. Android uses Java, a language that I have had experience with already and should hopefully give me an upper hand.
  2. iOS uses a different language altogether, Objective C. Last year at University I took a C Programming module which was quite possibly the worst module I have done, I really struggled to understand how C worked as language with its dangling pointers and structs. While Objective C is a different language, from what I know it takes a lot from C and it’s something I’d rather avoid.

Over the last two days I have been trying to find resources on the internet to help me get to grips with how you program in Android, as always one of my first points of call when learning a new language is thenewboston, thankfully they have a tutorial series on Android programming and today I have spent at least five hours working my way through the tutorials.  I haven’t got very far into them as I had a lot of issues with downloading and installing Android, the first installation took two hours to download (Aberystwyth doesn’t have the best internet speeds!). Once it had finally downloaded and installed it, loaded up Eclipse and found that it hadn’t installed correctly. This resulted in me download and reinstalling it again; by the time I was done with installing I was far too tired to undertake any tutorials.

Today was much better though, while the tutorials haven’t yet gone into any great detail, they have taught me a lot of the basics of Android, like how Activities are used frequently and how they need to be added into the Android Manifest to work. Also the Android SDK has some really nice drag and drop features that allow you to easily set-up your interface, but it also allows you to go into the XML behind this and tweak it to exactly how you want.

So far I have an application that loads a splash screen, displays and image and plays the first five seconds of Won’t Get Fooled Again by The Who. After five seconds it loads a menu where you can select two different options, one is a counter and the other is a textbox that allows you to play around with some commands. As I mentioned, it is really quite simple but it’s getting me to grips with Android which is the important thing.