Bitcoin Plays Pokémon

Bitcoin Plays Pokémon

As a side project I recently launched ‘Bitcoin Plays…’, a Twitch stream that allows people to collaboratively play retro games, while at the same time donating to charity. As the name tends to suggest, it uses Bitcoin as its medium of payment.

If you wish to get stuck it or just try it out, the Twitch stream link is:

For those who want to check where their donations are going to, take a look at this Google spreadsheet:


I’ve been interested in Bitcoin since I heard of it several years back. Since then, I’ve been curious about some of its possibilities that are more troublesome with traditional payment methods.

Fast micro-payments is one of the features that you really can’t do well with traditional currency transfer methods. Bitcoin Plays Pokémon takes full advantage of this by performs moves near instantly for every Bitcoin payment received.

The idea of automating devices via crypto-currencies also fascinates me. A good example of this kind of idea is the Bucket Splash experiment at By donating to charity addresses shown on the site, you get to trigger water to be tipped from various buckets. You see the result within seconds via a webcam stream.

The Bucket Splash experiment and other Bitcoin powered automation systems, such as the Bitcoin fluid dispenser were strong inspirations for the project.


This project three main pieces of software. These perform the tasks of emulating the game, streaming it to Twitch and controlled the game.

  • Visual Boy Advanced (VBA) – The VBA emulator is used to run the game ROM and is configured to accept input via specially defined keyboard inputs.
  • Open Broadcasting Software Studio – In order to stream to, the project makes use of OBS Studio. This renders the video content, encoding it and streaming it to Twitch’s servers. At time of writing this, OBS Studio is well known as the best game streaming solution for Linux desktop systems.
  • Bitcoin Plays – The receiving of Bitcoin payments and control of the game is handled via a bespoke piece of software I’ve coded for the task. It makes use of the bitcoinj Java library (used by the Android Bitcoin Wallet, Multibit and others).

The Bitcoin Plays software sets up a new wallet that watches Bitcoin addresses associated with each GameBoy colour control (A, B, Start, Select, Up, Down, Left and Right). Upon receiving a payment, the software immediately makes a virtual key press for that control, causing the emulator to react as if a player was physically playing the game on the keyboard.

Previous iterations of the software were not real time. I initially experimented with a system I’ve now dubbed ‘timed democracy’, which is actually an option still available (but disabled) in the software.

Timed democracy mode would display a countdown of X seconds. This was configurable and I experimented with values between 10 and 30 seconds. During this time period, players could send payments to the various address and the total received in this time period would be displayed next to the name of the control. When the timer hit zero, the control with the most value received in this time period would ‘win’ and be carried out in game.

It turned out this most was not particularly fun. The idea of a move only occurring every 10-30 seconds was not only rather dull, but also impractical if I ever wanted to see players get siginificantly far gameplay wise.

Very early versions of the software didn’t make use of the bitcoinj library. They instead used thread party APIs. I’d experimented with using Electrum’s CLI and several online Blockchain explorer APIs.

The implementation of these required frequent polling of all the controls’ addresses. Not only did this involve additional communications and the complications of parsing the response into appropriate formats, but it also proved to unreliable. Electrum’s servers would occasionally refuse connection, possibly due to too frequent polling requests and the frequent starting of the Electrum CLI process produced quite high load. Third-party API would sometimes not respond, or serve data that was cached by several minutes. None of this was really appropriate for a system that needed to react in seconds.

To get around all these issues, a bespoke watch-only wallet was created using bitcoinj and integrated directed into Bitcoin Plays. This directly connected to the Bitcoin network like any other wallet software, download a thin SPV version of the Bitcoin Blockchain and proceeded to monitor the controls’ address for incoming payments. The relevant control could then be pressed.

This proved to be a much better solution overall. It is much more reliable than using a third-party to handle the Bitcoin network communication and address balance monitoring. For anyone developing any form of automation using Bitcoin (or any crypto-currency for that matter), I would strongly consider whether you need a third-party integration. In cases where reliable immediate reaction to micropayment transactions is required, a direct connection to the Bitcoin network was certainly a must for this project.


Currently the Bitcoins Plays software, including the custom wallet application, the emulator and the streaming software all run on a reasonable low specification laptop. It connects via my home gigabyte network to a high speed fibre optic Internet connection, which is used for streaming to Twitch and also for Bitcoin network connectivity.


All donations are, after a time, sent to charity. There are two main reasons why funds are collected, and not directly sent to charity Bitcoin addresses.

  1. Charities don’t want to deal with microtransactions. Some of the tiny transactions sent by players can actually cause rather large transactions fees when grouping all the outputs together. I felt it best to keep this potential problem away from the charities, and instead wait until a reasonable amount is received before doing single larger payments.
  2. Without special arrangements, it would be difficult to tell if a donation to a charity bitcoin address was just a donations or whether it was specifically aimed at Bitcoin Plays. Without each charity providing a unique bitcoin address solely for the purposes of Bitcoin Plays, this could make controls fire in a seemingly random manner and make collective gameplay almost impossible.

I decided for the purposes of transparency to log details of every charitable donation made from Bitcoin Plays addresses. These details are stored in a Google spreadsheet available at the following URL.

If you’re got any questions, please contact me via this website or better still, send me a message on Twitter (@DivineOmega).

Balloon Bullies – A Ludum Dare 34 Game

Balloon Bullies screenshot

I recently participated in the Ludum Dare 34 game jam. Participants are tasked with creating a game in 48 hours on their own (for the ‘compo’) or in 72 hours alone or in a team (for the ‘jam’).

I went for the hard ‘compo’ option. 24 hours to made game seemed like a challenge, especially with an already busy weekend planned. However, I squeezed something in.

It’s called Balloon Bullies, and it is a deep and thought provoking game about the plight of a singular red balloon.

Okay, maybe not. It’s a simple game, with simple graphics, ridiculous sound effects and funny little stick people that throw rocks at yourever so precious red balloon. And  you’ve got to move it out of the way.

Let Me Play!

If you want to give Balloon Bullies a go, I’ve put it up on, which is an awesome indie game developer website. You can even play it right in your web browser.

Here’s a widget with a button you can click on for fun.

I hope you enjoy it. And if you do, please rate it on and/or leave a comment.

If you want to here my thoughts on its development – a post mortem of sorts – keep reading.


The themes for Ludum Dare 34 (or LD34) were ‘Growing’ and ‘Two button controls’. When developing Balloon Bullies, I made sure to include elements of both.

  • Growing – When in game, the balloon you control (pilot?) inflates over time. Growing larger and larger, it becomes a bigger target, thus making the game more and more difficult. Yes, I know, balloons tend to deflate over time if left alone, not inflate. But the sake of a sensible difficulty curve it inflates.
  • Two button controls – You steer your balloon using two buttons. One swaps the up/down directions, and the other swaps the left/right directions. Simple!

It’s actually quite rare for there to be two themes in Ludum Dare game jams. The themes are voted for before people start developing, and usually one wins outright. In this case, these two themes got exactly the same number of votes.



Overall, I’m happy with the game. Sure, it is simple, but its a bit of challenge (especially on the higher difficulties) and most importantly it is fun to play.

I got a few awesome comments, like these:

Something like this would probably work very well as a mobile game. Bonus points for using both themes. I liked it! @oav

Cool game! Great use of the theme! @87meansSuhail

Nice take on two buttons. I like the toggle concept. Would be cool to see it taken further. @xopsx

Finally someone is talking about balloon violence. @awentzonline

So that’s great and of course, pretty motivational.

I’d like to participate in another Ludum Dare game jam in future, perhaps at a time where I put my full focus on the development. The things I really feel like I need to improve on for the next Ludum Dare I take part in are as follows.

  • Graphics – All the graphics in my game are built using basic 2D geometric primitives (lines, circles, rectangles, etc.) and nothing else. Despite having visuals, the game files actually contain no images whatsoever! This is great in that it keeps file size down and means the game runs speedily on all but the slowest of toasters, however it does mean you get some mixed-bag comments. Perhaps some pixel art next time?

The art style looks like something a 6 year old would draw, but it doesn’t matter because I had a good time.

  • Sound effects – This really covers audio production in general. I was a little limited in what I could do, because I was having to develop on my old on-its-last-legs laptop. However, all the sound effects were literally me making whoosh and weeeee noises into the microphone and then tweaking them slightly. My aim was to get sounds that were obviously made in this fashion, but in a comical way. I think I did this okay, but the sound quality and production methods weren’t great.

The sound effects were really funny, albeit not of good quality.


Balloon Bullies is a HTML5 game that makes use of the Convergame game engine, which I am also a developer for.

The game has been made so it is compatible with a variety of web browsers and devices. It works on the latest versions of Google Chrome and Mozilla Firefox at time of writing this. It also works fine on the mobile version of those browsers, so you can play it on mobile phones and tablets. Yay!

Regarding mobile browsers, unfortunately audio was not always working on the mobile version of Google Chrome. I didn’t have time to dig into why. Other than the sound, gameplay and graphics work perfectly.


I made a game and had fun doing so. Cool people played it, and most of them had enjoyed it as well

I’d say that’s a win! 😀