3. Draft: Store prototype API

Draft: Store prototype API


  • @artch Nevermind I missed the sentence about StructureSpawn.energy and energyCapacity. I think deprecation is not needed though as they are semantically better then a store object with one always there energy entry. It's not that things are suddenly becoming dynamic.


  • How would store.getFreeCapacity work for say a nuker where the energy and ghodium capacity are in their own bucket?

    ☝
    1 Reply

  • I like the idea of a unified Store-object, but only for Structure, Terminal, Creep and PowerCreep. But for 'other structures' it would be nice to have a unified way to access resources.

    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.

    1 Reply
  • Dev Team

    @tun9an0 It's still to be decided. I see two options:

    • 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.

    2 Replies
  • Dev Team

    @xenofix Yes, implementing Store prototype only for general-purpose stores is also an option which we consider. But it will not allow for massive convenience improvement in the API for transfer/withdraw/whatever code reuse cases.

    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.

  • Dev Team

    OK, another idea came to my mind (top post updated): we can make Store prototype have getters for every resource types which will always return 0 for any resource, and never return undefined at all, i.e. we fix the inconsistency in favor of energy rather than in favor of non-energy:

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

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

    👍
    1 Reply

  • @artch I do appreciate the infrastructure concern but I do think it's kind of leaking here, I wouldn't model this as a store as it's obviously different from say a storage or container. Most of my code dealing with energy is kind of ortoganal to dealing with non-energy as is, checking structure.energy versus structure.store.energy otherwise is just shifting thing about. Another concern is store.energy though, the API currently guarentees .energy to be set. I am sure like me there will be a lot of people who deal with it like this also. undefined < 10 returns false, this will send some quite a few people astray I am sure. I will need to dig through a lot of code to get this fixed everywhere..

    1 Reply

  • @artch 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...


  • @artch said in Draft: Store prototype API:

    • 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.

    1 Reply
  • Dev Team

    @tun9an0 Database and API changes are irrelevant. They introduce separate optimizations for engine code and for player code, but they are not related to each other, we might deploy them in separate updates if we want to, but it seems logical to deploy them together. There is no "leaking" in that regard.

    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.

    1 Reply
  • Dev Team

    @xenofix said in Draft: Store prototype API:

    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?


  • @artch Ok well if it's not for infrastructure concerns, then my feedback is I do not need this change, I think it's currently fine. In my view it actually introduces a leaky abstraction. I don't need unified access to things that are essentially different logically. I would not model it this way.

    1 Reply
  • Dev Team

    @tun9an0 Very well then, thanks for your feedback! Let's see what other people will say, since this inconsistency and ambiguity in how resources are stored is being long complained by many players.


  • To me, carry is inconsistent. I would want to have it be named store instead. And a Store-object for general purpose stores is also very welcomed.

    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.

    1 Reply
  • Dev Team

    @xenofix

    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.

  • Culture

    As both a mod developer and player I'm exited about this update, for modding, it was always annoying not being able to iterate over resources in a simple way. As a player, the entire store/carry/energyCapacity/carryCapacity mess was annoying, in some cases, I actually wrapped all those to make them match, very similar to how this is designed. It might seem a bit more clunky for stuff with only one resource, but simplifies more than enough other code to make it worth it.

    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 } })

    1 Reply

  • @ags131 yeah I've had to abstract around energy, store etc in various places (e.g. if (instanceof_energy_structure(struc)) { } else if (instanceof_store_structure(struc)) { } )

    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.


  • From my point of view, I like and welcome this change, it will allow me to streamline my creep states so they can exit faster (Thus saving CPU.) I am concerned that heap use may increase, but that's Artch's problem... and in reality, any heap issue impacts everyone, mostly heavy users and users past the 300 CPU limit first, so I don't have a problem with that, despite that I'm breathing down the 300 CPU limit's neck. At the end of the day, it's pretty fair.

    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.

    1 Reply

  • I like the idea of a unified way of withdrawing / transferring resources, specially with getters that return 0 instead of undefined. I already have something like that in my code. I would have to keep it, though, since mine also supports pickup and drop. I'm not sure this change would benefit me specifically, but I see its value for general purpose code. The only things I don't like about this proposal are including nuker into this, which seems like a stretch and doesn't really add any value, and deprecating the old API. Forcing everybody to change their code, making it slightly more convoluted or it will eventually break, will just make people angry. I see no benefit in that. Keep both and everybody is happy.

    1 Reply
  • YP

    I also like the new structure .. I already had added prototypes for some of the features, like a cached storeSum and carrySum and having it official is a plus. If the api is decided I'd like to add a polyfill so I can already start to use the new store object 😉

Locked