Database

In the database, we will shift from storing all resource properties as root properties in the parent object document, to a unified store object property. It will affect both official MongoDB database schema, and private server schema:

{
  _id: 'XXX',
  type: 'storage',
  store: {
    energy: 1000,
    power: 1000,
    XGH2O: 1000
  }
}

This schema will be used for all game objects capable to store any kind of resources - not only with general-purpose stores (like storages and terminals), but also spawns, extensions, labs, nukers, creeps, power creeps. The property will always be named store regardless of the object type.

Why do we tell you about inner database schema changes? Because if you have a mod that works with private server database directly, you will have to change it accordingly starting from the server version 4.x.x.

Game API

We're going to implement new global prototype called Store and use it in all properties such as StructureStorage.store, StructureSpawn.store, Creep.store (Creep.carry will remain as a deprecated alias), etc. This change is supposed to be non-breaking and backwards compatible: all resources can be addressed as object properties as before creep.store[RESOURCE_ENERGY]. But it will also have some methods for more functionality:

• Store.getCapacity([resourceType])

  • resourceType is undefined: returns total capacity for general purpose stores or null for limited stores;

  • resourceType is defined: returns capacity for that particular resource (for general purpose stores equals to total capacity) or null if this resource cannot be stored.

• Store.getUsedCapacity([resourceType])

  • resourceType is undefined: equals to _.sum(store) with internal caching or null if this is not a general purpose store;

  • resourceType is defined: returns used capacity for that particular resource or null if this resource cannot be stored in this particular structure

• Store.getFreeCapacity([resourceType]) - equals to getCapacity - getUsedCapacity.

• Store.isWithdrawable() - a boolean flag whether you are able to withdraw from this game object.

This new API is going to remove all inconsistencies and ambiguities that we currently have in different game objects that complicate dealing with resources too much.

The only breaking change will be that Store.energy (unlike StructureSpawn.energy!) will be undefined instead of 0 if there is no energy, this change is long due, since energy is an ugly exception there. UPD: See another option below.

Old-style properties like StructureSpawn.energy and energyCapacity will also remain for backwards compatibility (but deprecated).

We will deploy this change to the PTR with factories simultaneously, and allow for a month or two to test everything on the PTR (and ptr branch on npm), so you can test your game code and mods.

What do you think can be improved further in the proposed change?

This will also prevent breaking everyone's code in many many places.

What do you mean?

Almost every structure depends on energy, so it's good to be never undefined. energy===0 is an ugly exception in store, but it's not ugly in 'other structures' like extensions, towers, spawns, etc.

But every player can change the prototypes to get the desired behaviour, so it's not a big deal.

I'm worried that a preinitialized store for 'other structures' just increases memory consumption a lot more, which is already an issue for some players.

• One store bucket for both resources (and you will be able to load only 5000 units of ghodium in it)

• Two separate stores energyStore and ghodiumStore each with its own capacity.

Almost every structure depends on energy, so it's good to be never undefined. energy===0 is an ugly exception in store, but it's not ugly in 'other structures' like extensions, towers, spawns, etc.

It will be undefined only in the Store prototype, but not in StructureSpawn.energy for example.

storage.store[RESOURCE_ENERGY] === 0 // true
storage.store[RESOURCE_HYDROGEN] === 0 // true

Enumeration will work only through properties that are greater than 0.

• Two separate stores energyStore and ghodiumStore each with its own capacity.

With any other property than store it's not a simple unified API anymore. It has to be one store or no store, but we don't win anything if we wrap number fields in xxxStore-objects.

For developing I must disagree with making the energy and energyCapacity deprecated. If you know the structure you are using, then these fields are the preferred way to access these values. The function of store is just to simplify some code for generic transfer/withdraw.

I like the idea with store-properties returning 0. I think what @TuN9aN0 pointed out is an implementation detail here. I would be against Proxy. Store-objects for Extension or Tower could be using a Prototype which is just a view to the Structure without own memory, which has a property defined in the prototype to be const 0 for each resourceType and energy is a getter to the (hopefully not deprecated) energy field of structure.

As to your compatibility concern, please see the post above.

How many resources were factories going to add again? I sure hope for the Game Object's footprint on the heap it will come through some proxy, otherwise each Structure that can potentially hold something will have this massive hash with 0 values in it...

40 new resource types. But there is no real data for absent resources in a Store. Store.prototype will just contain a getter for every resource type which returns 0 if the underlying DB data object doesn't have the corresponding resource property.

For developing I must disagree with making the energy and energyCapacity deprecated. If you know the structure you are using, then these fields are the preferred way to access these values.

I don't get it, why exactly is extension.energy so much more convenient than extension.store.energy that we have to keep this ugly duplication forever?

But for every other non-general-purpose structure this is only a little nice-to-have feature to simplify withdraw/transfer. If dealing with structure-specific code, I would prefer to access energy and other fields directly. If it's general purpose refiller/robbery code, then I would go for store.

Important to be is that such a change does not have a negative performance impact.

If dealing with structure-specific code, I would prefer to access energy and other fields directly.

Still can't seem to understand what's the difference between addressing .energy and .store.energy?

As to performance, CPU-wise it will not be affected, only heap-wise concern is valid here, and we can simply raise the heap limit on deploying this change.

For those wanting to keep energy/energyCapacity, they can easily do a simple prototype extension in their code. Object.defineProperty(StructureExtension.prototype, 'energy', { get() { return this.store.energy } }) Object.defineProperty(StructureExtension.prototype, 'energyCapacity', { get() { return this.store.capacity } })

Before I used typescript and enforced this at "compile-time", I remember fixing various bugs where I tried to treat an extension as if it had a store, or some other structure the other way around.

I will be glad to have a unified interface, even though I'll have to at some point rework some of my code.

It will make the game slightly less complex for new players.

Two potential issues. First, the obvious one: Nukers with their 5000 ghodium. Two stores? Ewww! Don't make them all the same except for this one weird bird. Applying a limit object with, for example: {G:5000,energy:250000} to it is the best solution, other structures would have null there to short circuit any checks.

Then the 800 pound Gorilla: LABS. Labs are incompatible with a Store object unless you dynamically reset the limit object on the fly. Sure, the capacity remains 5000, but it can change from (for example.) {UO:3000,energy:2000} to {energy:2000} to {KH:3000,energy:2000}. It can have only one non-energy resource as it uses that to determine what it's doing.

I think professional players already know how to overwrite prototypes and have aliases and getters for their needs already. Everyone can already model a unified store, and properties for energy and whatever. Keeping that in mind, the API change is mainly for newbies and those who cannot change prototypes using typescript or have found ugly ways around the inconsistent API which they like to simplify.

As a newbie I did often access creep.energy directly instead of creep.carry.energy. The same for storages, it was just so annoying that I always have to access either carry.energy or store.energy or energy when at first all I care about is just simple energy. The tower has no store, the creep has no energy and no store but carry instead; just not consistent. But I can make it consistent with prototypes. So yes, this change would not really help me, but it will help other newbies. One store for all kind of objects is a great change for the API.

About the database change: Please just choose the most efficient model.

I think every high-level player at 300 cpu cap and those who are looking forward to be one agrees with me that performance is more important than convenience. The database is hidden from us, so I prefer an efficient database model over a simple engine code. I have no idea if your proposed database change will have a positive or negative impact on overall performance, but I just fear that it's a negative impact because it looks more complex than before. In my eyes, the API and the database change are two different changes.

In the end these proposed convenience changes should meet the following requirements:

1. one store for every relevant object to allow a unified way to access energy and resources for convenience.
2. It shall not increase overall tick rate, better decrease it.
3. It shall not significantly decrease the free memory we can use
4. It shall not increase our cpu consumption, better decrease it.

If that's all met, then I believe every single player in the community will be happy about this change.

I have no idea if your proposed database change will have a positive or negative impact on overall performance, but I just fear that it's a negative impact because it looks more complex than before.

It will be positive. Look at this engine code:

exports.calcResources = function(object) {
    return _.sum(C.RESOURCES_ALL, i => typeof object[i] == 'object' ? object[i].amount : (object[i] || 0));
};

It will benefit greatly from this database change:

exports.calcResources = function(object) {
    return _.sum(object.store);
};

Keep both and everybody is happy.

This is exactly how legacy monsters are born