We keep getting memory corruption on shard2, with creeps losing their memory or parts of it.

It's happened just now - a few minutes before I got an email notification with the following error:

ReplyError: OOM command not allowed when used memory > 'maxmemory'.

and then 5 minutes later all of my creeps have lost their memory.

Any news on what's going on here? This is pretty serious, it would be nice to at least know that it is being fixed!

Ah great, I see them now, thanks. I also see an NPC stronghold - very exciting!

What's the status of PTR with regard to factories and new resources? I keep checking but haven't seen any of these on the PTR for ages.

Extending the prototypes makes sense - I guess I was thrown off because I tried entering Creep.prototype in the Screeps console, and I would see Error: This creep doesn't exist yet. I guess trying to "print" the prototype somehow tries to instantiate a Creep

This really threw me for a bit! You seem to have found the answer although you may not realise it so it's probably worth explaining exactly what's going on here!

Accessing Creep.prototype doesn't create anything. What's actually happening here is that the console calls .toString() on the object (e.g. Creep.prototype.toString()). When you call creep1.toString() it walks up the prototype chain and ends up calling Creep.prototype.toString(), but the this context is still creep1. If you call Creep.prototype.toString() directly, the this context is Creep.prototype. The toString() function tries to get this.name, but it's a getter, and it throws an error if the object doesn't have this.id.

This should work:

> !! Creep.prototype
true

Do you mean serializing them to Memory, or is there another "heap" that offers some persistence? I was under the impression from reading the documentation that global state is reset every tick. Is this a change with the introduction of isolated VMs? Is it as simple as using a global object/array?

var cached_creeps = {};

module.exports.loop = {
  if (!cached_creeps) { cached_creeps = [new MyCreep(Game.creeps.john_galt))]; }
  cached_creeps[0].say("I am " + cached_creeps[0].name);
}

Yes that's exactly it. There are basically 3 kinds of memory in screeps:

1. Game objects (e.g. Creep, Room, etc). These are only valid for one tick
2. The heap - that is, global variables or module scoped variables as in your example. These will last until a "global reset", which happens somewhat randomly depending on server load, but is generally a few hundred ticks or so. A global reset will also occur when you update your code.
3. Memory (including creep.memory, room.memory, etc). This is actually a bit of a misnomer. It's a flat JSON structure, so it's more like storing it on disk. Only cleared if you respawn.

I find it quite useful to use game objects to cache values that are only valid in the current tick. For example, I do things like this a lot:

Room.prototype.getRepairTargets = function () {
    if (! this._repairTargets) {
        this._repairTargets = this.find(FIND_MY_STRUCTURES, {
            filter: struct => struct.hits < struct.hitsMax,
        })
    }
    return this._repairTargets;
};

That way I can call this.room.getRepairTargets() on several different creeps but it will only call find once each tick.

Firstly, I would strongly recommend reading up on how Javascript's prototype system works, as this will probably clear up a lot of things for you. It's a bit confusing at first.

Very briefly: .prototype is only used to define properties on the constructor, which is actually a function:

function Foo(name) {
    // this is the constructor
    // Example: assign some arbitrary properties for this instance
    this.name = name;
}
Foo.prototype.bar = function () {
    // this is a method
};
// Create an instance
let foo = new Foo('one');
foo.bar();

When you try to access foo.bar, it will first look up to see if foo has a bar of its own. If not, it will check foo's prototype and see if that has a bar property. If not, it will check the next prototype up the chain and so on.

Instances don't have .prototype. You can get the prototype of an instance using .__proto__ (unofficial, deprecated) or Object.getPrototypeOf(foo), but you should never normally need to do this.

Since all objects in Javascript are dynamic, you can add methods to existing classes like this:

Creep.prototype.foo = function () {
};

This method will then be available on all instances of Creep, e.g. creep1.foo().

Generally there are two approaches to structuring code in screeps:

1. Extend the prototypes
2. Wrap everything in your own classes

I would suggest starting with option 1, since even the players using option 2 end up doing this to some extent. This approach is much easier to understand, as you only have to think about the one Creep type, instead of juggling Creep and MyCreep everywhere.

There are pros and cons to wrapping everything in your own objects. As you've noted, it can be quite a performance hit to construct all these objects every tick. The way around this is to cache the MyCreep instances on the heap and just update the internal .creep references each tick. This is why I suggest leaving this approach until you are more familiar with the game. It's best to deal with game objects (like Creep, Room, etc) and Memory - leave the heap until later.

Without wishing to confuse you, I'm currently using the prototype approach, but I hate the .prototype syntax so I use the nicer class syntax but then copy all the members onto the existing Creep class like this:

class MyCreep {
    bar() {
    }
}

function extendClass(base, extra) {
    let descs = Object.getOwnPropertyDescriptors(extra.prototype);
    delete descs.constructor;
    Object.defineProperties(base.prototype, descs);
}
extendClass(Creep, MyCreep);

I never create a MyCreep instance, I just use the builtin Creep objects everywhere, but I can still access all the methods from MyCreep because they've been copied onto Creep.

I hope some of this is helpful!

I would argue that Creep.move affecting PowerCreep.move is itself a bug. This surprised me when I encountered it and I fully expected it to be fixed at some point. Anyone relying on this behaviour is relying on a bug and should expect it to be fixed. For what it's worth, fixing this will break my code, but I still want it to be fixed.

All you need to do is publish an announcement far enough in advance that this is the plan and anyone relying on it can prepare for it by doing this:

PowerCreep.prototype.move = Creep.prototype.move;
PowerCreep.prototype.moveTo = Creep.prototype.moveTo;
PowerCreep.prototype.moveByPath = Creep.prototype.moveByPath;
PowerCreep.prototype.transfer = Creep.prototype.transfer;
PowerCreep.prototype.withdraw = Creep.prototype.withdraw;
PowerCreep.prototype.drop = Creep.prototype.drop;
PowerCreep.prototype.pickup = Creep.prototype.pickup;
PowerCreep.prototype.say = Creep.prototype.say;

For anyone who does this or isn't relying on the buggy behaviour there are no breaking changes!

Note: I would strongly suggest that all of the offending methods above should be fixed, not just the move ones, so the class should probably be called BaseCreep or something rather than Movable.

I started looking at unboosting but I abandoned it because it was just too expensive on lab time. At least we can ignore it at the moment, but as you point out, this will be a major problem if they change renew so it outright refuses.

I think renewing/unboosting needs reworking. The idea that you can't sanely renew creeps that have been boosted just seems confusing and nonsensical.

Why should it be so difficult to renew a creep just because it has been boosted?

My suggestion would be to not boost individual parts, but instead have boosts apply an effect to the entire creep for a period of time (obviously the duration is relative to the size of the creep). You can renew the creep whenever you like, but that doesn't renew the boost. If you want to renew the boost time as well you go to a lab and boost the creep a bit more, but this is entirely independent from renewing TTL.

The other advantage of this system is that it allows you to apply short-term boosts, which is a much-requested feature. For example, to boost MOVE so a creep can get to a destination quickly but doesn't need to move after that.

testPath(1, 1, 1)       length: 38, ops:  14 CPU: 0.25 ops/CPU:  56.39
testPath(2, 2, 2)       length: 38, ops:  14 CPU: 0.19 ops/CPU:  74.97
testPath(3, 3, 3)       length: 38, ops:  14 CPU: 0.18 ops/CPU:  75.74
testPath(4, 4, 4)       length: 38, ops:  14 CPU: 0.17 ops/CPU:  83.72
testPath(5, 5, 5)       length: 38, ops:  14 CPU: 0.17 ops/CPU:  84.21
testPath(6, 6, 6)       length: 38, ops:  14 CPU: 0.17 ops/CPU:  84.48
testPath(7, 7, 7)       length: 38, ops:  14 CPU: 0.17 ops/CPU:  84.67
testPath(8, 8, 8)       length: 38, ops:  14 CPU: 0.17 ops/CPU:  83.78
testPath(9, 9, 9)       length: 38, ops:  14 CPU: 0.17 ops/CPU:  84.78
testPath(10, 10, 10)    length: 38, ops:  89 CPU: 0.39 ops/CPU: 225.65
testPath(11, 11, 11)    length: 38, ops: 129 CPU: 0.53 ops/CPU: 242.89
testPath(12, 12, 12)    length: 38, ops: 155 CPU: 0.54 ops/CPU: 285.10
testPath(13, 13, 13)    length: 38, ops: 178 CPU: 0.60 ops/CPU: 297.97
testPath(20, 20, 20)    length: 38, ops: 392 CPU: 1.06 ops/CPU: 369.83
testPath(100, 100, 100) length: 38, ops: 928 CPU: 2.60 ops/CPU: 356.97
testPath(1, 1, 9)       length: 38, ops:   9 CPU: 0.16 ops/CPU:  54.63
testPath(9, 9, 1)       length: 38, ops: 867 CPU: 2.39 ops/CPU: 362.32
testPath(9, 9, 10)      length: 38, ops:  14 CPU: 0.18 ops/CPU:  75.75
testPath(10, 10, 9)     length: 38, ops:  89 CPU: 0.22 ops/CPU: 402.19
testPath(20, 20, 9)     length: 38, ops: 392 CPU: 0.58 ops/CPU: 675.35
testPath(9, 9, 20)      length: 38, ops:  14 CPU: 0.09 ops/CPU: 152.13

From my understanding the reason that { plainCost: 2, swampCost: 10 } takes more CPU is because the estimated cost h(n) assumes that all tiles have cost 1, so it branches out more trying to find something with a cost of 1. Obviously this is useful if you're using a costMatrix with a bunch of cells set to cost 1 (e.g. for roads), but if you don't have anything with cost 1 it's pointless.

But what I'm doing is compensating for this by setting the heuristicWeight. Since h(n) is assuming a cost of 1, but the base cost is actually 2, setting heuristicWeight: 2 should give the same behaviour as { plainCost: 1 }. My tests confirm that this is the case, but only up to heuristicWeight: 9. After that something else seems to come into play here.

I recently started with power creeps and I completely agree that there should be a shared base class. The fact that power creeps call methods on Creep caused me lots of issues.