Tuesday, May 27, 2014

The death of in-app purchases

In-app purchases for games are dying a slow death. The idea was to give out a free version of the game and charge for the extras. This way you could broaden your userbase by attracting cheapskates, and still retain big bucks from the users who wanted extra.

Entire books were written about this and the idea got a lot of attention. Unfortunately, for games this is the wrong model entirely. I was skeptical of this model from early on. At best this was a way to get some free publicity like a demo version of the application. But when you charge for every upgrade and every goodie, the game mechanic centres on  squeezing the user for money and not on fun. Every game I played which had in-app purchases was boring and repetitive. You can pay money to get to the next level. Initially, the game and challenging and engaging, but very soon you find yourself hitting a brick wall and you need to pay to continue. No amount of skill or determination will get you past the hurdle.

In some generous serving of humble pie, the games industry is suffering from a backlash against free games.  Recently, Dungeon Hunter got slammed for implementing in-app purchases poorly. Freemium has come under fire before, for luring children into spending money unknowingly. But this time the problem is more central.

It is difficult to make a fun game with in-app purchases.

In-app purchases require constant payment. They require the gamer to be stuck so that they spend money. It isn't about enjoyment anymore. Rather it is about erecting artificial walls to make sure that a paid level-up is required. The games that are the worst offenders are ones where you have a paid "energy", which can only be filled either by waiting or by paying money. After spending five or so rounds of gameplay, you find that you are arbitrarily locked out. There's no way to make this mechanic fun. EA fixed Dungeon Hunter by making in-app purchases cheaper and more generous. An easier fix would have been to sell the first half of the game for free, and charge $3 for the full game.


It might be possible to make in-app purchases mesh with gameplay if they are not central to the gameplay.  Additional level-packs for a flat-rate work.  Customized costumes and accoutrements work for reasons I might never understand.  New scenery or characters might work if you can still finish the game without it.

Or just skip all this confusion and focus on making a fun game. There will always be a market for those.



(Image courtesy: SlaveToTrends)

Game Review: The Shivah

I loved the adventure game "The Shivah" because it was short, crisp and enjoyable. Read on to find out why.

The game follows the adventures of a rabbi who is accused of murder. The game follows his attempt to clear his name. I'm not religious but I still enjoyed seeing through the eyes of the characters and sympathizing with them. The plot was well done and your choices can cause the game to end in failure. Luckily, the game allows you to learn from you mistakes and weaves this superbly into the story.

Adventure games have a long history. This genre includes popular games such as "Monkey Island" where you are a fierce pirate in a whimsical land filled with colourful characters. Most adventure games started out in the early PC world, and their keyboard/mouse control and game layout reflect this. The Shivah is an adventure game with evolves the genre with many subtle refinements.

The first refinement is simplification. The inventory system is greatly reduced: you don't have to grab everything on the scene with the fond hope that it might be useful five hours later. Also, the inventory items don't interact. While this was innovative in early games, it does lead to frustrating game play where you patiently try use every inventory item with everything else on the scene. In Shivah, the inventory is useful in its own unique way. Interaction with scene elements is also simplified. You get two actions: a hand and a spyglass. The spyglass allows you to look at the object; the hand allows you to use the object. This is much simpler than a rich vocabulary of actions: pull, push, give, pick-up, see, ...

The second refinement is in the choice of dialog. Instead of choosing the exact words you speak, you choose your mood: stern response, nonchalant response, etc. This works very well. Unlike other adventure games, you can choose the wrong response and end up in failure. So you need to think while responding. This also works well.

The game is also short compared to a classic adventure game. This works well for me,  I spend less time with games and still get a sense of achievement. A tasty nugget is better than a bowl of insipid mush.

I played it on Android: the graphics are gorgeous and the on-screen controls are responsive and intuitive. The dialog has well done voices and fitting background music. It is more fun on a mobile device while you are on the go and have a few moments to kill.

Highly recommended. Just two dollars on the Android Play Store. Worth every cent.



(Image courtesy: Wadjeteye games.)

Sunday, May 25, 2014

There's no such thing as real programming

There are lots of confusion online about what "real programming" is.  Most people aren't programmers, and the myths that programmers create about their own profession result in a lot of confusion.

My interest was piqued when I saw this question on a very popular programming site. I could imagine a confused kid, sitting through a boring lecture, wondering why a language was not 'real' enough for the programming world. And it is a confusing: there is no distinction between Physics and "real" Physics, so why programming?

There is a cottage industry of people claiming to teach you the tools that professional programmers use. I suspect these people are exploiting the confusion and fear related to programming.  A non-programming parent looks at the course curriculum to finds that their kids are being taught BASIC. "Basic? Wow, that stuff is dead. My child should learn what Google and Facebook engineers use so my kid can earn his first million right out of high school."


I write software for a living.  I am as real as a programmer gets. And I'm here to tell you that
 This notion of a "real programmer" is completely bogus.

It started out as typical male machismo about programming. And it has only gained in bullshit with time. It is an easy way to deride honest programming activity because it isn't as painful as the work that programmers do all day. The claim is that unless you are working with gigabytes of code and are fixing painful bugs you are an imposter.

Reminds me of a long time ago when I was learning juggling. A fellow juggler, let's call him Jack, was really good. Jack mentioned to me how you can't call yourself a "real juggler" till you could juggle five balls. I was just starting out, so I thought there must be a good reason for this. The mystery was cleared when a friend told me that Jack says this to everyone because:

A) 5-ball juggling is hard
and more importantly
B) Jack can juggle 5 balls

Jack needed external validation, that poor insecure fellow.
If you can juggle more balls than the hands holding them, you are a juggler. 


Programming is much the same. If you can write a program to make your life easier, irrespective of language and technical difficulty, then you are a programmer. I use a specific set of tools: an IDE, a debugger, a specific revision system. But plenty of expert programmers use completely different tools. There is no one tool that fits all tasks. An Integrated Development Environment can be great for large, unwieldy code-bases where you need to debug extensively and yet it can be a impediment to understanding and running a simple five-line program. The popularity of Arduino suggests that there is a huge demand for a simple programming environment rather than the complexity of a full IDE with an integrated debugger.

The essence of programming is writing down steps to solve a problem. The problem could be a very complicated one (What webpage matches the words "real programming") or a very simple one (What is the tip on a $20 meal). Since computing has become so pervasive, more problems can be solved with a computer. Previously, you would have a paper address-book with names written in them. Now you have them all written on a computer. This allows you to solve the problem (How many of my contacts live in Delhi) with very little effort. Simple programs can help reduce a lot of repetitive work.

But programming goes beyond. It is an aesthetic activity: making the computer draw fun shapes, or do silly things with sound or letters. All of this can be achieved with programming as well. Many programmers started out writing small fun programs in obscure languages and grew fond of the possibilities.

Programming is as enjoyable as painting.  Even if you never paint a million-dollar masterpiece.



(Image courtesy: Jim Pennucci)

Sunday, May 18, 2014

Basic 256: a great way to learn programming

Want to have some fun programming? Pick up Basic 256, a BASIC interpreter that runs on your system.

Programming is fun, but introducing someone to programming can be difficult. Even a simple program requires a lot of background knowledge, and it takes a long time to write something useful. Most new programming languages require a great deal of understanding: a simple line like 'import string' in Python is devilishly confusing to a child. Most programming books today aren't fun anymore, and that is a real pity. Programming can be as enjoyable as playing with Lego, except that you never run out of bricks and no laws of Physics limit your structures.

So I was very pleased when I recently tried out Basic 256, which is a Basic language interpreter that runs on Linux, Windows and Mac. The default window shows an editor on one side and text and graphical output on the other side. You can start right way, asking the computer to speak out "Hi there" which is this program:

say "Hi There"

That's all there to it: a child could do that. It has support for drawing graphics, accepting mouse input, synthesizing music, and more. The best part is that it is accessible: someone with no programming background could sit down and have a good time modifying programs they find online.

In addition to being an excellent environment to program in, there are two things that make Basic256 a superb resource:
  1. An excellent book: So you want to learn how to program? by James Reneau. The book is available free online, as an inexpensive PDF online, and also as a paper copy. I have read through a few chapters: it does a great job at introducing programming in bite-sized chunks of fun.
  2. A collection of copy-and-paste examples. This is a great collection of simple programs that do something concrete. Complete code samples like this are a great way to see how something works end-to-end and learn by taking things apart and modifying them.
In addition to having everything I remember from my early BASIC days, Basic256 has support for networking, databases, fonts, and a lot more. And it is available to download for free. It is a marvellous resource when showing children real programming and in getting them started with programming.




Monday, May 12, 2014

Simple paint program for children

I had blogged earlier about a simple program to allow children to use a computer without any supervision. That program shows alphabet and numbers and lets the child freely explore a keyboard.

A few weeks ago, my son showed an interest in using the mouse. I looked at a few programs meant for children. The best among them was TuxPaint, which can be put into full-screen mode and allows a child to draw using a mouse. However, for my two-year old, Tuxpaint was still too difficult. My son would click on the palette or the tools by accident and it was frustrating when his paintbrush went away, or the color of the pen changed accidentally. Also, the distinction between a left click and a right click was frustrating for him. It took a lot of patience to tell him the difference between the tools, the canvas, the color wells, all the while teaching him to use the left mouse button.

So I learned Qt programming and wrote a very simple program that allows a child to draw using a mouse.  It accepts no keyboard input and treats all mice buttons equally. You click to start drawing and move the mouse to make a free-formed line. The line ends when the mouse button is released. Well, it does accept very limited keyboard input that is difficult to press accidentally. There are a few hotkeys: Ctrl+Alt+t toggles the menu-bar and there you can see the other actions and their shortcuts. Changing pen width and color is supported even when the menu is not visible. You can quit the program using your platform-specific quit keystroke.

The program borrows heavily from the Scribble example in the Qt documentation. As a result, this is a good starting point into Qt programming: the code is easy to understand and modify. As a starting point, you could try changing the initial thickness of the pen.

The source code is on github. You need an environment capable of compiling Qt applications: this is possible for Mac, Windows and Linux. You can run 'qmake && make' or you could load it up directly in a program like QtCreator. I had blogged earlier about Qt Creator, it is a freely available IDE.

Precompiled Linux binaries for 32 bit and 64 bit are available. A precompiled EXE file for Windows is also available. You need to get Windows libraries which are rather big at 20Mb. These libraries have to be kept in the same directory as the EXE file. I don't update binaries frequently. If you can, the source is the best option.

And here is a screenshot of the program in action. It looks like this on every platform.

Sunday, May 11, 2014

Book Review: Merle's door

Merle's Door is a fantastic book about a man's relationship with his dog, a lovely description of the outdoors, and a rethinking about man-pet relationship. Read on to find out why.

I read Merle's Door because my wife loved it, and highly recommended it. It starts out promisingly with a story of how Ted found Merle and how they had to adapt to life together. It goes on through Merle's life and passions, and how Ted and Merle became one cohesive group.

A few ideas stick out from this book. I'm not sure these are new ideas, but this is the first book I found them. The first is the remarkable camaraderie between Merle and Ted. Not only do they enjoy each others company, but they also have a more understanding relationship.  The book is written from a dog's perspective as much as it is from a human one. At times this can get laborious as numerous online reviews point out. I understand the human urge to dislike Ted foisting human feelings on his dog. There were places where I wasn't sure what Merle was feeling and it felt excessive to force his feelings on the dog. But all writing employs some amount of guesswork of others' feelings.  In total, the portrayal was delightful and refreshing.

The only part which dragged on was Merle's last few days. Ted has written it as a painfully detailed diary, which was too painful and too detailed. I wish this section was concise, but I'm sure other readers love the detail.

This book also makes you think about the life of a dog in the city. Ted's dog had a large area he could run freely in, which is very different from most domesticated dogs. Illustrating from examples, Ted shows why a dog would be miserable in a confined area like an apartment, even if it had a generous yard.

If you have ever enjoyed playing with a dog, get this book. This will give you a fresh new perspective on what a dog's life must be like.


Saturday, May 10, 2014

Book Review: Revolution in the Valley

"Revolution in the Valley" is a heart-warming account of early computer engineering in the Silicon Valley. It recounts the work of the hardware and software engineers behind the original Macintosh. Read on to find out why I loved the book.

I have read over a dozen books about the original Macintosh. I never used the original Macintosh or the Apple II but I am impressed by the ideas that those computers popularized. The book "Revolution in the Valley" by Andy Hertzfeld is the first account that I identified with. Andy was a software engineer, a co-creator of the original Macintosh. I am a software engineer as well, and I got a better understanding of the project through his narrative.

The book is a collection of stories that are online at Andy's website Folklore.org. You don't need to buy the book, but I would recommend the book for two reasons. First, the book is loosely chronologically arranged. You can see the journey as it happened, all the way till the launch of the Macintosh and the break-up of the original team.  Second, the book is filled with lovely illustrations and images of the original team and the developer's notebooks.

After reading the book, I was filled with a deeper appreciation of the original Macintosh team. They worked in a very different engineering environment, and yet produced something exceptional. It is unlikely that their success can be repeated. Making a computer today requires a lot more effort, and the barrier to entry is much higher. The Mac team was a rare combination of talent, idealism and determination that is also difficult to recreate. Andy shows you some of the design decisions and the reasons behind them. As an engineer, it was a wonderful read.

I was filled with conflicting feelings at the end of the book. I doubt I would have survived Andy's experience. They had terrible management, were poorly compensated, and were overworked.

While the original Macintosh was made during a time of bravado, I'm glad that software engineering is a much more mature field now. Software management is better, co-workers are smarter and more numerous, and the general demands of the job are better understood.

(Image courtesy: Andy's wonderful Folklore.org site)