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.

Game - Controls

My Unreal game, with the final name of LaserTagged, can be played with a mouse and keyboard, or with a controller. This posts describes the controls work.


ActionMouse/KeyboardController
MoveW,A,S,D / Arrow KeysLeft analog stick
LookMouseRight analog stick
JumpSpaceA (xbox), X (playstation)
CrouchCB (xbox), Circle (playstation)
ReloadRX (xbox), Square (playstation)
PausePStart



Modelling - Model/Maya conclusion

In this post, I will describe my final thoughts and conclude how I feel my modelling phase went. I ended up producing a MAC-10 weapon inspired by the design in Counter-Strike.


Throughout the modelling process, I feel I have learned and understood a range of tools and techniques within Maya, which would allow me to create models in the future. The main tools which I found to be useful during the modelling included:
  • Edge Loop. I found this useful, as it allowed me to create new edges around a polygon, and also let me gain new vertices. This allowed me to create different shapes.
  • Boolean -  I found this useful to create gaps or holes within specific objects. This meant that I did not need to use a large amount of polygons to create specific shapes.
  • Extrusion - I found this useful, as it allowed me to expand out faces from existing shapes, which helped add efficiency to my final product.
  • I also learned about how to use the Maya software in general, and I have also looked into the FX and Animation sections.
I was happy that I was able to produce a model during this module, as I had no experience with 3D computer modelling previously. I had done some CAD work in school. I was also happy with the outcome of my final product, and feel I have been able to replicate some of the crucial detail, such under the nuzzle at the front of the gun. I was also happy that I was able to understand and use Maya, as I never used the software previously.

What didn't go well during the development was I did not fully get a chance to work out how to work out how the back of the MAC-10 gun connected to the weapon. This loses a bit of quality to the back of the weapon. During the development, I was also disappointed I could not complete the Overwatch gun, as the design become too complex.

Wednesday, 12 December 2018

Maya - Final weapon

For my final gun model, I was able to produce a MAC-10, as inspired by the design and style seen in the Counter-Strike series of games.

Original weapon from game (screenshot):

This is the default weapon skin of the MAC-10, as seen from the side.


Final weapon:
This is the final weapon, as seen in Maya.


How I developed the model:

The model was built around a series of schematics taken from in-game screenshots. I imported these as image planes into the scene by going to the View menu > Import Plane > Import Image. I used four schematics for the gun: one for each side, one for the front, and one for the back.

I imported a single cube polygon into the scene, and scaled the shape around the horizontal body of the weapon. Then I added a set of divisions (U1, V3) to allow me to create the lower section.

I extruded the bottom face of the central division, to allow me to create the handle and magazine. I used the connect tool to adjust the magazine, and make it smaller in comparison to the handle, and expand down.




For the front nuzzle, I used a cylinder, and used the connect tool to create an edge. This left me with a section (on the far right), to extrude it out to produce a thicker shape. To produce the individual spike-shapes, I went into vertex mode, and I was transformed the position of the vertex points, so they went above the cylinder shape.




For the pipes at the back of weapon, I created a 2D curve, extruded it into a 3D tube, and duplicated this. To perform this, I went onto Curves/Surfaces in the toolbar, and used the Bezier Curve tool to draw the shape, while on the Side X view (camera). I added a 2D NURBs circle to allow me to get the starting shape. To convert it to a 3D tube, I went to the Surfaces toolbar menu, and clicked Extrude, while having the circle and pipe selected. I changed the settings to output a polygon shape.


To create the trigger and surrounding shape, I used two different cubes. The trigger was created using a single cube, which I transformed to become a thin shape, before adding several edge loops to allow me to gain vertices. Once I got these vertices, I was able to re position the vertices, to give me a trigger shape.

For the surrounding shape, I started with the cube which I aligned under the gun. I was able to extrude and rotate the faces in-line with the schematics.


To create this section in the above image, I used the boolean difference tool. I used a rectangular cube and two sphere which were used to cut out the shapes into the top. For the circular shape on the top, I started with a single cylinder, added more faces on the side, and extruded every other shape out by 0.1.

To add more faces onto the cylinder, I went onto the polyCylinder object in the attribute editor, I changed the subdivisions axis to 40.



For the front section, I used a cube and a 2D bezier curve which was extruded into a 3D shape. 

I used a cube which I extruded and rotated out. I did half of this shape, as I wanted this to look the same on both sides. To finish the shape off, I used the Mirror tool to allow me to rejoin the shape, and give it a balanced look on both sides.

To produce the curved object which goes through the gap at the front, I used a similar approach to making the pipes at the back of the weapon.  I started with a 2D Bezier Curve (from the Curves/Surfaces menu), to draw out the shape on the Side X view. To extrude it to the 3D object, I used another 2D NURBs circle to give it the shape to extrude it (I did this under Surfaces > Extrude).



For this lower section near the back, I started with a 3D cube. I added several edge loops to allow me to add vertices. The vertices I then adjusted to create the general shape. From this, I deleted the faces toward the top, bottom and back sides, to leave myself with an open gap. I then extruded out the remaining faces to give them a 3D look. I also used a boolean difference tool with a sphere shape to add in the circular gap on the remaining face. I finally added in a cylinder to make it look like the two sides are joined together.



For both sides of the gun, I was required to leave a quad shaped gap etched into the weapon. I used a cube, with a single edge loop near the left side, to allow me to gain a new set of vertices, to add a triangular corner.  I selected this quad shape, and transformed it slightly into the body of the gun. Then, I selected the model and the quad shape, and used the boolean difference tool to create the gap. I performed this manually on both sides. I also added in two cylinders on each side, as part of the design. I also used a boolean difference tool to add a cube shape within the right hand side of the weapon.


For the upper front sections, each of the sides (one side is highlighted in green above), I used a cube to add edge loops, to allow me to gain more vertices. From this, I was able to rearrange the vertices, to create the upper facing curve. I duplicated this to appear on the right hand side as well, before adding a small central cube between them. This cube was scaled down on the Y-axis dramatically.

I concluded the design by adding a series of cylinders which went through the weapon body.


Maya - Why I cancelled my first model attempt



Around the week 9 mark, I was not satisfied with my attempts to create this weapon. This is because I was looking to add specific detail onto the model, and realised that some of the shapes and the design was not really feeling right.

Reason 1:
I was starting to experience some issues with adding detail onto the large sphere section in the back of the weapon. I originally lost a section of my work which was a personal fault of myself, and none of the backups would restore my lost section. When I attempted to recreate this section, it started to become tricky since I added to the model elsewhere, and it would be difficult to replace.

Reason 2:
When I started to look closer at the original model, I realised that some of the shapes were actually different to what I had already modelled. This was mainly regarding the large sphere section at the back of the gun - this should have been more of a complex shape, instead of a sphere. If you look at the images below, this should the comparison between the original shape, and my shape.

Shape I created.

Actual shape

In the end, I realised that I'd have to create complex shapes and linking methods to join the shape together, and keep it tidy. After receiving some feedback from my lecturer, I concluded that it would be suitable to try a different weapon, which had less curves and unusual shapes.


What I learned from this first model, and the cancellation:
In this process of developing the model, and cancelling this, I was able to learn several lessons which I kept in mind when trying a new model.

Firstly, I was looking to create more frequent backups of my work. The first issue during this process was the fact that I lost a section of my model early on, which I was unable to recover. I chose to regularly backup my work after each day of my process. From this, I realised I should regularly back up files of my work, and keep them on numerous devices in case one device is damaged or loss.

I also learned that this weapon would have been difficult to create, due to the weapon's design being highly curved and including complex shapes.

I was happy that I was able to challenge myself by creating a weapon with lots of curves and awkward shapes, but disappointed that I could not finish this. I was also happy to stop at this stage, because I was aware that I had time to perform new research, and develop a new model.

Maya - First attempt at a model

During the development of my project, I was interested in producing a weapon from Overwatch. This is because my game was planned to be a laser-tag game with a futuristic setting. I felt an gun from Overwatch would be suitable, as most weapons from the game have a futuristic design and feel.

I chose to model Mei's Endothermic Blaster, a beam type gun which fires shot-range streams of ice. I chose this design because I liked the bright colours and design of the weapon, and felt comfortable with a series of basic shapes I could have used.






To make the section above, I used a cylinder polygon which I rotated at an angle, added three divisions onto the central section, and extruded this out. This allowed me to create the extruded grey section. I added a second cylinder which I dragged through the center.



To make the section above, I started with a cube and I chose to manually adjust the position of the vertices. This is because I found this easier to produce and make the shape of this lower section by altering the vertices. I originally attempted to build this section using the Multi Cut tool, but I ended up getting some odd shapes and some faces went out of position.

This shows how I used the vertices to adjust the final shape. I would click and drag around the point, to access the front and back vertices, to keep the shape symmetrical.




To make the section above, I used two different shapes and tried to merge them together. I also used the bevel tool to allow me to create smooth edges, to make the corners look tidier. I used the boolean difference tool to allow me to produce the three rectangular gaps within the shape, as shown in the image below. I found this easiest to let me add gaps within existing objects, without breaking any other parts of the model. 





To produce the section above, I was required to add edge loops to allow me to add further edges into the cylinder. This allowed me to add the section with a red texture, as I ended up using the Extract tool to move the expand the faces out.



The above section felt a bit messy. It incorporate a large grey sphere, with the central section removed with a boolean difference of a sphere. I used a pipe tool to create the blue 'handle' shape which overlaps on top. However, I was experiencing issues during the development of this process, and ended up losing a section.

Textures used:
I used a series of Phong E textures to add to the design of the weapon. This was because they gave a metallic and reflective texture which is what I was looking for. I chose to use Phone E, instead of Blinn, because it renders quickly and uses less processing power.

At this stage, I chose to cancel development of this model, which I explain in the next blog post.

Final attempt:


Game - Debugging errors


Unreal contains a range of debug tools which allow the user to look at how they can fix any errors or issues which arise during development of a game. In this post, I will describe and provide screenshots of some of the key debugging features which I noticed during my usage of the engine during development of the game. 

The debug tools can be found under the Developer Tools menu, in the Window toolbar menu.  There are a range of different tools available here. 

Blueprint Debugger
A tool which shows what methods and classes are executing. This is really useful to show what is happening if someone wants to work out if a certain piece of the Blueprint code is running or not.



Call Stack 
A tool to show what is happening during breakpoints. This is where a pause is placed to see if everything is executing, as expected. Similar to Visual Studio and other IDEs, you can skip frames, step into, step over, and step out of a method. 

Breakpoints can be added to a step in the Blueprint by pressing F9 on the method you wish to add a break-point to.


Collisions Analyser 
A tool to show what collisions are occurring within the scene involving all actors and non-static objects. This can be used to detect what type of collision is happening (overlap/sweep), the owner of the object, how many blocking results there are, and how many objects are colliding with the object.





Debug Tools 

A tab which allows you to debug a series of features for the game engine, such as clearing the font cache, and reloading textures.




Message Log and Output Log

Two different tabs which allow for the developer to get feedback on the execution. This is usually where errors will be output. This is similar to the Message Log which is seen in Unity.
  • The Message Log displays a series of output messages with regards to any Blueprint class errors, editor errors, and build & runtime errors.
  • The Output Log goes into extended detail regarding the execution of the game, giving feedback on the game engine files, plugins, specification of the computer, the shading details, and the building process of the file.

Asset Audit 

Allows you to review assets which have been imported into your project. The tab lets you import an asset, and review the properties of the file. You can review this, and compare the different outputs if it was formatted for different platforms (e.g.
  • E.g. for an image, you can see properties such as the disk size, image dimensions and compression details.
  • E.g. for an audio clip, you can see properties such as the disk size, compression rate, sample rate and duration

Session Frontend

A tab which allows you to review to performance of the game during runtime. This includes a console to debug information on the execution, an automation tab which allows the developer to run tests on tasks to ensure the game engine is running correctly, a screen comparison tab, and a profiler tab to capture information on the game's performance (some of the key factors include looking at threading, tick time, memory usage, input tick rate).

This can be useful to developers with a good technical knowledge of the engine, as this could allow them to debug some of the factors which affect the performance, and help review technical issues.

The profiler in Unreal can be compared to the similar feature which Unity includes to debugging the performance of the game.




There are some other debugging tools included in the Unreal engine, in that menu, and are listed below.
  • Class Viewer - Retrieves a list of classes included within the project. This can be used to allow developers to easily find Blueprint classes. This can be useful to see if there are any classes which could be removed or deleted.
  • Device Manager - Retrieves a list of devices which the developer's computer is connected to. This shows what platforms the computer is connected to (Windows, HTML5, iOS), and also shows a list of processes running on the computer. This is similar to the Task Manager in Windows. This can be useful to see what tools the developer has got connected, and allow them to connect another device, if they wish to release their game on another platform.
  • Device Profiles - Retrieves a list of 'profiles', which are ways for the developer to review CVars (texture settings, console variables) and Texture LODGroups. This can be useful if the developer wishes to set up a specific texture output file.
  • Widget Reflector - a tab which allows the developer to review the technical output of  the UI reflections and visibility. This also allows the user to review the C++ widget code, show if the widget component can be focused on, if it is visible, and other details.
  • Pixel Inspector - A tab which lets developers review pixels, such as colour and texture details when hovering over objects in the Unreal scene. This can be useful to help the develop get access to a colour of a few pixels, if they want to reuse the the colour elsewhere.
  • Merge Actors - A tab which allows developers to join actors together. The tab contains settings which let you change the settings of the new, merged object such as the pivot point, merge of materials, and reviewing the culling.