PTR Changelog 2017-07-20: world shards
-
Something I just thought of.
If our code doesn't know which shards have CPU allocated to them, how can my AI know which portals it should send creeps through? Should I just blindly send CLAIMers through portals hoping that my caretaker has allocated the appropriate amount of CPU to the other side? Am I (as the caretaker) supposed to manually poke values into memory indicating which shards I've allocated memory to?
Am I going to have to literally write an out of game tool that scrapes the web UI for CPU allocation, pokes the values into memory, and then occasionally reads some segment of memory and pushes the desired allocation back to the UI? Because it's impossible to stop that from happening, and sufficiently motivated players will build this tool - and now you've just done two things:
- Forced me to implement an out of game solution to an in-game problem
- Put this feature out of reach of people who aren't able or willing to do the same
To be clear, because I've been pretty hostile in this thread, I am blown away that you guys already have a working shard implementation at all. I'm just extremely frustrated that you are making it more difficult to write code that controls this programming game.
-
Anisoptera, while being a tad aggressive... does make me think of an issue
If I send a creep through a portal into a new shard, do I have to have pre-allocated CPU for the creep to be able to move off the portal?
With programmatic controls, that wouldn't be too hard, as I can read the destination and give it some minimal CPU amount.
-
@artem Quick clarification, `Your GCL and CPU limit should be allocated...` Are we going to be allocating CPU directly? LIke 25 to shard0, 20 to shard1, 45 to shard2, etc, or just redistrubuting GCL points (Thus 1 point towards shard1 = GCL1 on that shard and 20CPU )
-
@kotarou from docs: If this is an inter-shard portal, then this property contains an object with
shardandroomstring properties. Exact coordinates are undetermined, the creep will appear at any free spot in the destination room.
-
looking great!
One suggestion: I'd love it if the shard-portals were way more rare, and if they not only occurred in highway rooms. It would add strategic value to holding certain rooms and zones for alliances. It will also help in making shard populations evolve independently from each other (other players settling the same space). As it is now, new players in shard1 may get squashed often by their upstairs neighbors.
For clarity, I'd also suggest using different naming, like "conduit" instead of "inter-shard portal", since their mechanics are very different.
-
@ags131: what @kotarou was asking is, if I send a creep over to the other shard, do I need CPU allocated there to be able to control it?
I can't imagine it working any other way. Which is my point. I can't send a creep through a portal I just discovered. I have to wait until my caretaker allocates CPU (or GCL) to that shard. And I don't have any way to know when that has happened (at least, no in-game method - of course my caretaker could have written some values to memory.)
-
"@ags131: what @kotarou was asking is, if I send a creep over to the other shard, do I need CPU allocated there to be able to control it?
I can't imagine it working any other way. Which is my point. I can't send a creep through a portal I just discovered. I have to wait until my caretaker allocates CPU (or GCL) to that shard. And I don't have any way to know when that has happened (at least, no in-game method - of course my caretaker could have written some values to memory.)"
Honestly, I'd be fine with a base 1 cpu per tick in each shard but a capped bucket of 100cpu unless you allocate account cpu to it. Have a players code only run if you have something in that shard. That way if they wander into a shard they have a bit of a grace period to move around and/or allocate cpu. It also lets you explore a shard without having to move your allocations around.
-
> ...move off the portal?
This is what I was responding to, the creep will NOT be on a portal
-
> Honestly, I'd be fine with a base 1 cpu per tick in each shard but a capped bucket of 100cpu unless you allocate account cpu to it. Have a players code only run if you have something in that shard. That way if they wander into a shard they have a bit of a grace period to move around and/or allocate cpu. It also lets you explore a shard without having to move your allocations around.
Maybe a base 10 instead? With base 1 you can never refill your bucket, which means you won't be able to run `require` statements on your code after a certain point.
-
10 seems fine if it doesn't cause any concerns on their side. Plenty of 10cpu players would be happy suddenly getting a lot more too.
But really, I don't think they should be running every single main world player's code each tick on all the shards. I think it should only run if you have something there.
Hence why 1 cpu would fill a bucket if no code is running. It would also limit outsourcing code requests to shards you are farming cpu on because you would need a physical presence in the shard to run the calcs. If you didn't require it you could just use the 10cpu to farm up cpu and run a bunch of calcs.
-
Thats one thing about it, IF its purely allocating GCL points and not CPU directly, you can just allocate 1 GCL to each shard, bam, instant 20CPU(?) available on each since each would effectively be at GCL1. That or maybe give 1 'free' GCL point per shard that cannot be allocated away.
-
> But really, I don't think they should be running every single main world player's code each tick on all the shards. I think it should only run if you have something there.
Currently (as in right now on PTR) if you do not have at least one creep or a claimed room (possibly just the structure) then your code does not run.
-
Then why wouldn't a 1 cpu base allocation work? It should still fill a player bucket up. Nothing against 10 but curious since you mentioned it wouldn't work previously.
-
bucket doesn't build if your code doesn't run.
-
Really? Because when we skip ticks etc I thought your bucket filled up.
-
I just double checked in the source to make sure I'm thinking of this right, when skipping ticks, your user is kicked out very early. When you have no objects, your user also exits out early before the bucket is updated. With shards, each shard is effectively its own seperate server, so if you have no creeps, structures, or rooms, you have no objects, therefore it exits out early.
-
Hm good to know, definitely not impossible to change if they decide to go that route.
-
How about adding a 100 CPU CONST cost to the API that requests the change in CPU allocation?
-
To play off of ags131's suggestion, what if it worked like this-
* 20 cpu automatically on any shard that has activity (creeps).
* 10 cpu for each claimed room on a shard.
* Extra CPU split proportionally among claimed shards (shards with claimed rooms).
This would make sending creeps to explore new shards much easier and would remove the manual aspect from the game altogether.
-
Biggest problem is that requires a central location tracking room counts in each shard, with the current design, that adds a lot more extra data to track and more update queries.
If its done by user allocating GCL points though, it could easily function identically without relying on trying to keep track of room counts on every shard