About oolealealealea

I like playing and creating all types of games.


October Challenge 2015

oolealealealea's Trophies

oolealealealea's Archive

Better late than never

Posted by
Wednesday, November 18th, 2015 8:00 am

My goal for this year’s October Challenge was to port Drone Invaders to iOS and earn $1 on the App Store.

Drone Invaders was built in 2013 October Challenge for Android. The game got a lot of attention and managed to earn about $90 since the release. Although there were 3500+ players, the main problem for monetization was that the game was free to play and I didn’t really build it to be a money milking machine like “popular” mobile games do. I wanted the game to be fun and challenging and payment to be completely optional. The result is $90 in two years, but nevermind.

Drone Invaders from Space

For iOS, I still didn’t want to change the way the game plays, but I decided to ditch the IAP idea completely and remove all the payments from the game. But how would I pass the October Challenge then? I decided to price the game itself. It’s $1.99 in the AppStore and I have already earned the dollar and the player ratings have been great as well:



All this in about a week since the release. The game has already earned half of what the F2P Android version has in two years.

It’s possible that this YouTube review (over 2700 views) made all those people come in: https://www.youtube.com/watch?v=rI4jNWXvJzY

I think my next mobile game will be iOS-first.


Is this puzzle too hard?

Posted by
Tuesday, April 7th, 2015 10:27 am

While waiting for next LD I’m making a game in between and I have one logic puzzle in it that I somehow feel is too hard. The game is C++/SDL2 but I made a web version (HTML) of the puzzle to make it easier for you to test.


Can you guys try it out and tell me if it’s too hard or not.

You can play it in your browser here:




Final release: Just in time

Posted by
Tuesday, October 28th, 2014 3:52 pm

Finally everything is complete. Just in time before October runs out:

If you have Android device, grab it on Google Play:



Gods of Sparta: fixed version

Posted by
Thursday, October 23rd, 2014 5:24 am

The second beta version is ready for testing. Everything should work now. The music in main menu screen is still missing, but everything else is there. Please test and tell me how you like it and if you think something needs to be improved.


If you installed the first beta, please remove it from your Android. Due to updated libGDX, the application package name has changed (from com.bigosaur.gos to com.bigosaur.gos.android), so Google is treating this new one as a separate application and won’t update the game if you have already installed. You have to install this one as if it was a completely different game. Sorry for the inconvenience.

Day 16: Gameplay fully operational

Posted by
Friday, October 17th, 2014 2:51 pm

I finished conversion to landscape mode and implemented the attack icons and animations. For most attacks the cards just move and shake a little bit. Ranged units have special animations, Zeus fires thunderbolts and Catapult throws rocks at enemies. I added the damage numbers to attack icons and it’s now visible which type of attack deals the most damage.

I also created some nice icons for unit Energy (heart) and also Attack (sword) and Defense (shield). Those show up when the default unit values are modified (by artifact or an ally that stands next to them). This makes the game fluid to play, as you don’t have to keep do the calculations manually all the time.

What’s left to do: Turn indicator graphics, Sound effects, Music (I’m going to get help from a musician), AdMob integration. Initially the game was supposed to be only a two-player game, but now I’m thinking about single player mode as well. Writing good AI for this strategy might get complicated, but it’s worth a shot. There’s still enough time before the end of October.

Day 14: reducing .apk size to fit 50MB

Posted by
Wednesday, October 15th, 2014 10:01 am

As I switched to landscape mode, I started to create mirror-flipped images of unit cards using the -flop option in ImageMagic in one of the card-generating steps. As the script rolled on for some time, it hit me that this would increase the amount of graphics a lot. I got worried about the size of the final .apk file. First time since I started the project I decided to check.

I created a package containing only the lowest (800×480) and highest (2560×1600) resolution images. It’s 106MB!

I need to add 4 intermediate resolutions, so I’m looking at 300+ MB for the final .apk. I searched the docs and found that the limit is 50MB and rest has to be provided as a separate package. Or, you can distribute two different .apk files. I didn’t like any of those. I hate when you download an Android game, and then you have to wait for it to download hundreds of megabytes more. I needed a new approach.

I searched the Internet. Most advices are about packing your code using compressor/obfuscator programs. But the gains are really negligible. Then one thing caught my eye: using JPEG for textures. I’m using TextureAtlas to pack everything automatically, but I could separate the images with and those without transparent areas and pack them separately as PNG or JPG.

The problem is that 90% or the graphics need transparency. In this particular case the main problem are the card images, which have rounded corners. And then I got this great idea: separate the card image into frame and contents. There are only four card types in the game (one for each faction and gold one for the items), and all cards of the same type share the same frame. The inside of the card is different for each one, but it does not require transparency. Instead of packing 126 cards into PNG texture, I would pack 126 cards into JPG texture plus 4 frames into PNG.

As I tried this, I got some weird clipping artifacts in the JPG texture, probably because I turned off the 2-pixel padding. So, instead of pixel precise cropping, I increased part of the graphics that gets copied to JPG so that there is some overlap. When staging the images, make sure the jpg one is drawn first and PNG frame over it. The part that overlays will covers the bad edge pixels.

BTW, by “staging” I mean placing the Images into libGDX Stage. To make the code simpler, I created a nice CardImage class (descended from Group) to handle drawing transparently. This Group contains the center of the card from JPG texture and then positions the frame from PNG texture over that.

This saved A LOT, but I got so concerned about the size that I wanted to do something about flipping as well. I researched if I could only flip a part of the image. It’s possible using AtlasRegion.flip() function. But I also had the problem that I didn’t want to flip the whole image. The textual part should remain the same and only the unit graphics should be mirrored. To do this, after calling flip(true,false) I used setRegionY and setRegionHeight to reduce the flipped region size. Using the flipped region I created another Image and added it to the CardImage group. At runtime, I simply show or hide this image when I need to unit to face left or right.


New .apk file with the same content is now only 12MB. A 88% save. Once I add all the other resolutions, I estimate the final .apk to be about 40MB if all goes as planned. Compare this with 300MB+ I expected at the beginning.

TL;DR Summary

Beside all the other advice you might find on the web (compressing the code, etc.), add these three:

  1. use JPG wherever possible
  2. if you use PNG only for semi-transparent border, cut the image into frame + content. Store the frame in PNG and content in JPG Of course, if your frame is not reusable on multiple images and has complex colors this my have the opposite effect. However, there’s a solution to that as well: cut the frame into four pieces (left,right,up,down) and assemble it at runtime. No more empty space in the middle of the frame in PNG.
  3. If you have images that are flipped or rotated, store only the original and flip/rotate at runtime.

Day 10: Battlefield

Posted by
Sunday, October 12th, 2014 4:34 am

If got a lot done in the past two days. The main battle mechanics work. You can place and move units, and attack. There is still no attack animation. As you can see on the screenshot, some units are turned upside-down. This is because it’s a two player game. The idea is that you put the phone/tablet down and sit across each other and play.

Flying units like dragons can reach any field, while others have to move one step at the time. Each turn, a player can move and attack, or attack only. Once you attack, it’s the other player’s turn.

I’m currently drawing some attack icons. When you select your unit in the field, those circles would rotate over the adjacent enemies and you can pick which one to attack.

Depending on the attacker, a different circle would be used. Olympus units would get a blue round one. Humans get the yellow square (at least I tried to make it resemble a cross). Underworld units have the hexagram. I drew all these in Inkscape.

Day 9: Picking cards and explaining how they work

Posted by
Friday, October 10th, 2014 8:01 am

I know players hate reading complex rules, so I tried to make a screen that would explain how the cards work without getting too complicated. Here are the basic rules:

At the start of each game, the players are presented with a deck of 20 cards and they take turns picking one by one until each has 10 in their hand. After that the battle starts.

When the first player picks the card, all the other cards rotate 180 degrees to face the player sitting across. It’s a two-player local duel game.

Day 8: drawing some artifacts with Inkscape

Posted by
Thursday, October 9th, 2014 5:33 am

One of the artifacts in my game is the mythical Ring of Gyges. I decided to improve my graphics skills and learn Inkscape better. Rings and other metal surfaces are rather simple to draw, you just need to combine proper gradients.

I started with basic eclipse, duplicated the shape multiple times and then created unions and intersections needed to assemble the ring. I used a brown-gold-white-gold-brown gradient (it’s easy to make a custom gradient like this in Inkscape). To get the proper gradient (straightforward or reverse) I put a real ring on my desk and watched the colors.

This is the basic ring. But lets make it look really good. First I rotated it about 180 degrees and then added a gem to it:

As you can see the gem has multiple layers. On the bottom we have a black circle with white border. Border is not the same everywhere, it has a gray-white gradient stretching from left to right. Outside it, there’s another border, with black-to-transparent gradient. This is used to create a 3D effect on the ring’s metal surface. Over that, we have a half-circle with another gradient. This time the gradient is radial, extending from the bottom-left corner which has a white point. That point looks like a point where the light enters the gem. This is the base. Now we will add color. You can pick any color. I choose blue.

First, we create the dark blue overlay (one the the right in the image above). Note that is also has a slight gradient going from left to right. The light blue layer on the top is used to complement the bottom-left white point in the black and white base. As the light enters in the bottom-left corner it goes through the gem and exits in it’s top-right part. There is no sharp point there, although you could put one if you want to achieve a different effect.

Finally, here’s the artifact’s card in my Gods of Sparta game:

Picking artists on Fiverr

Posted by
Tuesday, October 7th, 2014 6:39 am

I’m still learning how to draw well, and I’ll make all the artifacts images.

I’m pretty satisfied the way all this turned out. Still, I think that for my next project I will learn how to draw myself.

Battlefield is the screen players will see all the time. At first I thought about building it from tiles, but I changed my mind. It’s going to be fullscreen graphics, in all it’s HD glory. I found some free wood, sand and stone textures and played with them in Gimp for almost two days now. Here’s the end result:

Looks kind of lame on this thumbnail size, but I assure you it’s much better on an Android device. The shaded part is the background used to fill the space on wider devices. It isn’t really shaded in the actual file.

I created this screen at 2134×2733 pixels, so that it covers all possible Android devices. Now, I need to scale it to sizes appropriate for 800, 1024, 1280, 1536 and 1920 screens. To avoid doing this manually, I created a simple script that calls the imagemagick tool to do the scaling. Here’s the script:

convert images/2560/$1 -resize 31.25% images/800/$1
convert images/2560/$1 -resize 37.5%  -gravity center -crop 1024x1024+0+0 +repage images/1024/$1
convert images/2560/$1 -resize 50%    images/1280/$1
convert images/2560/$1 -resize 60%    images/1536/$1
convert images/2560/$1 -resize 75%    -gravity center -crop 2048x2048+0+0 +repage images/1920/$1

You need to create directories named 800, 1024, 1280, 1536 and 1920. You should create all images in directory named 2560 and then just run the script to create the others:

./generate.sh background.png

If you don’t like the default blurry edges, you can use -adaptive-resize instead of just -resize. The difference is similar to using Cubic vs Lanczos algorithm when scaling in Gimp.

For more detailed explanation and code that packs the images into texture atlas, continue reading this post on my blog:


Day 3: Enabling immersive mode on Android

Posted by
Saturday, October 4th, 2014 4:15 am

While testing the math from my previous post, I noticed that wrong set of images gets picked up on some of the Android devices. Those devices have on-screen buttons (home, back, menu) which are shown inside the screen. Luckly, the solution is simple, just enable the immersive mode and buttons would go away and you have the whole screen to your game.

As a side-effect, players would be much less likely to hit the home button at the bottom of the screen and exit your game mid-play, as they would have to drag the finger to make the button appear at all.

The immersive mode is available since KitKat. If you don’t want to bother with the docs, here’s the code you can simply copy/paste into your project:


The code uses a 5 second delay before immersive mode is activated. This is useful in case user lanuches the app by mistake.

If you’re making an Android game, please implement this.


Handling different device resolutions for Android

Posted by
Friday, October 3rd, 2014 8:53 am

For my first Android project I made a mistake of only testing on a single device. This time I decided to to extensive research to make sure my game looks great on all Android devices from 800×480 to 2560×1600 pixel screens. After two days of research and testing and made this guide for all the Android developers;


I’m making all the graphics in 6 different sizes, scaled from 100% for 800×480 screens to 320% for 2560×1600. I’m using letterboxing with 16:9 being the base resolution, but instead of plain black background I’m using a filler-background so the whole screen is full with some graphics. The “action” takes place only in the central 16:9 space though. It should cover 99% of devices out there. Here’s my main menu:

I plan to automate most of it with ImageMagick. The workflow would be like this:

1. draw everything for the largest resolution
2. scale images (svg where possible, jpg otherwise)
3. for any overlay text, use imagemagick to add it on the shrinked image using the appropriate font size

As you can see in my blog post 2134×2733 is needed if you simply want to scale the image down to any resolution. This enables you to use the single “scale” multiplier in entire game. Whenever you need a fixed coordinate, just multiply by the scale factor and you’re done. At least, for Sprites. If you’re using libGDX Stage, then you also need to offset each coordinate against the screen center, because libGDX Stage coordinates start in bottom-left corner which might be different on aspect ratios other than 16:9.

Well, I hope this helps anyone who makes 2D games for Android. I still see some very popular games not doing this right. For example I got CubeMen from the Humble Bundle and menus are so small on Nexus 10 that you can barely read text or touch the correct button.

I’m in!

Posted by
Wednesday, October 1st, 2014 4:40 pm

Being a busy father of two never leaves enough time to do regular LudumDares. It’s almost impossible for me to dedicate 48 hours straight to anything. That’s why I love the October Challenge. Last year in October I participated in my first LudumDare OC. I made an Android Game called Drone Invaders, released it on Google Play, got about 3000 players and earned some trivial money (about $140). But I learned a lot, especially all about Android development.

This year I plan to build another Android game. Some (say, 60%) of the graphics will be outsourced to artists on Fiverr. Rest of the gfx, programming and sound effect I plan to do myself. I’m still not sure about music. I depends how much time is left when everything else is done.

Last time I used libGDX as bare-bones graphics library, only utilizing Sprite and BitmapFontCache classes. This time I plan to use Scene2D with Stages and Actors. Another big change is that I will make sure that devices with higher screen resolutions are properly supported and all the graphics are crisp clear.

As for the $1 goal, I will stay away from IAP this time. Google Wallet accounts are still not available in my country, and doing it through some friend abroad just complicates things and slows me down. I decided to try AdMod instead. It’s linked with my AdSense account, so there should be no problems with the payments.

As for the game itself, I plan to revamp my Gods of Sparta strategy game. The main focus will now be local, hot-seat game for two players on Android devices. It will be completely free to play, supported by ads. I will reuse some old graphics, but more need to be drawn, especially higher resolution stuff for Nexus10 (2560×1600 pixel screen) I got recently. Also, UI needs to be drastically improved and game rules have to be simplified. To cut the long story short, I need to improve the player experience and make it feel more like computer strategy game and less like paper card game. Here’s some teaser graphics that will be included in the game…

Good luck everyone.

My experience from using Facebook Ads to promote a game

Posted by
Friday, November 29th, 2013 4:13 pm

Drone Invaders is a game I created for the October LudumDare Challenge. Some time ago I decided to spend $100 on advertizing it on Facebook.  Facebook ads have some really nice features, like picking only people from certain countries who like certain things. So I selected people from English speaking countries, who have an Android phone and like Space Invaders or Galaga.

The campaign ran for 18 days and got 839 clicks, which is around 46 clicks per day. On the other hand, I was monitoring players that played the game. Unlike Google Play which monitors installs, I’m monitoring how many people play the game and get to the Game Over screen. During the campaign I had about 40-45 new players coming in each day. Since the campaing has ended, I have about 10 new players coming in each day. So, the campaign effect was about 30 new players per day or 540 total. Thats 540 players for $100, or $0.185 per player. It’s nice to know this figure before doing some ads, but spending $100 to learn this is also not a big deal. During this campaign the game earned about $25, so it’s a net loss, but the game is not about making much money anyway. It’s free to play with completely optional in-game purchases.

To conclude: I find Facebook ads useful and would use it in the future if I create some game that I feel can bring in some real money. Especially if I make a non-free game, this seems like a good way to attract more players. It’s great that you can target people who like similar games and have a device it runs on.

October Challenge Complete!

Posted by
Monday, November 4th, 2013 10:55 am

(copied from my blog)

In the last two days, I got a couple of new orders for in-game coins, coming from Denmark, Australia and USA. Thank you.

That’s $21.81 of income, of which about $5 was me testing in the payments work, and there’s Google’s cut as well. In the end, I earned about $11. Since October Challenge was to earn $1, I succeeded. However, I still have a net-loss of about $14, since I invested $25 in Android developer license.

Now that I see there is some interested in in-app currency, I’ll try to do some payed forms of marketing, so see if that brings in some new players. When you publish an Android game, a lot of marketing companies e-mail you with their offers. I’m going to try some of those. I’ll write about the results here in a week or some after I have some data.

[cache: storing page]