PTR Changelog 2019-02-01: Power Creeps
-
@artch I strongly disagree with
Right, and this is a big problem. In an MMO like this, the attacker is always at an advantage due to the time he spent planning the attack, and if some mechanic gives him even more time-related advantages over the defender, it's a bad mechanic.
I think defense is definitely at the advantage. Walls, ramparts, towers, closer spawning, safemode, TTL travel distance. They all are 100% in favor of the defender and are huge advantages. The time spent planning and honestly just that you can attack when players are AFK is the only thing that makes it even feasible to attack a properly reinforced room.
I don't think that purely reactive defense should be as strong as a prepared defense. Right now the only difference is a few hundred ticks of spawning to get defenders out, which is negligible in terms of wall damage.
The cost with deleting and rebuilding PC is that you are missing millions of power worth of power creep levels for 24 hours. That's a HUGE opportunity cost, especially for a fully upgraded PC. Also, if your rooms are designed to run with them in mind you're operating at a position of weakness for that duration. I'd put it akin to suddenly restricting yourself by 50 cpu for 24 hours.
I do agree with making power creeps feel special. I see how you've arrived at this, especially given your starting point and I like the idea of a power creep being a commitment. The one thing that having freepass tokens for long periods of time does is that it makes it painful to programmatically control power creep creation. Which I think might be one of your goals based on previous discussions (not even wanting to make an API for power creeps etc), but is a very strange goal for a programming game.
Obviously the punishment of losing a level is way too high, and giving out tokens is weird and unintuitive gameplay that will especially punish newer players. I'd like to propose another approach:
- When a power creep is spawned, you are locking your power levels into that creep for a long duration. After X ticks since that PC was first brought into this world, you can choose to retire it by reabsorbing it over 24 hours. At the end of 24 hours you can freely assign those levels again.
- Leveling a creep adds a fraction of the CD to the timer
- Optional: The CD scales in part with the number of power levels an account has, where having a ton of levels locks a player out of refitting individual creeps for longer.
- Optional: Recreating a power creep you had before offers a discount. (Builds identity)
- Optional: Every time you reassign power creeps, the constant that multiplies the timer goes up. This decreases with time. (Disincentives frequent swapping)
This will make power creeps a large commitment that players will have to think carefully and design around. This means that it's not free or easy to swap between options, but it is possible to do so. If you want to add shortcircuiting logic you can spend a level to immediately reassign, but I'd advise against that.
I think it's clear the tokens are a just a weird way of trying to limit player swapping, and level loss is a definite feel-bad mechanic. I think removing both and making it clear that building a PC is like building a room, a clear commitment of time and resources that you need to think clearly about.
-
@davaned I don't mean advantage and disadvantage in general, I mean time-related advantage, the time frame available for reaction -- it's always on the attacker side. Allowing attackers to switch in advance (24 hours, 48 hours, a week, whatever) and disallowing defenders to switch instantly aggravates this even more. No delay-based mechanics would solve this unfair feeling. We either have to allow everybody to switch instantly, or disallow everybody to switch at all (or restrict it).
-
@artch Thanks for the clarification. Do you feel that this is taken care of with the current implementation of a 24 hour delay and losing a level?
This will always exist if it isn't easy to programmatically respond to threats, because people can't be oncall for screeps 24/7. Any significant barrier to readying defense that requires more player interaction (no api, huge costs, long time, etc) makes this worse, with increased frustration if a player knows they are being attacked and can't respond.
I think lack of PC API is a great example of something that would have made for a terrible user experience in a game about automation. I think having a huge cost or an out-of-game resource experience (some sort of change credit) is a large barrier to being able to code a defense. If you're looking to have people able to react defensively in a programatic way I'm concerned this isn't a good approach.
-
@artch said in PTR Changelog 2019-02-01: Power Creeps:
Definitely still need power creep LOOK and FIND constants, or roll them under the CREEP constants.
FIND_*_POWER_CREEPSshould work on the PTR currently, have you checked?Okay, so that does exist, but it isn't in https://screeps.com/ptr/constants.js which makes it super hard to tell what constants exist. I thought that was the actual file the server used and it always had to contain what is used in game.
Operate_extensions should alleviate this some, but the really low amount of energy moved + the really long cooldown (you can get 5 50 part creeps out of 3 spawns in the time it takes for 1 fill cooldown) makes the skill practically useless and the synergy between the two skills is non-existent.
OPERATE_EXTENSIONS just seems a bit underpowered. I think a better solution is to increase its effect rather than change the mechanics. What do you think is an appropriate value?
One idea is to change its effect to a percentage of all extensions in the room: 20/40/60/80/100% of all extensions in the room are filled rather than some energy amount is sent.
That'll definitely make it stronger, but how will that factor into energy required by the power creep?
-
@davaned I can't seem to catch your point here. How exactly the current implementation of losing a level makes people not able to react defensively in a programmatic way?
-
Okay, so that does exist, but it isn't in https://screeps.com/ptr/constants.js which makes it super hard to tell what constants exist. I thought that was the actual file the server used and it always had to contain what is used in game.
This is the actual file used by the simulator, not the server. The actual server-side version is in the
ptrbranch on GitHub: https://github.com/screeps/common/blob/ptr/lib/constants.jsThat'll definitely make it stronger, but how will that factor into energy required by the power creep?
All energy is taken from the target structure, as it is in the current implementation.
-
@artch said in PTR Changelog 2019-02-01: Power Creeps:
Definitely still need power creep LOOK and FIND constants, or roll them under the CREEP constants.
FIND_*_POWER_CREEPSshould work on the PTR currently, have you checked?What about the LOOK_*_POWER_CREEPS constants? I could not find them. Also, does it make sense to make one that finds any creep, power or regular? for pathfinding etc i would need to find both kinds anyways.
-
@geir1983
LOOK_POWER_CREEPS(withoutMY/HOSTILE) is on the PTR. Private server is not updated yet.A constant for both types makes little sense since they have different prototypes. It's better to find both separately and just concatenate arrays then.
-
@artch typing LOOK_POWER_CREEPS in the console gives me an "is not defined" error message in return when on the ptr (through the steam client)
-
@slowmotionghost said in PTR Changelog 2019-02-01: Power Creeps:
I personally feel the power creep is too large, I think it should be the same size or only slightly larger than a regular creep. I get that you want to differentiate it from regular creeps but the way it overlaps other objects looks funny.
I agree. We've touched up on this on slack with o4, he said PowerCreeps are intentionally larger than normal so normal ones would cower in fear and run away just at the sight of it.
What we suggested is shrinking normal creeps and power creeps proportionally, and maybe also shrinking the Storage too, because that thing is huge.
-
@artch Significant, permanent loss based on a judgement call on what game state in 24 hours will be? Definitely falls under the difficult to code region imo. If PC are intended as a separate way of playing the game from a GCL focused player, switching a major PC from eco to defense represents a huge loss of your empire for the duration, and then another level loss again when you swap back. 2 level loss and 48 hours of missing a chunk of the engine that is driving your PC based empire is a harsh tradeoff to wrap in code.
That's part of why I suggested having power creep templates and make swapping back to your old heroes be easier. Otherwise you pay a double price.
-
typing LOOK_POWER_CREEPS in the console gives me an "is not defined" error message in return when on the ptr (through the steam client)
Oops, indeed, sorry for that. Fixed.
-
@davaned It's rather indirect and obscure opportunity cost. If a player is not relying on PCs so much, he wouldn't consider this a loss at all. Cost should be direct, straightforward and obvious so that everybody understands clearly that reprofiling is not free.
-
@artch Ok, in the end of the day if you are set on punishing PC change in a clear permanent way it does do the trick. However the tokens are going to essentially render it non-existent unless players want to swap multiple times a week. If you really are set ensuring permanent penalty for changing is the 24 hour wait necessary? I feel like it goes against your previous comment.
No delay-based mechanics would solve this unfair feeling. We either have to allow everybody to switch instantly, or disallow everybody to switch at all (or restrict it).
I'm personally in favor of a delay since I feel it makes offense easier. However, I think that as from a game mechanics standpoint, having something based on RL time and not ticks is confusing as you cannot cleanly code for it and varies from shard to shard and day to day. I understand you did this because they are account resources, but the problem still remains that the game is experienced within game time. If you keep it, personally it seems more logical that the PC would be absorbed (die) at the beginning of the time period and at the end of it the levels are unlocked, rather than it suddenly poofing from somewhere on the map.
-
LOOK_POWER_CREEPSis missing from PTR (again?). I'm pretty sureRoom.lookAtis referencing it, but the spatial register is missing.
-
@artch seems no powerbanks are spawning on the ptr? Its no dealbreaker, but processing power is one of my energy sinks, without it my storages are overflowing, especially with the regen sources power. If we could have it enabled it would be appreciated.
-
However the tokens are going to essentially render it non-existent unless players want to swap multiple times a week.
Experimentation periods cannot be enabled from the API, so players can't include them into their automatic reaction algorithms. And they are finite and should be used carefully. It's unlikely that somebody will spend two experimentation periods just for some random war.
Also, I'd like to note that although we plan to replenish them in the future, but not necessarily up to 30 again, it might be any arbitrary increment depending on how big the game change is. It's better not to spend them under an impression that the next replenishment will make it 30 again.
If you really are set ensuring permanent penalty for changing is the 24 hour wait necessary?
The 24 hours wait is needed just to provide enough time to change your mind, since it's a permanent account loss and cannot be undone. Or imagine that someone with access to your computer just wanted to annoy you a bit and deleted all your PCs, then created them again and deleted again until you have GPL 0. With 24 hours delay, you have time to react and cancel.
-
I seem to have an issue where i apply the PWR_REGEN_MINERAL to a "X" mineral on PTR server where the function returns "0", but the power is not applied. I only have one "X" mineral, in other rooms it seems to work fine (on other minerals). I also have had two operators in the same room, both trying to apply the power at the same time, which may have caused the issue? Id of the mineral is "598342f3641acf0573578343"
-
@deft-code Works for me:
> Game.rooms.E13N15.lookForAt(LOOK_POWER_CREEPS, 18,23) < [powerCreep PC1]How do you reproduce it?
-
@geir1983 This mineral deposit is on cooldown, so the power doesn't work.
usePowerdoesn't check semantics of all powers, it simply returnsOKin such cases, and the check is done server side.
