Games Encounters - Spring Submission: 'Flying Shooter'

In the next part of the Games Encounters unit, we had to work in a small team and create a flying shooter for the Spring Submission. This entailed creating a flying player that could shoot enemies and included a menu system with a high score. Once we had decided who would be in what group (about four members) we all begun planning, sketching and generating ideas/concepts. After many hours of critical thinking and discussing our opinions, we brought pen to paper and made a story/plot to work from.

Above is our initial inspiration images for the player's ship. At first we came up with some great concepts for gameplay but after discussing these with our session lecturer, we understood that it was unrealistic or too extravagant at our level of game building. Eventually, we ended up with a shooter design very similar to 'pod racing' as seen in the Star Wars saga.

Here are my quick silhouette concepts that I used to narrow down our choice for the player's ship. Earlier in our development, we chose to all make a certain element in the game; one of mine being the player's ship. A way in which we were all able to draw together our strong mind set group, was to form shapes and see what symbolisms they could convey and who liked which. Then it was just a matter of mashing these up into a model that worked and looked/felt reliable.

Overhead is one of the early designs I made for the audiences perspective. The basic gameplay we came up with would to be the player flying down a large valley or canyon that perhaps had obstacles as well as flying enemies. 

Although we had thought about it, a 2D game felt a bit repetitive as many other teams were creating them and so it was decided that we were going to make a 3D 'arcade-like' shooter game. To get to the final blueprints was a very slow process. Above are the six impressions of what the back view of the ship could have looked like. Furthermore, this was a key task. As travelling in third-person forwards, meant the player would have to see this angle most of the time.

When our group narrowed it down to two ships, I created the last drafts before modelling the chosen one in the 3D modelling software Maya. From a majority vote we picked the left hand side player's ship. As an extra unlock-able for completing a certain stage in the game, we had planned for customizable parts to the player's ship. However, it soon became apparent early on that this was impracticable and not essential.

I really wanted to capture a preview of what our game could look like in this concept art piece above. The ship in this image was a primary test model made in Maya, that I mashed up (which came out rather well) using all my own photographs. Most of these images came from my holiday in Australia. In addition, the flames were taken from a bonfire and then manipulated into form.

Unfortunately, one-third of the way through our project, a member of our group had to leave the course and left us a little lost at first. However, everyone agreed after this, that to speed things along and make better decisions, we needed a group leader which I was then appointed.

In the previous image was our mood board and main reference images to create our environment of a canyon/fjord that the player would fly through. Above is a quick concept process that I made. The first image (at the top on the left hand side) was made using the 3D modelling software Mudbox in about an hour. Secondly, the image down was a Photoshop polygonal overlay of the first using colours that we thought worked well. For the third, I used my Wacom tablet to sketch the enemy's and player ship in. Lastly for greater experimentation, I duplicated all of these and converted the colours using the Levels tool in Photoshop.

A central and quite engaging part to a video game is the main menu, as it draws together so many characteristics that lead to the unfolding of events in a game's narrative. Having had particular interest in this element for many years, I gave my perspectives of what an outcome visually would look like; as seen in a rough prototype design above.

We struggled for some time on what to call our game; even using a random game name generator online to think of a tag. We went through many titles such as Pack Rat, Scavengers Causeway and Alpha Knights. After many alterations and versions later we chose Canyon Raiders.

Above is an early model of the player's ship in the 3D modelling software Maya (made in about two and half hours). I soon discovered I would have many issues for unwrapping the UV's for texturing with this structure. However, as this was the base model of our player's ship, I spent several hours just going over any mistakes and self-critiquing areas that I thought could be improved on.

While still sorting out the final ship, I imported an FBX file of it into a new Unity project to see the game preview for any errors or normal problems. I also began quite a challenging task of animating this model for the game introduction sequence using the Animation timeline.

As I thought there would be, there was normal face errors which basically do not show the objects surface in game. To fix this I did the same as I did in the previous submission work. I went back into Maya and using the reverse normals and normals highlighter, I could see where the problems were. In addition I cleaned up the hierarchy into a single element.

Next came the UV unwrap. At first I decided to layout the faces in the slow and traditional way of texturing; using a reference chequered sheet and the UV texture editor to un-distort any face and sides.

To make it easier for myself when it came to actually painting on the texture, I laid out the uv's using planar mapping and then sewed the vertex's together. Here is the rear Tail Fin which was very straightforward. 

The ship's two Engines were the toughest to layout and very strenuous. I also used the best projection layout when I was finished on the editor which came out really well.

During a meeting with our team, I discovered (as well as in a session we were taught this) that the Direct X 11 shader technique was a more efficient way to work with advanced lighting and real-time shading as it would look in game. I was also shown how to take UV snapshots from a member of our team. Although they were a bit disordered from the first model, these PSD's could be worked on in Photoshop and then updated in the Viewport 2.0 in Maya. Above is a step by step of me creating the ships textures from scratch in Photoshop which I really enjoyed.

Here is the one way I accessed Direct X 11 through the Plug-in Manager and then updating the Viewport.

Firstly I selected the whole model object and added a Direct X 11 shader using the Hypershade rendering editor.

Once my Photoshop texture was finished, I exported it in a TGA format that I could then just locate in the attribute editor and by pressing '6' on the keyboard, activated show texture maps as seen above.

In this image is the original ship and the new textured model which could simply be drag and dropped into the assets folder and then into the scene view. As I had already finished the animation in Unity, I had to copy the key frames over to the new mapped model and then position it and tweak it until I had something I was happy with.

Above is the timeline in Unity that I created the animation in. Using the transform positions I could set key frames where the red line cursor was and then preview it using the play button.

For our game we aimed at having explosions and particle elements such as the player's jet stream. As I had worked with this in a previous test, I knew what I was doing as much as changing the values on the inspector. I was really happy with the explosions except there was not enough time to include realistic particle debris that comes before the initial fiery blast.

For the plasma like jet fumes, I would have liked to sped up the stream as it is quite slow in game time. However, as it was a particle emitter this was not possible. On the other hand, I really liked the idea of the game at night time (the plasma jet fumes gave off a nice luminescent) and discussed this with my group who also liked the concept of a night mode feature in the game.

I was also given the task to find, include and edit all the sound within the game. As there was a fair amount to do, I ended up on not including audio effects such as explosion noises and bullet fire although this would have been nice to put in; the background audio score really overwhelms you and lets your imagination go free. 

The image before the last is Adobe Première Elements 11. This video editing software I own is so familiar to me after using it at college, I could mix the sounds in no time at all. After downloading the free WAV files we chose from freesound.org, I mixed/cut segments for loop times and also for the intro scene which had three sounds overlaying each other. I then simply exported them from Première adding them into the Unity's assets and implement them in.

For the UI elements, there needed to be a symbol representing the player's health as well as score points around the colour slider and score count. I came up with a shape system similar to the video game series Assassins Creed where underneath the assassins 'A', symbolises a heart on the UI next to the health bar. I did something very similar in that the shape looks like a target marker as well as a triangle heart in the centre of it.

Here is a test build of our game in its early stages. We had a massive issue of whether to have the camera view follow the player's ship or in a static frame state; with the ship moving around within its boundary's as seen above.

On clicking start from the main menu, the player is shown the introduction 'cut scene' sequence before jumping straight into the game. Here I placed a simple camera look at script onto the camera and the target at the fuselage of the ship; this is to give the impression of the camera tracking the ship as it moves from a ground 'wide angle' action shot.

Furthermore, I was appointed to create a skybox as all the textures and elements had to be ours. Above, I have selected the skybox material which I made by creating six sides (hence sky-box) of an equal square image in Photoshop, adding it to the assets and then dragging and dropping again into the correct panels in the inspector. I really enjoyed this part as it gave our game its atmosphere, with the dust storm clouds and moon in the horizon (which actually only took me about twenty minutes to create using my Wacom tablet).  

As with any video game there is coding to be created. Looking back at the start of the course where I was completely against making any scripts, I have come quite a long way and now actually like to try and figure out the process and structuring events. Above is a simple c# code for the delay of the plasma fumes on the intro of our game. Unbelievably, I made this entirely on my own without any help or references.

The above script was for the camera to look at the mouse as it moves across the 3D menu system which I had some help from a tutorial on YouTube; to get the smooth panning motion.

Following the creation of the 3D menu I made, I had to create a script to link the level scenes together and with a little help from a member of the group (and also a tutorial on YouTube) I created the above. I also added material renders so when the mouse hovers over the text's mesh, the colour would change from white to red and back again.

We ended up creating thirteen scenes in total and using four for the final game's build. This was due to the constant update from all our work and the combination of new scripts, models and textures. Here is the sub menu seen in the scene view in Unity, that appears in the game after the player has died having the choice to play or exit to the main menu.

All that was left after finishing the main scene was to finalise and fix any bugs. We also tidied up our assets and organised our work into name folders. Once this was finished we added in a credits page from the main menu of our team names and also the night mode. I would have liked to have made a script with the team that managed all the minor events in one code rather than several as we were taught of this efficiency in a session with our lecturer. 

Here is a screen shot of our final menu in our final game build. I really believe we captured an atmosphere and feel of what we were trying to produce from our concepts and have worked well as a team.

This print screen is of the final introduction sequence which I think looks fantastic the more I look back at it!

Atop is a gameplay screen shot representing the submissions 'flying shooter' characteristics.

When the health bar is depleted and completely red from damage, the players death happens and you are then presented with your high score and if you would like to play again or exit to the main menu. 

As an extra feature, the 'night mode' has a higher difficulty and more challenges to face! As an accidental audio placement error, the player can fly close to the wall boundaries and hear the background score get distorted and sinisterly slow down/speeds up! I really enjoyed playing around with the lighting and tone of the players plasma fume as it is the only light sources including the night-skybox.

We also included a credits menu of our team that worked on the game as seen over.

Our one sheet that we worked as a team together to make (with me digitally composing the above) sums up our game as a whole. Over the past three months I have really enjoyed the journey of working in a small team from generating concepts to editing code. Through trusting each other and believing our aims and goals, even when one member had to leave the course, we have completed the game to the best of our abilities and I feel this has been a hugely valuable experience to take away for the future.

Games Encounters - Winter Submission: Game Intro

As part of our Games Encounters unit, we had to create our own Opening Sequence to a Game for the Winter (Formative) Submission. This was to be created in a 'grey box' basic design using the Unity Game Engine. At first I had no idea what I was going to create and it was only after a journey on a train that I began to create a concept and develop from there. I then started to generate ideas and create a rough layout in my head of the map. Furthermore, on a trip to Aldershot from Farnham, I took several images (as seen below) around the train stations which then became my resource for visual construction and building.

                               

I then brainstormed the layout of the start and end position of the character as it was for a first person game. As we begun scripting and learning more in generating animation and functions in Unity (in our Games Encounters Sessions), I planned where things like triggered events could take place, title cards/text appear and in-explorable areas. Below is my final aerial map of my Game with the central events listed to the right.

As I had my general construction of events, I decided to make a three-quarter view plan showing the level in a principle manner below. I also included a perspective plan which let me configure the scale of the town with the players 'eye view'.

With everything organised, I could begin modelling. I decide to do a vast amount of building in the editing software Maya, as I had more freedom with creating the town layout. Below is a phone box's interior which was one of the first intricate details I looked into making. In addition, it is the first object in chronology of the scripted events.

As I developed along with the construction of the phone booth I realised that the phone would need to be detached from the holder in order to realistically represent a phone tone sound placement. I used several tools to achieve this, including the polygonal bend shape tool that worked perfectly for the curve of the cord to the phone.

In my game introduction sequence, a train departs without the player leaving you stranded at the station. I worked out that I only needed to construct part of the locomotive (giving me more time on other items) which is seen through the stations building. I also had to scale several objects into centimetres as I had a greater knowledge working in inches on Maya (from watching several tutorials). This then helped for referencing the human height to other components later on.

Below is my modern Class 450 South West Train complete with a human figure height scale to the left. While making each object that builds to the final product, I made sure that I named and arranged the Hierarchy tab to easily export the objects when they were finally ready for Unity.

After the first train has departed without the player, you explore more of the station looking for a Help Point button. After hearing a strange sound through the device, the player then hears a foghorn and spots a second train, this time an old steam train and carriage arriving at the stations platform.

I spent around six hours modelling this steam train (based off of the famous LNER Peppercorn Class A1 Tornado train) as it's the key focus in the games narrative. As the player can only explore one of the two platforms at the station, I decide on shaping mostly one side of the model saving data and memory for the final layout as mentioned by our lecturer.

Below is the final train model including the carriage with the face normals selected. This was a process I found in later experimentation and improvement but several features to an object can appear visible from only one viewing angle. This can be manipulated in the normals tool but unfortunately you would have to go in and out of Maya and Unity to see the actual difference of the surface change.

As I built my level's buildings and features, I doubled checked that the normals and vertex's were aligned in the correct path rather than having to go back and forth after realising something is wrong with the object in Unity.

After constructing several objects, you can select them in the Hierarchy and then go to normals in the tool panel above and look at them altogether (as seen below) than having to view each object. For some reason my station section was littered with normal errors and delayed my progress by quite a bit.

After making each plane for my levels ground, I would go into an aerial view using the view cube and check that it was accurate with that of my original sketched piece. This way I could not make any mistakes with the layout and confidently build around the areas.

Using the wire mesh on shaded tool allowed me to view the models more clearly together and was a massive help when making the railway tracks; seeing the 'wooden boards' below the lines parallel to each other as the curve of the platform advanced. As the player cannot travel in the non-explorable areas, the tracks beyond the horizon point angle of view, meant I did not have to fully complete the model again saving data and memory overall.

For the streets of the town in my game (I decided to call 'Alderham') I had several elements where I could just mirror cut objects, duplicate and reverse. This was also very practical when it came to things like Lamp Posts as real streets have two dozen or more.

Looking at aspects of creating my environment required quite a bit of spacial awareness within reality which as an artist has been something I have been fairly good at. The car park for example was completely created from the top of my head just thinking about the location in Aldershot. This was the same process with most of the objects in my game, although I did have my own photographs for references.

Although I knew it was not essential, I mapped out my level as though it was an actual street. Adding in items like car reflector bollards, traffic lights and pavement islands. Personally I found this made the game more in-depth and authentic to the concept as a whole.

Once I had finished all of my modelling, I exported all of the objects using FBX files and imported them into a new Unity project. It was very simple to add the layout into Unity; with just a simple drag and drop from the games assets folder, see at the bottom of the image below, into the scene view.

Over the next few sessions in Games Encounters, I learnt many new tools in Unity to enhance my games play-through. For example, I added in a soft 'moon lit' directional light and played around with the settings; something I found was a massive help; just exploring all of the mechanisms and how they worked taught me various skills in editing and my time management.

While at University, I used the suites computers Unity Pro, to expand my games limits; with the free version however there are several features that are disabled and only compatible if you upgrade. I decided to not let this draw me back, although the lighting system was reduced in realism as this was a key feature to give the game its atmosphere.

Additionally, I ticked the box in the system preferences for deferred lighting as several areas in my game flicked by the characters movement. This gave a subtle amount of light emitted over other game objects surfaces but was designed for the final rendering process only in Unity Pro.

Mixing the lights attributes allowed the mood to change in the game view screen and I went back and forth in the scene view to duplicate several of these. On the other hand, this was a massive advantage, with the lights symbolising the player's path through the level. The brightest man-made florescent whites are at the start and end of the introduction and then in between are a mix of orange lit lamp posts and green illumination for smaller components like the phone booth (as seen below).

After matching all of the lights to the chosen game objects (almost sixty in total) I then went onto looking at sound in my game. As this is the very first game I have ever made, I wanted to impress more with the visuals as well as the sound, as that was part of the submission for 'creating an atmosphere'.

I decided to find sounds online through the website Free Sound that I have also used in college, which is really useful for free material. The only problem was I had to spend many hours to find the best suited sounds for my game. Moreover, things like background ambience were easy to find and download but one of the toughest to search for was the Fog Horn. In my game it is heard as the train arrives at the station; taking about two hours to choose as some are limited by choice, I found what I was looking for. In total my game has eight audio sounds which after downloading, I moved into my assets folder.

A few extra elements I wanted to add in to my level were a night sky and light snow, although they were not essential. Thanks to my classmates, some of who have used Unity before, guided me to find the features called a Skybox and Particle System. These were really useful as they were just what I was after, set functions that could be manipulated in the settings inspector tab to the right. Furthermore, I could change the settings of things like how fast snow would fall, the surface spread area and size of the snow.

Towards our last sessions in Games Encounters, we learnt how to animate objects in Unity, both by using CSharp Scripts with transform selection and by key framing in the points of animation using the timeline as seen above. I needed at least two objects in my game that would be animated which were both my train models.

In all our sessions with Ewan Armstrong, our lecturer for Game Encounters, we learnt how to program code and built up our knowledge over time as it is quite a complicated process of knowing the names of the text that you type out for the computer to make the mechanics work. I really did not want to go anywhere near scripts at the beginning of the term, as I saw it as a really complex component to game making. However, as it is such a crucial part of making a game run, I openly rose to the challenge and watched all the beginner tutorials on the Unity website for scripting with CSharp in the MonoDevelop assembly.

Above is my first scripted code that I managed to create by myself. I felt so ecstatic after making the events happen, which was a phone tone atmosphere sound on loop. With selecting the variables for each part in the script, I could then find where the sound was in the assets folder and drag and drop it into the audio clip area in the Inspector.

As the player would advance through my game, the best way to communicate the story and the chain of events was through a GUI Text game object. This would then notify the players field of view with text. I decided on making the first two GUI Text areas an on trigger enter. So when the player reaches an area for example, like the end of the street ahead, the text would appear only in the trigger zone. 

As I proceeded with the scripts, I wanted to create my first train animation. This was perhaps the longest and most time consuming script out of them all, as there was many errors with the placement of animation and its designated variables. Eventually I had to turn to my lecturers help as the problem persisted and I got nowhere; it was just two commands out of place and several updates in the script that had to be swapped around. I was so happy after this and it gave me more enthusiasm to create the next code.

In my level, if the player walks close to the train station, the train on the platform leaves without you. You then walk into the station building itself and are then confronted with another GUI Text, telling you you could try asking at the help point device if any trains are running.

Above is the help point button similar to that of the actual ones at British Train Stations. I decided to put simple material colours over the help point button (the only thing in my game with an added colour over it). This was to help the player identify that that was the button console they have to push in order to trigger the next event.

Above and below are some more images taken from the game view mode. This enabled me to test the game multiple times and I really enjoyed the fluid fluctuation between editing and live play; allowing you to work even faster and critiquing certain things and then tweaking and adapting them.

Below is my final script for my game beginning sequence which has over twenty two stages of events. I remember looking at a procedure in scripting in a session but forgetting its placement for many commands in one code. I also tried to find tutorials on this, although there were many arguments with other methods such as Invoke, Switch statements and enabling and disabling an object. After getting nowhere with the script, I asked for a hand from our lecturer again and he said that the 'wait for seconds' coroutine was best for what I had in mind. Finally, I had to do some more research and figure out the delays I wanted between each parts in the actions but I eventually managed to complete the scripts and finish the entire game intro layout as I had planned. This made me look back at the past two months and made me think how far I have come in learning all of the software's to build my very own game.

After I had completed my game, I exported it using a simple process called 'build'. You can select what platform you want the game to run on and the settings of the selected scenes and as my game only has two minutes of play time it had rendered it within a minute! Below is my Game Intro One Sheet as if I was presenting the game to a studio for approval. I was keen on making this with things like the logo and features, as I have made several digital graphic pieces before in college, and for personal work.

Lastly, I also wanted to recreate my draft timeline storyboard to a digital version to make it look more professional (as seen below). As this is something I would love to do in the entertainment industry, I focused on the key spots of importance and illustrated the central level area locations. Overall, I have really enjoyed the experience of the practical making of a game using software that will not only help me in the new terms at University but for the future outside of higher education as well.