Project Flyer Shooter: Ewan Armstrong Game Group Project

For the Spring submission in the Games Encounters unit we have been tasked with creating a video game within the Unity engine. We set about getting into groups of 3-4 people and were given the specifics of the game.
Our game MUST include:

        1. High Score 

             2. Splash Screen 

   3. Enemies

4. Flying 

   5. Shooting

Before we set-up the jobs of each member we all began making our now concepts for each piece, I mainly did concepts for the player ship and environment.

This was just a series of quick sketches for the ship and I asked the others for their opinions on which model I should develop on.

In the end I came up with this preliminary sketch of the player ship, although this wasn't used once Jason took the job of designing the ship the final model has some aspects of this design in it, namely the "hover" jets protruding from the side.

These sketches were preliminary sketches of what the environment could be like complete with obstacles. In the beginning we had intended to make the map circular and the player would loop all around as the Infinite Runner but when it came to coding it we realised it was beyond our level to make so we had to scale it back.

My job for the project was the lead Environment artist and for this I created a few concepts for our game using Mudbox and Photoshop. We new we wanted the environment to be based off a valley/canyon, so to get a clear view for concepts I created my own mood board. 

I then set about creating concept pieces for the environment and having been taught how to use Mudbox recently I decided that to better present my concepts I would model them in Mudbox.

Model 1.

Model 2.

Model 3.

I really like how these came out for the environment and so did the others but we all decided that the art direction we wanted to go towards for the final model was with the first model. I then decided to make a concept piece in Photoshop.

At this point the one sheet was put together by Jason that featured art from all of us and a brief description of our game co-written by myself, Jason and Alex.

We then got started on the modelling stage of our project, being the lead environment artist I created all the models for the environment. The initial plan was to have a game where 3 or 4 models would be instantiated in the scene randomly and this would repeat to create the infinite runner aspect whilst changing the environment so that it isn't constantly repeating the same models in the same pattern. So for this I created 3 separate models for the environment, asking for the opinions of the other members of my group before modelling the next. Each are at the same dimensions and start and end at the same point so that they could transition from one to the other without noticing any breaks in the models.

Figure 1:

 Figure 2:

In the end we decided on focusing on one environment model for the final piece and we all decided on Figure 2.

Figure 3:

We decided that to make the world space a little less dull and as a game mechanic we would include obstacles for the player to avoid that once collided with would either damage you or completely destroy you. For this I looked at references of plateau's and rock stacks but decided to model our obstacles after this image:

and so we had our obstacles a pair of rock stacks. To make the models flow more naturally and feel a little less man made I imported the Maya file into Mudbox and played around with the sculpt tools to round out the edges and make them a bit more random in design as well. I like how they came out and I also like the design of them thinning out towards the top where they have eroded by the wind and other sources.

Jason created an animation that would be played once the player starts the game and would lead directly into the game itself. He asked me to create some scenery based around boulders and so (with Jason's input) I made this pile of rocks and boulders. They were not textured in Mudbox like the other models I made but instead had a simple material attached to them inside Unity.

With my models finished I went into Mudbox with the rock stack model's and and the chosen environment model and began texturing them. 

First off were the rock stack's, I like the outcome of these textures they have the rock feel I was going for and their coloration is spent on to what we were going for in tees of our game's aesthetics. One downside of these textures however is that the models are fairly low poly, which in some respects is good as they have smaller file sizes making it easier for the game to spawn them in however it also means that I had fewer vertices to play with when texturing in Mudbox.

In Mudbox the level of detail one could apply to a model is influenced by the vertices count and thus when I tried to paint with stamps and stencils very little actually came out of them, regardless I still feel these models came out well.

Secondly I textured the environment model, but before that I used the sculpt tools of Mudbox to make the model feel more natural and look less man-made than it had appeared to be when I modelled it in Maya. One way I did this was by using the sculpt tool to lower the centre of the canyon bed, this made it appear as though the canyon was carved out not only by glacier (as is most likely) but also that a river once flowed through the canyon and has since dried up. Because of this aspect I also textured the canyon bed with some green to make it appear as though foliage is growing there due to the fertile soil, but the rest of the model was textured to be dry and barren hence the darker shades of brown. 

I think this came out really well, again like with the rock stacks I had a little issue with the low number of vertices to play with whilst sculpting and texturing but I like it and so did the others.

And here is the model put together with the rock stacks in place in relation to the environment model. All there was left to do know was to export the models as an FBX file for use in Unity.

With the model stage complete I could move onto scripting and the most important script I contributed to this game was the Infinite Runner script. A script where my environment models would be instantiated in the scene and translated behind the player, creating the illusion of the player moving forward. 

This script in particular creates a private list of the instantiated prefab's the first being called "first road" and the last being called "last road" when "first road" is translate to a certain position behind the player (in this case: if(first Road.position.z <- 50f) ) first road is taken out of the private list,  is destroyed, the next prefab along becomes the new first road and a new "road" is instantiated where last road was initially instantiated and this repeats.

With the Infinite Runner complete I moved on to creating the script for the player. This script includes a boundary that prevents the player from going to far up, down, left and right, includes code that allows the player to move on the X-axis and Y-axis and instantiate and shoot a bullet prefab.

Another script I made was a simple script, it was simply On trigger enter destroy game object. This was attached to a cube without a mesh collider which was a child of the player model, this meant it stayed with the player. The function of the script is to destroy any and all game objects which pass through it, namely the enemy clones that aren't killed and the enemy bullet clones.

This was my final script for the game which had some use in the final game, it instantiates an explosion prefab upon collision with the player and was designed to destroy both the player and enemy that collided with the player. It was not used but the enemy explosion prefab instantiate was used in a separate script, final script for the enemy prefab.

Games Encounter Ewan Armstrong Unity Winter Submission

This is my story board for my level. I decided to make my project related to the mind, drawing influences from Inception, the game represents your death as the mind shuts down. There is an ominous repeating heart beat in the background and the world that has been created is a hospital. The weather outside is cold and inside heart monitors display weaker and weaker pulses.

Since the previous submission I have updated and made a new one sheet for my game which I feel describes the game a bit better than before, especially at first glance.

I also improved my storyboard, making it easier to read and follow now.

Here are a few of my models I made for the level:

I knew I was going to make a hospital so I needed to make office objects especially a Monitor, Keyboard and Mouse.

Something else of importance to the hospital environment is a heart monitor however these monitors are more than just for display in my game, pat close attention and you will notice that they provide clues to your current situation.

I was rather pleased with my work on this cabinet as at the time it seemed like a difficult object to make but I was able to make it and I like it's outcome, although they are just for aesthetics in the game.

Here are some snapshots of my game within the Unity scene view.

Outside I have piles of snow built up and a snow storm raging through the use of a particle effect. As this game ends with the realisation that the player character is dead the snow is meant to represent the cold of death.

On the inside the roof collapses, taking influence from Inception, the collapse represents the mind firing off signals in the last few moments of life and the chaos that ensues within the body.

The locked door represents the mind not yet willing to accept what has/will happen to you so it walls you off.

In the extra rooms in the corridor of the hospital there are heart monitors each showing weaker pulses representing your heart beat slowing.

This is the script I used to open the doors of the elevator, I was able to cannibalise (essentially mold it) it to work oppositely I.E the doors close but I also added a co-routine that moves the elevator up. That script is here:

Here is the script I made for the front doors, the doors are automatic doors that open when the tagged player enters the trigger box and activates the if statement to open the doors via transform if the Player is close and if not they close.

The key upstairs is required to open the door at reception downstairs, to do this the door downstairs is locked with a public bool which sets locked to true, there is a Global script that sets a public static bool which determines if the player has the key and the key itself which sets the keyHave global script to true once the player pick's up the key allowing the player to unlock the door.

Games Encounters Ewan Armstrong Session 4

Today we had the goal of "cleaning" our script for the door-move by making our code D.R.Y (Don't Repeat Yourself). This is the action of not repeating lines of code and only requiring one line of the code you need which can be called upon by a simple line of code. 

Here we made a void function followed by our own title DoorMotion (this has no significance other than the name of the function we want our doors to have) added () to the end and placed an open and close {} bracket with a line between them. To test it we created a Debug.Log within the {} brackets, followed by ("enter text here"); I put the word Flujible in the brackets. We then moved the If and Else of the door-move script already written in (shown in the image above) down into our new Void DoorMotion code below the Debug but within the {} brackets.

We then added Vector3 endPos1, endPos2 within the () brackets next to void DoorMotion

Then on this line of code:

myDoor1.transform.localPosition = Vector3.Lerp(myDoor1.transform.localPosition,new Vector3 (doormove, 0f, 0f), moveSpeed * Time.deltaTime));
and this:

myDoor1.transform.localPosition = new Vector3 (doormove, 0f, 0f;

We changed the new Vector3 (doormove, 0f, 0f line of code to endPos1 (and endPos2 for the second line of both)

The difference can be seen between the image above and below.

Now back in the position where the IF and Else code used to be I added the line of code - DoorMotion(new Vector3(doorMove, 0f, 0f), new Vector3(-doorMove, 0f, 0f));

Now in the void Update section when this code is called up it will take it from our own personal code we made in void DoorMotion.

Now in the else IF section below our new line of code in the void Update section we added the code:

DoorMotion(Vector3.zero, Vector3.zero);

Now in the else IF section when the DoorMotion code is called and is false, it will call up the line of code above to move the doors back to their original local position. This cleans up our code leaving just the one section which contains a lot of text for the door function but has been shortened into these small lines of code in the call up section - void Update

Next we moved onto applying GUI Text to an object which once moused over the text will appear.

We began by making the GUIText as a game object.

We then added a c# script component to the object which shall have the text attached to appear once moused over. In the script we added a public variable to attach the GUIText game object to in the script.

Now we added a new void called OnMouseOver (as we only want the text to appear once we hove our mouse over the object.), adding a () bracket on the end and {} brackets below with a line separating them.

In this line between the {} brackets we typed in the code:

KeyHover.text = "I am a Key";

now the code is connected to the public variable and the .text feature allows the GUIText to appear once the function is called. The = gives the code a value (a value being that actual thing the code is producing, in this case a text pop-up). At the end we add a semi-colon to finish the line of code. Now when we run the game and mouse over the game object the text within the "" appears but does not go away so we moved on to fix that.

Now we added a new void called OnMouseExit() again adding the {} brackets and in the space between them added the line of code:

KeyHover.text = null; 

Now when our mouse is no longer on the game object the GUIText disappears.

Now we want to make the function that makes the game object which is our key disappear when we click on it. For this we created a new void to be called up called void OnMouseDown() with the usual {} brackets. In their space we typed up the code:

StartCoroutine("KeyPickUp");

With IEnumerator KeyPickUp() set up beneath. This starts a function but allows said function to yield it's end result without hogging the CPU.

Now we could write code to disable the renderer and collider of the key game object and have the text "I have the key" appear on mouse down. This code is as follows:

Debug.Log ("Flujible");

KeyPick.text = "I have the key";

renderer.enabled = false;

collider.enabled = false;

yield return new WaitForSeconds (3f);

KeyPick.text = null;

The renderer and collider code switches off the box cllider and mesh renderer on the key game object, the KeyPick.text creates GUIText once the game object has been clicked and the yield return code allows a delay between the text appearing on mouse down and disappearing. However because it is a wait function and requires a yield the code expects a return function so we added the KeyPick.text = null; code which satisfies the code and switches off the text after the set time.