Programming a turn based role playing game with Sphero BOLT

Ashleigh Bartlett-Needham
7 min readJan 22, 2020

--

Create your own D&D game night with Sphero BOLT

One of the coolest aspects of the Sphero BOLT is the complete programming freedom. From maze solving to quizzes, you can create endless codes for this app enabled robot ball. And the programmable LED matrix is also a nice touch, adding to the level of creativity on offer. So I decided to push this to the limit, aiming to create an immersive, turn based RPG.

Sphero BOLT turn based RPG mechanics

To create this turn based role playing game, there were a number of game mechanics that had to be established. These include:

  • Speech- To deliver the story-line and quests, and indicate points where player interaction is necessary, the “await speak” command had to be used. As a result, all of the story-line is delivered through speech, in a similar way to table top RPG’s.
  • Shaking BOLT- Velocity is the easiest of BOLT’s many sensors to measure, for all players, without needing to calibrate the robot first. This means that shaking Sphero BOLT is a simple way for users to make a choice and play the game.
By measuring the combined velocity of the Sphero BOLT, it is easy to establish when the robot has been shaken.

Getting started

To get started with this project, there were a number of things to decide on, including:

  • The type of setting- I opted for the typical medieval castle/dungeon as the setting for the RPG.
  • The class types- In this game you can choose between two classes, a fighter and a mage.
  • The quest line- I wanted to keep this RPG fairly simple, due to the limitations of the device. So I opted for a simple dungeon style quest line where the hero (you) has to find a lost item by moving through the dungeon, slaying monsters.

That said, the first thing the user is asked to do as part of this program is to select a class.

(Finished ice staff animation for the class type) JavaScript code for choosing a class. (Ice staff in app design)

From there, the player is given some information regarding their starting weapon, and the quest. This will depend on the chosen class, as each has a slightly different mission, and will face different enemies. This is all established in the many variables within each class function.

The class functions allow a number of variables to be assigned different values, which will be used to determine the course of the game.

Setting different functions

For a game of this size to work, different functions were necessary. As well as functions for defining each character class, as shown above, other functions needed include:

  • Each quest line- when adding in a checkpoint system the quest lines had to be divided into different functions for each part of the quest line. This includes the final part of the quest, where the quest item is retrieved.
  • Opponent choice- a function to establish which opponent you are fighting each time, is important so that the player fights a range of opponents. There are 8 different opponents altogether.
(Finished Skeleton animation) JavaScript code for determining which opponent you will battle. (In app Skeleton animation design)
  • Health points- storing the health points in a function helps to keep track of them during each battle. It was also necessary to create separate function for the health points of the opponent.
  • Attack damage- a function to establish the damage caused by each attack is needed, as this will be called multiple times throughout the game. A separate function is also important to establish the damage caused by the opponents. These functions link closely with the health point functions too.
  • Checkpoint- added in later on in the development stages, the checkpoint function allows the player to restart at an earlier point, after losing all of the health points.

Developing a combat system for a turn based RPG

Fighting a fire troll.

Creating a combat system was complicated and there were several different iterations of the combat system before the final version was selected. These were the stages of development:

  1. A combat system where the user would shake BOLT to “roll the dice”, shown on the LED matrix, which would then determine the attack damage. This system made an effective link to the D&D style RPG games, but it did involve a lot of shaking.
  2. A combat system where the attack damage is based on a random integer, decided by the program, rather than the “roll the dice” animation. This was more straightforward for the user, but it also felt a little less immersive.
  3. A combat system where the player can choose between 2 different attack options, by shaking the BOLT. Different attacks result in different amounts of random damage. The first attack option will deal between 20 and 30 points of damage. The second attack option has a 20% chance of failing completely, a 60% chance of causing 30 to 40 points of damage, and a 20% chance of activating a power attack, causing 40 to 50 points of damage.
Being able to choose an attack is an important part of any turn based RPG.

In the end I opted for choice number 3, but I also added a “block” option for attacks too, which allows you to block the next, incoming attack. However, this will not deal any damage to your opponent.

Enemy attacks are set to a random integer, with boss enemies dealing larger amounts of damage than common dungeon enemies.

Visual feedback for damage caused

Providing feedback for the amount of damage caused by the players attack, and by the enemy attack, was also a necessary consideration. Initially I set this up as a spoken review, after each attack, but between choosing the attack, and announcing the enemy attack, there seemed to be too much speech. Instead a visual feedback system is used. This shows the enemy health as measured in a green heart animation, and the players health as measured in a red heart. This provides instant visual recognition, so you can plan and strategise your next attack accordingly.

(Finished animation for player health) In app player health design. (JavaScript code for determining the player health during battle)

Checkpoints

Another aspect necessary to include for any RPG are checkpoints. One of the limitations in creating a turn based RPG for the Sphero BOLT is that progress cannot be saved between games. So once the program ends, any data is lost. However, while the program is still running, it is possible to go back to an earlier point. Checkpoints are used to save progress at various points, so that if the player is unlucky in battle, they don’t have to replay too many enemies again, to return to where they were before losing health points.

To do this, the quest stages have been broken up into different functions. This means that the player can restart at the beginning of the latest dungeon chamber, without needing to replay the earlier part of the game.

Healing

After each dungeon chamber the user can heal with a healing potion. This is not optional, as without healing you will be sure to lose health in the following chamber. Each healing point is the same for each class and quest line and works as a repeated function for a more efficient program. This restores the hp variable to 100 points.

(Healing potion design in app) Finished Healing potion animation. (JavaScript code for healing points)

Finishing touches

Animation and sound effects were added once all the mechanics were in place (it was actually at this point that the thief quest line had to be removed, in order to run the program on Sphero Edu). The animations displayed on the LED matrix provide visual interest in line with the story which is told through speech. The sound effects are used for dramatic effect, and to create a more immersive player experience.

The finished project

The finished project is a turn-based adventure quest that involves shaking Sphero to make choices and take action. The player will need to listen to the emerging story line, as they delve into the dungeon and battle monsters in the dark.

There are an unlimited number of lives, but each time you lose health points you will need to replay the game from the last checkpoint. It can take between 4 and 10 minutes to complete one play through of the game, realistically. This means you can play through easily, without Sphero BOLT running out of charge. And if you choose a different class, you can then embark on a different quest the second time around.

This is a link to the Sphero EDU program.

If you want access to the direct JavaScript code just let me know :)

--

--