Greetings, blockchain enthusiasts! In this ongoing blockchain series, we're embarking on a journey to create a version of Rock, Paper, Scissors where two players can engage in fair wagers, all made possible by blockchain technology. If you've ever wondered about the power of blockchain beyond cryptocurrencies, you're in for an exciting ride.

The Problem with Third Parties

Let's begin by addressing a crucial question: Why blockchain for a simple game like Rock, Paper, Scissors? Why remove third-party intermediaries? While third parties can be essential in some contexts, they can also introduce elements of unfairness. Think about it; a third party could easily manipulate the game's outcome or even falsify results. In essence, they add an unnecessary layer of trust that isn't always warranted.

Our goal here is to build an application that eliminates the need for such intermediaries, ensuring a transparent and tamper-proof gaming experience.

Join the Journey

Before we dive into the technical details, I want to encourage you to follow along with us. Copy each section of the program as we create it. Feel free to pause the blog and experiment with the code. And if you ever find yourself stuck or facing issues, don't worry; you're not alone. We have a supportive community waiting to assist you on Discord.

In the previous blog, we set up our development environment and got everything ready for using the Reach programming language and platform. If you haven't done that yet, I highly recommend checking out that blog to get up to speed.

The Starting Point: index.reach

Now, let's explore where we are in this journey. In our "index.reach" file, we're laying the groundwork for our decentralized Rock, Paper, Scissors application. This file serves as the entry point for our program. Inside, you'll find a "main" export that defines our Reach program.

This "main" export sets the stage for our custom logic, acting much like the main function in languages like Java. In Rock, Paper, Scissors, we have two players, Alice and Bob, each represented as participants. We'll define specific operations that these participants can perform as we progress. For now, consider them as placeholders.

Understanding Participants

Within each participant, we create an interface that outlines a predefined set of operations. These operations will allow the participants to interact with the program. For instance, in our game, they might include accepting wagers, revealing their choices (Rock, Paper, or Scissors), or other relevant actions. The specifics will be clarified later.

To keep our code organized and understandable, we use comments (those lines starting with double slashes "//") to add helpful notes and explanations. These comments are for your benefit, helping you understand your own code as you work on it.

Storing Participants for Future Reference

Since we'll refer to Alice and Bob throughout our program, we store them as constants using the "const" keyword. This way, whenever we want Alice or Bob to perform an action, we can simply use these constants' names.

The Deployment Awaits

Now, you might wonder when we'll deploy our Reach program. Well, that's coming up, but before that, we'll need to create some front-end code in JavaScript. This JavaScript code will complement our back-end and facilitate the interaction between our users and the blockchain.

Stay Tuned for the Front-End Journey

In the next part of our journey, we'll explore how to create the front-end code, connect it to the back-end, and begin building the Rock, Paper, Scissors functionality.

The world of blockchain is dynamic, and we're just getting started. So, stay tuned for the upcoming episodes, and let's explore the endless possibilities of this groundbreaking technology together.

Building the Backend and Frontend Infrastructure

In our ongoing journey into the world of blockchain, we've set the stage for creating a Rock, Paper, Scissors game with a fair wager system. If you're just joining us, make sure to catch up with the previous episode to set up your development environment. Now, it's time to dive deeper into the technical aspects of our application.

Frontend Implementation in JavaScript

We're now entering the world of JavaScript as we begin implementing the frontend of our Rock, Paper, Scissors game. Here's how it all unfolds:

Defining Network Tokens

First, we need to establish the currency for our game. The actual tokens used will depend on the network you're working with. For instance, if you're on the Ethereum network, tokens might be in the form of "Wei." On the Algorand network, they could be "micro Algos." We define these tokens using the parseCurrency function from the Reach standard library. For our initial setup, let's start with 10 tokens and refer to them as the "starting balance."

Creating Test Accounts

In order to simulate user interactions, we need test accounts. We create these test accounts using the Reach standard library, specifically the testAccount function. For simplicity, we'll create two test accounts: one for Alice (accAlice) and one for Bob (accBob). It's important to note that these are test accounts and will only work on the Reach developer testing network. For Ethereum or Algorand, you'd need actual accounts.

Deploying the Backend

To deploy our backend on the Reach developer network, we'll use Alice's account (accAlice). This process results in a contract, which we'll save as ctcAlice. But we can't forget about Bob. To include him as a participant, we'll attach his account to the backend using ctcAlice.getInfo(). This gives us ctcBob.

Frontend Interaction Objects

Now, let's set up how users will interact with the backend as Alice and Bob from the frontend. To achieve this, we access the backend's attributes for both Alice and Bob. While we'll define these interactions later, we're leaving comments in the code as reminders to implement them.

Asynchronous Execution with Promises

Both of these interactions are asynchronous operations. To ensure they run simultaneously, we utilize JavaScript's promises. This allows us to execute both calls concurrently and wait for them to complete before proceeding.

Running the Program

Now that we've outlined the implementation, it's time to run our program using the Reach command (reach run). However, we encounter an error: "unexpected token." Typically, this points to a compiler error. In our case, it's in the Reach file at line nine, where a comma should be a semicolon. Once we make this correction, we're ready to run the program again.

But wait, there's a missing piece! We need to set the reach connector mode environment variable to inform Reach which blockchain protocol we're deploying to. In our case, we're using the Algorand devnet.

Configuring Reach

To set up the environment, we use the reach configure command. Since Reach is not installed globally, we copy the path and execute the command accordingly. This configuration helps Reach understand the blockchain network we're targeting.

The Future Beckons

With our configuration in place, we rerun the program, and it compiles successfully. There's a minor warning about deprecated tools, but nothing to be concerned about at this point. Reach is actively developed, and these issues are often resolved in subsequent releases.

Our journey into the world of blockchain and Rock, Paper, Scissors is progressing steadily. Stay tuned for the next installment, where we'll delve deeper into the frontend implementation, connecting it to the backend, and inching closer to realizing our fair wager game. The blockchain world is ever-evolving, and we're navigating it together.

Streamlining the Blockchain Journey

In our ongoing exploration of blockchain technology, we've laid a solid foundation for our Rock, Paper, Scissors game with a fair wager system. As we wrap up this episode, let's take a moment to consolidate what we've achieved.

Simplifying with the Contract Function

As we progress, it's crucial to remember that the blockchain landscape is ever-evolving. In our journey, we've used the deploy and attach functions, but it's worth noting that these tools may change over time. To adapt to these changes, we can use the contract function instead of deploy and attach. This flexibility ensures that our code remains robust and adaptable.

Our Progress So Far

While our application might not seem like much at this stage, we've successfully set up the scaffolding to build upon. Our Rock, Paper, Scissors game is taking shape, and with each step, we're moving closer to a fully functional blockchain-based game. We've leveraged the power of the Reach platform to generate a smart contract, create a backend, and establish a frontend. Running our application on the Reach developer network is just the beginning.

What Lies Ahead

In the future, we can automate much of this process with tools like Reach and Net. These tools streamline the development and deployment of blockchain applications, making the process more efficient. However, understanding the core concepts and the code behind it all is essential for any blockchain developer.

A Note of Thanks

Before we conclude, I'd like to express my gratitude to Algorand, Reach, and the entire blockchain community for their support and sponsorship of this series. Their contributions make it possible for us to explore the exciting world of blockchain development.

Join the Blockchain Conversation

If you're eager to delve deeper into blockchain development or have questions about our journey, I invite you to join me in the Reach Discord community. You can find us in the "Days of Blockchain" channel, where we discuss all things related to blockchain technology.

What's Next?

In our upcoming blog, we'll dive into the heart of our project – the logic behind Rock, Paper, Scissors. Stay tuned for an exciting exploration of how blockchain technology transforms a simple game into a secure and transparent experience.

Until next time, keep coding and continue your journey into the fascinating realm of blockchain technology.


Leave a comment