This is the third and last installment of a longer article about balancing issues in Ingress. You can find the first part here, and the second one here. I remind you that this is the result of a brainstorming by several players across Europe. I don’t claim that all the ideas here are mine, nor that all the contributors agree at 100% with all the ideas…
In the two previous parts we have discussed how recovery from an unbalanced situation could be made easier, and how unbalanced situations could be made less desirable from the point of view of game strategy.
Now, as everybody knows, no matter what the teams decide to do and the strategy they decide to adopt, the game is always extremely vulnerable to the actions of a few very active players.
That is why this last part will discuss this particular issue.
Limiting the impact of very active high-level players
A handful of very active high-level players is enough to decide the faction who dominates a small city. While such players are an asset for both teams, their impact on long-term game balance could be limited, while not depriving them of the fun of the game, of course. Extremely active players should not be able to spoil the game in a whole city.
There are several ways in which this situation can be improved. The challenge is to find a solution which does not frustrate the active players (which have the right to enjoy the game like the rest of the agents). These are a few proposals:
a) A player could have a stamina variable which gives gamers an extra boost for their first actions (throwing a burster, droprate when hacking a portal), and some penalty for quickly repeated actions. The stamina might be falling off exponentially with the number of actions, say from 1.5 down to 0.5 and should recreate slowly over time, like a full reset in 2 hours when the user isn’t playing. The aim is to give occasional gamers some extra motivation to also attack portals which are harder to capture. It would also allow teams to hold a hidden reserve of “silent” agents, e.g. for tactical reasons. This is more effective than what happens with the new rules about the xm cost of xmp firing, since no matter how many powercubes you have, after a while your xmps will inflict half the damage. However, if you are ready to use a lot of them, you will still be able to have a big impact on the game, which seems fair: active players should be able to keep playing as long as they want (although challenged by more complex gameplay), and not being constantly frustrated by the xm drain.
b) Stamina would limit, in part, all actions of a player. On the other hand, one may want to specifically limit only the attacks of a very active player. The xm drain upon xmp firing does solve in part this problem, but it is most likely an overkilling. If the aim is to forbid one player to completely take down a portal of arbitrary level (in the same way as a single player cannot build alone a portal of arbitrary level), then the implementation could be more along the lines of limiting the damage a player can do to a single portal, not limiting the player altogether. One could imagine scenarios where a portal becomes immune to attacks of a given scanner after having received some damage, because it learns how to defend itself. Immunity could be native or triggered by a mod, and implemented in the same way as cooldown (i.e. as a per-user, per-portal dead-time, reset for example after 30 minutes). The player can still move to a different portal and keep playing, no need for him/her to turn off his/her scanner. One can also imagine some extremely rare items that, when used by a player, change the imprint of his/her scanner and reset all immunities established against him/her until that moment. Or a mod that inhibits the immunity of a specific enemy portal against all users. The amount of energy a player can subtract from a portal before it develops immunity should be a function of the portal level and the player level. It seems sensible that if a player can build alone a portal of a given level, he/she must also be able to take it down alone, without many difficulties. On the other opposite, if a portal needs 8 players to be setup, it is unreasonable to ask that 8 players join their efforts to take it down, as this would make the game too static (unless, of course, said portal were inherently less stable, i.e. with much shorter decay times). Some tuning of the immunity could certainly be devised in such a way that on average destroying a portal requires efforts by one fraction of the players it takes to set it up.
c) To further discourage scenarios where 8+ high-level players turn a whole city into a farm, building high-level portals could need more “vertical” team play, involving also players of lower levels. One possibility would be to forbid direct deploy of L7 and L8 resos. They could only be used to upgrade an existing lower-level reso. This way high-level players are forced to keep around also some intermediate-level portals (and/or players) if they want to build high-level portals. This could be enforced more widely in a three-stage process: direct deploy only of L1-L2-L3, upgrade to L4-L5-L6, then upgrade to L7-L8. This will force teams to work together for high-level farms (not just the high-level players) or push lone wolves to have a more balanced inventory (that is, keeping only L8 resos would be pointless, since you cannot deploy them: you need to have an L1 and L4 too). Upgrading instead of deploying is, after all, already common practice any time you don’t want to draw too much attention. A somewhat weaker implementation could consist in removing the xm drain for reso upgrade. With some tuning, one could make direct deploy of high-level resos extremely expensive, and favour the upgrade instead. A nice side-effect of this is that we can keep all cities lively and enjoyable for players of all levels, without the need to set up dedicated playgrounds: low levels (players/portals/resonators) are needed and play a crucial role in the game, they are not just a not-yet-high-enough-level. This will probably also boost the recruitment efforts in those cities where a large number of players already reached a high level.
Enough for this last part, and enough with the balancing problem. My next post will be, most likely, about a few ideas on how to make the game more time-dependent, i.e. waking each morning and opening the intel and/or the scanner without knowing what to expect :)
In the meantime: how do you feel about extremely active players? Are they really a problem, or is this just a perception in some very special scenarios? And in case you are wondering, I do consider myself as a fairly active player. This does not prevent me from spotting what I consider to be weaknesses in the game logic. How about you? Feel free to voice your opinion in the comments here: as usual I enjoy discussing with you, and I’ll do my best to answer most of them.
At the end of these three posts on game balance, I’d like to thank all the agents who contributed. This was started by a g+ post by agent chaosline, and was enthusiastically endorsed by agents aamuuninen, fnord23 and barlow (who chaired the discussion and edited the final document, and is now posting this for you). New interesting ideas were contributed by many others of which I only know the g+ name, not the in-game nick. I’ll not mention them here explicitly to better preserve their privacy. But I have all the discussions logged, so feel free to claim credit for your own ideas if you wish: I’ll be glad to confirm it :)
Early exposure to readers/critics helped in refining the proposals and spot some obvious inconsistencies, as well as adding last-minute ideas: thanks to agents guschtel, balrog, aspergillus, flopp, tille, morghulis, sterlak (plus, again, the ones I don’t know the nicknames of) for the time spent in reading the article and giving feedback.
Part 3: Limiting the impact of very active high-level players