API for scheduling actions that do not run every tick
-
> this solution might also slightly reduce some of the complexity inherent in creating your AI engine.
I don't see how replacing
if (Game.time % 5 === 0) {with
if(Game.timer(timerThatRunsEvery5TicksWithSillyName)) {reduces complexity.
-
Remote the repeat option and your statement will be true.
-
-
That being said they really should randomize decay times a bit. Whenever they restore from backup all the rampart and road decay times synchronize, which I'm sure causes some spike in the database whenever all those objects get updated.
-
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.
-
> Believe it or not, I think that competing user implementations are an important facet of this game.
Ignoring the obvious sarcasm and rudeness for a second, you're completely missing the point.
Kotarou's suggestion for an API here is not to make users lives easier but to make the developers lives easier. Since the easiest way to make something only run every X ticks is to `Game.time % X === 0` you end up with situations where everyone using the naive approach is running their expensive functions all at the same time. This in turn could put an unnaturally large load on the database during these ticks.
I think that's a worthy problem to solve, and it's not likely to be resolved by users as there is no benefit or reason for them to do it. Going back to my point about attitude, I think it's flat out rude- not to mention completely dishonest- to jump from "let's reduce the load on the server" to "this person doesn't think competing user implementations are important", and by making that jump you have yet again brought hostility and trollish behavior to a situation which did not need it. You should consider discussing things on their technical merits instead of trolling around this community trying to cause drama all the time.
To address your actual point about competing implementations, I think there's a middle ground here. The devs could make a new value available- Game.seed- which is simple "Game.time + Unique User Offset". If that is used in the tutorial and made available to people they'd be likely to test against that instead of Game.time, and the developers would be able to better spread out the load from their website.
See? By focusing on the technical issues, and taking into account both the goals that kotarou is trying to meet as well as your concerns over how it might limit the game, we can come up with compromise solutions that work. No sarcasm, insults, or trolling required.
-
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 must be thick, but I fail to understand the benefit of your suggestion.
Why would it be necessary to provide an inbuilt mechanism for action control? That's a problem your code should solve if you want to optimize your cpu usage. If you don't, it's your CPU and your problem.
I would expect that most AIs have implemented proper execution control which offsets execution according to some frequency.
For the specific case you mention, you don't want all your lab actions to run every 10 ticks. You want lab actions of a room to be run every 10 ticks and execution of your rooms to be staggered based on a room specific property. This way lab CPU doesn't spike every 10 tick but instead averages out over your empire. But this is a CPU optimization which lies entirely in the realm of the player and part of the game's fun.
-
This is not about optimizing individual CPU usage. At all. It's a suggestion, based off of tests run using the private server, for a way to potentially lower usage spikes (and thus reduce tick times). If you are not approaching this discussion from viewpoint then you're not understanding the discussion.
> This results in a situation where ticks that are a multiple of 5/10/whatever spike CPU usage for multiple players - a noticeable difference when only running multiple instances of myself on a private server, and presumably a serious difference on live.
*That* is what this suggestion is about.
I do agree that the proposed solution is overkill. I think a better solution would be some documentation and a single variable that is set each tick. I'm not sure how much of an effect this would actually have, but it's a worthwhile suggestion that involves minimal work for the developers for potentially some benefit.
> I would expect that most AIs have implemented proper execution control which offsets execution according to some frequency.
Maybe i've been spending too much time in #help and reviewing screeps code on github but plenty of players are not implementing offsets, they're doing a naive modulus check against Game.time.
-
I think the scheduling thing is something everybody could implement on its own .. I can think of thousands of things the devs could implement that is not possible for the player to create.
If you use the every 10 ticks example there are 9 possible offsets .. but even with random distribution over all players that does not mean that it will be random distributed with players on the current running node.
I try to distribute my workload even over all ticks .. by using `Game.time % 10 == 5` for some stuff for example or by using 9 or 11 instead of 10. Even worse if you use Game.time % 2 == 0 everywhere ,)
An other solution would be to create a official inofficial standard library with basic tools like that and some hints .. which is mentioned in the tutorial.
-
That's why I opened with the assessment that I may be too "thick". I do get the point now. Most people stagger by just doing Game.time % frequency === 0. So labs are "synchronized" on the main world.
I hadn't thought of that.
Providing an alternative to Game.time such as Game.seed which is player specific might help mitigate this, however that requires that the player understands this additional property and uses it for the sole benefit of the "world health". Highly unlikely imho.
I'm not sure if there will be an easy method to mitigate this. However, before anything, it would make sense to have the devs actually do a code search to find how frequent these instances are and if they have a measurable impact on tick variability.
-
That should be easy to check for everyone with stats. Are ticks with % 10 === 0 slower then others?
-
Yes, every 20 ticks there is a slow tick. You can view this for yourself just by looking at the status website. I've attached a screenshot here for convenience.
Every 20 ticks there's a massive spike, and you can occasionally see smaller spikes on the other ticks divisible by ten. This is clearly an issue.
-
I'd like this feature with one caveat:
I'd like there to be an API that makes it apparent that it runs on average every X ticks. This should allow for more flexibility when scheduling. Generally I don't care about when these triggers happen, other than it happening too (in-) frequently.
-
I do like @Atavus's idea of a unique `Game.seed` per player. It could not only assist with staggering players' periodic code as suggested, it could also be used as a legit RNG seed to use for military purposes to foil ppl tailoring their military code to defeat visible flaws in yours. Random is not bad and would add another level to the military stratagem already in existence.
For the noobs, you could introduce it solely for the purpose of solving the current topic in the tutorials, and let them figure out other, ancillary uses later.
-
Hey now, that was my idea
-
My apologies, Rob, I must have misread lol. Please note, I agree with Tedivm's idea of a `Game.seed`
-
The seed idea is a much nicer approach to the issue.
+1 to tedivm's approach.
-
I agree with the Game.seed suggestion. It's a nice way to balance the tick times and avoid massive operations in 1 tick followed by nothing the next.
-
As a general philosophical principle, my preference is to slip any changes in at the lowest possible level so that the observable consequences are minimized.
Instead of introducing a new API function (which doesn't solve the problem unless people rewrite their code), or introducing a seed or player id value that can be added in (still requires people to rewrite their code), we should at least try to think of a solution that works even if people don't rewrite their code.
One obvious choice is to simply return a different value for game.ticks for each player. The server could simply have a unique offset for each player that it adds to the real tick number. That would immediately fix the problem. Of course it's not really unobservable; you'd get confused when you tried to match your logs with the replay, and you probably want to be able to coordinate attacks using the tick number as a clock.
So here's my real suggestion: change how mod works. Simply change the mod operator so that it adds the player's id number to the first operand before doing the mod operation. This doesn't change the domain or range of the operation, or change its behavior or usefulness, but it does solve the problem. On the down side, modifying v8 in this way could be annoying. You're forking a complicated component, which will have a maintenance cost down the road. Also, you'd have to dig into the JIT compiler so that it generates the correct machine code for the modified operation, which is not likely to be trivial. But from the philosophical point of view it would be ideal.