May 28, 2019
Code & Design
With under a rough total of 10 million consumer headsets sold combined, it’s clear that spatial computing (aka virtual reality & augmented reality) has yet to cross over to the mainstream. But cryptocurrency? Whew. For better or worse, Bitcoin, Ethereum & the rest of the gang are a public rage. I mention the “for worse” scenario, because, well, cryptocurrency is vastly misunderstood.
Frankly, it’s an innately very complicated & involved phenomena with many underlying & overlapping topics such as cryptography, economics & thermodynamics. Unfortunately, due to its digital nature, the crypto-industry as a whole noticeably lacks visual, educational aids. Consequently, the average newcomer struggles to understand & visualize Bitcoin or other blockchains.
So why not close this educational gap with a virtual-reality experience that literally lets one explore a live, 3D blockchain?
For the last eighteen months, I’ve been doing exactly that: attempting to close the education gap by building & releasing a VR blockexplorer. The target market? Simply any crypto-enthusiast with a headset that’s curious to learn more about the burgeoning universe of cryptocurrency.
This series is a walk-through narrative of my learning journey throughout these last eighteen months. Cramming all lessons learned on a single post seems admittedly ineffective, so, despite Medium’s recent “anti-serialization” position, I decided to split all large milestones up into the following chapters:
Yes, it’s certainly lengthy, but the lessons learned here are those that I’ve found paramount & general; ideally, this guide serves as a tutorial for anyone attempting to build his or her first Oculus app. Before we get into it, however, I’m going to take a step back to adequately depict the end-goal: a virtual reality blockexplorer.
What Is A Blockexplorer?
A blockchain is generally accepted as an immutable, distributed database; one in which each new “block” of data is confirmed to be truthful by some method (usually a Proof of Something) by a majority or measured minority. These blocks contain a batch of transactions that represent an exchange of value, usually denominated as a token or cryptocurrency.
For example, the latest block committed to the Bitcoin blockchain contains a rich plethora of data such as the block height, the number of transactions confirmed within the block, transaction hashes for all the transactions confirmed, the total value of Bitcoin exchanged within the block, the reward for mining the block, etc…
In short, there’s a trove of beautiful blockchain data that naturally exists within each blockchain project.
A blockexplorer is simply a web or mobile app as we know it that directly interfaces with the data contained on a blockchain. That’s it in a nutshell. Here are a few of the popular web-versions along with a screencap:
Enough Planning, Onto Building!
Now with a clear end-goal in sight, it’s time to dust off the keyboard & break open your web editor of choice. I might mention, however, that one slight problem sprang up during this product daydream: I’m a hobby/weekend front-end developer at best.
Javascript frameworks? Sure, that’s within my comfort zone. Any language with the letter “C” in the name though? Nope, hard swipe-left. This meant that, at least for the first iteration, I’d stick to what I was familiar with (web stuff), & would, unfortunately, forego releasing an official VR app (Oculus, Vive, etc…).
The world-wide-web is quite adept at staying on the fringes of burgeoning tech — spatial computing is no different. For those not in the know, outside of the mainstream VR platform, there is also an entire world of VR experiences that work on any browser! It’s called WebVR.
For this first MVP of a VR blockexplorer, I decided to build it in WebVR
Pictured Above & Live Here: https://bit.ly/BTChainVR
WebVR, as a general browser API, aims to bridge the future of web browsing by providing a beautiful cross-browser API for creating immersive 3D, virtual reality experiences.
As you can imagine, the options are quite limited when it comes to the WebVR development environment.There are mainly four front runners when it comes to frameworks:
To my surprise, both A-Frame & React 360 are actually written on top of the Three.js framework. So either way you’ll end up leveraging Three.js — the largest difference between it & its counterparts lies not in the functionality but in the functionally abstracted away in order to focus on maximizing developing virtual reality experiences.
Three.JS offers a much lower-level library that’s undoubtedly the best way to learn about WebVR with a deeper understanding; additionally, it’s likely the best candidate performance-wise. However, for immediately jumping into strictly WebVR development, prototyping with A-Frame or React 360 is the preferred option as they both simplify the setup process & still offer a rich WebVR framework.
So Why A-Frame?
Documentation, community & simplicity. The documentation was clean & clear, it also contained multiple hands-on tutorials. The community was larger than expected — with the A-Frame Registry hosting hundreds of beautiful shared models. And last but not least, the dead-simple entity-component architecture; as a weekend I expected, a concave-up learning curve: I can confirm A-Frame is noticeably new user-friendly. I was able to drag & drop a static HTML file in my browser that rendered a basic WebVR scene with the following, minimal overhead:
<!DOCTYPE html>
<html>
<head>
<script src=”https://aframe.io/releases/0.9.2/aframe.min.js"</script>
</head>
<body>
<a-scene background=”color: #FAFAFA”>
<a-box position="0 0.5 -3" rotation="0 45 0" color="#4CC3D9">
<a-text id="block" value="Block Height: loading..."></a-text>
</a-box>
</a-scene>
</body>
</html>
Unbelievably, the little snippet loads A-Frame, initializes a VR scene (think of this as the canvas), & positions both a static cube & a text label. It’s only a few more lines to add multiple cubes & cylinders to create an inactive static “blockchain” so I’ll skip over that for now. Let’s head over to the limited functionality this MVP offers.
Apart from setting up A-Frame, the single functionality this first VR blockexplorer offers is to display the latest Bitcoin block height. Familiar with Javscript API requests, this step is much more straight-forward. In summary, we’re going to make a request from a cryptocurrency API, parse through the response for the block height, then finally update the <a-text> component above with the latest Bitcoin block.
Our API of choice for this first round is the adaptable & friendly Blockcypher. With a free-tier of two calls/second, the URL for grabbing the latest Bitcoin block is simply:
var latestBlock = https://api.blockcypher.com/v1/btc/main
With our URL variable now set, all we have to do is invoke one of the most common JS methods: Fetch(). Once we request this data from the URL, we parse the returned JSON object for the “height” key:
fetch(latestBlock, {
method: ‘get’,
}).then(function(response) {
return response.json();
}).then(function(myJSON){
var latestBlockHeight = myJSON.height;
})
With the code snippet above, we’ve now successfully requested & parsed the latest Bitcoin block height; the only thing left is to update the <a-text> component with saved variable above (latestBlockHeight). With A-Frame, this can be accomplished in a single line as follows:
document.querySelector(‘#block’).setAttribute(‘text’,’value’,latestBlockHeight);
That about wraps it up! Manageable within a single HTML file & few lines of Javascript, we’ve now made a dummy, static WebVR blockexplorer. For brevity here, I won’t delve into the deployment process, however, Heroku & Neocities are both phenomenally simple publishing platforms.
The largest takeaway from this initial fling with WebVR is that in virtual reality development, OOP (object-oriented programming) principles are cast aside. Usually the go-to philosophy for most programming paradigms, from this MVP it was clear that instead of OOP, VR development strongly relies on EC — Entity Component architecture. EC is a programming architectural pattern commonly used in game development that’s been adapted for spatial computing programming (AR, VR & XR).
In an EC architecture, every entity consists of one or more components which add behavior or functionality; for example, all entities might share common bits of data such as transform information like position, rotation & scale — each separately considered a component. EC follows the composition over inheritance principle that allows greater flexibility in defining entities where every object in a game’s scene is an entity (e.g. enemies, bullets, vehicles, etc.). Therefore, the behavior of an entity can be changed at run-time by adding or removing components. As stated above, the idea here is to eliminate the ambiguity problems of deep & wide inheritance hierarchies that are difficult to understand, maintain & extend when managing a VR scene with tens, or maybe hundreds of entities.
Officially launching a WebVR prototype, I was admittedly hooked: building in VR is flat-out a great time. As a front-end developer, few things excite me as immediate, tangible progress — spatial computing offers this same instant-gratification reward but on a greater scale. Think watching a CSS animation you pieced together is exciting? Wait until you step into a virtual world crafted from your imagination: the feeling is intense & deeply-rewarding.
With a WebVR prototype hacked together, I convinced myself that if I wanted to build a truly engaging, educational & hands-on VR blockexplorer, I’d have no option but to leap ahead to the official VR IDEs: Unity or Unreal. Despite the seriously impressive & simple A-Frame framework, the lack of monetization & overall state of platform fragmentation motivated me to look at the next level: developing an Oculus experience. In the next section, Part II — Unity & Oculus Setup, we’ll walk-through the required packages & settings for developing on an Oculus Rift through the Unity game engine.
Sources
