Hey what’s Canvas?

Canvas is just a bitmap drawing surface. In the DOM it’ll just be one element.
You can draw on it using a javascript api: https://developer.mozilla.org/en-US/docs/HTML/Canvas

Browser support?

Canvas is usable since ie9, most other moderns browsers seem to support it:
http://caniuse.com/canvas

Shims/Shivs/Polyfills?

For ie<9 you may try excanvas: http://code.google.com/p/explorercanvas/
Supposedly it can’t simulate the api 100%.

Libraries?

Most canvas libraries give you some svg-like features, like a display hierarchy and easy to use event listeners. I.e. you can draw shapes and retain references to them, add listeners to the references and so on. Most of these libararies offer animation support too, so you can tween your heart out.

@kangax has made a comparison of libraries:
https://docs.google.com/spreadsheet/ccc?key=0Aqj_mVmuz3Y8dHNhUVFDYlRaaXlyX0xYSTVnalV5ZlE

The top five canvas libraries according to github watchers are:

• easel.js
• fabric.js
• paper.js
• kinetic.js 
• processing.js

Hey what’s SVG?

SVG is vector graphics format. Each element (shape) in an svg will be part of the DOM.

Browser support?

SVG is usable since ie9, most other moderns browsers seem to support it, besides the android stock browser before 3.0: http://caniuse.com/svg

Shims/Shivs/Polyfills?

ie<9 supports vml which is similar in functionality (although removed in ie10).
If you’re using raphael (a javascript svg/vml library) it can fallback on vml if needed.

Libraries?

• d3.js – Consider this for diagrams/graphs/etc. It’s geared towards data visualization and based on svg.
• Raphael – Provides an it’s own api for producing svg (or vml if ie<9). You can do animations etc.
  It can’t read in svg though, which kind of sucks if you have a neat svg file. There are conversion tools (svg to raphael js-code) in existence, but it’s still manual work.
• jQuery-SVG – jQuery plugin for dealing with SVG, but provides no fallback to vml.

When should I use Canvas and when should I use SVG?

Use svg for:

• Static images (svgs are great for responsive/fluid layouts)
• Vector graphics (e.g. produced in illustrator/inkscape, exported as svg)
• Diagrams
• Stuff which benefits from DOM integration (fancy UI-components?)
• Easier debugging since you can view that stuff in a dom-inspector

Use canvas for:

• Mutable bitmaps
• Your fancy graphically intense demos
• Games
• Stuff for which svg performance won’t cut it. (Thousands of rendered elements and a lot of real-time updates)

Of course the case might be you happen to know one of those canvas libraries really well, in such a case you’d be more productive using canvas vs. svg, if it meets all your needs.

So which one will you use for your interactive map?

Well I’m not done yet but it looks like none of the above.
I should be just fine with basic html/css with some creative positioning.
It has the best browser support and I won’t really need any of those fancy features.
According to some quick tests, pixel based scaling will look good enough for my use case.
Given some neat svg map and better browser support the svg stuff would probably be a cleaner implementation choice.

Redis is a key-value store and much more. For some good Redis use-cases read:
http://highscalability.com/blog/2011/7/6/11-common-web-use-cases-solved-in-redis.html

I installed redis using macports:
sudo port install redis
Although you can install it any way you want. Check the Redis download page.

Started the server
redis-server

Coded some Java based tests using Jedis.

Output on my 2010 macbook pro when running the tests within an IDE:

main: Starting cache writing test: 100 concurrent clients doing 1000 writes each. (100000 total writes)
main: Waiting for clients to finish writes.
main: 100 clients did 1000 writes in 5181 ms.
main: Served about 19301.29 writes per second.
============================================================================
main: Publishing 1000 messages to 10 subscribers.
main: Waiting for subscribers to receive all messages.
main: Published 1000 messages and confirmed receival in 10 subscribers in 360 ms.
main: Throughput (to confirmed delivery) with 10 subscribers was about 2777.78 published messages per second.
main: 27777.78 messages received in total per second.
============================================================================
main: 100 clients doing 1000 lookups each.
main: Waiting for clients to finish lookups.
main: 100 clients did 1000 lookups each for a single cached value in 3812 ms.
main: Served about 26232.95 lookups per second.
============================================================================
main: 100 clients incrementing the same key 1000 times.
main: Waiting for threads to finish.
main: 100 concurrent clients incremented 'incrKey1337529005509' 1000 times each. Completed in 3868 ms.
main: So around 25853.15 increments per second
============================================================================
main: 5 queue listening clients dequeuing 50000 items from a queue.
main: Waiting for all items to be dequeued.
main: 5 clients listening to 'queueKey1337529009407' containing 50000 items emptied the queue in 1942 ms
main: Queue listeners processed about 25746.65 items per second.
QueueListener-2: dequeued a total of 9954 items
QueueListener-1: dequeued a total of 10031 items
QueueListener-5: dequeued a total of 9991 items
QueueListener-3: dequeued a total of 9973 items
QueueListener-4: dequeued a total of 10051 items
============================================================================


Clone the repository and try twiddling around with it yourself:
git clone git://github.com/kallebertell/redisperf.git

You should be able to run the tests with plain maven:
mvn test

Or browse the github repo here: https://github.com/kallebertell/redisperf

For more info about Jedis, check: https://github.com/xetorthio/jedis/wiki

10:00

Venkat Subramaniam:

How to approach Refactoring – key step to agility

I’ve seen Venkat a couple of times and he’s a solid technical presenter.
Here he is presenting scala:

If the topic (Refactoring) interests you it’ll probably be a worthwile.
I think I know enough about the topic though so I think I’ll try to check something else.

Dave Snowden:

The new 3 C’s: Complexity based approaches to project management

Something about Project Management. Here he is presenting something called Cynefin:

I forsee this presentation being a bit too academic for my tastes.

Brant Cooper:

It’s the End of the (Startup) World as We Know it

Attending!

I haven’t heard of the guy but he seems to know his stuff:

11:00

Olaf Lewitz:

Agile Community Building – Using StrategicPlay with Lego

Attending!

This is a 90minute session.

Here’s an interview with Olaf:

I have no idea what it’s about but if it has Legos it must be good!

11:15

Phil Calçado:

Better Functional Design Through Test-Driven Development

So TDD with functional languages. Might prove interesting.

Joseph Pelrine:

“Cynefin – Making Sense of Agile”

This sounds like Dave Snowdens stuff, but I know for a fact that Joseph Pelrine has very engaging sessions.
It’s probably worth to attend no matter the topic is. Here he presenting about coaching self organising teams: http://www.infoq.com/presentations/coaching-self-org-teams

Stuart Eccles

Hey, this guy doesn’t have a topic yet.

13:45

Daniel Knott:

Mobile App Testing – Challenges, Solutions and Best Practices

Attending!

Probably about how to do functional testing on Android and iPhone. I’m not burning for the topic but might be useful.

Kati Vilkki:

Creating continuous improvement culture

I guess this is going to be about retrospectives. Kati is an agilista from NSN.

Otto Hilska:

Flowdock’s journey to product-market fit

Flowdock is a nice product. I’m gonna guess this is going to be some 37 signalish approach. (They are using their own product etc)

Riitta Saarikangas:

Vuorovaikutuskoulutus: sosiaaliset vuorovaikutustyylit

This is a 90min session, I guess about social interaction.

15:00

Chris Matts:

Feature Injection

I’m not quite sure what feature injection is, but I found this comic:
http://www.agilejournal.com/articles/columns/articles/1643-feature-injection-

Some day I’m going to read it.

Laura Snellman-Junna:

Mechanics of Empathy

So I guess some psychological thing explained so it can be understood by us nerds.

Tuomas Rinta:

Lean Organizational Growth

Attending!

I guess about how to scale a startup’s organization once it gets to a certain size.

16:15

Daniel Temme:

Quit Your Job

If you don’t enjoy your job you’re wasting your life.

Marko Taipale:

Showing the unseen

Some agile technique involving pictures.

Marc McNeill:

Agile Experience Design

Attending!

Don’t know the guy but the topic is interesting.
Here’s someone else on Agile User Experience:

Ari Tikka:

Zen at work

“After a short introduction we will do a 25 min meditation exercise.”

Ok

Check out the live version. It may work on some browsers (chrome).

I promised a publisher I’d review their book, Android Wireless Application Development (2nd edition), however, I tried doing a book review earlier and honestly it’s just a snooze to read; so I thought I’d write a blurb about tech books in general too.

In general these technical books suffer from a very common ailment, being big and boring – no normal people would read these tomes from cover to cover and enjoy it. There are some publishers which consistently publish enjoyable succinct reading; but a large majority still churn out heavy tomes which end up selling regardless of their content.

The subject has been covered in some detail.

Andrew Binstock wrote about Lax Language Tutorials not too long ago,

“These books are marked by common failings that greatly frustrate their simple mission. The first and by far most-common handicap is a confusion by the authors in which they conflate a tutorial with a detailed treatise on every aspect of the language. For reasons not quite clear, the latter approach seems generally favored by the publishing industry, resulting in almost ridiculous volumes.”

Philip Greenspun also touches the subject in his Dead Trees story,

“It is an article of faith in the computer publishing that bigger books sell better. They take up more space on the shelf and readers with a tech problem find a bigger book comforting. Readers aren’t really sure what is wrong with their computer and they only have a few minutes in the bookstore so they figure the thickest book is the most likely to contain the solution.”

Sounds plausible. I did a bit of googling about the myth of authors getting paid by the pages, but that seems to be untrue; although a thicker book might mean more sales which would mean there is an implicit motive to make your book as thick and heavy as possible.

The Bad

So how does this relate to Android Wireless Application Development? Well at 791 pages (including index and everything) it certainly is thick, although it’s not the thickest book I’ve seen. There are much worse. I’d love it if these books would limit themselves to 300 pages, but preferably closer to 200 pages.

The biggest cardinal sin of Wireless Application Development is explained by the authors’ themselves in the very introduction:

“This book was written for several audiences:”

It goes on to list software developers, quality assurance, project managers and “Other audiences”. I figure you can write a book for several audiences, but you cannot write a _great_ book which is suited for several audiences.

The tech books which have affected me the most, the ones which were of most educational value to me, have all had focus. They tended to a narrow audience which I was a part of.

In Android Wireless Application Development I found maybe 3 chapters out of 29 completely irrelevant; which isn’t that bad actually.

The Good

Then again this is a reference book first. Every chapter can be read independently of each other. There is no common thread from beginning to end; so you can just pick the chapters which interest you and read them; and this is definitely the way you should read this book. Thankfully most chapters jump straight into code examples which mostly get straight to the point.

It doesn’t go very much in depth into the more advanced subjects, but nor should it. It scratches the surface and lets the reader go online if it interests him further.
With 29 chapters this is certainly the way to go; although I myself would’ve maybe dropped some of those chapters, but at least it doesn’t leave any major subject unscratched.
It’s all in there.

The Judgement

I used this book as a head rest while camping for a week in Iceland; and at 791 pages it certainly worked well for that; but you’ll learn a whole lot more if you actually read some of it. Good for the non-beginner Java dev wanting to learn Android development but also for intermediate Android developers who just need a reference book.

Does it deliver? Yep. It might not be Clean Code good but still pretty damn good.

This book doesn’t really cover code at all but focuses on the coder, his behavior and on his  methodologies. It tackles very many difficult issues in very few pages in a clear and concise way. To cover the ground Bob does in about 200 pages is a major feat; especially when he manages to sprinkle in a fair amount of amusing anecdotes from his programming career to support his arguments.

I may disagree on some points but in overall agree with more than 95% of the stuff anyway so I’m not going to nitpick. This is an easily approachable book and won’t last you many evenings. This should be on any apprentice, journeyman and master programmer’s must-read-list.

A Code of Conduct for Professional Programmers

Short description of each chapter:

Chapter 1: Professionalism – How to act like a professional. Surprisingly few coders know how to do this.

Chapter 2: Saying No – Say no to stuff you can’t promise 100% as trying and failing will just make people distrust you.

Chapter 3: Saying Yes – When you say yes you should mean it. Commit to the stuff and don’t give vague promises.

Chapter 4: Coding – When you should code, for how long and what to do about external forces affecting your coding ability.

Chapter 5: Test Driven Development - Arguments for TDD.

Chapter 6: Practicing – Tips on how to practice and keep up with your craft.

Chapter 7: Acceptance Testing – How to do acceptance testing.

Chapter 8: Testing Strategies - Explains how and what to test on different levels. The levels being depicted in a pyramid from the lowest layer to the top like this: Unit Tests, Component Tests, Integration Tests, System Tests and Manual Exploratory Testing.

Chapter 9: Time Management – How to get stuff done and how to deal with interferences and time thieves.

Chapter 10: Estimation – Arguments that estimates are always uncertain and should be communicated that way. Proposes several methods of doing agile estimation.

Chapter 11: Pressure – Keeping your cool and staying clean under pressure.

Chapter 12: Collaboration - The most common collaboration anti-patterns you might be guilty of.

Chapter 13: Teams and Projects – Arguments for that teams shouldn’t be split up after projects.

Chapter 14: Mentoring, Apprenticeship, and Craftsmanship - How apprentices should be mentored into journeymen.

Appendix A: Tooling – The minimum tool set you should at least have in use if you wish to call yourself a Professional.

If anyone was wondering if the post had any effect on downloads the answer is yes. It was the only marketing which clearly affected the download stats. However, as with traffic to the blog post, the effect was temporary. I guess if you manage to write interesting content regularly you could ride that wave better than I did.

So here are some points collected from the feedback, and some of my own subjective opinions reiterated from the last post now condensed in this handy list.

Have an appropriate amount of polish.

Great game concepts can be ruined by crappy presentation or bad user experience. If you don’t have artistic talent consider getting a guy to do the graphics for you. Ditto for musical talent.

You can really immerse yourself and feel the seriousness of those orders when they're given by Mr. Potato head.

Don’t do ad-based marketing.

Your game probably only costs a buck or so, so you’ll probably end up paying $10 to make a $1 in sales. It’s ok to do do cross-marketing however, e.g. between your games, which doesn’t cost you a dime.

On the 8th of October I paid 5.29e for 23 clicks. You're going to need some crazy conversion rate and a product which costs more than $1 if you're going to make that marketing money back

In-game ads make for a poor income unless you have hundreds of thousands of players

You want to risk annoying your players for a few measly cents? You can annoy them when you can afford loosing some of your player base.

That's a YEAR'S WORTH OF AD REVENUE from Theseus. It's all gonna go to finance my extravagant lifestyle. I'm practically rolling in moolah.

A proven concept on platform X doesn’t mean it’s going to be a hit on platform Y

Sometimes it’s just how the stars are aligned. Sometimes your version just sucks.

You may have the first pacman on some device, it still might not make a difference.

Updating each week will boost your downloads temporarily

I have simply not found any other easy marketing technique to be as effective.

Visitors to Theseus. Each one of those peaks coincide with an update to the game.

Do it for fun

Chances are it will never make any substantial sales, so treat it as a hobby. Those cinderella stories about devs striking it rich are just that – cinderella stories.

Just me and my computer on a Saturday night hacking away. Fun.

Don’t re-invent the wheel, or the game engine.

Check out AndEngine for instance. You’ll save a bunch of time.

Thanks Clippy!

Pimp out your game whenever you can

It’s not going to make much of a difference but people who don’t know about your game can’t buy your game. Btw. download Theseus and the Minotaur.

Poor applications working for their pimpin' developers.

Use in-game analytics

You’ll want statistics about your game usage.

That's a black box. That's how much insight you'll have about your game usage without in-game analytics.

Retention matters

Old players of your game are your best source for word-of-mouth marketing. You can achieve better retention by for example adding new levels regularly. In free versions if you don’t want to add more levels you could for example switch which levels are available for free to re-activate old potential customers.

Word of mouth marketing in action. The tobacco industry has great retention among its consumers.

It doesn’t hurt to have lovable characters

If your game doesn’t have characters consider adding some and make sure they have some personality and are memorable.

The marketing-droids at Nintendo knew what they were doing when they unleashed this yellow cretin upon the world

Cram out several games

Your first game is probably gonna be a dud. If your game doesn’t seem to be picking up and developing it is become a chore, then just cut your losses and move on to the next project. The more games you make the better, faster, leaner and meaner you will get.

It's the episode of Lucy when she was working in the android app factory.

Prefer game concepts which have a fast development time

A role playing game is going to need a lot of story and a lot of graphics, and a lot of your time. A game in which the player tries to beat his own high score won’t be infinitely time consuming and might still be a bigger hit.

Developer, choose your fate!

Thoughts? Go ahead and comment.

I’ve done my own random software projects now and then and the last few years my interest had shifted to products that could make some dough. I had often taken ideas to the implementation stage, but most of these projects ended up fizzling out due to lack of motivation, becoming cute tech demos in the corner of my hard drive or in a forgotten code repository. In spite of that I was getting that urge to create something of my own again.

A MOBILE FUTURE NOT TOO DISTANT

I had read about the fortunes some lucky developers had managed to make on the AppStore, but the real gold rush seemed mostly over. On the other hand the Android platform was gaining traction and it had a serious lack of fart applications; and I reckoned those fart applications needed developers. I had a crappy old Symbian based Nokia phone and thought it might be time to get one of those new fangled smarty phones. The iPhone was only available from one operator (not mine), and developing for it required a Mac, which was an even steeper investment. This made me hop on the Android bandwagon. I ended up scouring an auctioning site for an HTC Hero and on the 28:th of February 2010, I had the winning bid on a white HTC Hero. In the beginning of March a package of used mobile electronics had arrived much to the glee of a new owner.

The horse sticker wasn't included. I had to accessorize it myself.

Soon even your grandma will be ruled by a smart phone overlord

I played around with the Hero – and compared to my Nokia it was night and day. I came to the conclusion that these smart phones were going to be our overlords very soon. We’d be fiddling with these buggers updating our tweetbooks, fouring our facesquare, reading, chatting and playing on the go. In fact I concluded the gold rush was far from over, it was merely beginning. It wouldn’t be over until most people were conducting most of their online time on their phones. I don’t know where we’re now, but if we’re not there yet I think it’s pretty safe to say we’re getting closer.

LOSING MY MOBILE DEVELOPMENT VIRGINITY

All hyped up about mobile development and with an old-new android phone I was ready to jump in. First off was the perpetual “hello world” application. This was a crucial moment in determining if I was going to develop anything at all for Android. Any hiccups in the install and setup of the sdk, or the deployment of the first application which would require hours of troubleshooting is usually a decisive motivation killer. Surprisingly I had none of those problems. It was an easy setup and painless to get that “Hello World” application running on the phone. This first hurdle was a breeze.

On the left: Snake. On the right: What puts bread and butter on the table - the three tier architecture.

I started playing around with the example projects. There was a Snake game which had a tile based graphics engine. It was simple enough for me to comprehend. I say simple enough for me comprehend due to the fact that I almost exclusively do “enterprise” software. That means a lot of backend java and some not so snazzy web-based or desktop-based front-ends. Many of my spare time projects were graphical in nature, but it paled in comparison to the pile of experience I had in database based applications and the likes.

So I picked the game engine for Snake apart and for the heck of it started making a turn based puzzle game I had played many years ago. I chose it since its logic was easy enough to be a suitable programming challenge. In a couple of evenings I had a rough playable prototype. To move my character on the screen I had to use the trackball. It moved without animation one tile at a time, and the game only had one level. It lacked a touch interface, animation, graphics and generally a lot of work, but it was playable and that really motivated me. I figured this might as well be the thing I develop since I liked the game and I had made it this far already, but it wasn’t an original game and I didn’t have a clue about licensing and such.

The Java applet of Theseus I had played years ago

SEEKING OUT THE DESIGNER

The name of the original game was Theseus and the Minotaur. I had played a java applet based version years ago during my studies. I remember stumbling upon it when I was searching for algorithms on maze generation, which I probably had some fine reason to do. I remembered that the original designer had a web page about puzzle games of some sorts and it was pretty easy to find it – Robert Abbott’s page about logic mazes. I think he had created the game back in the 80s when it was played with pen and paper.

Yesteryears gaming device

PopCap's take on Theseus and the Minotaur: Mummy Maze

The web page had a section of different implementations of Theseus. Here I noticed someone had already made the game for the iPhone among other platforms. Then it dawned on me that I hadn’t even checked if it existed for the Android. It didn’t, not by the same name at least. I googled around and turns out the game was more popularly known as the Mummy Maze. A game popularized by PopCap. I was a bit discouraged at first since I wasn’t about to be the first to rekindle this old puzzle. A lot of people had beaten me to the punch, a bunch of times, on a bunch of different platforms. The iPhone version had been a success though, and the Mummy Maze seems to have been quite successful as well. That meant that I wasn’t the only one liking the game and if I could make it for the Android I’d have a proven concept for that platform.

I e-mailed Robert on the 13:th of March and asked him if it’d be ok to create a version of Theseus on the Android. A few days later he replied that he’s been waiting for someone to bring it to the platform. We agreed on some license fee based on sales and I was happy to have the support of the original designer.

I had a successful formula and the exclusive rights for bringing it to the Android. This was promising.

YOU WILL PROBABLY FAIL

A picture of Android's thriving market back in 2010. The tumbleweed there is probably a free low quality application. Worst analogy ever but I'm not giving it up

Searching for information I found a lot of foreboding warnings of how nobody was making money on Android Market. There were no paying customers and a majority of applications were free.

It didn’t really detract me. Nobody was making money now but by the time I was about to release it might be gold rush time. Besides, most of the apps seemed of really low quality and I wouldn’t have paid for them myself. I was going to deliver something more polished than the standard fare.

THE BRUSH STROKES OF A LESSER ARTIST

iPhone Theseus. This is either some obscure reference to greek mythology or two marbles on a chessboard covered in matches

The game’s mechanics were so simple it didn’t take me too long to get the first rough prototype ready. Thus far I had been using the same tiles as in the Snake example that came with the Android SDK. For inspiration for my own graphics I was lucky to be able to sneak peek at what the iPhone developer, Jason Fieldman, had done for his iPhone version of the game. He simply had some pretty looking marbles on a checkered board, so I went the same route. It seemed smart – simple and suited for a small screen.

Theseus on the Android. Admittedly not as pretty as its iPhone sibling

I like drawing with pen and paper but doing it on a computer is not my forte. Regardless of that I downloaded a trial of Photoshop and followed an on-line tutorial on how to make a glass ball. It looked like shit. Frustrated and tired I gave up on Photoshop. A couple of days later I downloaded an Illustrator trial – and by editing some pre-made symbol of a blue marble I made the blue ball that became Theseus. I copy/pasted this and made another red one with horns representing the Minotaur. Then I made different color squares with gradients to use as the checkered board. This took me the better part of a whole evening of which most of the time went to learning Illustrator. However, I would tweak the graphics several times later on; obsessing over the right shade of blue, if it’s the correct size, if it’s too shiny or if the Minotaur should have straight or curved horns.

At some point I stopped and decided to be content with the graphics. The unnecessary gradients on the squares were probably distracting and the color choices might’ve not been the best but I didn’t see major improvements to make. I decided they were good enough for a puzzle game.

What turned out to be the darker side of graphics productions was to convert the vectors into correctly sized bitmaps, create two or three different resolutions of each image and save them as PNGs in your project’s resource folder. That’s stuff you should automate if possible; and I never did. This conversion was so tedious and boring it became the biggest hurdle to improving the graphics.

RESOLUTION INDEPENDANCE

Android phones come with different resolutions, so I made sure the graphics scaled to maximize the usage of the screen, which is why I needed different resolutions for my graphics. If I programmatically scaled an image too far away from its original dimensions it’d end up looking all jagged and crappy. In addition to that some levels were wider than taller so I wanted it to be possible to put the game in landscape mode. This would play well with my auto-scaling graphics that would just re-scale itself whenever you flipped the phone. On-screen controls seemed like they’d waste valuable screen real estate so I skipped them, which spared me having to worry about how to lay them out according to level size, resolution, portrait and landscape mode.

THE INTERFACE AND HOW TO USE IT

Without on-screen controls the game only offered trackball and touch screen swipes as input methods. This made for a more challenging learning curve since there wouldn’t be any obvious buttons to press on the screen.

Design your UI so even someone with the attention span of Homer could play it.

Whilst play testing the game with friends I got fed up with having to explain how to play the game, so I realized I had to put some effort into making a good tutorial. First I mistakenly used the “wall of text” method. I had a tutorial level where the player who walked through it got long click-through instructions. A minority of the players read them and the rest just clicked them away, ignoring any instructions, and subsequently getting stuck. To them it just seemed like a click-through EULA.

So I ended up splitting the instructions up and made sure the texts were as short as possible. That helped a bit, but what really made the difference was putting a colorful picture beside the text. I guess the pictures made the instructions more inviting.

Left: Wall of Text == Bad. Right: Short Illustrated Text == Good

KEREBUS – THE FACE OF MY IT-VENTURES

My startup advisor was an avid collector of bargain radios

I was well under way with development and was seeing light at the end of the tunnel already in April, which I happily told Robert as well. I hadn’t figured out what I had to do to be able to sell the game though. There were two big question marks. Did I need to register a company – and how was I going to sell the game; since selling applications hadn’t been enabled for Finnish citizens yet.

In Finland you better have registered a company if you were going to make over 8500€ in sales a year since you are then required to pay VAT on sales. Well I figured there might be a small chance I’d make that dough in 2010 so I concluded that I better register a company before releasing the game. I went to some informative meeting here in Helsinki on founding a company that was ok, but it didn’t answer many of my questions. I was able to reserve a one-hour session with a free startup advisor of whom I had planned to ask about contracts and taxation. The advisor was a gentleman at least 60 years old, and I guess he did these advising gigs on the side of retirement. I think in the one-hour session I had with the advisor I got 15 minutes of useful information, which was mostly about how to fill my form for founding the company. On the tax and contractual issues he couldn’t answer anything but refer me to some random lawyers, neither who seemed like experts in the subject matter. The rest of the time he spoke about his hobby of collecting radios. That’s a good 45 minutes talking about radios. They weren’t antique radios or rare in any way. They were just radios he’d gotten at a bargain price. In fact it was the bargains he was actually collecting. All in all I think I got my money’s worth from this advisor since it was free, and he got to talk about his radios.

At the end of May I paid a 70€ registration fee and submitted the form for founding my company- Kerebus.

THE INTRICACIES OF INTERNATIONAL TAX LAW

Laprohaig. Relatives, this buys you the best IT support

During learning about starting up a company I was also investigating the issues with selling the app. Since I wasn’t able to sell apps on Android Market as a Finnish citizen back then, I had to have someone outside of Finland sell it for me. Plan A was to sell the game through a friend in Germany where Google had enabled commerce. I probably spent a month on figuring out tax law and how I should bill the reseller of my game. I gathered I could look stuff up in books as well as any lawyer or accountant. I did end up uncovering most mysteries by myself but without being able to reaffirm my conclusions I felt like I was on pretty shaky ground. Finally I remembered that my uncle, whom I had helped with computer troubles in past years, was in the accounting biz. He usually gave bottles of whiskey for the computer help but I figured he owed me anyway since it wasn’t single malt. He didn’t know the answers himself but asked some of his accounting friends who emailed me the answers.

One of the peculiarities was that for the license fee I was going to pay Robert I had to pay 23% inverse VAT to the Finnish government. It all seemed bizarre and utterly demotivating. Tax law had been one of the most uninspiring subjects I had ever studied and I’m happy to forget anything I learned. I’ll refer to an Einstein quote, “Never memorize what you can look up in books”, either that or get someone else to do this soulless work for you.

Tax Law - that's why I look this awesome.

Anyway. It turned out my friend in Germany was to move back to Finland so I had to go with Plan B – sell through one of Robert’s acquaintances, Yann, in the US. This turned out to be favorable decision since the taxes in the US are more straightforward and considerably lighter compared to Finland or Germany. I could also organize for him to do the license payment straight to Robert within the US so I didn’t have to pay the inverse VAT.

THERE’S NO GAME WITHOUT LEVELS

With the boring issues of company and reselling resolved I could concentrate fully on development again. I was getting close to ready but was lacking levels. The other versions of the game had 87 levels, all of which were designed by Robert and some other guys I gathered to be some hard core puzzle aficionados. It was agreed that I could reuse the original 87 levels – this way I didn’t need to design any new levels for the initial release of the game. I had a text-based format for defining the levels. I painstakingly defined a couple of levels by writing wall coordinates by hand into a text file before deciding I had to make a level editor.

Making a level editor was easier than I thought, well worth the time put into it. I coded the first working revision of it during a 4-hour train ride from Helsinki to Vaasa. I made it a Swing/Java app. I hadn’t used Swing for some years but turned out it was just like riding a bicycle – a really ugly bicycle.

The level editor. Ugly but gets the job done.

So what I did for the original levels was to draw them in my level editor and export them into my text format. I also made a couple of my own levels so I could be among the level designers.

SIGN YOUR NAME IN E-BLOOD HERE, HERE AND HERE

For any contracts I was recommended to get a lawyer by our good startup advisors in Helsinki. So as usual I disregarded the sound advice of Mr. Bargain Radio and skimped on the lawyers. Instead I used one of Robert’s old contracts, which he had signed with some Spanish dude who had released a board game in Spain based on one of his designs. I used it as a template and just changed the names and tweaked the text to suit our situation. Afterwards I emailed this to all signing parties and defined that by replying “I AGREE” to the email they’d agree to the terms. Emails are considered binding contracts in most European countries and the U.S.

OH YEAH, I WAS SUPPOSED TO RELEASE SOME SORT OF GAME

Initially I had told Robert I’d probably release in April. If I started in mid March that means that I would’ve made it from inception to release in about a month and a half. It was now August, which meant I had blown up the original time budget by a considerable amount. The development probably took a bit longer than expected, but my insistence on founding a company and figuring out all the tax issues beforehand set me back significantly. I also had my month long summer vacation, during which I was supposed to code, but I ended up enjoying the summer instead. Good for me.

So on the 14:th of August the game got released. The release itself was fairly uneventful. Straight after release I got a pre-paid UK sim card from Ebay, luring Android market into thinking I was a UK citizen, so I could buy my own game. According to Yann (the reseller) I wasn’t even the first buyer, someone else in Massachusetts had paid top dollar to buy my game before me. The free demo version, which I released simultaneously, was getting 10, even 20 downloads a day. It was all rather exciting.

The excitement faltered when I realized the amount of downloads was always 10 to 20 a day. I couldn’t follow the exact download count of the pay version since Yann was publishing it, and I didn’t want to bother him with update requests too often. The download count on Android market stayed below the ”

GUERILLA MARKETING

To boost downloads of the game I thought I’d do some guerilla marketing. I tried mentioning the game in the comments of some blogs and game sites, but it didn’t do much except make me feel like an idiot.

“Have you checked this super puzzle on android. It’s called Theseus and the Minotaur!”

I don’t know if that’s the kind of stuff other guerilla marketers do, but to me it seemed moronic.

The alternative app markets at the time had a low number of users. SlideMe was the only one where I got any significant downloads of the ones I tried. GetJar is supposedly a bit bigger too but I managed to miss that one. I did try to submit the game to some review sites; but no one picked up on it. My negligible marketing effort didn’t have any effect as far as I could tell. I knew I had to get my app out there somehow but I preferred to do coding. I read somewhere that when a programmer has a problem he tries to solve it with more programming. I feel I fell into this category. I knew I had a marketing problem but instead I preferred to refractor my code, tweaking features X and Y, and adding feature Z. I knew this wasn’t addressing my main problem but I did it anyway.

MY TIME AS MICHAEL WINSLOW

So the game was out. I had released much later than planned but I still considered it an early release since it lacked a lot of features, like sound.

Michael Winslow of Police Academy

Sound seemed like the least important feature in a turn based puzzle game. It’s almost always the first thing I go turn off from an options menu, but a couple of people had asked for it; and I wasn’t getting much feedback. So I made sound effects that I felt would improve the user experience. Something distinct when you die, escape, wait a turn and so on. First I tried some free online sound libraries, but they didn’t have anything fitting my purposes. I ended up recording all of these sounds myself with my own voice. I used Audacity for the recording and post processing of my sound clips. A bunch of “Whee!”, “Munch munch munch” and *Click*.

Whee!

Sound did make the game experience more engaging; and I could probably add more of it and maybe even some sort of optional music in the title screen.

“JUST IN” MARKETING

It didn’t take me long to discover that updating the app lead to a spike in downloads because you got to the top of the “Just In” list. However, you could only jump up to the top if it had been a week since your last visit there. With an unknown app you’d get 90% of your downloads from being in the “Just In” list once a week. So in the early weeks and months I kept upgrading the game actively. Later on I just kept churning out a couple of levels each week.

The effect of being in the “Just In” list is of course a well know fact which the developers of Sex Tips, Trivia Games, Sexy Girl Wallpapers and so on know very well. Curiously these guys find some meaningful update to do every week in their dozens of template-based applications.

I can't wait to see what the next update to Sex Tips holds

The optimal time to be in the “Just In” list seemed to be during Sunday evenings. That time slot will give you double the amount of downloads compared to a weekday. I don’t know if this is because the Sex Tips developer and others only do releases during weekdays and don’t spam out other apps or because people like to play games on Sunday evenings. Might be both.

The amount of downloads you get by being in the “Just In” list has decreased remarkably since August 2010. I guess the competition is getting tougher.

CLOSING THE FEEDBACK LOOP

I was following the download stats daily and updating the game in response to the little feedback that I got, but I didn’t really know if my changes had any effect. The download stats don’t really give you much insight. You know that someone downloaded it but don’t know if they even played, for how long or which level they spend most time on. You don’t know if you’re retaining users. I stumbled upon Google Analytics for Android and integrated it with the game. I also noticed Flurry later on and I might’ve chosen that instead had I known about it.

Visitor statistics. The peaks occur right after updates to the game.

You can program your app to collect events and it’ll send them back to Google Analytics at a set time interval. I was able to see which levels were the most played, what functions the players used the most (e.g. restart and hint), how many minutes or seconds they spent in the game in average, resolutions of their phones, bounce rates etc. All kinds of stats which you can overanalyze, but at least you have something to go on.

It made the game development sort of a game in itself where the aim was to improve the right numbers.

NOW A BLURB ON PAID MARKETING

At some point I got a 75€ voucher for Google AdWords so I decided to try it out to market my game. I might’ve screwed it up somehow, but targeting only android platforms and doing display and sponsored search results had no effect at all. The Cost per Click ended up being something like $5 which is way more than what the pay version costs. I suspect AdMob might be more effective (but I haven’t received a voucher for this yet *hint* *hint*).

RETENTION

I kept adding levels to get into the “Just In” list, but I had mistakenly also helped retention – i.e. the game’s ability to keep old players interested. I realized this when I read this blog post which included a video with some Angry Bird guy. He was saying they keep updating Angry Birds to keep the old players interested. I made it a point to include new levels in updates for both the pay and free versions of the game regularly since.

PUTTING CHARACTER INTO MY CHARACTERS

This angry bird made me want to make my minotaur angry too

2010 rolled into 2011 and the game hadn’t really taken off. I had developed all the features I believed would make a difference already and was mostly adding levels now. The one thing that bugged me the most was the graphics but I didn’t know in what direction to take it. Not until I was watching another video with some Angry Bird guy again explaining how they built their game around their characters. I decided that was what my game lacked the most. My characters were glassy balls and nobody could relate to such inanimate objects.

I fired up Illustrator again. This time around it wasn’t that painful to create stuff since I knew how to use the tools. I still wanted my graphics to be simple so I still went with circles for characters, but this time I gave them eyes. I also wanted the graphics to look cleaner so I got rid of some gradients, which in my opinion improved it considerably.

The minotaur got meaner and Theseus gained eyes.

Since Theseus now had eyes I added some minor sprite animations to Theseus so he could blink and fall asleep. Making changes to the graphics, which there is much more of now, is as tedious as ever.

THE STATE OF THE MINOTAUR

So it’s over half a year since the first release, and over a year since I started this venture.

The free version of the game has 17556 downloads right now, 4378 of which are still installed (24%). The pay version has been bought somewhere in between 100 and 200 times, although most certainly closer to 100. The price is at $2.55 currently.

I estimate that less than 1% of the people who download the free version will end up buying the game. 163 people have rated the free version of the game on Android Market, which is also about 1% of the people who downloaded it. Currently it has 4.23 stars out of 5.

Sleep tight

The AdMob ads in the free version, which have been there for 4 months, have yet to make $10. The total revenue of the paid version should be between 250 and 350 dollars, of which Google takes 30%, and Robert and Yann get their shares. The rest is subject to Finnish income tax. Not that it matters with these sums. But it’s safe to say that reaching the 8500€ (about $12000 currently) for which I had to register my company was a pipe dream.

The game has received 18 updates after the initial release including bug fixes, tweaks, sound, hints, animations, new graphics and 56 new levels.

This isn’t meant to detract anyone from creating apps. This might be a commercial failure but I wouldn’t have kept this up if I didn’t enjoy doing it. As for any problems you encounter you just shoot them down one at a time and go forward.

WHAT’S NEXT

What now? I don’t know. I’ll probably keep on adding levels. I have some improvement ideas but they probably won’t result in any tipping point. I could have another jab at marketing though – like writing a blog post about my experiences developing the game. It’s worth a shot.

There’s a Statistics link just below the download and active installs numbers which will open up a more detailed statistics view.

Seems like they started collecting data after mid-december because that’s how far back the statistics for Theseus goes.

I never really figured I needed characters, since I classified this game in the same genre as chess or some such. Chess usually doesn’t have real characters (which laugh or cry). Then again Theseus is a bit less known than chess (just a hint). Having good characters shouldn’t at least take away from the game.

After a week I haven’t seen any difference in downloads, but maybe a slight decrease in bounce rate. The people I asked liked the direction of the new graphics and no one has complained thus far.

Old

New

To see more just check the screenshots on android market