Players.PlayerDied(player) event

I believe this would make handling death in games a lot easier. From what I see in death-driven games like Murder, R2D, Phantom Forces, disaster survival games, and almost all others, what matters the most when someone dies is their Player instance. As of now, the only way to access the Player instance of somebody who dies is to keep the player in the environment of the listener function as such:

    local hum = c:WaitForChild("Humanoid");
      --do stuff involving p

This is a bit involved and it requires lots of binding. It also makes it difficult to update what you want to happen when somebody dies since the death listener function is only bound when a player’s character loads. I think the PlayerDied event would fit much more nicely into death-driven game code and is much simpler to reason about.

I don’t suggest taking away the Humanoid.Died event. As for games that don’t use standard characters like those simulator games, this event would never fire.


It would be redundant to have a Died event for the Players service when you already can access when a player is added, their character is added, and the character’s humanoid Died event.

I don’t understand the first part about how it is “difficult to update”; as for the second part, I’ve never experienced a CharacterAdded missfire or prevented-fire at all. Are you experiencing these things?

Another thing is that CharacterAdded fires when a model is assigned to the Character property (not sure if Character needs to be nil beforehand or if the object needs to be a model, though), not just when a player’s actual character loads. :stuck_out_tongue:

1 Like

The current way of doing things doesn’t cause any errors inherently. It’s just a lot more annoying than it has to be. As for the “difficult to update” part, say you’ve got a game that features multiple gamemodes. Each gamemode handles death in a different way. When the time comes to switch gamemodes, for each player currently in the game, I need to load their character and then bind the following gamemode’s death listener function to their humanoid’s Died event. For players who join after the gamemode switches, I’ll need to handle them with a PlayerAdded -> CharacterAdded process like the one above and then bind an arbitrary death listener function to their humanoid. I say arbitrary because from the scope of wherever the PlayerAdded listener is bound, there probably isn’t a constant gamemode (if there is a constant gamemode then a new function would have to be bound to PlayerAdded every time a gamemode starts, causing even more chaos :frowning: )

When the time comes to switch gamemodes, wouldn’t it be easier to just unbind the previous gamemode’s death listener from PlayerDied and then bind the following gamemode’s death listener?

(When I say gamemode, I could be referring to any state of the game in which death is handled in a way that is different from other states. With this definition, the very common lobby/intermission state can be considered a gamemode.)

1 Like

You could make a module or framework to handle this kind of thing pretty easily though.

True but I feel like it’s something so common that it should be part of the API.

I don’t think its used often enough to warrant being a part of the API. Especially from the perspective of writing an API because died is not a property of a player.

1 Like

Then all you have to do is keep track of who is in the game and anyone not in the game is everyone else. Having a Died event in the PlayerService will not prevent this situation by any means.

1 Like

Not sure which situation you’re referring to. I had a few in my post.

You only said one situation (your last post), when you have separate game modes and you have to keep track of what to do after the player dies for each game mode. I was referring to that one. :slight_smile:

I would also like to propose a way to manually fire this from the server as well, for games that don’t use Humanoids.

EDIT: I would also like to propose that upon connecting the event, the event will return the player that died and a turple argument that we can use to send data to the clients such as:

  • Killer of player
  • What to do upon death (ie, play sound or play animation)
  • Death position
  • Cause of death (player or natural causes)

and whatever else we can send in a table or string or number or whatever.

1+ support from me @MrHistory

What is the advantage of this over just using a RemoveEvent? It seems like it would be very strange to introduce a special way to send data between server and client just for when a player dies.


Maybe instead set it as a function ala remote/bindablefunction, so you return the tuple you want, which then gets passed through the connection.

1 Like

1.) C-Side, rumor is everything C-side is faster.
2.) Laziness, typing game.Players.PlayerDied:connect(function() blah) is a lot less work then making a system to do this.
3.) Would be extremely useful for newer developers that don’t know/don’t understand how remotes work.

Really no other advantages then those, but its more of a lazy request. Either or, I would like to just have a built in way of detecting when a player dies rather then having to make a bunch of connections to find out.

There’s negligible performance increase/decrease for an event connection. You wouldn’t even be able to measure the difference until you connected to it a thousand times

We’d have a very confusing, unpredictable, and polluted API if we added anything just because people were lazy

Or they could just learn how remotes work. New developers can’t create anything more worthwhile by simply circumventing remotes.


I would find this quite useful. It would probably make more sense to be CharacterDied. Sometimes it is a pain tracking down the humanoid in the character every time they respawn and this would help alleviate that pain. Barrel Blast would have benefited by having this event.


At least to me, we already have some stupid APIs. Magnitude can replace this easily.

Also towards GuestCapone

1 Like

We have some stupid APIs. I don’t see that as a reason to add more.


Oh, no. I wasn’t trying to imply that as a reason to add more. haha.