Saturday, December 28, 2013

Game review: Little Inferno

I'm sick of casual games. Do repetitive stuff to get coins/stars/points. Spend points to get better equipment. Continue doing more repetitive stuff. After the first five minutes, they aren't fun at all. Games with in-app purchases are particularly bad, as they force you to do the same mindless chores again.

A few months ago, I had purchased a game called Little Inferno but I only just got around to playing it. It is brilliant. Estimating by the game content, I have played one tenth of the total game. Made by the same people who made the World of Goo, it is as enjoyable as my experience with the World of Goo.

The basic concept is boringly simple: you have a fireplace and you burn things. That gives you coins, with which you can purchase other things. But in a crazy twist, there are no in-app purchases. You get more coins when burning your things, so your cash keeps growing. Even if you somehow run out of money, there are small bugs that will give you coins for free. It gets even twisted...

There is no aim, there is no goal. You never lose.

You play for fun.

There is some story-line in the game, but that doesn't keep you going. What keeps you going is that this game is fun. You burn stuff, and it does interesting things. Sometimes burning things together does interesting things. It is difficult to explain why anyone would want to play it. Ever threw something in a camp-fire to see what happens? Well, this game is like that. You burn stuff, then head to your catalog to see what else you can burn. You could be done in five minutes and stop playing. Or you could burn stuff for hours. Either way, you get calm and enjoyment. That sets it apart from a significant chunk of the games already.

This game does two things which are remarkable. First, it has a commentary about the state of the world that unravels as you play it. I'm far from the finish, but the hints till now suggest an interesting message about the world we live in. The game is also a hilarious look at casual games, and how inane casual games have become. If it were that alone, it would be a gem. However, more importantly, this game is truly funny. The things you get are funny. The way they burn is funny. As it proceeds, the game introduces you to more elements. The instructions are funny, the in-game characters are funny.

Why must games be about the same boring concept? Why are half the games about being a soldier -- fighting or shooting? Computers are limitless: games should experiment and develop their own message and goals. How does it feel to be a honeybee? Maybe a game should allow you to find out.

Little Inferno is available from their product website. For the next two days, you can buy the Humble Bundle which includes Little Inferno. Runs on Linux, Android, Mac, Windows, toasters, ...

It is surprisingly, funnily, engagingly good. Now throw this review in a fire!

(Thermometer courtesy: Sugar Plumps)

Wednesday, December 25, 2013

E911 testing

A few months ago, I was working on a component that interacted with the Enhanced 911 dialing on a mobile platform. 911 is the emergency telephone number in the US for medical and law enforcement services. Other countries have something similar, like 112 in the European Union.

When I was developing my feature, I had to test out 911 functionality to ensure it was still working. My hope was to substitute the emergency number with something safe, like the number of my spouse. That way, I could call my fake emergency number without actually bothering the police.

I found that there are special requirements placed on mobile platforms for emergency dialing. Even if a GSM device does not have a SIM card, 911 dialing is required to work. An encrypted device does not have to be decrypted for 911 dialing to work, etc. Perhaps to ensure that the strict requirements are met, 911 dialing is handled directly by the telephony chipset. A mobile platform has little control over how 911 dialing works.

So, my testing plan wouldn't work. I would be forced to call 911. The real emergency number. Repeatedly. Now that was a scary thought. I had called 911 only once before that, for a true emergency. I wasn't looking forward to calling the emergency operators. When calling emergency operators, it is inadvisable to hang up immediately. This is for your own safety: you could be in a life-threatening situation. So 911 operators usually call you back or route the police to your location.

I developed a script that I would read out. The basic idea is to convey the following ideas as quickly as possible:
  1. It is not an emergency.
  2. You are an engineer testing stuff.
  3. This is your job, a routine matter for you.
  4. You are happy to be placed on hold.
The last part is important. 911 operators handle life-threatening emergencies all day and all night. They need to prioritize the events and dispatch them as quickly as possible. You want them to put you at the bottom of their priority list.

Here was my full script, which I now know by heart:
Hello, this is not an emergency. I am an engineer working at <company> testing out 911 functionality. Please tell me when to hang up.
While it is only three sentences, I am proud of my writing. The script conveys all the important points. It eliminates words, saving time. Instead of saying "Please let me know when it is safe to hang up", I chose a much more bland "Please tell me when to hang up." It avoids the tricky word safe, which could be misinterpreted to mean that I am in an unsafe situation. It introduces tell me to convey that I am at leisure to be instructed by the operator. Said in a calm and mechanical voice, that script accurately conveys my low rank in their priority list and my very routine intent. It lets the operator know that I am completely safe, and awaiting their instruction. I debated whether I should waste time with a Hello. Saying hello makes the conversation calm and highlights the lack of emergency. Removing it saves a second. After some thought, I kept it.

Somewhere around my second sentence, the operator would cut in and speak, "Please hold" and put me on hold.

There was no wait music.

I don't remember how long I waited, it was well over ten minutes on most calls. It was rare for me to finish all three sentences. On exactly one occasion, the operator listened to my entire script, and then said, "What do we do now?" I replied, "That's it. Please let me know when I can hang up." The operator allowed me to hang up, and we were both done.

On most calls, I was placed on hold.  I would hold the phone very, very patiently. I couldn't hang up, and I couldn't get distracted with something else. In addition, my phone had to stay charging because running out of battery would hang up the call. I couldn't attend a meeting or talk to a colleague. I couldn't go to the bathroom to relieve the stress of calling 911. On my first few calls I was tense. I was worried that I would do the wrong thing and cops would storm into my office building. Luckily, I didn't mess up. After calling them over a dozen times, these calls became routine. The stress involved with calling 911 for testing never went away though.

The operators were always calm and professional. They have to quickly evaluate the emergency of each call, determine the appropriate course of action, and move on to the next call. They don't have time to smile. They don't have time for pleasantries. During the testing, I developed great respect for their capacity. It must be a frustrating and stressful job: dealing with one difficult situation after another. Yet, they were calm, professional, and direct.

After I was off hold, the operator would sometimes quiz me on the nature of my testing. Sometimes they would ask what else was required of them. I was only testing outbound 911 dialing, so I required nothing else. After a polite and serious "thank you", I would hang up. I don't recall the operators ever thanking me or saying bye-bye. Like I said: no time for pleasantries.

My office-mates would perk up when they heard me call 911. It was a serious matter for everyone. Frankly, they were glad it was me making the calls and not them! For my part, I tried making the calls when the office was quiet and empty.

During the development of my feature, I called 911 frequently. I have lost count of how many calls I made. When the feature was done, I was glad to be done with 911 testing. It is one part of my software development I won't miss.

Qt Creator: a superb IDE for Linux

I learned programming in school with an ancient IDE: Turbo C++. I never got over the idea: the command-line is great for productivity, but there are times when you just want to explore. An IDE feels just right for such recreation. You can poke around and learn the environment. I developed an itch to test out a C/C++ IDE a few weeks ago.

Many people recommend Microsoft Visual Studio Express, and there is a free version for Windows XP. I spend most of my time on Linux machines so it would be a lot more useful to develop for Linux. In addition, my Windows XP machine is anemic compared to my Linux desktop. So I began looking for a good contemporary Linux IDE. Anjuta and QT creator both get good reviews. Anjuta was built for Gnome development, while QT creator focuses on the Qt toolkit. I am unfamiliar with Qt and have wanted to explore it, so I tried QT creator.

...and I found that QT creator is impressive! You can navigate to their web page or their Wikipedia entry to learn more. In short, it is a one-stop shop for project development, debugging, inspection. They have detailed tutorials through which you can learn the Qt toolkit. You can debug right from the IDE, inspect variables, set breakpoints.

My favorite feature is the integrated assembly debugging. You can get the disassembled output and step over an instruction at a time. You can view registers and it will highlight the ones that have changed after each line gets executed. This is a great way to learn assembly. The code is interspersed with assembly instructions. Even comments are included in the disassembly so you can find your way around. Now I wonder if we could install Qt creator on a Raspberry pi and use it to learn ARM assembly directly on the device. Here is a screenshot of the assembly output on the left and C++ source on the right. Pop quiz: what's my architecture?

Good C++ programmers understand what is going on under the hood. The innocuous line " : QWidget(parent)" produces a lot of assembly above because the child class (AddressBook) is initializing its parent (QWidget). Looking at the generated assembly code, you can learn the innards of C++, in addition to learning about your architecture. There are many books on 32 bit Intel assembly but few on 64-bit Intel assembly. So poking at toy examples is a great way to learn how something is implemented.

Qt creator integrates with good source control tools like git, subversion, ... And it integrates with memory analysis tools like valgrind.

This is an amazing tool, highly recommended for casual C++ hacking. Here's the full screenshot. You can click on it to expand the image.

Image courtesy: me.

Tuesday, December 17, 2013

Article about how children perceive pain

This is a brilliant article about how children perceive pain, and how to reduce their anxiety around a specific task. It is from a doctor who needs to address anxiety on a daily basis. From the article, it sounds like he has a great hold of the issue.

I won't paraphrase the article because the real article is much more valuable than isolated soundbites. It is a great read for parents: many difficult spots in parenting revolve around reducing anxiety and establishing rapport.

I am glad I am not a doctor in such a difficult role. I am also a little jealous about how much Dr. Baruch Krauss has gained from his experience. Luckily he can share his wisdom.

Sunday, December 08, 2013

A fun programming book: Land of Lisp

Do you want to read a fun programming book? Grab a copy of Land of Lisp.  Still undecided? Read on.

The recent explosion in programming languages and platforms has led to a similar explosion in books about programming. You can get a dozen books on each of a dozen popular languages: C++, Java, Python, PERL, Ruby, Scala, Haskellapackman.  There is a large variety of books, but I feel all of them miss out an essential ingredient.

None of them are any fun.

Remember fun? When you popped open an arcane book with funny cartoons and typed out a program filled with cryptic letters? And if you were right, the game worked!  You could change the source to see what happened.  That was truly fun: experimentation without an objective. You could imagine a wide expanse of possibility: there was so much a computer could do. Sometimes you typed hundreds of lines, and nothing worked. But that was fun too, in its own frustrating way. Sometimes you figured out how to make it work and felt very good about yourself.

Fast forward twenty years and modern computer programming is a mindless drudgery. Books are all about the techniques: how to combine five libraries to produce an XML parser. How to combine visual elements to make an application for a bank. None of these books would inspire anyone to learn a new language. They are all about how to get specific skills. Boring and dry, these books are made so a career software engineer can learn the buzzwords and stay employed for a few more months.

Learn <language> in 20 days: data types, branches, functions, objects, network programming, advanced techniques. That describes half of the books I see in bookshops.

So amidst this very boring scene I stumbled on The Land of Lisp. This book could be about an arcane and completely useless language and it would still be a lot of fun!  The book revolves around writing games in LISP.  Unlike old books containing BASIC code, the LISP code in this book is well explained and motivated. You can see why the author writes a specific function one way. Little functions are presented highlighting what their purpose is. You are told how to get CLISP and run code inside it. The games are fun! And there are cartoons.

Funny cartoons.
In a programming book about LISP. Hell just froze over.

This book gets you to enjoy programming. It could be written for Java or C++, and it would still be a lot of fun. Because programming, like any other hobby, is a heck of a lot of fun.  You could be a dentist and write code for fun. Isn't that a crazy thought?

To be fair, this book won't work for children. It is quite a detailed look into LISP, and requires a lot of motivation to get through. Children might enjoy looking at the cartoons (my kid certainly does) but they might not understand the intricacies (my kid certainly doesn't). It is like Calvin and Hobbes: a child will enjoy it but not understand a word.

For younger kids, a simpler book would be welcome. I'd love to see more books written in this style.  Let's make programming fun, and kids will learn it without any further incentive. A similar book on BASIC or Python might just work for young children. Yes, BASIC, that language nobody uses because grandpa won't stop talking about it. Well, that ancient language is still a lot of fun for children because children don't care about infix versus prefix, or cyclomatic complexity. They care about doing cool things with a computer. Children want to have fun while playing with their computer.

And while we are hoping, let's see more books like this for adults. I'm waiting for a book on Android programming or C++ that makes it fun!

(Image courtesy: Land of Lisp website)

Saturday, December 07, 2013

Simple program for a two year old child

I had blogged earlier about a program for a one year old.

Since then, my child has started identifying alphabets and has great fun hammering keys on his keyboard to produce letters. He has also started identifying numbers and lower case alphabets. Finally, he has strong preference on the color of the alphabets and the background.

So I present an update for my program, now for two year olds!

The basic structure is the same: it is a full screen GTK program that shows a number or alphabets. A number is shown in the middle of the screen. Alphabets are shown in both upper case and lower case. Finally, stars (an asterisk) is a recent favourite, so I allow typing that one special character. A brown bar at the bottom fills up as sleep-time approaches. This was useful in making the child aware of time: as the bar filled up, night time was approaching.

The full program is presented below.


import datetime, gtk, string, pango

class BigChar():
    """ Create a Gtk window for a single giant textview that accepts all keyboard input. """
    def on_key_press(self, widget, data=None):
        """ Intercept all keypress events and show ascii
            characters. This requires the CAPS_LOCK to be off.  We
            don't intercept CAPS NUM or SCROLL lock, probably
        # Start out by setting the current time
        ascii_value = data.keyval
        # Print the keycode received
        print ascii_value
        changedText = False
        # Lowercase alphabet should be shown as uppercase chars.
        if (ascii_value >= 97 and ascii_value <= 122):
            self.textBuffer.set_text(string.ascii_uppercase[ascii_value-97] + " "
                                     + string.ascii_lowercase[ascii_value-97])
            changedText = True
        # Uppercase alphabet should be shown as uppercase chars.
        if (ascii_value >= 65 and ascii_value <= 90):
            self.textBuffer.set_text(string.ascii_uppercase[ascii_value-65] + " "
                                     + string.ascii_lowercase[ascii_value-65])
            changedText = True
        # Numbers
        if (ascii_value >= 48 and ascii_value <= 57):
            self.textBuffer.set_text("%d" % (ascii_value - 48))
            changedText = True
        if (ascii_value >= 65456 and ascii_value <= 65466):
            self.textBuffer.set_text("%d" % (ascii_value - 65456))
            changedText = True
        if (ascii_value == 65450):
            changedText = True
        if (changedText):
            start = self.textBuffer.get_start_iter()
            end = self.textBuffer.get_end_iter()
            self.textBuffer.apply_tag_by_name("real_big", start, end)

    def realize_handler(self, widget):
        pixmap = gtk.gdk.Pixmap(None, 1, 1, 1)
        color = gtk.gdk.Color()
        cursor = gtk.gdk.Cursor(pixmap, pixmap, color, color, 0, 0)

    def set_time(self):
        """Set the progress indicator to the current time.  The idea
        is to show time in a horizontal access with the morning being
        near the left edge and night being near the right edge."""
        current_time =
        # Total hours past since 6am
        # (Assume Dev wakes up at 6am)
        minutes_past = (current_time.hour - 6) * 60.0 + current_time.minute
        # Minutes are capped at 8am, which is when Dev goes to
        # bed. Expressed as minutes after 6am
        day_end = ((20 - 6) * 60.0)
        if (minutes_past < day_end):
            fraction = minutes_past / day_end
            fraction = 1.0

    def __init__(self):
        """ Create a window with a single giant text view. Disables all chrome.
        # Foreground and background color are read from here.
        background_color = "black"
        foreground_color = "#1133ff"

        self.w = gtk.Window(gtk.WINDOW_TOPLEVEL)
        # No border
        # Take over the entire screen

        # Connect the callback on_key_press to the signal key_press.
        self.w.connect("key_press_event", self.on_key_press)
        # self.w.connect("realize", self.realize_handler)
        # Make the widget aware of the signal to catch.

        # Add a text view to show the key pressed
        textView = gtk.TextView()
        # Disable a cursor in the text view.
        # Show the single character in the middle
        # This is the place we will write the character to
        self.textBuffer = textView.get_buffer()
        # Make the text view huge and bold
        fontdesc = pango.FontDescription("monospace bold 400")

        # Creates a tag that is applied to the text every time
        tag = self.textBuffer.create_tag(
            "real_big", background=background_color, foreground=foreground_color)
        # The progress bar shows the current proportion of awake-time for a child.
        self.progress = gtk.ProgressBar()

        # Make the text view take the entire window
        vbox = gtk.VBox(homogeneous=False, spacing=0)
        color = gtk.gdk.color_parse(background_color)
        self.progress.modify_bg(gtk.STATE_NORMAL, color)
        self.progress.modify_fg(gtk.STATE_NORMAL, color)
        textView.modify_base(gtk.STATE_NORMAL, color)

        vbox.pack_start(textView, expand=True, fill=False)
        vbox.pack_start(self.progress, expand=True, fill=True)

        self.w.modify_bg(gtk.STATE_NORMAL, color)

    def show(self):
        """ Show the window"""
        # gdkWindow = self.textView.get_window(gtk.TEXT_WINDOW_WIDGET)
        # display = self.textView.get_display()
        # cursor = gtk.gdk.Cursor(display, gtk.gdk.BLANK_CURSOR)
        # gdkWindow.set_cursor(cursor)

if __name__ == '__main__':
    # Create a bigchar window, and show it.
    bigchar = BigChar()