Creep death: more than just a delete
-
@artch Hey there! I've been having a discussion in the slack channel that @o4kapuk told me to send over here.
I think there is value cleaning up the "poof" end of combat that we currently have. It's fairly boring, hard to determine due to room edges and ids+vision. Also, no death animations feels unsatisfying.
An idea I had to streamline this behavior would be to have creeps corpses/tombstones, and it would help with something that we already have (the killing caravans already leave a “corpse” of a container). A corpse/tombstone would have the full creep info (body, remaining TTL, creeps id, etc) Adding an array of the ids that performed an attack action against it last turn would make it possible to do kill credit and leaderboards for combat. Also, with the contract system you could effectively place bounties like "kill x enemy creeps" that could be tracked now. What was before a huge tangle can now be a check “in room xyz are there corpses killed by creeps with my ids?”
The second part to address: Part of what makes combat unappealing is the lack of rewards. If a killed creep drops a pseudocontainer for a short time on death it would make it feasible for an attacker to collect rewards from a successful battle (the 3+ piles of 60 or so resources on the ground decay so rapidly that its not worth arriving there for 15 or so minerals). Death animations would be able to have some fun effects that aren't possible now (shoutout to @bonzaiferroni 's awesome 3D client)
In summary, this would represent a way to clean up the current janky logic for determining when creep kills, add support for more involved logic surrounding kills for contracts, leaderboards, and tracking strategies, add incentives for combat by increasing effective kill rewards, and make combat a more exciting experience overall. Adding the ability to have "on death" code for an tombstone epithet or dying words would just be icing on the cake.
Thanks for your time!
-
I really like this idea. It feels like a missing feature, rather than just an enhancement. Tombstones would add a great visual element to aftermath of a large creep battle.
At very least the id(s) of dead creep(s) and a storage of their dropped resources. The other features would be nice to have but could be efficiently tracked by the player instead.
The feature could be extended to structures as well.
-
I think a new game object, "tombstone", that acts as a container but only lasts for like 300 ticks would be pretty awesome. They'd have to stack in case a creep stepped on one and died.
-
+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->Tombstoneclass 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
killerIdfor 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_TOMBSTONEScontant as well? Are there any other ways of how to access tombstones?Should this replace the current
dropToContainermechanic 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_TOMBSTONESandLOOK_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
Tombstoneprototype doesn't have any methods and cannot generate intents.Creep.withdrawagainst 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_TOMBSTONEScontant as well? Are there any other ways of how to access tombstones?FIND_TOMBSTONESwould be a good idea. Are they going to show up forFIND_STRUCTURESetc... as well?Should this replace the current
dropToContainermechanic 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.
