Embedded Files
When to make the monster walk towards the player
Making the monster attack the player was relatively simple, it just relies on a single collision box.
On the left is a screenshot of the door from the living room into the recording room. The small box in the middle of the larger box is where the player can use the door when they start to overlap it, meanwhile inside that there is the destination for the door from the recording room and into the living room. The larger box is a blueprint actor that detects when the player begins to overlap the collision so that it can send this signal to the monster.
The main idea here is that it's important that it is placed here at the door, as it means that the character will always overlap this box when they enter the living room on the final level and so will always have the monster come to attack them.
Once overlapped with, the actor will check if the overlapping actor has the tag "ThePlayer". If this is true, then the box will proceed with setting off the monster walking towards the player.
Once the overlapped component is determined to be the player through the tag check, the actor will get all of the actors on the level with the "MonsterHittable" tag.
This then goes into a for each loop which will cast to each member of the array through a cast to "BP_MonsterWalkToPlayer" and set off the event within these specific blueprints called "Start Walking".
The event to start walking is within the monster blueprint which is called "BP_MonsterWalkToPlayer" if that wasn't clear enough.
The custom event within the monster blueprint will lead to a timeline which manages the speed of the monster walking towards the player, setting off the final fight of the game in an easy and not at all overcomplicated way.
Speech events after progressing
Speech events whilst progressing to the next level are very important to the story. The main idea behind them is that it lets the player know what needs to happen through basic context clues found in the text. For example, the knocking at the door widget that pops up on level 2 allows the player to understand they need to go to the door speak to whoever is there, it also hints to them that they should go downstairs to the boxes they probably investigated earlier in their session that may have a weapon to defend themself with. The window shattering widget on the final level is just as important as it makes it clear that the player will need to fight something very soon.
The basic method I used for setting the widget off was through an actor placed inside the level. This actor (upon game start) would feed into a short delay whilst everything loads and compiles, following into a cast to the player character and then the activation of an event called "Play P1" within the player character blueprint. Since this means the actor has served its purpose, it will destroy itself to save the player from the performance hit of keeping it there.
The "Play P1" event will get the current level name and compare it to the level the event should be running on, it will do the same sort of thing with checking if it has already been played. This isn't really that needed as the actor setting off this event will destroy itself but it serves as a fallback incase any mistake are made, such as having 2 progression notes in the level.
The branch goes into another branch that is always true and so not really needed, I can remove this is part of my optimisation work. Meanwhile, the "Someone Knocked Widget" is created and added to the viewport to alert the player to what is going on. The widget will be removed by itself once finished and the variable holding whether the progression note has been played or not will be made true to reflect what happened.
The window breaking widget in the final level is activated the exact same way as the knocking widget in the second level. Below you can see the full blueprint that activates the event within the player blueprint.
The custom event "Play P2" is the exact same as "Play P1" other than the level check being changed to the final level and the widget being created and displayed is changed to be the "Window Break" widget rather than the knocking widget like the event "Play P2" sets off.
Conclusion
My overall belief is that my lesser blueprints were kept simple and efficient in a way that made them easy to fix and easy to understand. This sort of blueprinting allowed me to save time which allowed me to more finely hone the other parts of my Unreal project as well as lessening the chances of the game crashing. This is important as it gives the end player a better game to play as well as giving the player less of a chance of encountering game breaking glitches, bugs and crashes which could have led to a negative outlook on the game.
I also think that my monster being set off my a collision box was a great idea. If the monster began walking before anything set it off, then the player could walk through the door and instantly die as the monster already reached there. This would have made the game nearly unplayable which thankfully I managed to avoid. The way that I did it manages to avoid the player becoming frustrated or seeing the game as unfinished, meanwhile the simplicity I used let me have more time to work on other things without sacrificing any quality in the triggering of the monster walking.
(Skip to 2:25 and 6:10)
Page updated
Google Sites
Report abuse