Text game v1

View the raw code:

Try it out:

<!DOCTYPE html>
	<script src=""></script>

Ok. I want to make a text based game in the browser.
You could do that by linking regular static pages together, but where's the fun in that.
We want to emulate that semi-terminal experience with monospaced fonts, command parsers and stuff.

So first off I need a place to output text and somewhere to input it.

<div class="terminal-window"></div>
<input class="command-input" type="text"/>

Booyaah! We're hackers!

So I want to build some sort of text based world; made of rooms with descriptions which I can walk around in.
So I think:

function Room(opts) {
	this.description = opts.desc;

Supers! Now I can create funky rooms.

var livingroom = new Room({
	desc: "Really nice livingroom. There's a tv and all!"

var bathroom = new Room({
	desc: "You're in a bathroom. Some people come here to poo."

Then we need to be able to link these together too. 
Something like roomA.addExit('exitName', roomB);

function Room(opts) {
	this.description = opts.desc;
	this.exits = {};

Room.prototype.addExit = function(exitName, room) {
	this.exits[exitName] = room;		

var livingroom = new Room({
	desc: "Really nice livingroom. There's a tv and all!"

var bathroom = new Room({
	desc: "You're in a bathroom. Some people come here to poo."

livingroom.addExit("bathroom", bathroom);
bathroom.addExit("out", livingroom);

Having the bathroom next to the livingroom isn't completely wise but this is a game, we can do anything!

To track in which room we are; let's say there's a var called currentRoom.

var currentRoom = livingroom;

Ok. Think we have enough data to make this playable somehow.

We want a 'look' command which displays the room description and its exits.
In addition we want each exit name in the room to be a command which takes us into that room.

We want to take the user's commands from the '.command-input' element, parse them and react to that.

I guess we can represent a command as a function.
On enter keypress we should execute some sort of command parser which returns the command function.

To output stuff into our "terminal window" we'll create a "print" function.

var $terminalEl = $('.terminal-window');
var $inputEl = $('.command-input');

function print(msg) {
	$terminalEl.append('<div class="msg">' + msg + '</msg>');

function parseCommand(unparsedInput) {
	if (unparsedInput === 'look') {
		// The "look" command
		return function() {
			var msg = 
				'<div class="desc">' + currentRoom.description + '<div>' + 
				'<div>Exits: <span class="exits">' + currentRoom.exitNames().join(', ') + '</span></div>';

	if (currentRoom.getExit(unparsedInput) !== null) {
		// The move command
		return function() {
			print('You walk into the "' + unparsedInput + '" exit');
			currentRoom = currentRoom.getExit(unparsedInput);

	// The "unknown command"-command
	return function() {
		print('Unknown command: ' + unparsedInput);

function init() {
	console.log('Initing js code');

	$inputEl.keypress(function(e) {

		if (e.keyCode !== 13) {
			return true;

		var unparsedInput = $inputEl.val();

		console.log('Parsing: ' + unparsedInput);

		var command = parseCommand(unparsedInput);


		return false;


Won't work yet since we're missing exitNames() and getExit(exitName). 
Uno momento.

Room.prototype.exitNames = function() {
	return $.map(this.exits, function(value, key) { 
		return key; 

Room.prototype.getExit = function(exitName) {
	if (!this.exits[exitName]) {
		return null;

	return this.exits[exitName];

<p class="help">Here's some help to get started, try typing 'look' and pressing enter.</p>

Let's add some styles to make it a bit friendlier to your eyes
and more terminal-like.	
.terminal-window {
	width: 600px;
	height: 400px;
	overflow-y: scroll;
	font-family: monospace;
	background: black;
	color: #cfc;
	padding: 5px;

.exits {
	color: white;
	font-weight: bold;

.command-input {
	width: 605px;

.msg {
	padding-bottom: 10px;

View the raw code:

Try it out:

Canvas vs SVG

I need to create some sort of interactive map. So I did a quick investigation of canvas and svg stuff and thought I’d document my findings. I am by no means an authority on these matters, and my knowledge is based on an evening on reading/trying stuff out. Mostly I’m summarizing stuff I read elsewhere.

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:

Browser support?

Canvas is usable since ie9, most other moderns browsers seem to support it:


For ie<9 you may try excanvas:
Supposedly it can’t simulate the api 100%.


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:

The top five canvas libraries according to github watchers are:


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:


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.


  • 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.


Trying out Redis with Java

I decided to take Redis for a spin on Sunday.

Redis is a key-value store and much more. For some good Redis use-cases read:

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

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://

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

Or browse the github repo here:

For more info about Jedis, check:


So Scan-Agile is coming up on the 8:th of March.
I’ll try to forsee what I’ll go watch from


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


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


Olaf Lewitz:

Agile Community Building – Using StrategicPlay with Lego


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!


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:

Stuart Eccles

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


Daniel Knott:

Mobile App Testing – Challenges, Solutions and Best Practices


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.


Chris Matts:

Feature Injection

I’m not quite sure what feature injection is, but I found this comic:

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


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


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


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 :)

Old Map of Helsinki Overlaid

Earlier today I got this obsession of overlaying an aerial view of current day Helsinki over an old map from 1837. I had to rotate and skew the pic to get a better fit and here’s what I turned up with:

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


Analyzing a Tech Book: Android Wireless Application Development


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.

Book Review: The Clean Coder

Just finished The Clean Coder by Robert C. Martin. The predecessor, Clean Code, was one of the best books on programming I’ve ever read so the expectations for this book were high.

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.


Amateur Android Game Development Tips

I’ve been meaning to write a summary about the feedback I got to my post about being an amateur Android game developer. It was mostly collected from reddit comments, hacker news comments, and comments on the blog post.

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.

My Year as an Amateur Android Game Developer

Back in February of 2010 I was coding in the offices of our customer – a semi-big Finnish company. It was interesting from a technical perspective, but the project had changed directions about half a dozen times in the past 6 months. I guess it lacked someone with some backbone to lead it according to one vision. Instead they were bending over to anyone with an opinion and we had a veritable software Frankenstein on our hands. Despite being a neat programming challenge the product itself was a mismanaged collection of random features in which my own faith was close to zero. It’s at times like these you start looking elsewhere for something that would bear more meaning.

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.


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.
Continue reading

Android Market Publisher Console Now Comes With Stats

Google has enabled more detailed statistics for all android applications.

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.

« Older posts

Copyright © 2015 KEREBUS

Theme by Anders NorenUp ↑