[Sticky] Support – Modern Survival Horror Framework

@criss1818 Yes, you can definitely use a MetaHuman for the BP_Zombie. You can add the separate MetaHuman components for each body part directly to the BP_Zombie and set them up accordingly... I recommend backing up your project before making these changes.

And as you mentioned, you'll definitely need to retarget the animations to the MetaHuman skeleton.

@farshad hello! Is the workaround of importing the puzzle V1 inside modern always the same ? I can't interact with them,last time I used was in 0.3 I think,but I re-imported and copying the interact logic inside the character puzzle inside my metahuman blueprint,but nothing.

Also can I copy the wall open variables inside some maps on puzzle of V1? Basically I just want to open a passage,which are the best variables for doing this? 

@g-scairp The door system works this way by default because this is how doors are commonly handled in modern AAA survival horror games like Resident Evil and Silent Hill...However, you can definitely modify a door to open only in one direction. You would need to adjust the opening closing logic inside BP_DoorBase, which is currently controlled by some Timelines.

Subway style sliding doors are also possible... The current system uses the Timeline to smoothly rotate the door by 90 degrees. Instead, you can create a Timeline that smoothly changes the door’s location rather than its rotation.

If you have any questions or need more details, please let me know... I’d be happy to help! 🙂

@criss1818 Yes, nothing has changed. Just follow the same documentation for the Puzzle V1. There’s a video there showing exactly how to integrate the Pack with MSHF.

Try to add the interaction logic to the main parent character class, BP_CharacterBase, rather than directly to your MetaHuman Blueprint. It should work without any issues.

As for your other question, yes, Forgotten Puzzle V1 has an example where a wall rotates after the puzzle is solved. You can use the same logic with V1 inside the MSHF. That should work perfectly for what you’re trying to achieve.

@farshad perfect! Im mostly trying to create the logic for when the character goes up or down in stairs,it would be mostly easy to integrate in a state machine on the locomotion,but seems really hard to implement it on gasp,hope the state machine will be one of the priority for the next updates!

If I change the logic in BP_DoorBase, then future updates will work?

Time frames must be established for each door.? 

Perhaps in future updates there will be doors like in the subway.

Hii I was wondering, is there a way that I can pause the game when picking up an item? I was testing the game and there was a moment that I picked up something and the zombie attacked while I was at the pickup Hud screen and the game glitched.

@criss1818 I agree with you: GASP is a bad design, and Blend Space is much better.

@criss1818

Why GASP is a bad design for RE-style Games.

1.Tone and animation-style mismatch

GASP is built around athletic, fluid, game-feel-heavy movement: quick direction changes, smooth accelerations, parkour-friendly transitions, and responsive starts/stops. Resident Evil-style games usually want the opposite: weighty, deliberate, slightly stiff, vulnerable movement. A GASP-driven character often feels too capable, too agile, and too “action game.” That can weaken the horror atmosphere.

2.Loss of deterministic animation control

Blend Space and state machines are deterministic. If the player is in “aim walk,” you know exactly which blend space is active and which animations can play. Motion Matching is emergent: it chooses poses from a database based on trajectory, velocity, tags, and cost. That makes it harder to guarantee a specific animation for a specific horror beat, such as a cautious step, an injured limp, a nervous turn, or a slow backpedal.

3.Expensive animation database requirements

GASP works best with a large, consistent, well-tagged animation database. Building that database is expensive. RE-like games often rely on a smaller set of bespoke, highly authored animations. If the database is small or inconsistent, Motion Matching quality drops quickly. You may spend more time cleaning data than you save on state-machine authoring.

4.Too fluid for survival-horror movement

RE-like movement is often intentionally limited: slow walk, normal walk, run, aim walk, strafe, backpedal, turn-in-place, quick turn, stop-to-shoot. GASP excels when the player has a large locomotion space. In a small, constrained space, Motion Matching can smooth over the exact awkwardness and hesitation that make survival horror feel tense.

5.Harder to debug and tune

With Blend Space, if the character plays the wrong animation, you can usually trace it to a state, parameter, or blend setting. With Motion Matching, the wrong pose may be chosen because of trajectory, velocity, tags, cost weights, or database coverage. That makes debugging less intuitive. Designers and animators need a deeper understanding of the system, and small parameter changes can produce unpredictable results.

6.Weaker fit for cinematic and choreographed horror

Resident Evil-style games often need precise choreography: a character limps at a specific speed, turns with a specific hesitation, raises a weapon with a specific timing, or reacts to a scripted scare. Motion Matching is designed for emergent, player-driven movement. For tightly authored moments, it can fight against the intended pacing and timing.

If your game only needs a few movement modes, GASP is overkill. You can achieve excellent RE-like locomotion with:

• 1D/2D Blend Spaces,

• state machines,

• aim offsets,

• layered blend per bone,

• root motion,

• IK foot locking,

• turn-in-place assets.

That stack is cheaper, more controllable, and better suited to the genre.

Conclusion

For a Resident Evil-style game, GASP’s drawbacks usually outweigh its benefits unless you heavily customize it or use it in a hybrid setup. It is not a bad design—it is simply designed for a different kind of game. Blend Space + state machines + layered animation + aim offsets is generally a better foundation for RE-like survival horror. GASP makes more sense for open-world traversal, parkour, or highly fluid action games where a large locomotion space is the core of the experience.

@g-uncleray Yes I also agree with state machine being better than gasp on survival horror! But in general I dont like gasp a lot,it looks like a more rpg-action oriented locomotion,also is really hard to change the animations,I know it might look easy for the motion matching but for example,you need like 20 different animations on walk and run (and not counting all the different poses of the weapons) than adding them on blendspace and state machine normally,currently I want to implement a simple state when the player goes up and down in stairs,but seems really hard do understeand it (since all the tutorials on youtube are made with state machines for this,there isnt one about gasp or motion matching). For now I am not going trought locomotion or changing main weapons till 0.6 update,mostly better to focus on other things before the stairs locomotion

@criss1818 Yes，GASP  is a big obstacle for animation or locomotion custom,now i just stop work with aniamtion or locomotion related things unitil MSHF bring the new Blend Space(Maybe V0.6),now i am working with story narrative，enemy design,enemy AI,enemy react, scene build,etc.All of them is not related with locomotion.

If you want to do your game,no one likes GASP. 

@g-uncleray looks really good! The traversal system of gasp is really easy to replace since it's most an interact input to find any obstacle with a trace and play a vault animation. 

About the narrow passage and ladder were also in 0.2,so I think the passage of gasp was done mostly about the traversal system. In any case,these things can also work by replacing a placeholder animation (like grab and Bite of 0.4.3) to the right one that we have! By doing this it's possible to avoid the traversal system of gasp,having different play montage animations on 2 different heights of obstacle (for example). 

You can use the ue4 skeleton ABP inside 0.5 actually,it has a state locomotion if I am not wrong. It's the same of 0.2 but yeah it can be expanded directly into the framework,maybe the best thing to do is having 2 booleans exposed inside the ABP_Character of the framework on selecting GASP or State Machines,so we can select which one to use maybe in 0.6 update,of course with a metahuman and ue5 skeleton support! 

@criss1818 Yes，GASP or State Machines as an option is really good.By the way,have you found the turn-in-place issue in the weapon-aim state,The upper body is right, it turns instantly ,but the lower body turns slowly,not at the same speed as the upper body?

@g-uncleray I need to verify it! In any case,I have found some issues about the grab and bite of the enemies if they are turn on the right or left,but since 0.6 priority will be the AI enemies I also hope they will not stop to attack you like now inside the overview map,in any case I will test the turn in place with aim state!