Creep death: more than just a delete
-
+1 on the missing feature rather than an enhancement.
Visually I think it would be very appealing too, considering huge battles would leave brutal devastation in their wake as opposed to some energy piles we see now. A field of covered with the graves of the fallen is a nice touch. Adding a tombstone.say ("Here I lie/In endless rest") or even a more passive read-only message would be cool too.
One thing to consider would be whether tombstones would give vision of the room, which I'd say should be no.
-
I like it. So:
- New
RoomObject
->Tombstone
class with properties:id
,room
,pos
,owner
,creepId
,store
,deathTime
,ticksToDecay
. - New constant
TOMBSTONE_DECAY_PER_PART: 5
. Decay time is set tocreep.body.length * TOMBSTONE_DECAY_PER_PART
. When decayed, resources are dropped on the ground. - No active actions.
- Vision is provided.
- One tombstone per creep, no stacking.
Anybody willing to make a PR (both engine and docs)? Chances are that it can make it into one of the next PTR deployments, if done rapidly. We can grant 5 Subscription Tokens to the author of a successfully merged PR with this feature.
- New
-
Is it possible to add something like
killerId
for the creep/tower which did the last blow (or all creeps/tower having attacked it the tick it died) ? It is probably hard to do, but I'm asking :).
-
@hiryus No, it's out of scope of this functionality. Tracking actions is a whole another story.
-
@artch said in Creep death: more than just a delete:
@hiryus No, it's out of scope of this functionality. Tracking actions is a whole another story.
That's the answer I was thinking I would get. But at least I tried.
The idea is great anyway.
-
I can start working on it this afternoon.
Still got a few question that I need some input on:
Should the tombstone be created for creeps that die of old age as well? I think it should and contain the resources the creep was carrying.
Should creeps that
suicide()
create a tomstone? Maybe add this as an optional parameter (true
/false
)?Should I add a
FIND_TOMBSTONES
contant as well? Are there any other ways of how to access tombstones?Should this replace the current
dropToContainer
mechanic NPCs have? I think it should but it might break some peoples NPC raids or make them a lot less profitable until adjusting their code to tombstones.Should room owners be able to
remove()
/destroy()
tombstones before their ticksToDecay reached 0?@artch said in Creep death: more than just a delete:
- One tombstone per creep, no stacking.
What do you mean with this? If multiple creeps die at the same RoomPosition, should there be multiple tombstones, one for each creep?
@artch said in Creep death: more than just a delete:
- No active actions.
What is this supposed to mean? No creep actions against tombstones? I previously thought about allowing
Creep#withdraw
(see NPC containers above), but this got me thinking. If withdraw isn't allowed it just delays resource decay, does it?
-
Should the tombstone be created for creeps that die of old age as well? I think it should and contain the resources the creep was carrying.
Yes.
Should creeps that suicide() create a tomstone? Maybe add this as an optional parameter (true/false)?
Always create.
Should I add a FIND_TOMBSTONES contant as well? Are there any other ways of how to access tombstones?
Yes,
FIND_TOMBSTONES
andLOOK_TOMBSTONES
.Should this replace the current dropToContainer mechanic NPCs have?
Yes, it should, but I will do it myself.
Should room owners be able to remove()/destroy() tombstones before their ticksToDecay reached 0?
No.
If multiple creeps die at the same RoomPosition, should there be multiple tombstones, one for each creep?
Exactly.
What is this supposed to mean? No creep actions against tombstones? I previously thought about allowing Creep#withdraw (see NPC containers above), but this got me thinking. If withdraw isn't allowed it just delays resource decay, does it?
It means
Tombstone
prototype doesn't have any methods and cannot generate intents.Creep.withdraw
against a tombstone is allowed, of course.
-
@postcrafter said in Creep death: more than just a delete:
Should the tombstone be created for creeps that die of old age as well? I think it should and contain the resources the creep was carrying.
That makes sense, maybe it the tombstones lifetime should depend on the creeps TTL at time of death.
Should creeps that
suicide()
create a tomstone? Maybe add this as an optional parameter (true
/false
)?I think
suicide()
andrecycle()
should stay as is. Some players move creeps to die on a specific RoomPoisition where they expect resources to drop into a container etc...Should I add a
FIND_TOMBSTONES
contant as well? Are there any other ways of how to access tombstones?FIND_TOMBSTONES
would be a good idea. Are they going to show up forFIND_STRUCTURES
etc... as well?Should this replace the current
dropToContainer
mechanic NPCs have? I think it should but it might break some peoples NPC raids or make them a lot less profitable until adjusting their code to tombstones.Would make sense. Best to be consistent.
Should room owners be able to
remove()
/destroy()
tombstones before their ticksToDecay reached 0?If they do the tombstone would need to drop any resources it was holding.
Should it be a creep action? That way a defender can't rip them up the instant they appear.
Should they decay instantly if they reach 0 stored resources?
@artch said in Creep death: more than just a delete:
- No active actions.
What is this supposed to mean? No creep actions against tombstones? I previously thought about allowing
Creep#withdraw
(see NPC containers above), but this got me thinking. If withdraw isn't allowed it just delays resource decay, does it?I'd say that like a container the tombstone would have no actions that it can perform.
-
I think suicide() and recycle() should stay as is. Some players move creeps to die on a specific RoomPoisition where they expect resources to drop into a container etc...
If a creep dies on a spot with a container, then resources go to the container, and the tombstone is created with empty store.
FIND_TOMBSTONES would be a good idea. Are they going to show up for FIND_STRUCTURES etc... as well?
No, tombstones aren't structures.
Should they decay instantly if they reach 0 stored resources?
No.
-
Should resources in tombstones decay like when on the ground ?
-
@hiryus To my understand only the tombstone decays and drops the resources on the ground afterwards, then they'll decay normally.
-
That's what I understand too. But I raise the question for game balance as resources will now decay slower. In my opinion, the proposed change is fine.
-
so who is designing the nicest tombstone svg ?
-
@artch Excellent, I'm really glad you agree. Very excited to see it appear. The creepId field will be great. Eventually having a kill credit/actions leading to death will be a huge boon but this definitely helps as is.
@PostCrafter Thanks for picking this up! Go get them sub tokens Mind linking your PR here when its ready?
-
First part of PRs for Tombstones! https://github.com/screeps/engine/pull/74
-
@artch We should consider adding a .remove() for tombstones (and construction sites). It might be important to allow people to deny vision, and adding a .remove() for cosntruction sites would prevent the extractor site issues.
-
-
A thought I had, can I add creep name also? On my codebases I don't save creep IDs and instead use names, it would be easier to say, lookup the creep's memory with a name than it would with a non-existant ID.
-
It would be awesome to add a killerCreepId and killerCreepOwner field to the tombstone as well.
Tracking this right now is fairly tricky.
-
Not sure if it should be possible to control (remove) tombstones in any way.
As for the visual it could be some icon that does not makes it possible to use it to hide stuff. Maybe it could be a bit colored depending if it was a own or a hostile creep and look different depending if it's empty or not