The second iteration of 2v8 is now LIVE - find out more information here: https://forums.bhvr.com/dead-by-daylight/kb/articles/480-2v8-developer-update

My Solution to the Dodgy Hatch Mechanic

Before I start, I play both killer and survivor and have no particular bias either way so my solution aims to please both parties while making the hatch more fair and fun.

In it's current state, The killer can choose to end the game by hitting the survivor and letting them escape. To the same effect, the survivor can choose to end the game by jumping and letting the killer grab them. Either way someone has to choose to lose the game and it is any persons arbitrary opinion that it has to be either the killer or survivor who loses. But who does it and how long the game can get dragged out for brings up debate and argument. My solution to the hatch aims to fix this problem and make the endgame more interesting.

My ideas as to exactly what needs to change are as follows:

  • Survivors CANNOT use the hatch while in the dying state. Survivors cannot repair generators, cleanse totems, hop windows or throw down pallets while dying. Why should they be able to leap into the hatch? if you are downed, it means the killer has caught you.

  • Survivors can only be grabbed out of the hatch escape animation while injured. Just like windows, this change brings more predictability and makes more sense.

  • The window in which the killer can grab the survivor during their escape animation needs to be massively increased. This makes it more fair to the killer. I may just be bad though but I struggle to find the right timing to grab the survivor in the current state and I've seen a lot of other posts from people who have the same problem. Either way, with these proposed changes, an increase in the time frame to grab escaping survivors makes sense.

  • The entity should block the middle of the hatch. I'm talking a tiny amount just so the killer can not stand directly over it and prevent the survivor from being able to jump in. It doesn't need to be textured like the exit gates. Just a tiny invisible wall that blocks the exact center of the hatch for the killer.

So what do the players gain from these changes? I'm glad you asked. With these changes, I hope to bring fairer play and mind games around the hatch. if the survivor approaches the hatch while injured and the killer is there, survivor can just be downed and hooked. This removes the annoying "hatch stand-off". The survivor could, however, hide nearby and make the killer think the survivor is searching for a med-kit/healing/doing gens while the killer is guarding the hatch since healthy survivors can rush the hatch which would make the killer leave to search for the survivor before they can be healed and rush the hatch, in which case, the injured survivor could run to the hatch (slight buff to Nurses/Stridor/Iron Will). The survivor has to hide away from the hatch in order to heal which puts them in danger of being found and downed (rap god btw). also allows for survivor "outplay" (debatable use of the word "outplay") by running to the hatch while injured, baiting the killer to attack, then the survivor using the ultra rare insta heal add-on for the med-kit can heal themselves before the killer strikes and make a dash to the hatch before the killer can recover. (buff to unrelenting??))

Perhaps a perk for the survivor and/or killer that reveals the aura of the survivor/killer when they are within a certain range of the hatch.

That more or less sums up my ideas on a solution to the current hatch mechanic.

please offer your suggestions on how this solution could be tweaked to make it better.

Comments

  • RoKrueger
    RoKrueger Member Posts: 1,371
    Maybe the hatch can respawn somewhere else every couple of minutes. What do you think?
  • AetherBytes
    AetherBytes Member, Alpha Surveyor Posts: 3,048

    @RoKrueger said:
    Maybe the hatch can respawn somewhere else every couple of minutes. What do you think?

    When it firt spawns in no, but when it opens then the clock starts ticking.