TL;DR:

Add a new pocket dimension of rooms in each shard. The world is mapped onto terrain layout of those rooms with one shard room per pocket squircle. Regular creep actions are used to conduct trades or terminal transfers. The center portal in each chunk is now permanently connected to portal squircle in the portal rooms. Using the portals is allows predictable long distance travel.

What:

Create a pocket dimension in each shard. The central portals would connect to the pocket dimension instead of each other. Each room in the pocket dimension maps to a full 10x10 chunk in the shard. The terrain walls are placed to mirror which rooms are connected to each other. Each room in the shard maps down to one squircle. Claimed rooms have a rampart placed over them. Rooms with a Terminal have an ephemeral terminal under the rampart preventing access to other players with the usual public / private mode.

Creeps would get new intents to buy or sell from terminals within range. A buy intent is limited to the capacity a creep has and the credits available to the player. The credits are deducted and the resources are withdrawn from the terminal and transferred to the buying creep. Similarly for a sell intent from a creep.

To make getting the central portal in each chunk would raise the bar for terminal and market use. So Terminal can used as a one way warp to the portal room.

Why:

• Local Combat
  It's been long argued that local combat is more fun. It's gotten to the point that the devs are revising the API for the terminal to limit the transfer rate. With the portal dimension blockades are feasible for both terminal transfers and market orders. Further the blockade is dynamic thing where a single lapse on the attacker doesn't completely open Terminal to a flood of resources. Further busting or blitzing a blockade are now options.

• Market piracy
  There is very little incentive to get local players to cooperate with resources. It's easier to just use the magic global market. Yet another level of play is to intercept a player market caravans and plunder some resources.

• Performance
  The market and terminal are currently global intents and must use the global processor. Avoiding the global processor increases the parallelism and remove once source of slow ticks.

• Long distance hauling
  Long distance resource movement is hard and expensive and Terminal beaming is too easy and too efficient. Now players would be able implement long distance hauling as part of using their terminals to share resource between their rooms. Looting the corpse of fallen enemy and just get the resource into the portal dimension and get within range of you your terminals to drop it off.
  The 10 rooms is near the maximum influence players will usually allow creeps to wander. 5 is much more typical with 15 being absolute 1500 lifetime limit. Using portal rooms hop in then out extends the range to about 100 rooms.

• Chunk differentiation: Many of the chunks are very uniform. The central chunks are slightly preferred for commoditiy access. The local market effect could also differentiate the chunks, with some having more diverse markets or proximity to pirates or tiggabot.

• Chunk defense
  Players with higher GCL and rooms to spare can use their rooms to secure their local chuck to prevent intruders from portalling in. The ramparts over each claimed room can be used to deny access to chunk portal squircle.
  Newer players may also get in on the portal defense as their rampart are indestructible giving them a dominant defense

Random boring details

The portal room doesn't completely solve to the cross room coupling that the global apis cause. However, It does effectively chop it up into many pieces. This can be further improved by making all Terminal intents duplicate into their portal room as well as the players room (duplicated in the runner not the processor). The duplicate intents ensure the view of resources in consistent between the portal terminal and the room terminal with out needing to use the global processor

The pocket dimension should be be "in" the shard. Drawing them in the world is interesting, but they could just as easily be drawn like shard in the UI.

If the pocket dimension stuff works well, it might be an interesting way to update the intershard portals with a pocket shard.

I have not considered whether the environment should be agro or not. I kinda think npc creeps would fit with the rest of the screeps theme. Maybe another incentive to wipe or cores is to keep your portal room clean.

The shards are 20 x 20 chunks so the portal rooms would require 400 new rooms, so 4 chunks worth. I don't know how tight the cpu budget is for a shard but hopefully 400 chunk shard can handle 4 extra chunks. Alternatively it should be possible to fit 4 chunks into one room.

Brief estimate of work to pull this off. This reuses a lot of existing systems, but new stuff will of course be needed.

• new creep buy / sell intent
• new Terminal warp intent (reuse existing portal code so they appear randomly in portal room?)
• new ephemeral terminal structure (reuse graphics)
• vet dual intent idea to avoid the global processor
• implement dual intents for terminal intents.
• script to create a room terrain based off of the chuck.
• double check that rooms with owned structures owned by different users is ok (this doesn't occur anywhere else).

I don't cross shard much, so I may be incorrect. I have heard of a few gotchas when hopping shards.

The biggest being you need to keep your ticks going on both sides to get reliable transfers. An empty shard will often go to sleep and stop ticking.

Another problem is sometime the shards will have difficulty talking to each other. This can cause creeps to stuck in limbo for hours. As far as I've heard they all eventually arrive often in a single clump.

You may have stopped tracking your creeps too soon and the lost creeps are still in transit.

I agree the addition to the return value would be nice. I never pass game objects into a pathfinder. It's always an array of destinations (range,pos) even if it's a single destination. Associating the returned path with index of the destination was straightforward in my case and not terribly cpu intensive. My wrapper then returns the index so my higher level logic knows which target was selected.

It get's a little hairy when the pathfinding fails but that corner case is hard no matter how you handle it.

If the plugin did the index tracking it would be noticeably faster only when there are large number of destinations (>100 i'd guess, but for sure >10). Changing the plugin is a tall order.

Another way to view the API is there are no live game objects, only a snapshot of what internal game object looked like at the start of the tick.
This means using a stale object is totally a thing. A stale StructureController is nearly identical, a stale Creep however is much less forgiving.

The good news is Game.getObjectById is really really fast. So just store game ids and create an object for them when needed.

I love the long lived ruins left over from an abandoned room. It gives an archeology vibe. I'd like to see some even longer back. How cool would it be to find some ruins for Dissi or Atavus.

However, I totally understand about the need to clear ruins out of a claimed room.
How about an API to dismiss a Ruins that only works in claimed rooms. Like how remove() works for ConstructionSites.

The alpha map is worse for colorblind folks as well. On the current map I often can't tell player colors apart. Not a huge issue. The alpha map is worse as I can't tell if a room even has player activity.

I have multiple times thought one of Eiskalt's rooms got wiped. I could only see the roads. The player colors seem deterministic. I think it'd make the players easier to see (for everyone) if the saturation was bumped.

Sorry for breaking the regex thing. I was really hoping they'd keep the regexes and use RE2 to do it safely.

The actual implementation is done completely client side, so RE2 isn't an option.

I hope losing the regexes means we avoid a troll, as opposed to nerfing a feature because of a corner case that will likely never arise (looking at you Intel and Spectre). It would have been a great part of Screeps lore if someone used this offensively, though I could imagine a rage quit over a wipe and no way to view the effected rooms.

How would it cost to import all of a player's market history into BigQuery or RedShift? It'd be cool if the devs supported it directly, maybe charge and access token per year (6 months?).

Another aspect I hadn't considered. Resources all spawn based on ticks rather than time.

Sources:
This could never change. The regen time is too tightly integrated and optimized in creep builds.

Minerals:
Regen every 55 hours instead of 50K ticks. Player harvesting would be completely unimpacted, especially since they already have to adjust to different regen amounts. The sticky part is the ticksToRegeneration property, but I don't think a fuzzy value would break anything.

Deposits and PowerBanks:
From the player's point of view there is no change. It'd be a bit more work on the backend to convert from ticks to time.

It's all a little complicated and the result is not perfectly fair. I'd suggest it isn't worth it unless deliberately differing tick rates was going to be a feature of the shards.

The idea of CPU Unlock fairness brings up a good point. Shard0 is an obvious bad choice for players.

How about fairly refilling buckets based on time instead of ticks. E.g. every 4 seconds add a player's CPU level to their bucket. Now the Devs target tickrate means something in game.

This would balance the slow vs fast shards a bit. It would allow shard0 to deliberately remain slow, or possibly slower (does anyone want 8s ticks with ~double available cpu?). This might enable new play styles, without the disadvantage of losing 33% of your CPU Unlock. (E.g. a player on average would pay for Memory serialization less often on a slow shard).

This would also enable a FAST shard (1 tick/s) without making it cost tremendously more to run for the server. (Per player over head increases, but time executing players' code does not).

Best of all a change like this is nearly imperceptible to the players' bots. Any bot with enough CPU control to notice will also have enough cpu control to cope; it would appear that Memory serialization is taking more or less cpu.