Let's move this discussion to the follow-up thread.

The discussion is moved here.

Temporary Shards/Monthly Challenges where players compete (or cooperate against a shared challenge) for prestige/practice.

 

ooh, and maybe allow us to get early access to a new shard before it opens up if we want to have to jump through the temporary shard.

This mechanic does definitely seem interesting, but I would be much more open to it if there was a smaller cooldown.

As is, as Steeler said, it very heavily penalizes spread out empires, and practically makes portal-expansion completely pointless.

As of now, my furthest two rooms are have a linear room distance of 104, and all of my rooms are either claimed by moving a large distance, or by moving through a portal. I felt this was a good strategy at the time, both because it allowed for more remote mining, and so that it was harder to "attack" my empire.

If this change goes through as is, it will leave players like me at a huge disadvantage compared to the ones who just chose to "dominate" an contiguous block of rooms.

Just one more point I would like to make, is the technical burden for remote mining.  As a new player, I still haven't dealt with remote mining, since it would take a significant time to get code that would result in a profitable operation.  Right now, I am more focused on immediate issues inside my own rooms.

If you make is such that we need this power creep to boost a source, I fear that will just increase the burden of remote mining for newer players, in terms of coding (and cpu).  

I 100% agree that higher player remote mining operations are too profitable right now, but on the flip side, if you reduce those profits, you will make it such that newer players will almost never remote mine.  I would like to see a balance that limits higher players, without harming newer players.

I found Dissi's suggestion of "intermediate rooms" very interesting.

What about yellow/orange sectors for intermediate players. While there wouldn't be walls blocking entry, it would have some limitations to help players get established. For example - no boosted creeps (any creeps entering the zone lose their boosts), and no nukes.

I could also support Tedivm's idea of signing controllers with boosts to prevent noob zones from opening.

Dewey

Let's move this discussion to the new thread.

I quite like the proposed equation. ~0,5 cost @ 25 range is a really sweet point to me,

As a random thought, what effect would making different tiers of boost / resource have different transfer costs be? Atm the t1 boosts, do not see much trading at all, even for new players. If they were to have lower transfer fees, or a wider transfer range, than t3 boosts, it may make them more palatable?

On the whole I really like the idea of regional markets, provided that each region has equal maturity (a regional market of only new players would sort of suck).

@artch if you launched it next week and put it in production three weeks later (for a total of about four weeks) it should be fine. People won't be getting back from the burn until September 5th, so they won't see this announcement until after that.

@artch I agree about the isolated shard. I already don't interact meaningfully with 99% of the players on shard0 and shard1, so I don't know that it would really be that different to play on a 100 person shard. The new shard1 => shard0 portals are so dense that I have lost track of who is potentially an inbound threat. It's basically random.

I would like to revive this thread, so I will what I understand from all comments so far:

* It is easier to wipe player than to take single room (and thus big players are de-facto immortal)

* It should be easier to take single room than to wipe player

* 2 week holding by attackers is not fair against insta-reset by defenders

* It shouldn't be more complicated

* One 'correct way' of waging war shouldn't be enforced

* Rooms shouldn't be steamrolled (even against 'few hours a week' player)

* Is screeps fully PvP-based strategic game with conquests (part of community) or semi PvP-based sandbox game with PvP arena fights (Artem)?

 

Also from another thread about SWW1 we have learned that there are various playstyles, where "Culture is a lighthearted civilized collection of city states (Greek), TK is a barbarian horde (Germanic) and SUN is a militaristic empire (Roman)". And of course each of these playstyles would prefer different attacker-defender balance. I personally advocate for...

* more dynamic wars and against immortality, where single rooms change hands casually but players respawn rarely. For me this is the first beauty of screeps - survival in diverse universe.

* perseverance of player diversity. For me this is the second beauty of screeps - survival in diverse universe.

* simplicity. I think it is critical to ease automation and make everyone better at survival in screeps universe.

* wider strategic and tactical options. I think it is critical to make screeps universe more diverse.

 

I think that root controller won't solve this. I really liked the idea by @Dissi that creates more fixed points in times on which people can act (fun), and by @tedivm that attacks mean something (simple, easier to take single room). Here is my combined proposal that tries to take the best of both:

const DECAY_OFFSET = 1500;  // Some ticks to wait since last upgrade to start decay controller
const DECAY_AMOUNT = 50;  // Some amount at which controller loses points per tick
const DECAY_THRESHOLD = 0.25;  // Some percent at which decay doesn't decay at decayAmount rate but drops to 0 and lowers RCL.
const CONTROLLER_LEVELS.8 = 32805000; // some amount RCL 8 controller continues to accumulate points

Example #1: Attacker wants to conquer fully filled RCL 8 room and destroys everything in it. Defender retaliates DECAY_OFFSET/2 ticks later, kills attackers, puts 1 energy into controller and DECAY_OFFSET is reset, no controller points are lost. Attacker successfully attacks again before defender builds defenses. The rest of defender raids with intention to reset DECAY_OFFSET are unsuccessful so he prepares for a big battle several days later just before DECAY_THRESHOLD will be reached. Defender successfully kills attackers, and starts building both defenses and upgrading controller to buy time. Attacker is aware of opportunity to burn DECAY_THRESHOLD amount of controller points, so he calls in friends, kills defenders, waits until DECAY_THRESHOLD is reached and room drops to fully filled RCL 7. --- From that point on, everything repeats but with shorter periods. Both sides are motivated to fight for the room and are rewarded for that. Simpler, more balanced and motivating, and taking a room becomes easier than wiping a player.

Example #2: Underdog is up to bite a big player. He watches one room that just turned RCL 7. Underdog prepares a high burst army and waits until that RCL 7 gets just below DECAY_THRESHOLD controller points. Then he launches the attack, luckily gets through and after DECAY_OFFSET instantly burns all constroller points and drops room to RCL 6. Big player soon after gets army together and easily regains room. --- Well timed attack can cause big costs so that even underdogs can at least hinder big players. More fun.

Extra ideas:

* Make controller to drop energy at DECAY_DROP rate as it loses controller points, and drop a proportional pile when threshold is triggered. Could also be intentionally used by defender as "emergency funds" in case he runs out of energy under siege.

* Make creep.attackController part to fasten the process.

* In case of respawn don't release ownership of rooms but transfer ownership to dummy player, so respawns don't free up rooms instantly. Probably with -1 RCL penalty to prevent respawn spam.

 

What do you think about this?

After some debate let me make a statement to leave no room for ambiguity:
According to http://docs.screeps.com/tos.html

Under LIMITATIONS

Register more than one account to play the Game.

So a maximum of 1 account per player.

I’ve discussed this matter with Artem and this is the final decision

 

Unfortunately, the Cassandra experiment has failed.

We've migrated the entire room objects data set on the live world, set up proper partitioning based on room key, and allocated server capacity to Cassandra instances 3x times larger in comparison to the MongoDB server.

The world simulation worked correctly. However, no considerable performance increase has been achieved.

This thread is now closed, the PTR is switched to the master branch. We're back at the world sharding idea, the discussion is in this thread.

Hi, sorry, that was the quickest way for me to test many creeps moving around.

The sim, while paused, seems to sit at 30-35%, even after I've put a number of buildings up.

Is there any chance for one more hopefully small adjustment to the smooth animations option? When disabled, could "Ambient" animation loops (energy, source keeper, spawning spawn, reserved/degrading controller, etc) only make a 1 second loop once at the top of any tick?

That would allow a full pause in animations between per-tick animations, allowing the CPU to go into a deeper sleep state temporarily. This should help a lot for laptops. In public there's a 0.5 to 1s space between animations for previous tick and the next tick starting, so this would be perfect.

Thank you! This already helps a lot.

> My point is that the nuke change finally gives attackers some real options. No room is unassailable, which is good.

I agree to this. If someone is willing to spend a fortune then there should be a way, and of course there should be counter-measures to diminish the effects and make it even more costly. Sooner or later someone will throw 20+ nukes to a single room but that's excessive fortune and defender may even be better off rebuilding, not defending it.

More strategic options, more fun!

In my opinion it should be heal first. That's much less speculative and very consistent with the descriptions from dissi and BlackLotus.

To clarify the steps which are happening in the chosen pull/15:

collect all damages and heals check for death apply damage drop carry if damaged apply heal cap max health

So now it's damage first without death check. So effectively a creep can have -10k health after receiving damage and be healed back to max hp with 15k in the same tick, giving every healer the Defend skill of a power creep, making that skill obselete. That is called 'overhealing' in this post.
That also means, that healers must guess which creep will receive damage to give the intent to heal such damage before it happens.
Boosted tough-parts will only be effective when they're always healed before knowing the damage.
Fights with boosted creeps will be a gamble.
If it stays like that, I just see one inconsistency: After step 3, there is no death check, but there is a carry-check.
I guess the check for `'./creeps/_drop-resources-without-space'` should be done after the healing. Because If death is delayed then the drop of resources should also be delayed.
I'm also a little confused why the check for death is step 2.

However, I see another way of a more consistent overhealing:

collect all damages and heals apply heals (without cap --> 'overhealing') apply damage drop carry if damaged cap max health check for death

This allows overhealing, but doesn't revive dead creeps. It gives boosted tough parts their strength back, because you'll know exactly how much you need to heal in order to use the boosted tough parts.

Kind regards,
Xenofix

Just wondering about the other end of this. I'm GCL 7 and I would never spawn next to Dissi.

I don't think it matters how good your code is, if you spawn there you die.

This really raises the stakes when you are GCL 4+ and you get wiped out because you will probably never be able to get a good start ever again.

Breaking the expected behaviors of common operators is a very dangerous move. I don't ever think it's a good plan.

As W4rl0ck points out, this would completely break the encryption module developed for public segments. I'm sure there are a variety of other things that we aren't considering which would also break. It would also require essentially forking node as far as I can tell.

Detect a newly placed flag, save its position into memory, create a visual point at this position (optionally), delete the flag. You don't need even 10 flags if you only use them to point to something via GUI.

Why should it only be PvP? If an Invader or a Source Keeper damages you, you should get that information too.