So, the “Enemy” – who is he and what does he do?
In the last version of the game, the enemy had two main functions. First, they provided a game clock. If, on your turn, you had the “enemy pawn”, you advanced the “Enemy Progress” track by the current position of the “Enemy Zeal” track, and if it reached its end, the Enemy had found the temple ahead of you (and then you passed the pawn to your right, so it counter-rotates relative to the player turns). The “Enemy Zeal” track started at 1, but advanced by 1 every time someone attempted a dig for the temple or a relic, so it organically accelerated the movement of the Progress track and gave a sense that time was running out, which was cool. Second, there were “enemy cubes” placed in the cities on the board, and these represented the difficulty of the challenge you faced upon arriving in a city. This was very clean and simple, but perhaps a bit too abstract, and worse, they slowed the game down as it progressed – more enemies to beat means more cards to acquire means more turns drawing cards means less turns drawing stuff. Again, this was somewhat desirable – on the one hand, you feel time is running out, and on the other, your ability to efficiently collect information is decreasing, so you feel like the best bet is to go into the temple, perfect info or not.
There was really nothing wrong with this scheme, but I still question whether it was as good as it could have been; there was little correlation between the enemy cubes and the enemy progress, and as mentioned, facing cubes for challenges felt dry and mathematical.
I’ve previously talked about a newer and better (?) system for handling the encounters, but the board topography introduced by the enemy cubes was nice. A simple way to integrate that with the enemy progress is to have the movement amount on the Progress track correspond to the number of cubes in the player’s current city. And, have the movement happen on every turn. Taken together these get rid of the counter-rotating enemy pawn, and the enemy zeal track, so it’s an overall reduction in complexity.
Now comes the part where I add some complexity back in. Sort of. The previous system had a “trigger” mechanism, whereby if there were too many enemy cubes in a city, the enemy attempts to dig for the temple in that city. Again, clean and efficient. I think we can preserve that but broaden the scope a bit, with a deck of “event” cards – whenever a city overfills, an event card is revealed, and it could do one of a couple of things – kidnap a theme card in that city (if there is one), attempt a dig, etc. But one effect I’m particularly interested in considering is “reveal an Enemy Agent”.
I may have mentioned previously the idea that we could perhaps add several “Enemy Agents” into the game, each represented by a card. These start face down in a row. Whenever an “activate Enemy Agent” event occurs (however that comes about), one of them is flipped over, indicating that that Agent is now known to be “active”. As I had said, these agents can be incorporated visually into the encounter cards, so if you see an Agent that has been activated, you can attempt to fight him (and “deactivate” him, I guess?).
But what happens to agents that aren’t deactivated? I want to integrate the enemy presence more strongly into the temple, and I feel like the number of active agents should be a serious consideration for the players – the more agents are active, the more difficult it will be for a player to win in the temple. So I came up with three schemes.
1. The simplest: the enemy progress track continues to click down when players are in the temple, and the amount it clicks down by is determined by the number of active Enemy agents. So, the fewer Agents are out, the more time the players have. This is simple and functional, but only abstractly conveys the sense that the Enemy is competing against the players to race through the temple.
2. The number of active agents represent the level of knowledge the enemy has, “1”, “2”, or “3+”. In the temple, the enemy is assumed to be “right on your heels”, and every time you enter a room, you check the solution card to see whether the enemy acts in that room or not – BUT, the sleeve you slide the card into is “1”, “2”, or “3+”, depending on the enemy’s knowledge. So a more informed enemy will make more intelligent choices. This adds some cool AI to the game, but it’s a minor headache to introduce component-wise, and it may be a pain from a playability standpoint.
3. Once players enter the temple, take the active agent cards and place one between each pair of players. Before play passes to your left after your turn, if there’s an Agent card between you and the next player, the Enemy first gets a turn. The enemy is a single pawn that moves through the temple with some simple AI, and he attempts to pass all challenges and tests any and all features he comes upon. When he faces a challenge, the difficulty is checked against the stats of the current Agent (or maybe all active Agents?), and if he fails, that Agent is deactivated and out of the game.
I like each of these for different reasons. 3 has the advantage that it really hurts to have multiple enemies active going into the temple – with, say, 4 enemies active, the enemy gets 4 turns for every one turn that you get! It would be hopelessly hard to beat an enemy that is so fast (but on the other hand, perhaps you were able to enter the temple before the enemy). I’d have to write a simple AI to govern enemy movement, but that shouldn’t be too bad.
