Merry Christmas everyone, and Happy Boxing day to folks in the Southern hemisphere.

In the last post, I wrote about the tech I’d like to play with for this project, but never really go into what each of the services does. This prompts the question to some of my mates who don’t play Tribal Wars “does this application need to be this complex?”. Besides getting all the tech in, what functionalities and services should this project provide to the player?

At the very basic level, to be of value, this project needs to provide 6 services:

  • Data collection service
  • Alerting service
  • Farm service
  • Ops service
  • Build & recruit service

Data collection service #

At the heart of it all, first we have the data collection service. This service requests:

  • World data, including information about the villages on the map, players and their achievements, tribes
  • Player’s build data, including building levels, current build queue, recruit queue, troops count, resources and market information
  • Player’s ops data, including outgoing and incoming commands

All of these services require the player’s credentials to log into the game. The data collected here serves as a the source of truth for all planning and building services going forward. In the past, I had chosen to go with MongoDB due to mlab’s free 500MB clusters. For this project I decided to go with Elasticsearch as its querying capability is very much similar to that of MongoDB and it includes a really nice UI i.e. Kibana out of the box.

As the game can notify the web UI on any new events through web socket, I’m employing RabbitMQ’s persistence and queue durability to allow for higher reliability. Yes this is a total overkill if the entire project is going to run on a single Docker node, but we never know. With tw2-tools being sunset, this service could become more prevalent than ever.

Alerting service #

The alert service is aimed to use Elasticsearch’s alerting plugins such as Yelp’s elastalert since we’re not using X-Pack. The alerts will depend on player’s configurations but at the very least, I’d expect to see an alert when:

  • There’s an incoming attack
  • Troops in the village had completed building to a preset
  • A player/tribe/village I’m monitoring changes
  • Someone relies to my watching messages

Each of these alerts could trigger further actions to be done like send the messages to Slack or Discord for the last one.

Farm service #

The farm service is 100% a bot. The mechanics is simple:

  1. Get a list of all barbarian villages in a 15-village radius.
  2. Divide available units used for farming into 50 teams with equal capacity.
  3. Send them out.

Within the service, through a web UI, the player can configure:

  • List of any other inactive non-barb villages
  • List of barb villages to exclude after a certain time, say when your tribe mate wants to take it
  • What types of units qualify as farming units
  • Time interval to send out farm runs

The farm service is very simple. However, before we send out our farm runs, there are couple of checks we need to do: is this village getting attacked, is it due to send out support to another village after its determined run time, is it a prime target in an ongoing op that troops need to stay home for?

While these questions can be answered and solved with coding or text configuration, after using either approaches, I’ve come to a conclusion that I needed something more verbose, easier to manage, something that do all the checks, lets me configure the rules and send out the final commands to the game, something like…

Operation service #

The operation service or Ops service is responsible for issuing final commands to the game. It checks the data service’s collected data, perform checks on any requested commands, deny/approve the commands and issue them. The Ops service should have a GUI with nodes that you can drag to draw up workflows, configure rule sets, something like IBM App Connect, Automation Anywhere RPA or NodeRED; but free and well-documented.

Aside from providing checks for farming, this service is also responsible for calculating and performing dodge and backtime based on rules set by player, such as when a village is offensive, it should dodge or backtime or whether such action is specified by player.

Workflows for this service will be configured in Activiti BPM.

Build & recruit service #

Lastly, we have the final automation bit: build and recruit. These are dumb services with configuration files most likely hosted on mlab for each villages, specifying the build order and troops presets. This service will include a web UI to view buildings and troops queues for all of the player’s villages.