Creep death: more than just a delete

tedivm

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.

Davaned

+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.

artch

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 to creep.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.

Hiryus

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 :).

artch

@hiryus No, it's out of scope of this functionality. Tracking actions is a whole another story.

Hiryus

@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.

PostCrafter

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?

artch

@postcrafter

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 and LOOK_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.

Arcath

@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() 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...

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 for FIND_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.

artch

@arcath

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.

Hiryus

Should resources in tombstones decay like when on the ground ?

PostCrafter

@hiryus To my understand only the tombstone decays and drops the resources on the ground afterwards, then they'll decay normally.

Hiryus

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.

W4rl0ck

so who is designing the nicest tombstone svg ?

Davaned

@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?

ags131

First part of PRs for Tombstones! https://github.com/screeps/engine/pull/74

Davaned

@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.

ags131

ags131

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.

shedletsky

@artch

It would be awesome to add a killerCreepId and killerCreepOwner field to the tombstone as well.

Tracking this right now is fairly tricky.