Background

For quite some time many players have been reporting issues with the baiting system in theHunter, chief among the symptoms being a lack of activity at bait sites. Although not an opinion shared by everyone, it seems the general consensus among the active community is that the system was altered and “broken” at some point. Some players still enjoy acceptable and in some cases generous yields at their bait sites, while others have no such luck. This inconsistency, especially for those adversely affected, has cast a shadow over the value bait sites add to the game.

Overhaul

The good news is we have spent a great deal of time reworking the system and are pleased to introduce brand new, simplified baiting mechanics. We consulted a small panel of trusted advisors from within the community during the game design review process and we feel that the new system offers a balanced and reasonable compromise. Please read this document carefully as it contains important information about how the new baiting system works, how it compares to the old system, and what players should expect in terms of results. It is important to emphasise at this stage that the old system generated far more baited animals at bait sites than Expansive Worlds ever intended from a game balance perspective in the original game design. For that reason, players should not expect the new system to be comparable.

The “Good” Old Days

The activity at a bait site in the old system was determined by a lot of variables, most of which the player had no knowledge of, or control over. For example when a feeder was placed in a reserve, the client determined how much of the attraction zone (imagine an invisible circle around the feeder) overlapped the spawn map (imagine invisible patches on the map where species can spawn) for the species in question. The result was a figure from zero to 100, based on the percentage overlap. So if approximately 75% of the feeder overlapped the spawn map for that species, the maximum attraction level that feeder could ever reach would be 75. That is just one example, there were many other variables involved, making the system utterly complicated.

Simplify

One of the objectives when setting out to rework the baiting system was to simplify it. Not only to make the experience for the players more consistent and hopefully more enjoyable, but to make the system easier to debug, maintain, and further develop in the future. To simplify the system, some important decisions were made which have changed how baiting works now. We understand that some players may have preferred a more complex system which had a lot of unknown variables resulting in unpredictable behaviour, but it is our hope that the new system will offer better value without removing all of the challenge from baiting.

Attraction

The new system no longer has any concept of attraction, formerly a number between zero and 100. A feeder now has a status, and this can either be “active”, “inactive”, or “penalty”.

• Active: The feeder contains bait and is capable of baiting species.
• Inactive: The feeder may or may not contain bait but is incapable of baiting species.
• Penalty: The feeder is currently disabled because a baited animal was shot at the site.

When you place a new feeder in a reserve and add some bait to it, the initial status of the feeder will be inactive, for a period of 4 hours (real time). During that four hour period, the feeder will not bait any animals. After the 4 hour “warm-up” period, the status of the feeder will change to active and two things will happen; the bait will start to deplete and the feeder will be capable of baiting animals.

If you let a feeder run out of bait, the next time you add bait the 4 hour “warm-up” period will start again. This can be avoided by keeping feeders topped up with bait at all times. Topping up a feeder which already contains bait does not restart the “warm-up” period. A feeder that is kept topped up with bait will always remain active and capable of baiting animals.

If you shoot a baited animal near a feeder, a 30 minute (real time) penalty is applied to that feeder. During this time the status of the feeder will change to penalty, and the feeder will no longer bait any animals. After the 30 minute penalty period, the feeder will return to active status and will start baiting animals again. The penalty cannot be circumvented by ending the current hunt and starting a new one. In a multiplayer game, only the host can invoke the penalty by shooting a baited animal at a feeder.

Bait Consumption

This aspect of baiting has also been simplified. Bait is now consumed in a constant linear rate, whereas before it was determined by the attraction level of the feeder. The bait consumption rate is 10 units every 24 hours (real time). That means a full feeder will run out of bait exactly 5 days after being topped up.

Location, Location, Location

The location of your feeders still matters, and for that reason we have simplified this process too. Now, if you attempt to place a feeder in a location where the corresponding animal does not spawn, you will not be able to and will receive a message to this effect. This is to avoid a situation where a feeder generates no activity. This does not mean location becomes irrelevant. Some locations will still generate better results than others. This is when it becomes important to discuss locations with hunting buddies and fellow community members.

Expected Numbers

For most players an important question now will be “how many bears or hogs can I expect to see at my feeders now that the system has been overhauled?”, and the answer is, it still depends on location. The new system has been written in such a way that results should be more consistent. If you place a bear feeder in the same location as your hunting buddy, you should see pretty similar results in most hunts. There will always be variations in activity due to the random nature of the spawning system which theHunter uses, but in general results should be more predictable.

Existing Feeders

If you have an existing feeder and want to start using it again, all you have to do is add some bait. Depending on the current location, you may want to consider moving it if you feel the area is not optimal. Once you add bait to an empty feeder, remember the 4 hour “warm-up” period will start and during this phase the status of the feeder will be inactive.

If you already have feeders with bait in them, please remember that the new system is now in place and consequently, you may notice differences in the rate of bait consumption. This is particularly true if you have a feeder in a bad area which previously resulted in a low bait consumption rate. The result is a possible drop in bait in some feeders. This is not a bug and is to be expected in some cases. Unfortunately this is unavoidable but should balance out in the long run.

Technical Overview

Roberto (our lead client programmer) and I were tasked with the baiting system overhaul, and neither of us had any idea how the previous system worked, or what would be involved in beating it into shape for the new design. As is the case with many things in theHunter, it was far more complicated than it perhaps needed to be, and everyone who had ever touched the system before had either left the company, or left the team to work on other projects and probably forgot the words “baiting system” forever.

Björn Öjlert, the original game designer now working on theHunter: Call of the Wild, kindly gave us valuable feedback on how the original system was supposed to work, which helped us understand the reasoning behind some of the existing code. Needless to say though, it was still akin to wading through porridge, at least in the beginning.

The baiting system, from a technical perspective, is essentially a combination of interactions between client and backend. When you start a hunting session, the client requests information from the backend. Included in this data is information for each feeder on that reserve, including a series of timestamps (when the feeder was placed, when bait was last added, and so on), information about how much bait is in the feeder now, how much bait was in the feeder after the last fill, and more. During the hunt, any interactions with a feeder by the player (e.g. moving a feeder, placing a new feeder, filling a feeder, shooting a baited animal at a feeder) result in calls to the backend API to update the data for that feeder.

When you open the launcher and view a reserve map on which you have a feeder, a similar API call is made to the backend to obtain information for that feeder, which drives the mouse-over pop-up box containing the feeder’s status and bait level.

Final Thoughts

As with any change to a system which has been in place for a considerable amount of time, we acknowledge that these changes will evoke various reactions. Some might find the new system too simple; others might welcome the change and consistency. We endeavoured to find a compromise and we are happy with the results.

From a development point of view, we have made good progress and taken a big step forward in terms of understanding how the baiting system works. Very little of the original backend code remains, and what exists now has been optimised. We now have a solid platform upon which we can build in the future, and one which made adding the goat mineral feeders far easier than it would have been with the old system.

We can now, without any shadow of a doubt, say “the baiting system works exactly as designed”. We hope you enjoy the new system.

Discussion

Last week we released Hunter Score 2.0. From a backend perspective, this was the biggest change we’ve had in quite a while, and it touched quite a few systems. For those that don’t know the details from a game design perspective, please refer to Alena’s post.

In this blog post, I will discuss what has been done from a technical perspective.

Preamble: theHunter’s server architecture pre-Hunter Score 2.0
Before I can explain how the new architecture looks, I would like to go over how the old (and current, mostly, see further) architecture works and is set up. We’ll do this back to front, meaning we’ll discuss the layer the furthest away from the player first.

– _Storage_: The SQL database: We use google Cloud SQL to store all the data related to the game, nothing special here, Google takes care of our database, it’s mostly stable.

– _Caching_: Google App Engine’s managed Memcache, with 10GB of dedicated memory.

– _Servers_: Google App Engine (PHP and Python): This is where it gets more challenging. We use Google App Engine to serve the website, as well as the API for the game. The website is a mix of PHP (inherited from the olden times before Expansive Worlds and Avalanche Studios owned theHunter) and html/css/javascript. The API servers meanwhile are written in Python 2.7, both the PHP and Python code are running on App Engine, and connect to the Cloud SQL database and memcache.

– _Cloudflare_: Cloudflare provides an additional layer of caching, it will cache static files such as images, html, css and javascript files, so our web server does not get swamped.

– _Website/Launcher_: The html/css/js served by the web server will be rendered by either your browser, or the game launcher. It is a single page app built using pretty old versions of marionette/backbone frameworks(the ones released back when the website was built).

Challenges
There are several pieces in this stack that are posing challenges for us in the dev team, the main one being the current server/web stack.

– These old versions of marionette and backbone are incredibly verbose and troublesome to work with, making any web changes slow and hard to test.

– The App Engine servers have no unit tests nor automated integration tests, this makes them prone to breakage, especially with the weakly typed languages that are being used.

– The servers have no sane error checking, making it impossible to tell the difference between a user sending an incorrect request and genuine server errors, this makes logs dramatically less useful than they should be.

– Database consistency was not considered during its development, meaning that errors can sometimes cause data corruption, which burdens both the players and our support team.

– Much of our static game data (such as which achievements are available to players, which animals spawn where, etc.) are stored in JSON files. While this is a practical format for developers, these files are most often changed by the game design team, this leads to occasional breakage whenever a single comma or quotation mark is forgotten.

What we’re moving towards
With the release of HS 2.0, we made the first steps towards improving on all this to move towards a more stable server architecture. The idea is that we will minimize the amount of changes made to the Python/PHP servers and instead start building on a new server stack, written in Go and hosted on Google GKE (Google Container Engine: A Managed Kubernetes cluster).

How does this improve on our problems, and why aren’t we just fixing the current servers instead? Well, I’m glad you asked, there are several reasons:

1) The main and most important reason is that, to fix the current servers, we’d need to rewrite them anyway, a lot of individual pieces are poorly designed (from a technical POV) and exhibit unexpected and undocumented behaviour in many cases. Writing new pieces and making sure they are well documented and don’t exhibit such undocumented behaviour solves this issue.

2) Weak typing and lack of unit tests: Python and PHP are both weakly typed languages, combined with the lack of unit tests, this makes any large refactoring or change extremely prone to breakage and passes the whole burden of ensuring correctness for any change onto the QA team, this is not sustainable. Rewriting piece by piece from scratch and making sure we have good unit tests coverage and use a strongly typed language for the new pieces solves this issue.

3) This allows us to move static game data to an administration panel, much easier to use by the game design team.

Upgrade approach
We are not going to be rewriting the whole server stack in one go, this would take months if not years, and would completely stop development of new features.

Our path forward consists in rewriting piece by piece as we make new features, the first step in this was made with the release of HS 2.0, we’ve moved the achievement system from JSON files to our administration panel, we’ve made an administration panel for ranks, and we’ve written an entirely new server for all of it that is now hosted on kubernetes. The new achievement and ranking system does API calls to our new servers written in Go, which are hosted in a kubernetes cluster on Google Cloud.

Compared the the Python servers, we’ve already noticed a huge increase in stability and performance compared to the old, the logging is also much better and they have full unit test coverage.

Hope this was of some interest to you. If you have any questions, please do not hesitate to ask! I am looking forward to working towards a more stable and faster theHunter experience.

Discussion