Undifferentiated access unfortunately harms the ability to observe gameplay which is a significant way to experience the game and an excellent way to advertise the game.
Something like a 50 tick delay for rooms outside of the player's vision would be an ideal compromise, but this is most likely a non-trivial feature.
Test edit.
I agree with a penalty for shard travel.
I do not think it should apply to CLAIM creeps at all. If portals are 10 rooms apart then it will be impossible to use them to quickly move CLAIM creeps in the first place. The mechanics of moving to a highway and back are bad enough as kotarou says.
For power creeps perhaps they pay this penalty in wall time? That is, a power creep that wishes to move between shards should be unavailable for play for 1500 ticks.
No, there's not much of a point if you feel entitled to the same information as the web UI.
Why bother figuring out using range if you can scrape the web.
On the contrary, I think that limited creep visibility is part of the "fog of war" you should be dealing with as an AI dev.
Imagine the added challenge when you have a military action intruded on by a 3rd party - you have to deduce based on their position and potential actions whether or not they are coming to your aid or to the aid of your opponent.
When we discussed the Terms of Service and multi-account play previously I was heartened by Artem's response, to paraphrase: there are no new rules other than the rules as written but don't try to circumvent these rules with code.
1. Offline command execution should be ok because of the 2 levels of uncertainty: the results of the correct context for a command are not knowable by an external script, and commands are not executed until the following tick. This means at minimum a 2 tick latency for commands.
2. I consider offline training of an AI to be a primary motivation for experimenting in this game. Getting that AI to perform well is a challenge because of the limitations placed on user scripts: limited CPU and 12MB of persistent storage. Offline pathfinding is hardly an issue and using it is just a crutch which limits the abilities of a script.
3. information leakage is the most significant use of the web API "not as intended" by the developers and the thing I think we should be addressing.
Already we have both public and private services which scrape the web API in order to gain new information and reveal tactical information about the game world. Some of these services mirror functionality which could be gained by having a large network of allies in the game, but other services can remove gameplay constraints and provide an advantage which can only be repaired by hiding information from the best advertisement for the game: the ability to spectate the living world.
I propose that communication creep population from the web API and introducing this information to the game without human intervention should result in a ban. I don't think that any other data tool like portal or markets is as threatening to the core gameplay as unlimited visibility of creeps on the map.
How about adding a 100 CPU CONST cost to the API that requests the change in CPU allocation?
So far the CPU use seems more consistent and the compilation penalty is not as high.
Being forced to defend from attack across multiple shards is more apparent when it's described as a ladder / elevator / floor / Z axis
A shattering event could be really fun. Would anyone really be upset to have their empire distributed among multiple shards?
Some world position logic might be disrupted, but otherwise there's no reason to change room names.
I didn't think anyone was trolling. This conversation is better served by assuming good faith rather than tone policing.
Focusing on technical solutions: a suggested user offset might be incentivized to encourage adoption.