I’m writing a book called “Dogecoin Tricks” about cool and interesting and unique things to do with Dogecoin. One recurring example is the use of a Dogecoin-based payment system for a video game arcade. While this blog post overlaps with the book and I’d like you to look into the book, you don’t have to know or care about it to get something from this post.
Dogecoin is about fun and it’s about utility. People should be able to use Dogecoin to send funds across the world, get paid for doing cool things, and buy and sell stuff with ease. The more interesting uses we can find for Dogecoin, the better it will be.
I’ve spent time over the past year or so talking to a few other people and working on ideas for using Dogecoin as the payment system in an arcade: pinball machines, coin-operated redemption systems, arcade cabinets, et cetera. A contactless, permissionless, low-friction payment mechanism could solve a lot of problems, and programmable money can enable some interesting technologies.
While this post concentrates on the arcade game example, the system design can fit a lot of redemption systems, so if you can imagine something slightly different, the approach may still apply.
Let’s brainstorm to see how the pieces of the system fit together.
Getting Paid with Dogecoin
The obvious place to start is replacing coin slots, quarters, nickels, or card swipes with programmable money. Back in the ’80s, you’d have to put paper money into a token machine to get a handful of coins redeemable only in the arcade/pizza place/party zone you were in (cue the Five Nights at Freddy’s fans).
This was a hassle for kids (you have to bring a wad of paper money), arcades (you have to maintain the token machines and modify the coin slots on your arcade machines to accept tokens), and parents (you’re going to end up with unspent tokens after the birthday party is, mercifully, over).
How much cleaner is it to say that 1 Doge (or 10 or 100 or whatever) equals one credit and gameplay? Customers don’t have to carry paper money, or a roll of quarters, or a bag full of nickels. They don’t have to worry about a physical token machine breaking down. They don’t have to scrounge around in the junk drawer for a magnetic swipe card the next time they visit the Fun Center. They just need the ability to send and receive funny dog money.
Three Transaction Mechanisms
In my research, I’ve found three payment mechanisms. One, unlimited admission for a cover charge. Pay 100 Dogecoin at the door and you can explore the pinball museum all afternoon. Two, a per-machine charge. Send the appropriate transaction to a machine-specific address and you get to play until you run out of lives. Three, an electronic credit system. Send Dogecoin to a customer-specific address and get credits you can redeem at each machine.
There are pros and cons to each approach, and you might prefer one over the other depending on many factors. The road forks at this point immediately, however. For all three scenarios, you have to wait for a Dogecoin transaction to settle. That generally happens about every 60 seconds, depending on network traffic and block mining difficulty. This can be fine if you’re scheduling tournament plays on a DDR machine, kicking off a banger on a jukebox, or letting people lounge in a waiting room while the max occupancy sign is lit. It’s not so great when you have someone tapping their toes standing in front of the Addams Family pinball machine.
No matter which approach you take, you’re going to need some software.
Event-Based Transaction Reaction Code
Consider the single-fee admission case first, not because it’s the best or only approach, but because it makes the first necessary software feature obvious.
The nice part about handing the pinball museum cashier a sharp new $20 bill is that they can immediately check for counterfeit currency and let you in the door. You’ve established your identity as the person who pays.
In a cryptocurrency world, you’ll wait for the transaction to settle, but you’ll also need a way to know that Person A’s payment arrived, while Person B’s payment has yet to get mined into a block. The smart way to do that is to generate a new payment address for every person and keep track of the person and the pending payment.
This means your software has to do two things: generate a bunch of addresses and let you know who’s authorized for what. This is the same thing you need to do for the electronic credit system, of course. It’s also similar to what you need to do for the per-machine charge.
You need software that:
- generates a bunch of addresses
- associates those addresses with customers or machines
- listens for transactions to those addresses
- kicks off some real-world behavior for the person or machine associated with those addresses
Easy, right? That real-world behavior gets interesting. Maybe you flash a light on a bracelet that lets people into the museum. Maybe you deposit credits into their balance in your arcade. Maybe you unlock a door and let them out of the escape room (or maybe charging people to leave is a terrible business idea).
You’ll need some kind of persistent data store, a feed of block and transaction
information from the Dogecoin network, and an administrative interface at least
as good as a psql shell to your database server.
Coin Mech Compatibility
If you get someone to open up an coin-operated arcade or pinball machine sometime, you’ll get to see something called a “coin mech” or coin mechanism. This is, more or less, a slot that closes a circuit when someone inserts the appropriate coin or token. That circuit triggers an event in the machine’s hardware itself to add a credit to the machine: one more wave of missiles to command, balls to launch, or claws to grab a plush figure.
Many or most of these machines have a free-play mode, so if you’re using the museum-style entry fee approach, set all of your machines to this mode.
If you’re using a pay-per-play approach, you need a way to close the circuit electronically. This is where things get fun in the hardware sense.
The best approach I’ve found so far is to buy a pile of programmable network-enabled switches and connect them to the same circuit as the coin mech. You can buy these boards in bulk for a couple of dollars apiece. With a couple of minutes of programming, you’ll have a switch you can trigger with a simple network command. If all of your machines conform to a well-understood coin mech standard (such as the JAMMA standard), you can wire up the switches without too much work.
If you have a dozen machines, this is the work of an afternoon. If you run an entire pinball museum (life goals, people!) you’ll be busy for a while longer.
If you’re using machines that do not conform to JAMMA, which conform to different standards (read the operator guide to your pinball machine carefully), or which don’t have any particular standard (admit it–you have a Raspberry Pi in a custom cabinet running a ROM, just for testing), you’ll have to do more work. In the latter case, simulating a keypress for an emulator turns out to be an incredible ordeal depending on lots and lots of factors.
(I have a homebrew cocktail arcade cabinet running RetroPie and there’s no single, obvious, predictable way to simulate a coin insertion event. Believe me, I’ve tried the easy ideas and a few difficult ones.)
User-Visible Software
Next up, depending on your system, users need some way to interact with the system. This could be as simple as adding a QR code generator to your point of sale system at entry, printing out a bunch of tickets with QR codes and handing them out (recycling the numbers once a day), or adding a QR code per machine.
Those approaches cover the entry-fee scenario and the address-per-machine scenario.
I prefer the users-buy-credits scenario for other reasons, including the cool factor. To make that approach work, you need software to:
- give each user a unique login account
- generate a Dogecoin address to which they can send payments
- track the balance of their accounts
- list the machines they can play
- deduct credits from their accounts when they play machines
- request refunds, report broken machines, etc
If that sounds like a little web or mobile app with a handful of important features, you’re probably right. The downside of this system is that it’s software you have to maintain and it requires some kind of smartphone usage inside your arcade. The days of handing out a bunch of sticky tokens to a bunch of excited eight year olds full up on cardboard pizza and trying to avoid a headache are gone.
On the other hand, you can do a lot of cool things like track high scores, playing time, and tournament information, provide a map or support or history information on your games, et cetera.
Administrative Support
No matter what approach you take, you need the ability to intervene when things go wrong. Maybe a payment never arrives. Maybe your Popeye machine pops a CRT just as a customer dumped 100 Doge worth of tokens into it. Maybe you need to keep track of payments per day for tax or accounting purposes.
For this system to be worthwhile to arcade owners, it has to be usable. If you’re going to pitch someone running a retro arcade in Shibuya, you want to put your best foot forward.
I’ve done the least work here. I’m comfortable with psql as an administrative
interface. That’s not great for other arcade owners, and it definitely gives
me cool nerd points and geek credibility with my friends, but we’ll flip the
machines on free play mode after that anyway.
Okay, How Do We Build It?
I’m not sure how we build it. I mean, I have a good design and some working prototype code and working hardware. By the time I finish my book, I’ll have made this work with real arcade cabinets, pinball machines, and possibly even a supergun.
That gives a working prototype proof of concept that works well enough for my own purposes, but how do we turn this braindump and the proof of concept into useful, usable, pleasant control software for a Dogecoin-enabled arcade other other mechanism?
This idea keeps coming up. See, for example, my discussion with William the Doge Wrangler about a Dogecoin-powered arcade where he baited me into writing this blog post!
A fellow developer called nformant wrote software called Dogecoin Bartop Arcade which performs similar behavior (see the related Reddit discussion.
Another Reddit discussion brought up handling Dogecoin payments in a game, which requires similar behavior to that described here.
Finally, a recent Reddit discussion about a video game lounge brought up payment options in addition to the normal cool arcade stuff.
Clearly there’s interest and opportunities to work together. I estimate a couple of good developers could spend a couple of months putting things together, bundling them up, and making sure the integration and usability are worthwhile. That might not handle the hardware side, but if you’re running arcade machines in this day and age (especially if you’re into retro gaming or restoring old hardware), a little bit of soldering isn’t out of line.
A couple of developers funded full time could get this done. A larger group of developers over a larger period of time–if they agreed on the approach and code and language and tools and stack–could also get this done. A small business could sell support, but that requires writing a business plan and discovering the market coverage.
If I had to choose an approach, I’d rather publish a working prototype, open source the code and designs, and let people decide what to do from there. Perhaps there are bounties or milestones or suggested donations. Perhaps not. Perhaps you have other ideas.
Where do we go from here? Let’s talk about it on the Dogecoin Developers subreddit.
