Here is a pure mutex system (no backwards writes). The key I think you missed it it's based on time not ticks.

1. Claim the segment by writing your shard number and time + 3*N seconds
2. Wait till you've claimed the segment for N seconds.
3. If N < time < 2*N seconds then write data (also increment a sequence counter).
4. Do not reclaim the segment for M seconds.

During all this every shard keeps its own copy of the shared memory. which it refreshes every tick. If their copy is more up to date overwrite the segment.

• N should to be your slowest tick + clock skew between machines.
• The safest M is # of shards * N. Smaller values allow write starvation of slow shards.

The easiest way to break this system is having a shards write get committed long after the script's tick is over (like > 3N after).

It is also possible for this scheme to break when ticks are > N. But even then a single slow tick doesn't break the system. Consistently slow ticks also don't break the system. You need inconsistent tick times.

1. Shard A 2N slow tick while Shard B claims
2. Shard B has a 3N slow tick while trying to write.
3. Shard A claims and writes during B's slow tick.
4. Both Shard A and Shard B think they have the next sequence.

Choosing N and M can be tricky but picking large values like 1 minute and 5 minutes respectively for the MMO server will just work.

The big problem with this scheme is it's SLOW. A shard could wait 100 ticks or more before acquiring the shared segment.

Quick hack to fix this.

Creep.prototype._notifyWhenAttacked = Creep.prototype.notifyWhenAttacked;
Creep.prototype.notifyWhenAttacked = function(notify) {
  const spawning = this.spawning;
  this.spawning = false;
  const ret = this._notifyWhenAttacked(notify);
  this.spawning = spawning;
  return ret;
};

The processor doesn't check that the creep isn't spawning. So bypassing the client side check in Game is all you need.

Getting rid of the restriction entirely is better idea though. The change is simple and sane enough that you would probably get it done faster by creating a pull request than asking them to do it for you.

PS: Devs, please make an official intents api, most (all?) client side checks can be bypassed anyways.

You may not know much about programming but you seem to have a natural talent for QA.

I fall on the other side of manual control argument.

I do NOT think they need to add to features into the UI, I'd rather the spent dev time elsewhere. However if they enabled a click or viewing api from the console we could answer these request when they come up with a snippet of code to get the player going.

In other words I don't think screeps is only about automation. I think it should be fine for a player to write a much more manually controlled bot. Taken to the extreme I think it would be awesome if someone built an open source bot that was 100% manually controlled. Like the worlds slowed RTS. It would be a much better open source starting point for an overwhelmed player than a semi-complete autonomous bot.

That looks like an error from the Sim. Something about the Sim really messes up line numbers.

It seems that an eve like market might fit screeps best (automation, etc). I'm not familiar with EVE so I can't compare them really.

A question about local markets. Are screeps shards a good approximation of EVE's different markets? It seems like the shards would have to be more asymmetric to drive that kind of economy. E.g. X spawns at a higher rate or large deposit in a shard0.

I'm not inter-shard so it's hard for me to judge just how hard it is to accomplish. But I assume that it's good proxy of the complexity of shuffling materials between market in EVE.

I think it would be interesting for someone to compare screeps market systems with those of successful games. Those market are designed by economists and data scientists not programmers. So in theory they should be a good model of how to build a thriving market.

Guild Wars:

• List Item (SellOrder)
• Sell instantly (deal with BuyOrder)
• Place Order (BuyOrder)
• Buy instantly (deal with SellOrder)

If screeps followed the GW market.

• SellOrders still cost 5%. Resources listed for sale immediately disappear. They are returned when the order is cancelled.
• When someone deals with your SellOrder, 10% of the credit evaporate.
• Dealing with another player's SellOrder is free.
• Dealing with another player's BuyOrder costs 10%.
• Placing a BuyOrder is free, but the credits are taken immediately. They are returned when the order is cancelled.

Other GuildWars differences:

It's impossible to create a BuyOrder for more than the lowest sell or vice versa.

GuildWars has an Global Market (not sharded).

Vendors will buy anything but a low fixed price.
You cannot create orders at or below that fixed price.

Not all Items are sellable on the market. They do this so that players have to acquire some resources by play (limit pay to win). This is kinda like screeps CPU.

When GuilldWars introduced a new raw material they limit the amount that could stockpiled to force it to be actively traded. Once the market was established (about a year) they enabled the standard stockpile behavior.

Of these differences I think the current screeps market might be wise to follow the GuildWars fees.

I also think that a Global Proxy market would have been better than a distributed direct market. E.g. terminals upload or download resources from the market. You then deal and create orders with materials uploaded to the market. Honestly I think this would have been more efficient server-side as well. Run the market at its own tick rate that's much lower than any shard like 1 per minute.

Anyone else have experience with Path of Exile or Diablo 3 or WoW's economies?

Honestly :), I'm OK with the idea of scrapping hitback from ATTACK parts.

Another option. Add a new creep intent called .defend() that enables hitback, then keep the current behavior and values. I'm not sure whether this should be concurrent with .attack(). This feels more fair as the attacked creep is no longer getting free damage. It might help the devs too as the new intent should lighten server load.

Currently I only count on hitback for SK mining (theoretically, I don't actually run that code) and on healers so naive attackers will eventually kill themselves. The .defend() is only a little more code for my healers. Assuming concurrent .defend() and .attack() the SK creeps should keep working, though they will cost more intents which is why I and others don't run them in the first place.

I assume the 60 day cadence for billing it to simplify the business side of the code and operations. Shifting to a daily cadence might be a lot of work for devs. I'd rather the focused more on game code than boring billing code. (That said, I'm not a game designer, micro transaction might be a huge boost in revenue for the devs which would be a positive for us players as well).

A simpler (I hope) suggestion, break your request into two parts: micro-subs and partial subscriptions. Microsubs would be a new resource (or they could replace the current subs). Then players can buy their tokens piece by piece and that might increase the trade rates. To keep the billing logic simple, a 60 day subscription consumes 1 million mirco-subs.

The more complicated problem of enabling partial subs can be solved later if/when it looks like a good ROI for the devs. 500,000 for 30 days, 31337 for 3 days, etc.

Using flood fill looks like a cool way to analyze a room. However it really should not be part of the api. The recent changes to the terrain inspection enable fast communication between JS and WASM. This could be a wasm module if you really need to call it frequently. Though honestly I expect this would be a just fine as an expensive but cacheable calculation.