Thursday, 13 December 2018

Game - Conclusion of game

During this module, I was required to produce an first person character game artefact using the Unreal game engine, where the player holds a gun.

The brief of our assignment said that I was expected to use Blueprint or C++, and produce a one level game using the first person template, where the player remains within an arena area. I feel that I have been able to produce a game which matches the above specification, and I am happy with the outcome. The game is titled LaserTagged, to go along with the original project theme of a laser-tag style arena experience.


Is my games objective clear?
I have added an instructions screen on the menu, which tells the player that they need to defeat the enemies and escape the maze. In the game, there are some text elements around the level which help tell the player about mechanics, and how to perform certain actions.


Can my game be completed?
When the player defeats the boss at the end of the level, it shows a screen which says the game is completed, and a button which returns you to the menu.


Is there a lose state to my game?
If the player loses enough health, or hits some of the lasers in the level, they will lose their life, and need to restart the game to continue.


Functionality on top of the existing template:
The mechanics of the FPS template originally saw the player fire a projectile from the built-in weapon. However, I changed this and I went for a laser-tag style experience, which changed the shooting mechanic. Instead of spawning a projectile, the player now uses a LineTrace shooting mechanic.  This LineTrace mechanic became complex near the end of development, because it was responsible for comparing what the player shot towards, and what action to take from the object fired at.

The projectiles originally used for the player shooting are now used for the enemies shooting. This was easier to include, instead of creating a new projectile, because it previously worked fine. The material was also changed to a red colour, because the red colour can give a negative connotation to the player.

I removed the VR sections of Blueprint code from my level, because it was not necessary to keep in the project, and I felt it also tided up the player's Blueprint class.

I changed the colour of the crosshair, because I wanted to use a different colour during the development. In the end, I felt the colour looked nicer and stood out to others.

Throughout the scene, I have added targets, which the player must shoot to unlock doors to let them progress in the level. This is because lots of training modes in FPS games include targets to fire at, and I wanted to include a similar feature in this game.

I have added a series of static enemies which fire bullets at the enemies in short bursts. This is because I wanted to add a challenge to the game, and it gave the player something to try and defeat in the process.

I added the ability to crouch - something not included in the first-person template - because it was a mechanic I was looking to add into the game from my early plans, and it was a mechanic which the player needs to use to progress through a section of the level.

Thoughts of polish/quality/UI
I was happy with some of the final level design elements which I included in my game. This includes textures of the walls and floor, the user interface elements, and the audio included.

I chose the minimize the numbers of textures in my game, to try and keep my game running efficiently (avoid too many textures which could cause lag), and to keep a consistent art style throughout my game (ensures the player know they are in the same arena).

With the UI elements, I tried to keep a consistent design, as it means the players will be used to the colours and button layout throughout the games. I also wanted to ensure the players could stop when they wanted, which is why I included a pause menu. The pause menu, game over screen and end screen all allowed the player to return to the menu, or restart the game. From the main menu, the player could choose to quit, meaning the player does not need to perform Alt+F4. With regards to the Heads-Up Display (HUD), I tried to keep the display simple, because most games try and minimize the information on-screen. If there was any information to display on screen, I planned to keep it minimal and simple - such as saying how much health the player had left.

With the audio elements, I did not want to overload the player with music and sound effects. I chose to include some sound effects for shooting and taking damage, to help give the player understand when they took damage, without looking at the HUD always. I only wanted to add music during the boss battle, to try and add tension to the battle.

I added an instructions screen on the main menu, to allow the player to have a basic understanding of the game. But I tried to keep the instructions simple, to let the player experience the game to learn more. This means the player can learn tricks and tips by playing the game repetitively.


Issues which I noticed in the final game:
I noticed a series of issues in the final build of my game.

Firstly, I noticed that the game begins to lag (drop frames) over time. I am not sure why this was happening, and it was cutting the enjoyment out of the game as the player progresses forward. This might be because there are numerous m\ethods running during the Event Tick. I used the Blueprint Debugger to try and understand this issue, but it did not prove to cause any direct issues.

Secondary, I attempted to create a mini-map in the bottom left of the screen. I was interested in adding this in, because it helps add some perspective to the level from an alternate angle. However, I noticed that this would sometimes glitch out, and produce a pixelated image, which I was unsure about. I received some mixed feedback for this; some people said it was good because it adds to the spookiness of the level, while some people felt it was looking buggy.

I was disappointed with both of these issues in the final game, but there was no answers when searching online for the issues.



What I could add in the future:
If I wanted to continue development of this product in the future, I could add some new mechanics or gameplay elements to the game, such as the ability to use grenades or explosives, or introduce a melee weapon to allow for close-range combat.

I would also like to add in some animations for the reload, because this can make the game feel more immersive for the player.

I was also interested in adding a mechanic to allow players to change their crosshair colour. This is because different users have their own preference for a colour - some people may use a different colour as they experience some colour-blindness. 


Final thoughts:
Overall, I was really delighted that I was able to produce an FPS game because it is a genre of game which I enjoy playing, and it gave me some insight into how these games are produced. I was really happy that I was able to add a custom shooting mechanic, with the LineTrace shooting, and also able to get enemies which could hurt the player. I was also really happy to add a secondary input mechanic - which allows players to use a controller instead of mouse and keyboard. I like to add this to games, because some users prefer to use a controller, instead of mouse and keyboard.

I was also happy to be able to incorporate my custom model of a MAC-10 gun into the game, because it made the game feel much more personal to myself, and this also proved to myself that I could build my own assets for a game.

I did not think the game was perfect, and the issues mentioned above made the game feel uncompleted, and if I got a chance to look into the issues further, I would want to fix those. Despite the issues, I was impressed with the outcome of the product, and this is a game which I'd happily add to my portfolio.

With regards to using Unreal, I was happy that I got a chance to use the software, and it gave me experience in a new game engine. I struggled in the early stages with Blueprint, but it took time and practice to understand how it works. In comparison to Unity, I feel I would use Unity over Unreal. Unreal's collision system is a lot more complicated, and there were lots more options than actually needed. I also dislike how moving objects in the scene causes the engine to rebuild the lighting - which can take up to minutes to fix.