Post navigation

After over two years of development, I have finally released my game onto iOS and Android. The release has gone pretty well, with the game being featured by Apple on the App store in a whole bunch of different regions and getting over 100,000 downloads in its first two weeks of release!

For the last year and half while working at Fabrik Games I have been working as part of the team on the companys debut Playstation 4 title Filthy Lucre. In September the first version of the game was released on PS4 and since then we have been working on updates and the Steam version, which will be released soon.

The game is a stealth/action hybrid with a focus on letting the player tackle missions in whatever play style they like best, with a friend in online multiplayer or by themselves in single player.

Working as part of the programming team I helped develop many areas of the game, some examples include:

Creation of Gear and Weapon items

Worked on the Trigger System used for interactions (e.g picking up items, doors, panels)

Networking of gameplay elements

User Interface

Filthy Lucre has been a great project to work on and through it I have developed skills in a lot of new areas as well as experience with the process involved with developing games for Playstation 4.

A project I worked on awhile ago using LibGDX and the engine I made for FlyBy was an asynchronous multiplayer minesweeper game based off the MSN instant messenger game Minesweeper:Battle. I decided to try creating an asynchronous game as at the time I had never worked with databases before and it seemed like a fun challenge. I chose minesweeper because it is a game with very simple game logic, which would allow me to focus more on the asynchronous aspect of the project.

Since I had the project lying around with no intention of doing much with it I decided to open source it in the hope other people who want to try something similar might be able to take away some value from it. The end result used three different database tables. One for accounts, matches, and player turns. The structure for the tables is included in the repository as well as all the SQL files in the SQL folder in the root of the repository.

Recently I have developed a technique to generate random planets, with the plan to use the generated planets in a game I am developing in Unity. The generated planets look like this:

These planets are created by first generating a random spherical mesh. This is done by choosing a start position, then creating a set number of vertices around this start point at any given radius. To randomize the position of each vertex in a way to avoid overlap with neighboring vertices, the vertices are moved a random amount on the line that represents its direction from the start point. So essentially, they are either moved randomly closer or further from the start point. Once the vertices are in place they can be used to create a mesh. However I found only having one set of vertices from the center point to the radius of the planet created problems later when I was trying to use a shader to fade towards the edge. To create a mesh that I could work with more easily in a shader I repeated the first process many times, creating sub layers within the mesh that connected to each other.

UV’s for the mesh could be calculated fairly simply by comparing the vertices position to the start position. To generate the texture used on the planets I came up with a technique that makes use of Cellular Automata. The idea is to generate multiple layers of the texture, that only consisted of two colors on each layer. I devised two different Cellular Automatons rule sets that would be used. The first would try and create small isolated sections of the layer color on the texture, then switch to the second rule set that would try and grow these isolated blobs outwards. To create more diverse layers the rules were randomized in several ways, for example the number of cycles before switching rule sets is randomized, as well as the actual rules that affect how cells die and live. An example of what an individual layer looks like can be seen in the picture below:

To combine the layers into one texture, each layer is added incrementally, averaging the color of each pixel in its texture with the value of the corresponding pixel already on the combined texture. The result of combining 4 layers (which is the amount used in the picture at the top of this blog) looks like the following:

To create the fade effect a simple shader is used to blend the texture with the polygons color alpha, which gives the final result.

I feel the results so far are pretty good but there is still a bit of work I would like to try and do, for example experimenting with ways to make the edge of the asteroid more apparent and possibly finding a better technique for the fade to edge that is already in place.

Its taken awhile, but FlyBy has finally been released on iOS! Check it out!

Of course, the game is still available on Google Play too!

When I first started developing FlyBy, LibGDX had no support for iOS. I had decided I would just make an Android game and it would never be released on iOS. So its pretty amazing to be able to say the game is available on iOS. But there were quite a few challenges even once LibGDX added its RoboVM backend for iOS. For starts, I don’t have a mac, or any iOS devices and I’m not a registered Apple Developer. Three essential requirements for making an iOS game! Luckily fellow game developer Matt Taylor offered to help out with the iOS version, and he had access to all three of the things required. Due to the way LibGDX works, where each platform has its own project that shares a common core project, it was possible for me to work on the core game, adjusting game play elements and re-factoring certain areas that would allow Matt to work on implementing game center support for the iOS version. The process essentially had me exposing certain elements of the game into interfaces so they could be accessed by the iOS project (for example achievement unlocks). This worked well, since Matt was not familiar with the code base at all, and allowed him as little direct interaction with it as possible, making it possible for him to focus on getting the core game center implementation to work.

For the most part, the core game worked almost without any adjustments, once the initial setup of deploying to iOS was overcome. However, there was a few quirks, mainly with sound. If serveral sounds were playing at once, there was a noticeable drop in FPS on the iOS version. Debugging issues such as this was very difficult. As they lied with the base engine classes, I had to essentially guess at what the problem could be, ask Matt to try out some changes, wait for him to do it, and then wait for him to tell me the results. This made for quite a slow and tedious development cycle and made it nearly impossible to tackle the problems to an acceptable standard. In the end, to overcome the sound issue, all sounds except the background track was removed from the iOS version, a less than ideal solution.

However, against all odds, the game is now released on iOS, and works decently on most devices we know about! So if you haven’t yet, download the game!

I recently used three different techniques to generate dungeon structures. This was done as part of my final year project. All techniques were implemented with Unity and used a common procedure to produce a 3D representation of the dungeons. The full report I wrote to go with these generators can be found here

Cellular Automaton Generation

Arguably not the best technique to use for dungeon generation, and much better suited for cavern generation, the results did give interesting shaped domains.

Binary Space Partitioning Generation

A much more common technique used to generate dungeons. Produces very uniformed shaped dungeons.

Delaunay Triangulation Generation

Based off the generation technique created by Phi Dinh for his game Tiny Keep. This techniques creates much less uniformed dungeons than the BSP technique and gives very appealing results. My implementation uses the incremental algorithm for constructing a Delaunay triangulation combined with the edge flipping technique.

Level Editor
One of my largest tasks was developing tools inside the Unity Editor that could be used to develop level segments (known as ‘chunks’) in the game, and maintain the documentation for it. The tool was designed so everything about how the levels spawns could be controlled from outside the codebase, including creating biomes (sections that only used certain chunks during that biome), creating predefined “Super Chunks” (a series of chunks that always spawn in the same order) and controlling the random creation of obstacles and collectibles on chunks, including the probability of any given obstacle spawning.

Game Play
I created many areas of the game play. The most important being the player Monster Truck movement and handling how it should collide with solid obstacles in a way that didn’t disrupt game play. I also worked on a few obstacles such as the Flash Bang and the Crane as well as other areas such as particle systems and the random generation of the endless level. As well I designed and created every chunk as well as all the OBS files in the demo using the Chunk Editor.

Performance
I also took a role of performance optimizing for the game looking for ways to improve the performance. I worked closely with the design team advising the use of Texture Atlases for there models, as well as general techniques to lower render calls and profiled the game looking for areas of the code base that were more intensive than necessary.

FlyBy has been on the Google Play store for nearly 4 months now. The game has been downloaded over 23,000 on the Google Play store and scored an average rating of 3.8 out of 155 reviews at the time of writing.

What went right

People actually played the game

Press and reviews of the game on various websites

“Piracy” in China

What went wrong

Game Difficulty

Giftiz

Crashes

People actually played the game

When we released the game we really had no idea what to expect. I had read developers posting on various websites and forums saying how they were stuck with only a handful of downloads and were struggling to get any attention at all. At the same time I had seen similar games on the store with what seemed like really high downloads in comparison. I had decided that 1,000 downloads would have been a good result before release. So with 23,000, I am really pleased with the reception FlyBy has received.

Press and reviews of the game on various websites

Before the release of FlyBy we put together a press pack to try and make reviewers life as easy as possible. It include screenshots of the game, information about its development, and even a PC version of the game for press use only. I believe this helped us get reviews on some websites, and although non of the reviews had too much of a dramatic effect on the download count, they definitely helped. Our biggest feature happened when one of the other developers wrote to a local newspaper on a whim. We honestly didn’t think there would be a response, but to our surprise the newspaper decided to write an article about FlyBy. The online version of the article can be found here. Please excuse some of the quotes, the guy doing the telephone interview was a little nervous/excited, and not fully in the loop with the development of the game!

One of the events that had the biggest impact on FlyBy’s download count was when the game got uploaded to some Chinese app stores. I noticed this was happening due to integrating Google Analytic’s. There was a few days where Google Analytic’s was showing very high new users but Google Play wasn’t showing information that agreed with all these new users.

Graph of new users from Google Analytic’s

Although these downloads didn’t get added to the Google Play page and potentially impacted the visibility of the game on Google Play, it was still positive to get a few thousand extra downloads.

Game Difficulty

FlyBy is probably too difficult. I was very keen on integrating Google Analytic s into FlyBy to collect more detail information about the users who would play the game, to hopefully be able to use to make improvements in later updates. One of the challenges in the game is called “Flying License” and is basically an achievement for completing what is considered the tutorial section of the game (flying through the first two caves for the first time). To date, this achievement has been earned 1,562/23,000 (more like 25,000 if you count the Chinese downloads). Considering most of the content in the game cannot be seen until this section is completed, and this section is suppose to be easy compared to the rest of the game, this is a tiny percentage of players. Most the people who downloaded the game never saw the ‘good’ parts of the game.

Giftiz

Giftiz is a company that has created an app discovery service. It largely evolved around users being rewarded to download apps from their app. The rewards can be built up for real prizes too apparently. Giftiz contacted us presenting us the opportunity for a free feature in their app, in exchange for putting a button that advertises their app in FlyBy. The featuring did give us quite a big spike in downloads.

Giftiz Spike from Google Analytic’s

So why was it bad? Well part of the agreement is you have to keep their button in your app for at least 6 months after the featuring. That is quite awhile considering the featuring only gave about 2-3 days worth of extra downloads. The company also claimed there was no pop-ups to go with the button. When I was integrating their SDK into FlyBy using a developer key they gave me, I never saw any pop-ups either. However it became apparent once released, that on the first time the game is ran, Giftiz forces a full screen page explaining about their product. Interactions with the company were often unprofessional. In e-mails they referred to FlyBy by the name of a completely different game (one that was getting featured around the same time), and they pushed back the feature date of FlyBy very near the agreed date (due to a paid featuring, which is understandable) meaning we got featured after our first month on the store had passed. All in all, this featuring was not worth the time it took to integrate their SDK or communicate with the company.

Crashes

Since release there has been 10 different crashes reported roughly 150 times. Although I feel this number is relatively low, I think it could of been lower. The most common crash report is in “android.opengl.GLSurfaceView$EglHelper.throwEglException” which has been reported 110 times. 94% of these reports come from devices running Android 2.3.3-2.3.7. Considering the game probably does not run very well on these phones at all, I feel setting the minimum Android version higher and not allowing these devices to download the game could of had an impact on the overall rating of the game, by avoiding as many 1 star reviews from users who the game did not work for.

Conclusion

I feel there are more improvements that I could of made to improve the release of the game, such as working on updates after release. The game was released right before my final year of University began, meaning I did not have as much time to continue developing it. However, as mentioned before, the game has received far more downloads than I had anticipated and has been a great learning experiencing. I hope to use the what I have learnt from this process in the future, when I hopefully release more games.