Check out my new course Learn you some Lambda best practice for great good! and learn the best practices for performance, cost, security, resilience, observability and scalability.
Here Be Monsters is one year old!
Big things are happening behind the scenes in the world of our episodic MMORPG Here Be Monsters, since the beta started back in September 2012 we have attracted a small but dedicated group of players who have watched the game grew with us and who has lived through the majority of the first two episodes of the evolving storyline in Here Be Monsters and we thank everyone for their continued support and faith in our ability to deliver.
Major refactoring on the way
We have learnt an awful lot this past year and over time we have added many features and capabilities to our system so that our game designers can continue to create new and fun contents for our players. After much deliberation we have decided to rework large parts of the first two episodes of the game (Europe and Nanjing) because:
- our game designers can create much more interesting contents these days as they are no longer limited by the system capabilities we had a year ago
- we have a better understanding of what types of contents our players find most interesting and fun to play through feedbacks and analysis
We hope the refactored quest lines will be much more engaging and allow players to see the best the world of Here Be Monsters has to offer. The new quest lines are under the last stages of testing and once ready will be available for new players joining the game from there after.
Balancing the Economy
Balancing a RPG, or any game for that matter, is never easy, and often:
- laborious – involving many iterations of trial and error, and likely repeated each time new contents are added
- subjective – what ‘feels’ right can vary greatly from person to person
with hundreds of quests and recipes and thousands of items already available in Here Be Monster and many more added on a weekly/bi-weekly basis, manual balancing is simply not a solution that will scale, especially for a relatively small team as ours.
Instead, we have opted for a more automated process where by every item’s intrinsic value in the game can be evaluated based on the values of its inputs (e.g. bait for monsters, and ingredients for crafted items, etc.), the amount of time involved and your chance of success. Once we are able to definitely say what the intrinsic value of an item is, it can then be used to derive or quantify other less tangible aspects of the game’s model.
Economic value of items
How much an item can be purchased with and sold for should be directly proportional to the item’s intrinsic value.
Difficulty and Reward for quests and achievements
Many quests and achievements involves acquiring items (via foraging, farming, chipping rocks, etc.) or catching monsters, and their difficulty can therefore be quantified by the intrinsic values of the items/monster involved.
Once you can quantify the difficulty of quests and achievements, you can then balance their rewards against their level of difficulty so that players are always appropriately rewarded for their efforts.
Progression through the game
Since the storyline of the game is largely driven by a sequence of core story quests, and if you are able to quantify the difficulty of the quests you can then use that knowledge to ensure a smooth progression through the quests so that players are given tasks that are appropriate to their level at that point in the game and not bored by dull, unchallenging tasks or; frustrated by tasks that are clearly beyond their ability to complete within a reasonable amount of time and effort.
Of course, not everything is straight forward and there are many types of quests and items which we can’t easily quantify using our model and at the same time we also don’t want the game to feel cold and formulated so a guided form of human subjectivity is still very much a necessity in the process (although importantly, as a supplement rather than the driving force).
Once again, this major change in the underlying economic model is well underway and very close to being released into the game, we certainly have some exciting times ahead!
The Complexity Challenge
One of the main challenges that came up in our effort to automate the economic balancing was that we really needed to understand the complex relationships between the items, quests, achievements as well as locations and activities that can be performed against/with specific items at specific locations.
To look at a specific example, let’s consider everyone’s favourite mythical creature, the Bigfoot:
to catch the Bigfoot (in order to cure him of the corruption caused by Stariums, no harms are done to creatures that you catch I must add), you need to consider:
- location – Bigfoot is only available in particular parts of the world
- bait – to lure him out you need the Alluring Goat which gives you a roughly 4 out of 7 chance of seeing the monster
- trap – you need a trap strong enough to hold him after you’ve managed to lure him out, and only the Musket-teer Trap is strong enough for the task when it comes to the Bigfoot, even then you only have 5 out of 7 chance of succeeding (which is pretty good, considering!)
- loot – upon successful of a Bigfoot you occasionally get a loot drop which you might need in future quests or to make other items which requires the loot as an ingredient
Looking beyond the immediate connections to the Bigfoot, you have the Alluring Goat and Musket-teer Trap which each have numerous connections of their own.
To make the Alluring Goat, you need to gather
- Honey (which you need to harvest from Bee Hives you have to build in your homestead)
- Goat (which you can buy baby goat from animal traders in cities around the world such as London and Nanjing)
- Golden Hair (which is a loot drop when you catch Blonde Mermaid, Dandelion Pixie and Blonde Selkie monsters)
- Fiery Hair (which is a loot drop when you catch Redheaded Mermaid, Banksia Pixie and Redhead Selkie monsters)
- Yeit Fur (which is a loot drop when you catch the Yeti monster)
And similarly the Musket-teer Trap requires a number of ingredients to make, each requiring their own ingredients and so on and so forth, you get the idea.
There can be an arbitrary level of connections between two items, some even recursive, and it’s nigh-on impossible for any one person to understand and rationalize all of these connections in order to make informed decisions around the design and validation of the proposed economic model. We needed a way to store and query against these connections to help us answer questions about our data model in order to build an economic model that runs along it.
If you have been following the NoSQL movement the last couple of years then you might have heard about graph databases. In case you have missed all the fun (and public confusion, debates and misguided PR about what it is and why we should care), check out my slidedeck below to get a quick introduction to the vast landscape of NoSQL.
One of the more mature and most widely used graph database today is Neo4j, and whilst graph databases are most frequently associated with social data (friends, followers, etc.) thanks to the prominence of companies that are operating in that space, but they’re actually very powerful and scalable ways to store and query any form of highly connected and/or complex data in general and have use cases beyond modelling social data, including fraud detection and network management.
Disclosure : my employer, Gamesys, already uses Neo4j for a number of social features in our real money gaming business so the choice of using Neo4j was an obvious one since we already have both operational knowledge as well as site license within the company. I didn’t go through a careful venting process to decide which graph db to go with.
If you represent every item in the game, ever location, recipe, monster, fish, etc. as nodes on a graph and linking them with relationships such as:
- item A drops item B as loot
- item A is available at location X
- monster A can be lured by item B
- monster A can be caught by item B
you end up with something along the lines of:
This diagram illustrates the highly connected and complex nature of the data we’re dealing with, the result of us making a game where everything you can do and every item you find has a purpose and can be used for something else.
Each node and relationship also has a set of metadata associated with it, for instance the can_catch relationship contains the probability (or catch rate) whilst the Musket-teer Trap node contains the buy/sell price as well as stats of the trap and many more.
This diagram is also by no means an unconnected subset of the overall graph, for simplicity sake I have omitted many types of relationship and connected nodes. Visualizing the 5000+ nodes and around 25000 relationships in Gephi (using a Neo4j plugin), with the colour and size of the nodes representative of the number of connections it has, this is what the internal data model for Here Be Monster looks like from afar:
As you can see, the degree of connectedness varies greatly, and for common low-level monsters such as Sylph, Spriggan, Sprite and Salamander, they are each connected to no less than 300 location, trap and item nodes.
Similarly, for common ingredients such as Salt, which can be found through many items (e.g. most fish drops seaweed and salt as loot when you catch them) and are used in the recipes of many items (Pastry, Pizza Base, Ketchup just to name a few)
With the internal data model captured as a huge graph in Neo4j, we were then able to ask questions that would have been difficult or impossible to answer otherwise.
To give you a few examples.
An item can be connected to other items, quests, achievements, monsters, and even level up rewards through n-levels of connections, so changing the value of an item can cause unforeseen and unintentional knock-on effects further down the chain (think the butterfly effect but in a miniature scale).
Neo4j allows us to start with the said item, easily and quickly traverse through the graph to identify all the nodes that are connected to it through arbitrary levels of connections.
By design, in order to catch those high-level, rare monsters, you will first catch lower-level more common monsters in the same family of related monster as you need their loot to make the baits for higher level monsters.
Going back to the Bigfoot example. You need to first catch the Yowie, use its loot to make the baits for the Yeti, and use the Yeti’s loot to make the bait for the Bigfoot which represents the top of this particular chain and whose loot drop will then be used in future quests and/or monsters.
To understand the total amount of effort required to catch the monster at the top of its chain, and to acquire its loot (which could be the goal if you need it to progress on a quest), you need to:
- identify the monsters on the chain
- take into account the attraction rate and catch rate of the baits and traps capable of luring and catching each of the monsters along the chain
- drop rate of each monster’s loot and the amount of effort required to make the bait for the next monster (time, success rate, number of loots required, etc.)
Again, this is a difficult question to answer considering there are more than 100 live monsters and more are added regularly, with many such chains leading to one another.
As you explore the world of Here Be Monsters, you will find different types of trees, plants, rocks, butterflies, and many more, depending on where you are. For instance, you can forage durians from durian trees, but durian trees are available in certain parts of the world as you can see from the screenshots below.
The scarcity of durian (and durian trees) is therefore linked to the number of travelable spots in the parts of the world where they durian trees are available.
With Neo4j’s help, to understand the scarcity of items in the world it became a simple query to aggregate the is_available_at relationships between items and locations. As you’ve probably guessed already, this also applies to monsters and fish which are also available at specific parts of the world.
So there, I hope you find these insights into the world of Here Be Monsters interesting and thanks to the guys at Neo Technology for building such a wonderful product!
I specialise in rapidly transitioning teams to serverless and building production-ready services on AWS.
Are you struggling with serverless or need guidance on best practices? Do you want someone to review your architecture and help you avoid costly mistakes down the line? Whatever the case, I’m here to help.
Check out my new course, Learn you some Lambda best practice for great good! In this course, you will learn best practices for working with AWS Lambda in terms of performance, cost, security, scalability, resilience and observability. Enrol now and enjoy a special preorder price of £9.99 (~$13).
Are you working with Serverless and looking for expert training to level-up your skills? Or are you looking for a solid foundation to start from? Look no further, register for my Production-Ready Serverless workshop to learn how to build production-grade Serverless applications!
Here is a complete list of all my posts on serverless and AWS Lambda. In the meantime, here are a few of my most popular blog posts.
- Lambda optimization tip – enable HTTP keep-alive
- You are thinking about serverless costs all wrong
- Many faced threats to Serverless security
- We can do better than percentile latencies
- I’m afraid you’re thinking about AWS Lambda cold starts all wrong
- Yubl’s road to Serverless
- AWS Lambda – should you have few monolithic functions or many single-purposed functions?
- AWS Lambda – compare coldstart time with different languages, memory and code sizes
- Guys, we’re doing pagination wrong