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.
I think that the concerns here regarding the competitive advantage of young vs old shards are well expressed. I think that it should be possible to address these concerns by scaling the core progression statistics based on each shard's time dilation.
Base resources scaling could be something like y = 2 - 2/x so that at a 2s tick there is no benefit but the bonus is not linear (encouraging DoS).
For example, if with 3 shards exist: A (the origin, 5s tick), B (first new shard, 3s tick), and C (brand new shard, 2s tick) then the benefit to several resources should exist:
* GCL gained on an account might be scaled up per y = 2 - 2/x. Shard A would contribute 60% additional GC per RC, B would contribute 33% additional GC per RC.
* Power processed could have limited scaling perhaps on the function y = 1.5 - 1/x. Shard A would contribute 25% additional Power per Power processed. B would contribute a 16.7% bonus.
* The 5% market surcharge may be reduced to y = 0.05 * (0.5/x +0.75). Shard A would charge 4.38% on market orders. Shard B would charge 4.58%.
CPU expenditure would not be affected.
There's probably some edge cases I haven't considered, but scaling of this kind would slightly blunt the advantage players get from aggressively populating new shards, and provide some incentive to spanning new and old shards.
Believe it or not, I think that competing user implementations are an important facet of this game.
I wouldn't be happy to be forced to choose a between a subsidized (zero compile/memory cost) polling API and writing my own event-driven API.
Remote the repeat option and your statement will be true.
Perhaps this could be game-ified?
Periodically give players bonus CPU which won't go into their bucket if they don't use it immediately.
I understand the purpose of encouraging players to spread out their CPU consuming actions, but this solution might also slightly reduce some of the complexity inherent in creating your AI engine.
@Hernanduer well that makes sense. Without an opportunity to take advantage of this mistake the reversal is far less offensive to your opponent.
Had I committed resources and mental energy to an attack in this war I would feel that the game was being manipulated against me.
Because creeps can move in formation and move thru one another you don't have this information when the command is returned.
Holy necro-post. Is this still the case?
@Atavus - I'm referring to using daboross's patch to explicitly affect the outcome of combat.
meaning, fix it before more players implement double strike code
I like this API change. It will be up to the users to setup message routing or shared memory. Both good use-cases.
The tick timing exploit is definitely something that needs to be solved before this is utilized on a large scale.