FlyBy is Released!

After around 7 months of work, I have released FlyBy onto the Google Play Store! Check it out!

FlyBy On Google Play

SS0 SS1 SS2

FlyBy On Google Play

FlyBy is an exciting, fast paced, arcade style mobile game with a variety of exciting obstacles and challenges to complete! With randomly generated levels and online leader boards powered by Google Play. FlyBy offers many hours of plane flying fun! We hope you will enjoy playing and share our game with your friends!

Check out our website at www.FireFreeGames.com for more information about us or follow us on Twitter at @FireFreeGames!

Features:

Collect coins to buy power ups and upgrades in the in game store
Randomly generated caves and levels for endless game play
Many different exciting obstacles to avoid and fly through
Online leader-board powered by Google Play Services
Thrilling challenges to complete

Development

Working on FlyBy has been a long and at times challenging project. When I began the game I was just trying to make something small I could get done in a weekend. I made a little engine using LibGDX and put together a very rough prototype. After showing the prototype to Liam Bower we decided to work together (him doing art and me doing programming) and turn it into a full game. Our main goal always being to create a finished, released game. We figured it would take about a month to do. In reality it took us closer to 7. Along the way Luke Avery began doing small contributions on and off, mainly working on the in game menus, working with Liam to make them look the way Liam envisioned, while I worked on most the engine and core game play elements of the game. Adam Brown generously composed a few sound tracks and created some sound effects for the game as well.


Time lapse video of key versions of FlyBy’s development

 

There was a range of challenges I had  to overcome during the development, such as the procedural generation of the caves, game design decisions, performance optimization to improve the speed the game ran, integrating the Google Play Services into the game and countless other difficulties. Each challenge forced me to learn a lot about a wide range of topics.

FlyBy grew into a bigger project than I could have ever imagined when I started working on it, and I am proud of the way its turned out and the work everyone involved contributed to the game. So please, give it a go!

Tutorial: Integrating Google Play Services with LibGDX

Source Code for tutorial on Github

Over the past week I have been working on adding online leader boards to my game FlyBy using the Google Play Services game API’s. As I ran into a few things that caught me out I thought I would write up how I got it working in hope it helps other people. So here we go:

Prerequisites

  • a Google developer account (this requires paying the $25 registration fee)

It is probably a good idea to have downloaded and got the Type-A-Number example from the Google developer site (which you can find here) working before you try integrating with LibGDX just to make sure you know how to handle the backend stuff on the website like setting up an OAuth 2.0 client ID and linking it to your app (which isn’t as hard as it may sound!). I’d highly recommend following that tutorial before this one. Some things to watch out for on Type-A-Number tutorial:

  • BaseGameUtils doesn’t import as a library, have to click the toggle box “isLibrary” on the projects properties (right click BaseGameUtils go to Properties>Android and tick the “isLibrary” box)
  • If you get “NoClassDefFoundErorr” when trying to run the project make sure to go the android projects properties > Java Build Path and make sure to tick the check box’s next to the dependencies your project uses.
  • Logging in with my developer account in game didn’t work for me, even with it set to be a tester (which happened automatically). If you are getting “Unknown Error” when attempting to sign in try using a different Gmail account (Be sure to add the account as a tester)

LibGDX Intergration

If you have got the Type-A-Number tutorial running your in a pretty good position, theres only a few changes needed to make it work with LibGDX. You can get the source code for this tutorial here. This tutorial assumes you are using Eclipse.

Step 1 - Import BaseGameUtils and google_play_services_lib into your LibGDX project.

  • The BaseGameUtils project is located from the Google Play Game Services Sample Games located here. It also came with the Type-A-Number tutorial so you can just grab it from there too.
  • google_play_services_lib is located in your android SDK folder at android-sdk\extras\google\google_play_services

To import the projects go to file>import>android>Existing Android Code into Workspace. Browse to the location of the lib your importing. The project should show up in the “Project to import” section. Make sure to click copy projects into workspace. Do this for both projects.

Step 2 - Add google_play_services_lib as a dependency for BaseGameUtils.

  • To do this right click BaseGameUtils and then click properties>Jave Build Path>Project>Add . In the popup box tick the google_player_services_lib and click ok. This should remove the errors BaseGameUtil was complaining about. If not try Project>Clean and hopefully that will help.

Step 3 - Add google_play_services_lib and BaseGameUtils as build dependencies for your Android project. To do this:

  • Make sure BaseGameUtils is set to “isLibrary” to do this right click BaseGameUtils go to Properties>Android and tick the “isLibrary” box.
  • Now add them to your Android project. Right click your Android project and go to Properties>Android in the library section click add and add both projects. They should appear in the pop up window after clicking add.
How it should look

How it should look

  • Right click your Android project and go to Properties>Java Build Path>Order and Export and make sure to tick the box next to ‘Android <your android version>’ and ‘Android Private Libraries’ as well as any others your project relies on (this is required for the newer Android Developer Tools).
How it should look

How it should look

At this point the game should compile and deploy to a device without any errors. We can now begin working on the code. We need need to set-up some interfaces for platform specific code. We will pretty much just be doing what is discussed on this page. But to begin with we will setup a xml file to hold some important values needed by Google Play Services.

Step 4 - Setup an xml file to hold values for the application id (that you get from your google developer page). The advantage of using an xml file like this means you don’t have to change the value throughout your project, just one place you put the value in and reference it from there everywhere else in your project

  • In your Android project go to res>values and create a new xml file (right click values folder> new> Android XML File and call it ids.xml then click finish. Either click the add button and create a new String. When the string is created name it  ’app_id’ and give it the value of your games ID from the Google developer page for your game or edit the file directory in the text editor by clicking the ‘ids.xml’ tab at the bottom.
  • Open your AndroidManifest.xml file and click the ‘AndroidManifest.xml’ tab at the bottom to get the text editor. We need to add some code to setup the ‘ids.xml’ to work so add the following code inside your ‘application’ tag. I have it under android:label

PasteBin Version of Code with better formatting

<meta-data android:name="com.google.android.gms.games.APP_ID"
            android:value="@string/app_id" />

PasteBin Version of Code with better formatting
Step 5 – Create the base interface for platform specific code

  • Go to your main LibGDX project and create a new interface. I called it GoogleInterface. I set-up a very basic interface for this tutorial that has some very basic wrapping of some Google Play Services functions. You will most likely need to expand on this or create your own. But mine looks like the following:

PasteBin Version of Code with better formatting

package com.me.gdxGooglePlay;

public interface GoogleInterface {

public void Login();
public void LogOut();

//get if client is signed in to Google+
public boolean getSignedIn();

//submit a score to a leaderboard
public void submitScore(int score);

//gets the scores and displays them threw googles default widget
public void getScores();

//gets the score and gives access to the raw score data
public void getScoresData();
}

PasteBin Version of Code with better formatting

Step 6 - Create a class that implements the GoogleInterface for the Desktop implementation

  • Still in the main LibGDX project create a new class, I called it DesktopInterface and let it implement the GoogleInterface. My version of this class looks like the following:

PasteBin Version of Code with better formatting

package com.me.gdxGooglePlay;

public class DesktopInterface implements GoogleInterface{

@Override
public void Login() {
System.out.println("Desktop: would of logged in here");
}

@Override
public void LogOut() {
System.out.println("Desktop: would of logged out here");
}

@Override
public boolean getSignedIn() {
System.out.println("Desktop: getSignIn()");
return false;
}

public void submitScore(int score){
System.out.println("Desktop: submitScore: " +score);
}

@Override
public void getScores() {
System.out.println("Desktop: getScores()");
}

@Override
public void getScoresData() {
System.out.println("Desktop: getScoresData()");
}
}

PasteBin Version of Code with better formatting

Step 7 - In your projects main game class (the one that extends from ApplicationListener) create a constructor that takes an instance of GoogleInterface as a parameter. My constructor looks like this:

public Game(GoogleInterface aInterface){
platformInterface = aInterface;

platformInterface.Login();
}

As you can see I store the interface in this class, what you do with it once its in the project is up to you. I also call the interfaces Login method straight away so the game attemps to Login when it starts. In practice this probably isn’t a good idea. But for testing its fine.

Step 8 - Change MainActivity in your android project to implement GoogleInterface.

  • There is a lot going on at this stage. You need to make your MainActivity implement both GoogleInterface and GameHelperListener. This class will handle most of the actual talking with BaseGameUtils. I’ve set up a basic implementation that handles logging in, logging out, submitting and receiving scores. It probably isn’t suited to go straight into a game but demonstrates some ways to do these tasks. The main thing to note here is you pass the MainActivity into the Game constructor. Here is my class:

Pastebin version of code

If your getting an error with leaderBoardID you need to add it to your strings.xml file which is located in your Android project at res>values>strings.xml. The value for leaderBoardID should be the value of a leader board from your Google Developers page if you have made a leaderboard for the project.

At this point running the game should prompt you to choose a google account to log in with. If that actually happened, I’m surprised! If it didn’t, I probably forgot something or the tutorial needs to be more clear, so please contact me where you have got lost or what’s going wrong and I will try to help!

Source Code for tutorial on Github

Unity Dungeon Generator

Github Repository

This week I decided to take a little break from FlyBy and work on something  fun, so I decided to try and make a BSP Dungeon Generator in Unity.

To begin with I needed to create the Binary Tree that would store the space inside it. I decided to represent the space just using Unity’s primitive cubes. Splitting a BSP Node would take the cube it stored, break it in half randomly, and create two new cubes that would be stored as its left and right children nodes. After 5 splits of the tree it resulted in this:

The level split up into sections

Each color square is a leaf of the BSP Tree

With the level now partitioned it was time to start adding rooms to each section. I decided I would create a room prefab, and make several variations of it for each possible number of exits. Then when it came time to generate the connections between rooms just change the room to the correct prefab. So I created a prefab that looked like this:

A room with 4 exits

A room with 4 exits

Then it was a case of just randomly putting these into leaf nodes on the tree. Randomizing its position and size depending on the size of space that node was holding:

Stretched room prefabs

Stretched room prefabs

And doing this cause the prefabs to get horribly stretched, making the exits a non uniform size, and look like a complete mess. At this points I re-thought my plan and decided to store everything as tiles in a grid. this would mean that each room would be made out of lots of floor and wall tiles. Although significantly more expensive, it is a much more flexible approach. After making these changes I ended up with this:

Rooms now made out of tiles

Rooms now made out of tiles

Ah, that looks much better. Now to start connecting them. I decided to go with the most simple approach possible. To begin with I connect sibling rooms, these being rooms that share the same parent node in the BSP tree. To actually connect the rooms I created a ‘Digger’ class that would move from a start position towards a target position changing the tiles it touches into floor tiles, and surrounding the tiles it creates with walls, if those tiles are empty. The Diggers movement was a very naive ‘while My_x is less than Target_X, My_x ++’ sort of affair. Ideally I would like to go back and make the ‘Digger’ use a form of path-finding to find the shortest path avoiding other rooms and such, but that is a job for another day. The results of connecting siblings looks like this:

sc4

Siblings connected to each other

Not too bad, but we do get the unideal double connecting of rooms. I fix this by checking if nodes are already connected before connecting them. At this point it is just a matter of continuing traversing up the tree connecting the rooms with parents higher up the tree, until we are back at the root of the tree. At this point the dungeon should be fully connected! Lets have a look:

A fully connected dungeon!

A fully connected dungeon!

Top down view

Top down view

That doesn’t look too bad. At this point I decided to do a few iterations of a cellular automaton to ‘clean up’ the dungeon a little. This mainly removes corner pieces to make the dungeon feel more open and remove wall pieces that are sticking out awkwardly by themselves. I am pretty pleased with these results but there are plenty of improvements that could be made. If you are interested in the code for this project check out the Github Repository.

Github Repository

LibGDX Mobile Game

So for the last few months I have been working on a small mobile game. I had to stop using Marmalade because I was unable to get a student licence and my trial expired. Because of this I have decided to moved back to LibGDX which actually supports iOS now. The process of getting a LibGDX game onto iOS seems a little daunting but I will give it a try anyways when the game is more complete. Anyways, here are some screen shots of what I’m working on:

Inside a cave

Inside a cave

Some spinning obstacles

Some spinning obstacles

A mine field

A mine field

The graphics are being created by Liam Bower. The game is basically a helicopter style game with extra features such as different areas, power ups and a shop. We hope to have it finished pretty soon, although it has already taken much longer than originally anticipated.

One interesting problem I had to work on recently was generating caves with smooth walls like in the first and second screen shot. Before smoothing the wall generation, the walls were generated in square blocks, and actually still are. What I do is convert the top and bottom blocks on the walls into two triangles.One triangle using the center point on the top edge of the block, the center point on the top edge of the next block, and its x and y position to draw a triangle. Then the other triangle just draws to fill in the rest of the block. This picture should help illustrate whats happening:

Debug drawing of triangles

Debug drawing of triangles

The results of this method are good, however it is probably more process intensive than it needs to be, and finding ways to optimize it will be something I will need to look into. One solution could be generating ‘height map’ like structures, and then using the triangles to draw from the edge of the screen to the tip point of the map. This will remove the drawing of all the boxes under the triangles as the triangles would create the entire terrain. Generating the terrain in wider sections will lower the number of triangles being drawn at once too.

The progress of the game is going good, with almost all the main features already programmed into the game, but there is still quite a lot of work to do before we can call it finished and release it…

Been awhile

So oops, I haven’t blogged in about 2 months! But there is good reasons:


Firstly, I started a 12 month work placement at Canalside Studios back in September which has made me much more busy. I am currently working as part of a small team at the studio creating a mobile game using Marmalade. Although I have only been at the studio a short period, less than 3 months, I have already learnt a great deal. One of the areas I have learnt the most in so far is C++, as Marmalade is a cross platform SDK written in C++. The game is still in pretty early stages but so far the team seems pretty excited about what we’re creating! Hopefully it’ll turn out good.

In a slightly related note, I have also been working on my own little Engine/Frame Work for Marmalade. When we began our current project we created our own engine at the studio, however I am interested in trying my hand at creating some small mobile games in my own time so have decided to create my own engine based on what I’ve learned so far. The main reason for switching to Marmalade, over say, just continuing with LibGDX is because Marmalade works on iOS , Android and a whole array of other devices. So far my engine is in pretty early stages but check out all these crabs:

This does unfortunately mean I have stopped working on the Fish Game I was making in LibGDX. After learning about basic game engine structure working at the studio, it made me realize what a complete mess the code was. Also, the game just wasn’t very fun!

Manchester Game Jam

So this week I haven’t actually worked on the Fish game. However last weekend I did go to the 2nd Manchester Game Jam at MadLab.

Here are some related links for more information:

Blog Post About Jam

MCR Twitter

The jam started at about 11 am on saturday morning. There was a mixture of people there, some were entering Ludum Dare, others were participating in the mini jams being hosted by the Manchester Game Jam. I took part in the mini jam. We had to draw a theme from a bowl then had about 5-6 hours to develop a game with that theme. My team (consisting of me and my brother) drew the theme “Aeroplanes”.

We decided to just try and develop a pretty generic shmup as we only had 6 hours using XNA. We were also using this opportunity to try and get our heads around version control using GitBash. To begin with I drew some awful sprites while my brother set up the project and started working on the player class. When I was done drawing the sprites I started working on the enemy class. Then we tried merging our version together and everything broke. After awhile we realized if you added something to the content pipeline the merge wouldn’t go well, so we had to manually add graphics at the same time. Besides that issue, eventually we managed to get Git working really well and merging our version fine.

So by the end of the first day we had a controllable player that could shoot, destroy enemies and be destroyed. I had developed a wave point system allowing us to create waves of enemies that fly in different patterns, and I had used it to make a short level. At the end of the day we had to present our game in front of everyone else, it is the only rule of game jam that you must show what you do off at game jam.

On the second day we continued working on the game adding a power up system and a few new sprites. Although we did a lot of work on the second day for some reason not as much felt like it had changed! Anyways heres a video of the game at the end of the 2nd day:

Heres the GitHub repository of the game

All in all the jam was pretty fun, and I hope to make it to the next one, which will be the same weekend as the next Ludum Dare!

Procedural Generation

This week I’ve done some procedural generation using cellular automata. This was for generating coral reef inside levels. The coral reef acts as another obstacle that the player must avoid touching. Here is a look at some of the outputs of the generation:

Both the foreground and background coral are procedurally generated

The background coral uses a different tile set and tile size

The generation can create interesting loops such at this some times

To begin I had to write a grid structure as I found out LibGDX didn’t have one included. After a little research on different ways to implement a grid, I choose to represent mine as an Array of Arrays, which although might not be that efficient, is pretty easy to implement and understand, so heres the grid class I came up with:

package com.me.mygdxgame;

import com.badlogic.gdx.utils.Array;

public class Grid {

private Array<Array<Boolean>> grid = new Array<Array<Boolean>>();
private int rows;
private int collums;

public Grid(int rows, int collums)
{
this.rows = rows;
this.collums = collums;

//populate the grid with false values
for (int i= 0; i < rows; i ++)
{
Array<Boolean> tempArray = new Array<Boolean>();
for (int j = 0; j < collums; j++)
{
tempArray.add(false);
}
grid.add(tempArray);
}
}

/**
* Used to get the value of a cell from the grid
* @param row the row of the cell
* @param collum the columns of the cell
* @return the value of the cell
*/
public boolean getTile(int row, int collum)
{
return grid.get(row).get(collum);
}

/**
* Used to set the value of a cell in the grid
* @param row the row of the cell
* @param collum the columns of the cell
* @param aBool the value of the cell
*/
public void setTile(int row, int collum, boolean aBool)
{
grid.get(row).set(collum, aBool);
}

/**
*
* @return the number of horizontal rows in the grid
*/
public int Rows()
{
return rows;
}

/**
*
* @return the number of vertical columns in the grid
*/
public int Columns()
{
return collums;
}

public void printGrid()
{
for (int i= 0; i < rows; i ++)
{
String aString = new String();
for (int j = 0; j < collums; j++)
{
if (getTile(i,j) == true)
{
aString = aString + "1";
}
else
{
aString = aString + "0";
}
}
System.out.println(aString);
}
}
}

Once I had the grid, I ported the code from a flash demo I made that created cave/caverns using cellular automata. From there I just spent some time playing around with the rules. The main rules are cells with less than 3 neighbour cells that are ‘alive’ will die that pass, and cells surrounded by 5 or more living cells become ‘alive’ if they aren’t already alive. I do 5 iterations of these rules before doing a few special rule sets at the end to help clean up situations such as 1*1 single living cells and to shape the coral a little better.

Once created each cell auto tiles by working out how many cells it is surrounded by and in what positions to determine which tile to use for itself. I use two layers of coral, one for the foreground that when touched ‘hurts’ the player, and the other is a background layer just for aesthetics. The background layer uses bigger size cells, so has less cells in its grid. As such I fill the gird with more noise to start, but besides that it generates using the same rules as the foreground cells, and just auto tiles using a different tile set.

I am pretty pleased with the results of the generation, and have additional rules in place to make levels generate with more coral in later levels to make them harder as you progress, which I feel works pretty well.

This week I am planning to think about the design of the game more, as I feel it is more tedious to play than it is fun to play, so I will try and think of ways to make the game more fun!

Volcanoes

So its Friday of week two, so I really can’t put off doing a blog now if I want to stick to a blog a week!

This week I have implemented volcanoes into the game. Lets take a look!

Just one volcano, shooting some lava balls

Things can get hectic fast with more than one volcano

So maybe the level generation could do with some tweaking…

Lava Balls work pretty similar to Jelly Fish. If your finger ‘touches’ one you get hurt. The main difference is the movement. Jelly Fish swim around minding there own business much like fish (in fact exactly the same as fish). Lava Balls however get launched out of a volcano when it erupts and shoots upwards. They then slowly lose momentum and provided the initial eruption wasn’t so powerful they got launched off the top of the screen, they will then fall back down to the sea bed.

Although functioning well on a basic level, Volcanoes and Lava Balls could still do with some polishing (steam particle coming out of volcano before an eruption). One small issue I am having is the Lava Ball sprite is stretched on some screens. This is peculiar as I haven’t had this problem with any of the other sprites, and it is using the exact same code (copy and paste!). I hope to mess around with them a bit longer to try and sort the problem out.

Anyway, that is all I managed to do last week, this week I hope to work on some procedurally generated coral reef!

Time to Blog!

Hello.

So after putting it off for some time I’ve decided I should really start blogging. The main focus of this blog will be on the development of projects I am working on, so lets begin!

For the last 2 months I have been working on an Android game which I am developing with LibGDX. I have never done any Android development before so I am basically just learning it as I go along, but so far it has been pretty smooth (I’ll probably regret saying that when I start testing the game on a more diverse range of devices!)

The games main mechanic is drawing squares on the screen to catch fish. There is more to the game than that, but I keep changing everything else constantly. Here are some screenshots so you at least have some idea what I am talking about:

Image

(Just some fish swimming around, touching the jelly fish hurts you)

Image

(Drawing a square to try and catch two blue fish at once)

Image

(This is the half developed crab mini game!)

Most the art is ‘borrowed’ at the moment, it will all be replaced with unique art at some point before release, but for now I am focusing on the development to ensure the game does actually get released!

Recently in development I was having trouble with the game crashing after clearing about 30 ‘waves’ of fish. It turns out it was actually the seaweed that was causing the crash. At the moment the seaweed is the only animated object in the game, and each seaweed object loads all the textures in the animation (bad idea really!). After each ‘wave’ the sea bed would generate a new floor with new seaweed objects in new positions. It seems that after 30 waves there were so many seaweed textures loaded the game crashed. I have fixed the issue by pooling seaweed objects (you can only ever see like 10 on the screen so no more than 10 need to be created) however I can probably further optimise the seaweeds and improve performance by loading the textures in the animation once, and just reusing it when drawing all the seaweeds, instead of having it loaded into memory 10 times which I am doing at the moment.

So next I’m going to do a little re-organisation and cleaning up of the code base and then start working on volcanoes! The plan is a blog a week, so shout at me if I don’t do that!