Welcome to our fifth installment discussing how we built a dungeon crawler in Salesforce. If you haven't had a chance to try the game yet, we'd recommend you mosey on over there and give it a go first. The context will help. It's free to play and we'd love any and all feedback. Find it here: https://www.cloudpacific.tech/blockzero
Today we will hit on a bunch of smaller topics of interest that are by no means small, but merely loose ends that we should touch on before we close out this blog series.
User Interface & Mobile
Our original User Interface for the game was clunky. We thought it was rather good, but as soon as we handed it to the wolves (first round testers) it became apparent that what we had built needed some serious revising.
The original UI had the Map on the left, the location to the right of the map, the enemy information under that, and finally on the right-hand side, all of the stats. You can't see the far-right column in the image here.
There was also no mobile support at that time. I wish we could show more of the original interface but that version was scrapped and those sandboxes refreshed before we ever thought about documenting it.
A great bit of feedback we received was to remove the stats from the main UI. The stats were informative but didn't change all that often and it didn't make sense to take up 1/3 of the screen real estate.
That was a fair critique.
We were also asked to build this for mobile. Users knew the game wasn't built for mobile and we discouraged playing it on mobile, and yet those users still tried playing it on mobile and complained about how it didn't work well on mobile.
Sigh. This is why we live in a 'mobile-first' world and why we should have built the UI for mobile in the first place. We'll walk through all of the main mobile screens.
Here you can see we have started the game and the flow starts. One of the great things about flows is they are already mobile-ready. No changes were needed functionally to get this to work. However, the text was really long for the flow screens, which caused the user to scroll. Scrolling on a mobile screen on a flow embedded in a modal makes the experience super jittery. So, we shortened the text so no scrolling would be needed.
The main interface includes all of the relevant information for navigation, the story-line and resource management. We had many requests to make the location images and the map more prominent. On the bottom right of the interface, you will notice arrow buttons that are used to move the character around the map. The database icon button (looks like stacked coins) is where all of the stats and game information is now held.
Let's click on that button.
All stats and character attributes are here in this new modal, while fitting well on a mobile screen. We also created a tab for Inventory and another button on Game Play instructions.
Let's click Inventory.
There is nothing really to view here yet at the start of the game. But here is where a player will hold all of their items and perks as they go through the game. We'll lightly touch on the inventory system in the next section.
Now, we click Done and then Game Play.
Game Play contains all of the same content with some of that content reduced to create a better scrolling experience as we already mentioned earlier.
We then tap out of the modals and move on the map to get to a battle.
When a character enters into battle, a modal pops up. This was probably the largest change in the UI, and was intentional so as to move the players attention completely to the battle, as the player is unable to do anything but engage in battle.
Here we have all of the necessary information, including relevant stats, attack success, damage, as well as the ability to make either a basic attack or energy attack.
We retained the exact same interface for the desktop version, but with the desktop version the keyboard can still be used to move and attack.
A Basic Inventory System
We had really big plans for the inventory system. Originally, we wanted all of the following:
Items that could be purchased
Items that could be discovered
Items that could be picked up from defeated enemies after battle
Items that could be used whenever the player wanted
In the end, we only did #1 and #2.
Inventory systems are complicated and hard. We mapped out the architecture for a full blown inventory system, but we ran out of time. We won't go into the system we were going to build, just the one that we did build.
We'll start with #1.
All items that can be purchased are found in the Shops. Every shop has the same items for the same prices. So shops aren't unique in any way. Purchasing is basic and is found in the confirmPurchaseHelper function.
In the code, we get the characters money, get the cost of the item, subtract the cost of the item from the characters money and set the new value for the characters money. Simple. The last thing we do is check if the item that was purchased is for health or energy. If so, those items are used immediately. You do not store them. Adding in item storage and usage later would have taken another several blocks of js code and component code, as well as modal updates. So, we didn't do it.
On to #2.
On the Inventory tab, we created a grid just for the items that can be discovered. That grid is a 3 x 3 which allows the inclusion of 9 items total. There are only 9 items to be discovered in the entire game. These items don't change, meaning the cell on Row 1 Column 1 will always be for the same item. Furthermore, once these items are discovered, you cannot get rid of them. They are now permanently part of your character. Think of them as upgrades. These items, along with all of the other items we've already covered in the store, are loaded when the game begins. See the code block here:
We set up the visibility of these items to triggered using a basic aura:if tag when the player discovers the item. Since all we care about is whether or not the user has discovered the item, visually there is nothing else to do, and the character is upgraded immediately.
This is a very VERY basic system but works well and gives the player more reason to explore.
Each attribute you give your character has a number of advantages. We lay each of them out below.
Strength - Inflict greater damage to enemies in battle.
Endurance - Go greater distances before succumbing to starvation and dehydration. Suffer less damage when hit in battle.
Intelligence - Inflict greater damage to enemies in battle when using energy weapons. Receive greater stat increases when items are discovered.
Charisma - Items cost less in Shops.
Some attributes are more powerful then others; some give advantages early in the game and some later in the game. Attribute Systems are exceptionally difficult because they are integrated into the code in many places, not just one like purchasing an item from a Shop. For example, the Strength attribute is only used when attacking in battle, but the Endurance attribute is used in battle and when navigating the map. For these reasons, we won't look at code for these but wanted to mention them to highlight how they factor into game play.
BlockZero was very challenging to develop. I want to thank all of the developers, testers, and the Salesforce community that have all been exceptionally supportive. We couldn't have done it without your help and encouragement. The Salesforce community truly is one of the best.
We built the game and wrote these blog posts during the COVID-19 pandemic which dramatically slowed our work load. However, work has picked back up for us and we are moving our attention back to our clients and other internal projects. We will not forget about blockZero! A full game will be on the way when we have time to devote to it. Until then, feel free to continue to send us your feedback on our demo, and follow our blog and company, Cloud Pacific, on LinkedIn.
Happy coding & much aloha!
The Cloud Pacific Team