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:
game.Players.PlayerAdded:connect(function(p)
p.CharacterAdded:connect(function(c)
local hum = c:WaitForChild("Humanoid");
hum.Died:connect(function()
--do stuff involving p
end);
end);
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.
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 )
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.)
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.
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.
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.
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.
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.
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.
)