Nano How Special: NanoQuake
tl;dr — NanoQuake is a modified version of the Yamagi Quake 2 client/server. Using sockets for inter-process communication, we were able to develop a python wrapper which integrates Nano transactions directly into the game. On a higher level, we created an automated e-sports tournament system where players can pay an entry fee and get rewards for frags; the winners of the round split the jackpot. Nano enables ultra-fast transactions and we can perform hundreds of microtransactions per game without any network fees.
The story behind NanoQuake
NanoQuake was a proof of concept example of integrating Nano into a First Person Shooter (FPS) game. We wanted to prove it was possible to have per-kill transactions and to show off some of the unique features of the Nano currency. Quake 2 was chosen due to its historical popularity and well developed open source version (Yamagi Quake). It’s possible to use a free demo to play multiplayer games, which means there is no need to buy a full copy of Quake2. A lot of work has gone into developing a good experience for newcomers, as it was recognized that it has to be really easy to play to encourage adoption.
Ways to Play
A new player can choose to not spend any Nano initially, in order to try out the game. Both free and tournament modes co-exist in the same game round, and by default, everyone starts in faucet/free play mode. You can then choose to enter the tournament at any time.
Faucet/Free Play
By default, players play for free, and if they complete the round and score at least 3 frags, they are rewarded from the faucet. Current servers pay out between 0.01 and 0.02 NANO. The payment is sent to their NanoQuake wallet, which they set up to start playing. The aim of the faucet is to encourage play and introduce people to Nano. The faucet is supported through donations and payouts are made at the end of each round.
Tournament Play
A player can choose to “pay in” by triggering a transaction of 0.1 NANO from their NanoQuake wallet to the server’s account. The funds are added to a jackpot. Each frag is rewarded with a small share of the jackpot. At the end of the round, the remaining jackpot is split between 1st, 2nd and 3rd place. The “pay in” acts as an entry fee to an automated e-sports tournament. The more people who enter, the larger the jackpot. These players are also rewarded from the faucet for each round if they match the criteria.
Player Experience
A player opens the NanoQuake application, which is the modified Quake client wrapped in a python application with its own light wallet (read our previous Nano How on light wallets).
The wallet has its own Nano address and QR code to make it easy to for the player to deposit funds.
They can then start the actual Quake 2 game and a new window will open.
The player now selects Multiplayer. The common NanoQuake public servers are preloaded, and identifiable as the server’s account is embedded in the server name (without the leading xrb_ or nano_). The servers use vanity addresses to help identify them.
Once the player has selected the server, the application downloads the necessary maps and textures off the server and the player enters the game. As previously described, by default each player is in faucet/free play, but they can enter the tournament by triggering a payment to the server account. There are a number of maps on a rotation.
How does it work?
The yquake source code is written in the C programming language. We were able to add a socket client directly into the code which enables communication with the wallet, which runs a socket server. Sockets were chosen as they are included in most development setups and supported by a number of programming languages. The proof of work needed for every Nano transaction (learn more) is provided by the Distributed Proof of Work system (DPoW).
Client
The client has a number of custom commands added:
Balance ‘b’ — When the player triggers this command the socket client opens up a connection to the wallet and requests the wallets balance which is returned and printed.
Nano_address — This is an internal command that allows Quake to obtain the wallets address
Pay_server ‘p’ — This opens a connection to the wallet and sends a command to the wallet (including the server Nano address extracted from the server name) to send the “pay in” amount.
The python wallet acts as light wallet and communicates with a node based on a server via a REST interface. It has its own seed and associated private keys which are encrypted using AES encryption. They are decrypted with a password. The wallet monitors for new blocks and will update its interface to show them. On setup, the python wallet will also download all the required files for the game to work.
Server
The server software requires a different approach, as it needs to interpret triggers from the game, track the players and their scores as well as interface with the Nano network via the node.
- Player IDs and their wallet addresses are kept internally and are used to keep track of a scoreboard.
- Triggers via the socket client include players connecting, disconnecting as well as information about frags.
- The python server is connected to a Nano node via the RPC interface, and blocks are further processed within the game server; the node is only used to retrieve and push new blocks. This allows the server to work more efficiently than by relying on the node itself to process the blocks.
- Due to a high number of blocks that need processing at any time, the system uses Python-RQ to queue blocks for processing. Python-RQ is a redis-based job queue system and prevents the game from getting stuck while it waits for the blocks to be processed. There is therefore a slight detachment between the game and the blocks being sent out/arriving. However, due to Nano’s minimal latency and the player’s focus in the game, this delay isn’t particularly noticeable.
- Incoming blocks to the server (pay in from the clients) are detected via the node’s callback mechanism; this provides low latency in detection of a “pay in”. There is also a regular sweep of the pending blocks via the node’s RPC to ensure that no blocks are missed.
Conclusion
NanoQuake successfully shows that Nano can be seamlessly integrated into a game to create a new experience for gamers. In this example, it creates an automated esports tournament system where players can contribute to a jackpot prize which is distributed to the top 3 players. The free faucet mode encourages people to play and, in the future, this model may become a method of earning Nano.
Overall the addition of Nano adds another element with rewards for skillful play. It is important to note that Quake 2 is a game of skill and as there is very little chance within the gameplay (the most skilled players will often win) this model does not fall within the definition of gambling.
The system has had to overcome a number of barriers to allow it to be as seamless and fast as possible. While the addition of the node callback and the use of Python-RQ has allowed the game to run with low latency and no interruptions, the most important contribution is the provision of quick proofs of work from the dPoW system; without this system, NanoQuake would not be feasible. There have been situations where an intense set of rounds of NanoQuake have pushed the Nano network to nearly 1 TPS where often, at the time of writing, it remains around 0.3 TPS. Another key area is the ease of use. The team has worked hard to make the game easy to install and use as it was clear that barrier to entry was a significant issue.
The Future
While NanoQuake is a proof of concept it has been very successful and has developed a small but committed following of players. This model of integration and the gameplay of a tournament seems to be best suited to deathmatch-style first-person shooter games. The aim of NanoQuake is to inspire other integrations either into pre-existing games or into games as they are being developed. Nano’s key attributes of being ultra fast and feeless allows the use of microtransactions in a way that other digital currencies can’t match.
We plan to continue to refine NanoQuake both in regards to internal processes but also polish the gameplay to make NanoQuake as accessible as possible.
