Common practice is to track In-Game Currency (IGC) in a central database. There is no problem with this method and it has served firms and players well so far. However, a blockchain currency can offer:

  • Absolute virtual liquidity, allowing players to exchange their IGC for actual Fiat currency.

  • Higher stakes so that players begin to feel like they are playing with actual money. This brings a new dimension to game design allowing rewards and losses to come with much more impact.

  • Provable Scarcity, IGCs from PAYVR are public so players know exactly how many units there are in existence.

  • Provenance - The ability to assign dynamic values to an IGC based on the history of ownership and other properties.

  • Fraud elimination - With the security and trust that blockchain provides, IGCs are guaranteed to be valid.

What it does

We have chosen a project which we did not expect to complete within the 24-hours of the hackathon. We have tackled the core building-blocks of the system but haven't gotten to the glue that makes it all stick together.

What we have

  • We have a distributed network of remote servers that provide consensus on our private blockchain.

  • We have a smart contract with generates a token based on parameters

  • We can push a contract to our private blockchain and interact with it using command-line tools.

  • We have a barebones Flask app which does user registration and authentication and allows users to specify the params of their token

What we don't have:

  • A way to get params form the Flask app, generate the smart contract, and push it to the private net without manual command-line commands.

  • A way to interact with the smart contract without manual command-line tools

  • Anything resembling an API

How we built it

Our application is multi-faceted. It consists of a web server, smart-contract generator, NEO private net, and API layer.

Let's start with the fun stuff:

Smart Contract

We're creating tokens built with the NEO blockchain for developers to use in their games. Tokens are a subset of cryptocurrencies. They are special because they inherit all the benefits of the blockchain they are built on without having to incentivize the creation of a new blockchain.

In Ethereum, a simple token can be created using the following smart contract code.

contract MyToken {
    mapping (address => unit256) public balanceOf;  // initialize wallets

    function MyToken(unit256 initialSupply) { // Create token with an initialSupply of circulating tokens
balanceOf[msg.sender] = initialSupply  // send all the tokens to the creator of the contract

function transfer(address_to, unit256, _value) {  
    if (balanceOf[msg.sender] < _value) throw;  // quit if the sender dosent have the tokens he is trying to send
    if (balanceOf[_to] + _value < balanceOf_to]) throw; // quit if attempting to send a negitive balance
    balanceOf[msg.sender] -= _value; // remove tokens from the sender
    balanceOf[_to] += _value; // add tokens to the reciever

In NEO, it's a bit more complicated. Our contract exists as a Python class which is compiled into NEO Virtual Machine Byte Code. It also has more features.

Smart Contract Generator

A backend Python function generates a new token contract like the one above and pushes it to our own NEO private testnet.

NEO Private Net

The NEO mainet is reserved for live contracts. The NEO testnet requires test NEO and test GAS to interact with. Test NEO and test GAS are received only after submitting an application (ain't nobody got time for that)

We deployed our own NEO private net. Since we control the net, we can give ourselves GAS and NEO to interact with it. A private net needs at least 4 consensus nodes to functions. We built a Docker container which simulated 4 nodes and deployed the container on two servers. We have 4 virtual nodes running on a Linode in NJ and 4 virtual nodes running on a Linode in Tokyo.

Web Server

When a developer wants to create a new coin for her game, she'll head over to our website, register and design her coin by imputing parameters like the NAME, SYMBOL, TOTAL SUPPLY, and INITIAL AMOUNT. (We'll add much more options later defining coin generation and ability to trade tokens for actual USD!)

API Layer

Cool, so the game dev has a shiny new currency, but how do they use it in their game? Simple! We're building an API.

Then the developer can simply generate a unique NEO wallet for each player and call our API to transfer coins between users.

Challenges we ran into

So Many.

We started with only minimal research. We knew what we wanted to do and that we wanted to use NEO. However, learning how to use NEO, how NEO was structured, how to deploy, EVERYTHING was new to us. We learned by reading the fragmented documentation and Medium articles. No StackOverflow for us! (it doesn't exist for the blockchain tools we're using yet!)

We wanted to leverage the IOT to make up the nodes in our private blockchain. The Qualcomm Dragonbaord 410c would have been an excellent embedded system. We struggled for hours trying to boot from the SD card loaded with a Debian image. We followed Qualcomm's Hackathon "Getting Started Guide" to a "T". However, the board refused to boot at all. We determined that the board provided to us by the MLH Hardware Lab was faulty and returned it.

Luckily, we came prepared with a slew of Raspberry Pi boards brought from home. After hours more of "failure-driven learning", we discovered that the libraries required to run a NEO node simply aren't available for the Pi's ARM processors.

At the last minute, we pivoted away from IOT and are hosting our private net on a pair of distributed Linodes (NJ and Tokyo)

Accomplishments that we're proud of

So many.

Every accomplishment was so rewarding. Our development approach was very much "guess and check".

We learned a lot about Docker and it paid off. In the near-constant struggle called "Build the Private Net" we used Docker heavily and it helped us avoid having to configure many different servers. In the end, getting the NJ server and the Tokyo server talking to each other required editing each server's respective Docker file to pass in the other's IP.

Our web developer was new to building a Flask from scratch and he learned a lot about the many ways to properly structure an app while incorporating the various software architectures and their relation to the database. The type of database used was also MySQL which was also new to our web developer as he used SQLite.

What we learned

The neo-python library only has about 70% coverage. We needed to deploy consensus nodes and also query a smart contract, but we determined that there exists no python function in the library to do so. These are the constraints of working with cutting-edge technology that is still being developed.

The NEO framework is a native .NET app so we could have used C# to achieve this functionality. Although, none of us are comfortable with .NET so there would have been issues even if we went that route.

What's next for PAYVR?

We're competing in Idea State U (Kentucky's state-wide business plan competition). We will continue with development and have a minimal viable product along with a business model and revenue projections by the competition finals on April 15, 2018.

Share this project: