Tournament and Spire Requirements (2020)

In this post I am going to outline how Tournament and Spire of Eternity requirements calculation works after changes that were introduced in 2020. Both game elements feature fighting and catering options, and squad sizes for fighting and negotiation/catering costs increase as your city evolves and you do more encounters. So this is an umbrella post for several models that are (or will be) used for calculating these requirements.

* – * – *

Summer 2020 brought us some major changes to the tournament structure. I won’t be focusing here on listing all the changes, but suffice to say that tournament calculations are completely different now from what we used to have for several years before that. In fact, if we peek under the hood, we will see that there is a significant overlap between new tournament calculations and the current Spire calculations. And while most of the completely different stuff will be related to the tournaments, Spire calculation are also impacted by this new development – albeit to a much smaller degree.

Modeling Overview

There are quite a few moving parts involved in the modeling, both on input and the output side. So a picture may save me a thousand words 😉

It looks complicated, but it really is not that bad. If you’ve seen previous posts on Spire and Tournament modeling, you already know what’s going on here. Probably 😉 The only new item here is City Advancement Level (CAL), but as you will see it is not exactly new.

Inputs

So green boxes in the diagram above are observable model inputs. Those who read Spire Squad Size Model v5.0 will recognize these, but here I will list them again:

• maxB – maximum unlocked boost percentage for T1/T2/T3 goods
• M – total number of unlocked mandatory tech items (research)
• A – total number of AW levels (including currently upgrading)
• V – number of placed non-premium expansions (including initial 6)
• P – number of placed premium expansions

The other ones (star # and province # for tournaments and encounter # for the Spire) are fairly self-explanatory. You’ve seen those in the respective progression models before.

Outputs

The orange boxes in the diagram are observable model outputs, so the parameters that we actually want to figure out.

CAL

Which leaves us with CAL. Previously, we would pin Spire and new tournament progression to their respective own base squad sizes. Well, CAL is basically a generalization of that idea. Base squad size was always effectively a representation of the city evolution, and had very little to do with fighting per se. And now we know that both Spire and new tournaments use the same calculation to figure out this city advancement level, and pin all other progressions to that single number. But actual base squad sizes are obviously different for Spire and the tournaments.

If it is somewhat confusing now, it’s OK, you’ll see how it all works together 😉

So in the separate posts we will describe all 3 models in the diagram above.

City Advancement Level Model

• City Advancement Level Model (2020)

CAL, or City Advancement Level Model takes different parameters that developers consider relevant for city development (e.g. relics boost, research, AW levels and expansions) and bakes all of them into a single CAL number. This number represents city advancement level (duh!) the way the game sees it. I.e. if you have a higher CAL number, your squad sizes and catering costs for the same encounters will be higher in both Spire and the tournaments. Literally all size/amount parameters in the Spire and tournaments for any particular encounter are determined by this single number.

Tournament Progression Model

• Tournament Progression Model (2020)

For a particular province number and stage (1*-6*) in the tournaments, enemy squad size always has the same ratio to your own squad size. And similar to that, your own squad size progression is also fixed. So all squad sizes in later provinces are completely determined by your own squad size at the very first 1* province encounter – which in turn is completely determined by CAL. And the same again goes for catering costs. The tournament progression model connects it all together.

Spire Progression Model

• Spire Progression Model (2020)

For a particular encounter in the Spire, enemy squad size always has the same ratio to your own squad size – just like in the tournaments. And similar to that, your own squad size progression when you ascend the Spire is also fixed. So all squad sizes in later encounters are completely determined by your own squad size at the very first Spire encounter – which in turn is completely determined by CAL. And the same again goes for negotiation/catering costs. The Spire progression model connects it all together.

Full Tournament and Spire Requirements Calculator

And here is a spreadsheet calculator that combines all these models. It uses fundamental parameters (research, provinces, AW levels, relics boost) to calculate CAL, and based on that it can calculate all progression outputs (squad sizes, catering costs) for new tournaments and the Spire. You can see it here:

• Full Tournament and Spire Requirements Calculator v2020.09.29 (Google Sheets)

You will need to clone it, then populate data on CALCalc sheet. Then your full tournament progression data will be on TournamentCalc sheet, and your full Spire progression data will be on SpireCalc sheet. Let me know if that works for you.

Expected Accuracy

Unlike the previous modeling of Spire SS (CAL predecessor), I don’t intend to make it super accurate. The reason I wanted to do that for Spire SS is to make sure that the functional form of the calculation is correct. But this also meant that I had to do a lot of data cleanup. I mean, A LOT. Now, when we are reasonably certain that functional form is correct (assuming it is the same), there is no reason to shoot for sub-1 accuracy. Errors of several points for base squad sizes are perfectly fine for all practical purposes, and it allows for much faster model updates. As long as there are no systematic drifts (indicating potential changes to functional form) this would work just fine.

And that’s pretty much it 😉