On this page

latest contributor to this doc

Last Edit:

@gcharang

Rogue Module Tutorial

This tutorial documentation is associated with the Rogue API documentation.

Link to Rogue API documentation

The Rogue Antara module serves as a proof-of-concept to demonstrate Antara's capabilities as a blockchain-based gaming technology.

The Rogue module is based on the classic Rogue game. As such, it can be categorized as a Roguelike.

The core aspects of Rogue gameplay occur on the blockchain. These aspects include such data as character health points, items, movement, attacks, and other relevant game states.

Komodo's Rogue implementation makes use of the classic on-screen visual representation of gameplay. This interface relies on ASCII characters to represent characters, items, and other in-game objects and actions.

The procedures to launch and finish a game require the execution of various methods (RPCs). To make the game more easy to start and finish for players who are not comfortable with the terminal, the Komodo team has created a Terminal User Interface (TUI).

The following installation and walkthrough tutorials can assist the reader in testing Rogue. For more information, please reach out to our community on Discord. The #cc-rogue channel is available for questions and assistance.

Rogue is available for modern MacOS, Linux, and Windows operating systems.

Komodo provides downloadable software bundles that contain all necessary components. The user need only download and unzip the contents for their appropriate operating system and they are ready for gameplay.

Software bundles can be found in the link below:

Link to software bundles

Please feel free to ask on our #cc-rogue channel on Discord for updates and assistance.

The following instructions are necessary only for users/developers who wish to compile Rogue software from source code. Users who have already downloaded the software bundles linked above do not need to compile source code manually.

sudo apt-get update && sudo apt-get upgrade -y
sudo apt-get install build-essential pkg-config libc6-dev m4 g++-multilib autoconf libtool ncurses-dev unzip git python zlib1g-dev wget bsdmainutils automake libboost-all-dev libssl-dev libprotobuf-dev protobuf-compiler libgtest-dev libqt4-dev libqrencode-dev libdb++-dev ntp ntpdate software-properties-common curl libcurl4-gnutls-dev cmake clang libsodium-dev -y

Use the terminal to ensure the MacOS XCode tools are installed:

xcode-select --install

Ensure the latest version of brew is installed. If necessary, execute the following command:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Once brew is installed, execute each of the following commands:

brew update
brew upgrade
brew tap discoteq/discoteq; brew install flock
brew install autoconf autogen automake
brew install gcc@6
brew install binutils
brew install protobuf
brew install coreutils
brew install wget

Playing Rogue on Windows requires an installation of MinGW, which can be downloaded here:

Link to MinGW

Once installed, use a Debian cross-compilation setup and run the following commands in Linux:

sudo apt-get install build-essential pkg-config libc6-dev m4 g++-multilib autoconf libtool ncurses-dev unzip git python python-zmq zlib1g-dev wget libcurl4-gnutls-dev bsdmainutils automake curl cmake mingw-w64
curl https://sh.rustup.rs -sSf | sh
source $HOME/.cargo/env
rustup target add x86_64-pc-windows-gnu

cd ~
git clone https://github.com/jl777/komodo
cd komodo
git checkout FSM
./zcutil/fetch-params.sh
./zcutil/build.sh -j$(nproc)
cd ~
git clone https://github.com/jl777/komodo
cd komodo
git checkout FSM
./zcutil/fetch-params.sh
./zcutil/build-mac.sh -j8
git clone https://github.com/jl777/komodo
cd komodo
git checkout FSM
./zcutil/fetch-params.sh
./zcutil/build-win.sh -j8
#This can take some time.

Change the 8 in the -j8 portion of the last command to any number of processor threads desired and/or appropriate for your machine.

cd ~/komodo
git checkout FSM
git pull
./zcutil/build.sh -j$(nproc)

Start the ROGUE chain with the following command in a terminal window and wait for the daemon to sync. Keep this terminal open and the daemon running for the duration of your Rogue gameplay.

cd ~/komodo/src
./komodod -ac_name=ROGUE -ac_supply=1000000 -addnode=5.9.102.210  -ac_cclib=rogue -ac_perc=10000000 -ac_reward=100000000 -ac_cc=60001 -ac_script=2ea22c80203d1579313abe7d8ea85f48c65ea66fc512c878c0d0e6f6d54036669de940febf8103120c008203000401cc -daemon

Open a new terminal. This terminal can be used to execute all remaining installation and gameplay commands.

./komodo-cli -ac_name=ROGUE getnewaddress

The returned value is a ROGUE address. We need to find the associated pubkey for this address.

Use the validateaddress method with the address.

./komodo-cli -ac_name=ROGUE validateaddress insert_address_here

The validateaddress method will return information similar to the following:

{
  "isvalid": true,
  "address": "RPCeZmqW4Aam52DFLmMraWtu5CuXPxqk92",
  "scriptPubKey": "76a91498b5caa42ffe9868844c51ba6e085e5e7e92fc2588ac",
  "segid": 13,
  "ismine": true,
  "iswatchonly": false,
  "isscript": false,
  "pubkey": "02f183a71e93dfa7672ce7212187e45eabcf4077fed575348504b20295751ab1a2",
  "iscompressed": true,
  "account": ""
}

Look for the pubkey value:

"pubkey": "02f183a71e93dfa7672ce7212187e45eabcf4077fed575348504b20295751ab1a2",

This is the pubkey for our address.

Set the pubkey for the ROGUE Smart Chain.

./komodo-cli -ac_name=ROGUE setpubkey 02f183a71e93dfa7672ce7212187e45eabcf4077fed575348504b20295751ab1a2

The pubkey is now set.

To reuse this pubkey in the future, include the pubkey as a pubkey launch parameter.

Include the pubkey in the -pubkey launch parameter as follows:

cd ~/komodo/src
./komodod -ac_name=ROGUE -pubkey=02f183a71e93dfa7672ce7212187e45eabcf4077fed575348504b20295751ab1a2 -ac_supply=1000000 -addnode=5.9.102.210  -ac_cclib=rogue -ac_perc=10000000 -ac_reward=100000000 -ac_cc=60001 -ac_script=2ea22c80203d1579313abe7d8ea85f48c65ea66fc512c878c0d0e6f6d54036669de940febf8103120c008203000401cc -daemon

Komodo offers an unofficial Terminal User Interface (TUI) to allow players to launch and conclude a game without having to interact with the module's API commands. The TUI software is provided for testing and ease-of-use purposes only.

Use of the TUI is optional, but recommended for most players.

The TUI software can be found in the downloadable software bundles:

Link to downloadable software bundles

Under normal circumstances, a user does not need to manually execute methods in the terminal to launch and conclude a game. Rather, the downloadable software bundles contain all necessary tools to play.

For users/developers who need a reference for the manual process, the following walkthroughs provide detailed step-by-step instructions.

Open a new terminal and navigate to the ~/komodo/src directory:

cd ~/komodo/src

Create a new game via the newgame method. For this example, we choose to have a single player with a 0 buy-in requirement.

Methods for ROGUE require the use of the cclib method. The Rogue module's required EVALCODE for the cclib method is 17.

Command:

./komodo-cli -ac_name=ROGUE cclib newgame 17 "[1]"

The ROGUE software currently broadcasts the hex value automatically. It is not necessary to use the sendrawtransaction method.

The returned transaction id txid is the gametxid. Save this for future use.

Check the game's state using the gameinfo method:

Command:

./komodo-cli -ac_name=ROGUE cclib gameinfo 17 '["09d702b9bf678ee9d4efc29354566b4453e2e4ebdf7bac3496e667e8d435fe70"]'

In the returned json object, observe the run value. This lists the specific command that must be executed in the terminal to register the game.

Register the gametxid using the register method:

./komodo-cli -ac_name=ROGUE cclib register 17 '["09d702b9bf678ee9d4efc29354566b4453e2e4ebdf7bac3496e667e8d435fe70"]'

Check the game's current state again using the gameinfo method. Use the gametxid as an argument:

./komodo-cli -ac_name=ROGUE cclib gameinfo 17 '["09d702b9bf678ee9d4efc29354566b4453e2e4ebdf7bac3496e667e8d435fe70"]'

Note that the gameinfo method now returned a seed value, as well as player data.

In the returned json object, find the run value. This is the exact command needed to start the game.

Wait until the network mines the register_txid. Optionally, use the getrawmempool method to monitor the status of the transaction.

Once the transaction is mined, execute the run command (found in the returned json object earlier) to start the game:

cc/rogue/rogue 3767108440867690538 09d702b9bf678ee9d4efc29354566b4453e2e4ebdf7bac3496e667e8d435fe70

The game is now running and should be visible on-screen.

For instructions on in-game controls and objectives, read this linked section.

If your character is still alive and you would like to leave the game while keeping your profits, follow this procedure to save your character:

To quit the game, type the letter Q on the keyboard. This opens a context menu. Type the letter n and press Enter.

This begins the process of leaving the game, but you are not finished yet.

Wait for the ROGUE network to mine all keystrokes transactions. To see a list of all keystrokes created, check the keystrokes.log file in the ~/komodo/src directory, and use the getrawmempool method to verify when the last keystrokes are mined.

When the last transactions are mined, execute the bailout method to leave the game while keeping the character and items in your pubkey, and the method will also transfer your in-game gold to ROGUE coins.

For example:

./komodo-cli -ac_name=ROGUE cclib bailout 17 '["09d702b9bf678ee9d4efc29354566b4453e2e4ebdf7bac3496e667e8d435fe70"]'

After the bailout transaction is mined the player may view their surviving character(s) via the players and playerinfo methods.

In this walkthrough we have used single-player mode. The following highlander method is only available if the character manages to capture the amulet and safely exit the dungeon. In a normal multi-player game, the highlander method is available to either the first player to safely retrieve the amulet, or to the last player standing after all others have died.

The player that successfully executes the highlander method receives a prize: the collective value of all ROGUE coins that were contributed during the buy-in stage.

The highlander method is executed as follows:

./komodo-cli -ac_name=ROGUE cclib highlander 17 '["4fd6f5cad0fac455e5989ca6eef111b00292845447075a802e9335879146ad5a"]'

After the highlander transaction is mined the player may view their surviving character(s) via the players and playerinfo methods.

In this walktrough we use two nodes to play a multi-player game of Rogue.

  • Node 1 is player1
  • Node 2 is player2

For educational purposes, we execute all methods manually, as opposed to using the TUI.

Open a new terminal and navigate to the ~/komodo/src directory:

cd ~/komodo/src

For this game, we choose the following details:

  • the max number of players: 2
  • the cost in ROGUE coins of the game buyin: 0.1

Execute the newgame method on player1 as follows:

./komodo-cli -ac_name=ROGUE cclib newgame 17 '["2","0.1"]'

Save the returned txid value for future use. This is our gametxid.

Use the gameinfo method to check information about the game:

./komodo-cli -ac_name=ROGUE cclib gameinfo 17 '["4ccf9ca8b1198b35b48dc7126c6b9648b243c44076e4c4e4fe474b129028abde"]'

As shown in the returned json object, the game has a maxplayers value of 2 and an openslots value of 0, as no players have joined.

Note that the gameheight value is 54265. This is the block height at which the gametxid was created.

Also note that the start value is 54270. This is the block height at which the seed value will be revealed, allowing players to generate the level design and begin the game.

For our example, player1 would like to use an existing character that survived a previous game. This allows player1 to start with all the advantages this character achieved previously, including character statistics and items.

To activate the existing character, player1 includes the associated playertxid for the character when executing the register method. (The playertxid values of any pubkey can be found using the players method.)

The player also includes the gametxid as the first argument of the register method.

./komodo-cli -ac_name=ROGUE cclib register 17 '["4ccf9ca8b1198b35b48dc7126c6b9648b243c44076e4c4e4fe474b129028abde","8005f81a604df6bbfae91dc8252505df43edbdf06492a2201362cb42dba4d8f2"]'

In our example, the player2 node does not have a character from a previous game, and therefore player2 executes the register method with only the gametxid.

./komodo-cli -ac_name=ROGUE cclib register 17 '["4ccf9ca8b1198b35b48dc7126c6b9648b243c44076e4c4e4fe474b129028abde"]'

Wait until the txid values returned on both nodes are mined. (Use the getrawmempool method to check the transaction's status.)

After the transactions are mined, use the gameinfo method to check the game's status again:

./komodo-cli -ac_name=ROGUE cclib gameinfo 17 '["4ccf9ca8b1198b35b48dc7126c6b9648b243c44076e4c4e4fe474b129028abde"]'

The openslots value is now 0, as 2 players have joined.

Note also that the start block height has past, and therefore the seed value is available.

Also note that the response includes information about the playertxid character provided by player1 during registration.

The game is prepared. Both players may begin the game using the command found in the returned run value.

cc/rogue/rogue 3928429259918614461 4ccf9ca8b1198b35b48dc7126c6b9648b243c44076e4c4e4fe474b129028abde

View this linked section for instructions on gameplay.

In our example, player1 decides to bail out of the game without waiting until player2 dies, and without retrieving the amulet from the dungeon.

To exit, player1 executes the bailout method:

./komodo-cli -ac_name=ROGUE cclib bailout 17 '["4ccf9ca8b1198b35b48dc7126c6b9648b243c44076e4c4e4fe474b129028abde"]'

With the bailout transaction mined, the gameinfo method now returns updated information:

Command:

./komodo-cli -ac_name=ROGUE cclib gameinfo 17 '["4ccf9ca8b1198b35b48dc7126c6b9648b243c44076e4c4e4fe474b129028abde"]'

Note that the alive property has a value of 1, indicating that the player1 character has left and the player2 character remains. Also note that in the players array, the first json object (which describes the player1 node) has a status of finished.

Since player1 left early, player2 is the last character standing. The highlander method is now available to him.

player2 first begins the exit procedure by entering Q, then y + Enter.

With the exit process in motion, player2 executes the highlander method:

./komodo-cli -ac_name=ROGUE cclib highlander 17 '["4ccf9ca8b1198b35b48dc7126c6b9648b243c44076e4c4e4fe474b129028abde"]'

The multi-player game is now finished. The player2 node received the highlander prize, including the total buyin amount and an increased conversion rate of in-game gold to ROGUE coins.

After the bailout and highlander transactions are mined, the players may view their surviving character via the players and playerinfo methods.

As Komodo's Rogue implementation is based off of the classic Rogue game, the classic manual provides the basic instructions for the game:

Link to Classic Rogue Manual Here

After reading the linked manual, there are additional aspects to keep in mind for Komodo's unique implementation.

Komodo's Rogue features two different game modes. There is one mode for single-player gameplay, where the maxplayer value is set to 1, and one mode for multi-player gameplay, where the maxplayer value is greater than 1.

The single-player mode is more limited in nature. In general, this mode is for practicing or farming purposes.

There are no time limits.

As soon as the register_txid is confirmed the player may begin to play.

When concluding the game, the conversion of in-game gold to ROGUE coins is halved. See the highlander and bailout methods for further details.

If more than one player is allowed in the game parameters, the game goes into "Highlander" mode. In this mode, there can be only one winner of each game. The winner is either the last player standing, or the first player to retrieve the amulet and successfully exit the dungeon.

Multi-player mode also adds a time limit that is based on the frequency of keystrokes. So long as the players are frequently entering commands, the time limit will expire in approximately one hour. If players are not frequently entering keystrokes, the time limit can vary.

There is a waiting period after the gametxid is confirmed. This ensures that no player receives an unfair advantage via advanced knowledge of the start time. The delay is 5 blocks. On a default Smart Chain, this creates a 5 minute wait period. Once the 5 blocks are mined, the Smart Chain automatically reveals a seed that is created using blockchain-based provable randomization. The seed provides the basis for level-design generation. After the level is generated, the players may begin to play.

Due to the fact that the entropy (based on the seed) was the same for both players during level generation, both players will begin at dungeon-level 1. However, the generation of levels greater than 1 take into account the gameplay of the characters, and therefore the level designs will be different for each player.

There are two methods for winning the game. The most direct way to win the game is to obtain the amulet and return from the dungeon. Alternatively, the player also may win by having the last surviving character. The winner receives all of the buyin coins that were originally contributed, as well as an increased conversion ratio for their in-game gold to ROGUE reward.

See the highlander method for further details.

Due to the nature of saving and reusing characters, the Komodo implementation of Rogue changes the manner in which the user saves characters. Instead of typing s on the keyboard, type Q + y + Enter, then execute the bailout method to conclude the game.

If a player successfully uses either the highlander or bailout method to conclude a game, the player may save their character, items, and achieved characteristics. They also convert the character's in-game gold to ROGUE coins. The ratio of conversion depends upon the game conditions; see the highlander and bailout methods for further details.

When either of these methods are executed, the returned response includes a playertxid transaction id. The playertxid represents the state of this character at the completion of the game. It is used as an argument for the register method when recalling the character, items, and achieved characteristics into a future game.

The playertxid value changes with each game, and therefore only the most recent playertxid for a character should be used. To see a complete list of current playertxid values belonging to the user's pubkey, use the playerinfo method.

When the user registers an existing character, the game dungeon's difficulty begins at level 1, and the character has no gold (as it was converted to ROGUE coins). Also, even if the character has armor and a wielded weapon in their item list, these items are not equipped by default. The player must equip them at the start of the game by typing the letters w for weapon and W for armor.

One gameplay element that the Komodo team has changed from classic Rogue is the ability to scale the amount of inventory the character may carry according to the character's strength. The formula is as follows:

current max inventory = character strength * 2

The highest max inventory value is 23 unique letters. Throwable-object packages count as a single item.

If the user bails out of a game while holding more items than they are allowed to carry, the game will automatically flush items from the character's inventory as a part of the bailout method.

A character that survived a game is also a non-fungible asset and can be traded on the blockchain. When trading a character, the user does not use the playertxid value. Rather, the user employs the tokentxid value. This tokentxid is used in coordination with the Tokens Antara Module module for on-chain trading.

The tokentxid can be found by using the playerinfo method and submitting the known playertxid as an argument. For more information, see the playerinfo method.

The tokentxid is created at the character's initial creation and does not change throughout the character's life. When the character dies, the tokentxid is sent to a burn address, making the character permanently unplayable.