“I DARE YOU” Individual Game

I was initially planning to work on the one-button game. The images and a video of the initial work are shown below along some attempted codes before realizing different approaches. After foolishly spending too much time just trying to figure out the jump feature, I came to understand that the concept of the one-button game can be degraded to a 2D model. In order to have more immersive experience, I switched my idea to my new game “I DARE YOU”. However, I still wanted to keep the element of hand-eye coordination.

Figure 1. Appearance of initial plan of the game

Figure 2. Attempted code for the sound when the obstacle hits the sphere (player). Here I did not realize the need for triggerboxes.

Figure 3. Attempted code for the mechanics in the game for the sphere. The ‘Move Forward’ was okay but the ‘Jump’ feature gave me a nightmare.

Idea1_'Failed'.mp4

The term “I DARE YOU” is referring to a challenge a game poses in terms of how much you can go through. Hence, my game is an endless running game which is also similar to ‘Smash Hit’ Android phone game. The idea is that the sphere will be travelling forward as soon as the game starts and meet obstacles on the way. The aim is to use the left or right buttons to move away from the obstacles. I plan to use different shapes to test how much the user can predict the extension of the shape and avoid it. Below is the picture of the code/blueprint that lets the player start moving automatically and the setup of the direction inputs.

Figure 1. Blueprints for player motion

The game will also have checkpoints at certain stages that, for now, only let you play one more time from the checkpoint.

Figure 2. Blueprint to reset location of player after one collision with obstacle. It also plays sound for collision after checkpoint

Figure 3. Blueprint to show a sign of checkpoint when the player approaches.

As part of the production process, it was important to include sounds to enhance the immersive experience. As a result, I included two sounds as a sample: sounds that play during the game and when the player clashes with the obstacles. The former is easy to setup through drag and drop in the viewport. For the latter case, I implemented the blueprint below (figure 4).

Figure 4. Blue print for sound playing and consequential user interfaces.

Moreover, it is important to have user interfaces (UI). I have implemented multiple user interfaces for different purposes. The main one, of course, is the main menu. As a demonstration, I included ‘Start’ and ‘Exit’ buttons along size the game title. The blueprints are also shown below.

Figure 5. Blueprint for buttons used in Main Menu

Figure 6. Blueprint to display the Main Menu upon start of the game

The other important UI was the score. The blueprints are also shown below. For now, the score display is not perfect after the checkpoint but it is an area that could be improved easily.

Figure 7. Blueprint to setup the score

Figure 8. Close screenshot of blueprint to display score on screen

The third UI was the ‘Game Over’ display. The blueprint is shown in figure 4. This UI basically shows the game over display after hitting the obstacle once (or twice if it is past checkpoint). This includes the ‘Restart’ and ‘Main Menu’ buttons with the blueprint setup shown below.

Figure 9. Blueprint setup for buttons in ‘Game Over’ UI display

The last UI used is the checkpoint display. This display shows a tick mark to indicate reaching a checkpoint and disappears after a few seconds. The blueprint is shown below.

Figure 10. Blueprint for checkpoint indication

Here is a short video of the game running with all the functionalities mentioned above included.

GamePlay.mp4

Here is a link to the game executable file.

Meet Google Drive - One place for all your files

Reflections

1. The first challenge I embarked on when I started this project was to use a blank template instead of the ready made ones in UE4. I think my game could be made first person or third person. But for this project, I wanted to show an indication of the player because it would be easier to understand. Starting with blank template has challenged me a lot and I needed time to work on setting up basic components. Because of this challenge, I am more aware of how the first person or third person characters are set up in the templates. It was a time-consuming but an entertaining, fun experience.

2. Because the group project was more focused on skills such as photogrammetry and mechanics rather than user interface and immersive experience through sound, I was trying to work on the latter areas. As shown above, besides the setup and mechanics, I have focused more on user interface and sound design. I can definitely tell that I have mastered these areas and I am more comfortable working with them. I also got to work with setting up landscapes which was an interesting technical skill.

3. With VR and the game set as first person, the user can be made to jump here and there which boosts the immersive experience. A running VR has more immersing ability than a 3D game on a 2D screen.

4. The game is more of a prototype than a perfect complete work. Had I had more time, I can improve a lot of things (some shown in the video). The mechanics can be improved. The player can be made to accelerate and jump over obstacles. The obstacles can also be automated to move whenever the sphere approaches. The aesthetics and environmental appearance could also be modified to change based on runtime so that it does not get boring. These are part of future development plans.

Overall, this assignment was a GREAT step towards having a wholesome picture of what UE4 can do. It was with great pleasure and a bit of frustration that I spent time working on it.

The sounds were edited on TwistedWave and the fonts for the display were downloaded from Template.net, 1001fonts.com and Fontmeme for free.