Building an application on a blockchain is a real challenge for developers who are seeking to leverage the power of the decentralized Web. With that in mind, dfuse is inviting experienced developers to share their journey of building these next-generation dapps. Today, we are pleased to speak with Lynn Duke, Founder at Bitjoy and one of the early users of the dfuse API.
Could you introduce yourself?
My name is Lynn Duke, CTO and Founder of Bitjoy.io and I’ve been developing software professionally for almost 20 years. Born and raised in Texas, I was first introduced to computers when my dad brought home a TRS-80 Color Computer from our local Radio Shack with a whopping 48K of RAM! When the TRS-80 expired, I burned through several more Tandy’s and Commodore 64’s during my teenage years. I started college in 1996 and initially had a tough time deciding between a theatre curriculum or a computer science focused path. Within a year, my passion for programming video games settled that debate.
My first full-time development gig out of school in the late 90s was for a real-time operating system company called Wind River. I was exposed to assembly and C for the first few years but eventually left embedded software development and found my way into game development for THQ, a then Atari-owned game publisher. I spent several years learning everything I could about graphics rendering technology on the Xbox and PlayStation consoles. I worked on core game engine and technology teams for a few game studios and even built my own game engine in the mid-2000s. By 2008 I caught the “mobile development” bug and set out to pursue my own iOS software startup. The next 4 years I’d spend building over 200 iOS apps and games, some of which would reach #1 in the App Store.
During my iOS startup years, in 2011, I stumbled across bitcoin.org. Unfortunately, and like many others, I completely misunderstood the entire concept. I remember reaching out to the webmaster on bitcoin.org to learn more about their plans for a mobile “SDK”, haha. Of course, I never got a response back. By 2013, I had gotten the memo and was completely obsessed with Bitcoin and the broader Blockchain technology that powered it. I believed wholeheartedly that it could fundamentally change people’s lives for the better. I listened to every bit of discourse I could find on Blockchain.
For some people it’s coffee they wake up to. For me, it’s Blockchain. People like Adam B. Levine, Stephanie Murphy and Andreas Antonopoulos fueled my imagination and curiosity by the close of every LetsTalkBitcoin Podcast. In 2015 I began building blockchain applications professionally and have never looked back.
Could you present the vision of Bitjoy?
With a large gaming background, it’s fitting for us that we’ve decided to focus on the crossroads of gaming and blockchain. Of particular interest to us is the relatively-recent explosion in live game streaming. Live game streaming has become a hugely-popular social experience accounting for incredible amounts of web traffic with millions of people not only playing online together, but watching other people play.
Platforms like Amazon’s Twitch, Microsoft’s Mixer and new contenders from Facebook and Google are showing us the future of live entertainment where unique gaming experiences are created, curated, and commented on by communities and spectators all over the world. Engagement between the live game streamer (or player) and their viewing audience is a largely unexplored facet – especially within the context of the game.
We’re building a platform and token-based protocol that incentivizes new models of interactive gameplay and value creation between live game streamers and their viewers. We call it, Bitjoy. It enhances interaction by creating economic incentives within the game experience and backing them with real-world, tokenized value. That value can be safely transmitted, aggregated and acted upon by the game code in real-time to modify the stream experience.
Underpinning the Bitjoy Platform is a token called the “POWER” token. During gameplay, viewers send POWER tokens to cause real-time changes in gameplay and the live stream. POWER tokens are much more than a means of transaction – they are a form of collateral that represents a viewer’s stake in communal gameplay mechanics – opening the door for new economic incentives, new types of cooperative gameplay, the ability for the viewers to earn based on the player’s performance, and much more.
Imagine if viewers were able to assist a player during a live game stream by opening a secret door. Imagine if viewers could replenish the player’s health just in the nick of time during a boss fight. Unique game assets and game mechanics can be created in real-time as a result. A one-of-a-kind magical sword could be leveled-up when 20,000 viewers “power it up.” That sword could live for a year on the chain during which the streamer is free to use it in gameplay again, sell it or rent it to other players. Unique assets in the game world could be minted by celebrity streamers able to command a large enough viewer base. Or, viewers could pool their resources to endow lucky streamers with gameplay modification or temporary upgrades – essentially incentivizing a streamer to begin a stream because the viewers are ready to watch.
And let’s not overlook the opportunity for game designers. I think this is what fascinates me the most, personally. As game developers, we put most of the development time on building a great experience for the player and virtually zero on the viewing audience’s experience. I think that’s partly because viewing audiences of 650,000 people for a single streamer is quite a new thing, haha, but also because monetizing a viewer is a new idea in game design and development. By bringing viewers into the game experience with the streamer and giving them the power to participate in value-creation during the stream, they become valuable “players” in their own right. Game designers can begin building for an addressable market that is potentially orders of magnitude larger than the playing audience.
It’s usually at this point in the discussion that we get the question – “Why do you need this on a blockchain?” I love this question. I start off by saying – “we don’t.” That usually raises an eyebrow or two but sets me up for the uppercut of conversation that comes next. The truth is that you can build any of these applications on centralized infrastructure. However, the reason to build this system on a blockchain in place of centralized systems is so that we can store information in a database where the user is in complete control of their own records. When you do that – when you move from a centralized store of information to a decentralized one – you unlock tremendous audibility, provability, and safety to stakeholders in an ecosystem who choose to use it as an oracle of truth. You align incentives between owners of value in that system.
Borders between games, applications and even corporations melt away leaving a truly open and secure means of moving your value to another live stream or even another game. POWER tokens represent discrete bits of digital value and blockchains can move them around the world with no middle-man. There are no 3rd party payment processors taking fees or blocking transactions that don’t match their separate ruleset or whitelist. Any application or platform that promises safe, secure, real-time transfer of value can’t do so on a centralized system where control is in the hands of a few administrators. Bitjoy must be built on a blockchain to enable true peer-to-peer communication of value.
What are the main challenges that Bitjoy faces while developing for the blockchain?
The impact of block times and transaction fees on the user experience still presents the largest challenges to blockchain developers in my opinion. It’s something you must deal with at every turn. We have a few battle scars from our time spent developing with Bitcoin and Ethereum in the past and thankfully we can draw upon those past lessons and mistakes.
I’ve spent countless hours trying to hide high-latency block times behind fancy wait spinners and creative app logic only to realize that no matter how pretty it looks or how well you explain why the user needs to wait – it just doesn’t feel good to anyone. No amount of creative education you give the consumer can make the wait times acceptable. That Bitjoy is focused on real-time gameplay and interaction makes our job all the more difficult.
Initially, a version of Bitjoy was prototyped on Bitcoin in 2015 and then again later on Ethereum. The tradeoffs in user experience we had to make on these chains were unbearable. We still had to introduce intermediate SQL databases to aggregate value before transacting due to transaction fees we had to pay on these chains. The dream of sending a fraction of a penny at a time would unfortunately remain just that – a dream.
In 2017 we leaped technological bounds by moving to EOS – a newer generation blockchain with no transaction fees for users and sub-second block times. To be quite honest, we’ve never felt so empowered. What we’ve accomplished on EOS in the last few months puts the last few years to shame. Do yourself a favor and choose a chain that is appropriate for your particular use case from day one.
Challenges still remain for applications like ours that attempt to modify value and affect a game experience in real-time. Micro-forks present a specific challenge on EOS. Guess what? A transaction you sent 10 seconds ago didn’t actually make it into a block and any side effects of that transaction potentially need to be rolled back! If we’ve modified game behavior for thousands of players, how do you explain to them – “oh, sorry everyone, that powered-up game sword you’re all watching isn’t actually powered at all. Can we have that back?” To mitigate micro-forks, we found it helpful to segment our transaction types into a few levels of severity. In some cases, we find that no rollback is even necessary.
In a system like ours, we actually need the game designer to assign metadata that describes how devastating a micro-fork (or unexpected delay) could be for a particular game item or power up. That’s because there’s no one way to handle micro-forks that works for all side effects. A powered-up game item that does double damage is quite different than unlocking a character skin in terms of side effects in the game world.
The chain data will eventually become consistent but you should take care to keep your application side effects in sync as much as possible. Large value transactions should probably wait until some threshold of finality has been reached. For instance, transferring a game item from player to player could wait for a high degree of certainty from the chain with minimal impact to the user experience.
Will it be obvious to a user that they are on a blockchain?
Yes and no. Our current belief at Bitjoy is that a decentralized platform with a daily active user count of 18 isn’t interesting. Furthermore, we subscribe to the mantra that if the user is seeing the word “blockchain” during the most-critical seconds of signup into our platform, we’re doing it wrong.
If you simply want to use Bitjoy and couldn’t care less about this “blockchain thingy” your coworkers obsess about, then by all means, please create an account with a traditional username and password. Let’s get the party started. When you begin to accrue value on our platform, however, we’d love to take the opportunity to tell you about the benefits of controlling your own private keys and give you the option to become the master of your decentralized future.
We’ll provide a way for you to take control of your account and remove our custodial control. Until then, we’re happy to have you in any capacity. We’re even exploring some interesting ways to incentivize these types of users to take control of their keys sooner rather than later.
If you show up to our welcome screen and you have your own EOS account and/or private keys – perfect! We’re ready, able and quite excited for you to connect an account for which you own the private keys.
From Bitjoy’s perspective, if we wait for mainstream users to become blockchain-aware and submit to the hurdles that account creation and key management present, then I truly believe we’re already staring at the GAME OVER screen.
What advice would you give to a developer who wants to build a project on blockchain?
Start at the finish line for your project and work your way backwards. Sounds counter-intuitive right? Developing a blockchain application is largely similar to any other type of application development. The languages you already know, the platforms and IDEs you’re already experienced in… you’ll need them all. The part that will challenge your developer-brain is the way in which decentralized applications store data and the timing of reads and writes to that data. Authoring Smart Contracts will feel strangely familiar but their unique timing constraints and limited instruction sets will present a learning curve.
We’re currently powered by dfuse in terms of interpreting transactions on the blockchain. Our backend is a combination of dfuse, web services and other processes that provide information about game items, power-ups and other mechanics that live on the EOS blockchain. Some of our processes are even responsible for submitting transactions on their own at special times. However, it’s really streamer and viewer token transactions that propel the entire system forward in time. We maintain a few databases for caching purposes which allow us to support sophisticated queries for games and applications running Bitjoy SDKs.
We’re fortunate that with EOS there is an abundance of development resources. Block.one provides the EOSIO open-source software and with that alone comes many code samples you can leverage in your applications. Updates to the software occur quite frequently and there’s always new functionally you can pick up in the latest releases.
Then there is the community. EOS has one of the best blockchain communities I’ve been a part of in years. Block producers and community members are constantly making massive contributions to the community in all forms – for instance, EOS Canada’s dfuse API and Structured Query Engine (SQE), GenerEOS’s EOS Toolkit, EOS New York’s Echo publication, and podcasts like The EOS Podcast, EOS is Very Cool, and Everything EOS just to name just a few. Open source smart contracts from trail-blazing applications like MonsterEOS, Dice, Infiniverse, provide inspiration while teaching you the fundamentals of smart contract development.
Again, I suggest building some momentum in your application development cycle by starting with the vision of the final product and working backwards. Introduce decentralized components opportunistically and when they make 100% sense for your application and use-case. Constantly challenge yourself and others when blockchain dogmatism inevitably reaches your neck of the woods.
The global movement towards a decentralized, peer-to-peer future will take many iterations and best practices will be redefined over and over again. So relax, have fun and build something compelling on blockchain for the world to use. At the end of the day, you’re the one putting in the sweat and tears to incorporate blockchain into your project and that means you get to ultimately define the role it plays in your final product.
If you are a developer and want to share your experience to build on the blockchain, please feel free to contact us. We would be happy to integrate your interview in our series “In the Eyes of a Blockchain Developer”.