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 http://www.ucontrol.tv/buckets/. 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 Twitch.tv, 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.
- 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.
- 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).