#unit18

When I look back at my level I’m already seeing parts I’d improve or completely change. I learnt a lot about Unreal whilst creating this small horror game and saw many ways I could simplify parts and reduce the amount of clutter in my code.

Using timelines more often instead of matinees would be a great improvement because it also means I can move the assets in the level at any time. With Matinee’s once you’ve created it you are unable to move the actor otherwise you’d ruin it.

If I were to recreate my game, I’d focus a little more on physical obstacles and hazards such as pitfalls that the player must jump over. This would require a redesign of the setting and would have to be larger than just a small building. I’m happy with what I created however and think for a first attempt it runs quite well. I’d use free sounds from the market place to make the game scarier as sounds and music is the most important part of horror. In most horror games they spend a lot of time focusing on the quality of the music and also the timing that it plays. You can use music to build up to a jumps care or induce panic in the player during encounters with monsters.

I’m happy with the amount I’ve learnt by just experimenting in Unreal and seeing what my limitations are. I definitely feel I’ve managed to create working blueprint classes and widgets and can use this knowledge to create higher quality content in the future. I’m going to keep working on my horror game and what I’ve already made as a base.

When creating a puzzle like I did, it can be easy for the player to get frustrated and quit if they can’t remember what letters they have found. I think however what I’ve created is simple enough that it’s not an issue but if I were to create a more complex layout and scarier experience then it would be more difficult. I’d definitely create a more permanent way for the player to keep track of what they’ve found. In a lot of games, a small checklist appears with helpful hints such as “You’ve found the key!”. With a system like that I can even make the password a lot longer as the player would be able to see all the letters on their screen and be able to work it out without relying on their memory.

An important part in horror games which I did not think about is pacing. For example, in “Amnesia the dark descent” you are sometimes limited to a slow walk which is great way of building tension and fear but also allowing the player to enjoy the environment that’s been created instead of just sprinting through it. I’d definitely slow down the player’s movement to a walk and also remove their ability to jump unless I do a more obstacle themed game instead.

The player once they have found all five letters can return to the locked door. The password UI prompts the player to enter the password. The puzzle is that they must work out the five letter word that opens the door. I kept it simple as “DEATH”. The player has already avoided all the hazards to find the clues so I didn’t want it to be too difficult by having a ridiculously long password.

This is the code I created to bring up the UI. It also is removed when the player moves away from the door. The player character gains control of the mouse but also stays in control of their character. This is so they don’t get stuck if they move towards the door before they figure out the passcode.

This is code which fires off to check if the password is correct. Once they hit the enter button on the UI it’s checked and either goes down the “TRUE” or “FALSE”. A message shows if the player has put in the wrong password.

If they are correct however it activates a custom event which starts a timeline!

Procedural Programming is a simplified way of telling a computer what to do. It is easier to read and has more flexibility as it uses procedures (made up of subroutines) that have already been well tested. You do not need to reinvent as you are already given tools that you can incorporate into your work.  By giving the computer step by step instructions the computer is able to overcome obstacles that have been foreseen. When however, an issue comes up that has not been planned you must go back and create a different pathway.

“Procedure” means having an established way of doing something. The computer follows the procedures it has been given. Each procedure is a pathway that the computer follows when certain criteria has been hit. This is called “control structures” and the criteria could be a statement like “when, if, or” this can tell the computer to continue on the path it is on or change pathways. With procedural programming you can watch the flow of the program, ensuring that it is well structured and efficient. One issue however is it can be difficult to find where exactly a problem may originate from and you must go back and code a new procedure for the computer to follow. The benefit of procedural programming is before using code you can write it in common language. This pseudocode gives you the opportunity to ensure it is efficient and logical. The computer never makes its own decision and will only follow the instructions it has been given by you the programmer. This can mean that creating a de-bugged working program may take some time. The program is only as simple or complex as you make it. It could be as simple as a straight line or as complex as a tree branching off in many different directions.

An example of a pathway that procedure programming would use is at the beginning of every single game. This is called the “EventBeginplay”. You’ve inserted the disc, game cartridge or started up the program and now the game is ready to begin. The “Eventbeginplay” node is fired and the computer or console begins following the procedures it has been given. This commonly means that the game starts up the main menu. From the menu different procedures could be activated. The player could head straight into playing where a tutorial or cinematic would be told to begin. The player could instead open up the options and begin changing settings. All these different pathways (or procedures) are only followed when told to. These procedures are also only available to the player after the very first node has been fired. Passive consumers don’t see all the work happening behind the scenes or the path that the program is taking depending on their actions.

In this unit we are learning about the principles of procedural programming and using our what we learn to create solutions.

This is so we can get a good foundation of knowledge which will help us in the future when furthering our education in programming.

We want to be able to design, implement and finally test our programming solutions.