@tehfiend That is an awesome idea! It opens up endless avenues for exploring efficiency after "virtually every strategy is discovered" 5 years from now. I can see the E-Sport footage now... "Well, Steve, they are both using virtually identical quad attack squad strategies, but look at the CPU usage... I think we can see how this is going to end!"

@detox The only actually erroneous part in the upgrade controller text is: "This limit can be increased by using ghodium mineral boost." This alludes to a pre-alpha power creep concept. The actually implemented power creep ability is the Operator's "OPERATE_CONTROLLER" power which uses the "ops" resource.

But irrespective to that, yes. 15 is the normal cap for a level 8 room. And yes, "0" will be returned from the call because it was a perfectly legal call that returned no error in that it's the CUMULATIVE amount that is eventually checked... this is beyond the purview of the intent system to test for.

It would have helped if you indicated what room that was. But no problem, I found it.

Once a room is level 8, you can only use 15 WORK to upgrade it's controller. Trying to do more will return 0 for the intent, but not do what you want. The 32 WORK upgraders you were using simply weren't going to fly. Likewise, if there are 2 creeps and the first creep upgrades 15 worth of WORK, the second will return O and do absolutely nothing.

Ok. I've had this happen several times. This is a screenshot of a room I've recently taken and started building: Note that the room has 2 "safe modes" available... which makes sense in that it's level 3... One at level 2, one at level 3. Ok, great. Notice also that the Safemode Cooldown is over 37K. I never used a safemode. What DID happen is the room was under safemode cooldown when I destroyed it, and that cooldown NEVER RESET when I subsequently claimed the room. I crushed this room fair and square. The cooldown needs to reset on the subsequent claiming of the room.

So, I was under the belief that if we had a sub, we could keep that sub. But when my sub needed to be renewed, Not only was I unable to do so, but the sub was cancelled. Steam also told me the game was removed from my library... but that was obviously not so.

I had to quickly buy some "CPU Unlocks" from steam to restart my CPU.

Unlike most people that had subs, I do not have a "lifetime subscription." This isn't because I think they're too expensive... I would certainly save money. No, I am ethically opposed to the very concept of the "Lifetime subscription" as it promotes zombies.

Irrespective of that, am I just doing this wrong? I would like to keep the option of renewing the grandfathered in sub OR buying CPU unlocks.

Wow. Ok. This is a great concept. You've clearly done your homework, here.

Sign me up!

But I noted that in one of the posts, the game is flagged as "Windows Only", but you indicated there would be a "Mac OS" version. I've never been a Mac fan, and dropped Windows completely when support for Windows 7 was stopped in January. I've used nothing but Ubuntu Linux since then. Will Linux be in there too?

@fantasticmark Then you store the object's data in the Memory object. The heap can go away at any time, you have no "hard drive", and you have no persistent "data base" outside of the Memory object, which is reconstructed every tick.

An example: the RoomPosition object. You can create new RoomPosition objects all day with the constructor, and it saves the data on the heap for use during that tick. If you save the object onto the Memory object, only the data is saved, the Memory object won't carry the actual object to the next tick, only the data. You would have to reconstruct the RoomPosition object with the constructor every time you want to use it.

Now, there are types of data that you CAN safely store on the heap, and that's data that's derived from other data as a convenient cache... you can store THAT on the heap, and not take any cost of serialization every tick, but you have to be ready to recreate the data if a tick starts and it's gone.

As another example, I have data stored about the colony. It's data that can't be reconstructed if lost, so I store it in the Memory object in an object called "Memory.colony." Any data I need for the colony is stored there as properties. If I stored it on the heap, it would be wiped every time the heap is deleted... which would be bad. So It's in the Memory object where it's rebuilt every tick and available.

What deft said.

I would also point out that you don't directly change the objects you reference with Game.getObjectById() anyway... you REGISTER AN INTENT that the system then uses to change the object AFTER your code runs. So at the end of every tick... any object you have stored is going to be stale.

You can't have direct control over these objects... if you DID, you could just do stuff like change their hit points on the fly. Your script is like a proxy, once a tick, it runs. It has a shapshot of the current state of the objects, then it orders changes to those objects by issuing intents (Through the API calls.) at the next tick, it gets a snapshot of the updated objects.

I was wondering where the color came from, it just arbitrarily chooses one of the badge colors? Yeah, that doesn't work.

There are ONLY A FEW COLORS to even display. Your units, enemy units, screeps units, roads, structures, etc. Don't be lazy with the UI! Store them as 32 bit color values the user can set.

Then, everyone is happy! Even that one guy with teal-chartreuse colorblindness can set the UI to something they can see.

Where the video?

Well, those are impressive rewards. And many are fungible to many millions of credits.

Also, the last prize, that says "top N" from 1 to 100? Does that mean the number 1 player gets 10 of each of the top 1..3 items, then on down to 3 of the "top 100" items?