University Work
Levels and games completed at University.
Bye-Plane (Dissertation Project)
Software Used
Roles
-Level Designer
-Project Manager
-Game Designer
Trailer
Gameplay
Bye-Plane was a game created for my final year dissertation.
Bye-Plane is an open world game about a pilot who goes through a portal into a strange world. He crash lands in a village and must re-build the village using resources that he can find around the game world.
The player must fly between the islands in their Plane to gather resources and collect mystical rocks for the trader, these rocks are scattered around the islands.
The main aim of the project was to create a game that players became immersed in to see how they're mood changed once they had completed the game.
The link below will take you to the Team's website where you can find the details of all the people who worked on the game.
Detailed Information
The plane was added to give the player a fun way to travel through the world. This mechanic also provided players with two different play styles to choose from. This is because by completing the hoop activities players were given a 100 gold reward. These hoops reset after time meaning that players who wanted to fly the plane can still gain enough money to buy resources and complete the game. Also the plane is upgradable and customisable so players are able to put their own personality into the world. The team felt that allowing two types of play styles was important because it meant that the game would appeal to a wider audience.
I began by creating the level plans that would be used to build the whiteboxes and the final islands. The plans were given measurements so that it was clear how large they needed to be in Maya. On top of this they also outlined where paths would go and where points of interest would be such as camp fires and chest locations.
To demonstrate height colour gradients were used to show the height variations on the islands. The lighter shades of grey show higher points and darker shades lower areas.
Once the plans were completed, I began construction of the three islands in whitebox form. These whiteboxes were used as a play space for the programmer and myself to test out mechanics and begin implementing game play as well as giving the environment artist a base to begin building the Islands in Maya 2016.
The whiteboxes were built in Maya and were then imported into Unity. This method of building whiteboxes before fully constructing the levels is a very common process during development and the team thought it would be best to follow this practice.
Dressing the scene involved myself and the environment artist working together to position assets in a way that made the world look appealing and feel alive. This was the longest process as it involved lots of trial and error for placing objects to help guide the player and make them want to explore.
We decided early on that we wanted the player to get a massive sense of agency and reward playing Bye-Plane.
Because of this we took several simple mechanics and then combined them to try and create a complex system overall.
The main mechanics consisted of; resource gathering, village building, plane flying, plane activities and exploration. These were chosen because they were systems that could be used in tandem to create interesting and immersive gameplay.
Resource gathering was used to give players a need to explore the world. Their main objective was to re-build the village and to do this they would need resources, therefore this system tied in with the mechanic of village building. The player was given the chance to both build the village to complete the game and customise it the way they wanted. Not only did this system give the player greater agency, it also gave then a big sense of reward.
An essential mechanic to the core game loop was exploration. It was my job to outline the play space and make the player want to explore it by filling the world with interesting objects, putting characters in interesting places so that the player would encounter them and make the world feel alive and worth exploring. I worked very closely on this aspect of the game, making sure that there was a play space that rewarded curiosity. Surprise is the greatest reward for exploration and the world must pique the player’s curiosity.
Overview
Below is information about the game I entered Dare to be Digital 2015 with. We entered with our Game 'Pathos' which is a 3D puzzle adventure game with a strong rhetoric for Android and handheld devices.
For this project I took on the role of level, game designer and project manager.
Below I have provided information on my areas of the game. These include concepting puzzles during pre production, designing puzzles for the final game and designing the levels.
This game successfully made it to the finals of Dare 2015 and took part in the ProtoPlay event.
Take a look at our pitch video and game trailer or scroll down to see some puzzle designs and information of the work I completed for Pathos.
This game was the winner of the Channel 4 award and the Design in Action award.
Pathos (Dare to be Digital 2015)
Trailer
Software Used
Roles
-Level Designer
-Game Designer
-Project Manager
-Puzzle Designer
-Audio Designer
Pitch Video
The image below is the plan for the second level known as 'The Bell'.
The image below shows the final level layout along with the camera positions and what areas they will be showing.
You can click the PDF links below to see the puzzle solutions for these levels. Hopefully this will give you a better idea about how the game would have played and functioned.
Detailed Information
On Pathos I had a large involvment in Level and Puzzle design as well as the other tasks that I have listed above. The final levels and puzzles that were used in Pathos for Dare to be Digital went thrugh many iterations during the production of the game. We wanted the level to consist of three main puzzles or challenges that the players would have to complete to finish the level.
There would be minor challenges in the level as well that would fill in the gaps between these main challenges. Since Pathos is a Puzzle Adventure game we felt very strongly about giving the player something to explore. This is the reason for the long corridors, and is the main reason for the dopples to exist.
The dopples were used as a 'adversary' for the player. Pathos is a non violent game and we had to design the level around this. The dopples job is to get in the player's way and hinder them. Therefore the dopples push the player off of balance beams that the player needs to cross to proceed in the level.
The puzzles are intended to get progressively harder and require more thinking as the game progresses. One main mechanic that was featured in Pathos was the flip mechanic. The flip mechanic is used when the player reaches a portal and then flips their handheld device. The flip sends the player into a world that is exactly the same as the previous but, has some key differences. For example in order to solve some puzzles in the normal world the player must flip and acquire several puzzle pieces that are needed back in the normal world.
This flip mechanic would provide the player with a mirrored world and this meant that we had to design the levels and puzzles in a way so that the player could easily navigate the level but, still have some challenge no mattter what state they were in.
Below is a level plan for the Cave.
ShopBot Level Design
Describe your image.
Describe your image.
Game Video
Software Used
Roles
-Level Designer
-Game Designer
-Project Manager
-Audio Designer
-Scripting (secondary role)
-3D modelling (secondary role)
For this assignment we had to create a level with two states, a present state and a future state. We also had to create gameplay for the level as well as a cut scene that narratively describes the reason for the levels second state.
This led to us making the game ‘ShopBot’. ‘ShopBot’ is a non-violent game about a robot advertising to potential customers to try and get them into a store. For each person the player gets into the store they will be given a score.
We decided to make a non-violent game because we felt it would stand out among the other levels being created. Moreover it was an excellent challenge trying to make a game which had no violence in it.
This thinking led to us creating our core mechanics which are the upgrade system, charge level (which effects how long the player can move around for until they need to re charge), Whales (big spenders who give the player a bonus score), Business hours which determines how long the player has until the shop closes and the advertisment dispersal which is what the player will use to attract the AI into the store.
We also decided that we would use an Xbox 360 gamepad and the A,X,Y and B buttons to use the advertisment dispersal. This is what led to there being 4 different colour AIs. They are all a different colour because they will only be attracted to the player when they use the right colour button.
This was the first project at university where we were given the opportunity to work with people from different disciplines. The team consisted of 2 artists and 2 designers. I learnt a lot of new techniques from the artisits and I also learnt how they function and the pprocess they go through to get artwork completed for a game. This was one of the most valuable things I learnt from this project.
The scripting for this game was completed using Blueprints In Unreal Engine 4.
We began by taking measurements of the area and putting these measurements onto a level plan. This was crucial for the artists, it meant that they could look at a glance and check the real life measurements of the area they were working on. From a design perspective it was important so that we knew the size of the area that we were putting gameplay elements into.
This led to us putting together a second plan that placed all of the gameplay elements. On this plan you can see the AI spawn points, player spawn point, the player travel radius and the paths that the AI will be taking through the area.
Setting up the character AI and their spawn points wasn’t too difficult. However we only wanted a certain amount of AI to spawn and we wanted this to happen in waves. This led to us creating variables for each AI that would set how many were being spawned and a second variable that counted how many were spawned in the level. These variables are called max spawn and spawn index and they relate to their respective AI. Max spawn and spawn index are compared and if max spawn is greater than spawn index (which is automatically set at 0) then a branch is set to true. The true goes into a set node for the spawn index. Which gets 1 added to it if the branch turns true. The AI are then spawned and then this is looped for all of the other spawn points. If the branch is false then it sets the spawn index to the same as max spawn, this then runs into a delay and once the delay finishes the spawn index is returned to 0 and the AI can start spawning again.
We tried several methods of AI movement before we settled on what you can see in the final game. We initially tried making the AI move between random points within a radius. However this was very unpredictable and sometimes led to un-wanted behaviour. This led to us setting up a behaviour tree, this behaviour tree moves the AI randomly between multiple points in the level and makes them wait at this points for a short amount of time. Even though we managed to set this up we still struggled getting more than one AI to follow the player at a time. This was an unforeseen problem that appeared during the very late stages of development. Therefore we struggled to get this fixed. Even with this problem we feel that we have created some very interesting AI movement and found an interesting way of setting it up.
To get the behaviour tree working we had to set up a Basic Task and a Blackboard. The blackboard stores variables that will be used in the basic task. With the blackboard set up we needed one more thing to get the behaviour tree to work, this was a basic task. The basic task below takes the variables that have been made it the blackboard and assigns them values. For example it set the goal for the AI to be an actor in the scene. These actors are notes that the AI will move between randomly in the scene. The basic task sets the goal as one of these actors and will do this whenever an AI moves. Once this was done we had to implement the task in the behaviour tree.
To get the AI to follow the player we set up a ray cast that hit the AI. If the AI detected this ray cast then their movement destination was changed to the player's location.
So the player can hit the AI with advertisements we used a sphere cast to send out the advertisement dispersal. This method worked very well because with the sphere cast we were able to send out the dispersal and move the AI’s target location to the player.
We set up this ray cast with the blueprint that can be seen below. We also have to set up trace channels so that specific ray casts will only affect AI with that trace channel on them, for example green trace will only affect the green AI because it has the green trace channel attached to it.
We have several animation sets in our game. We have animations for the ShopBot and animations for all of the AI characters. These animations include forward, backward, idle and basic movement animations.
The animations for the player character are based off of a speed variable which is set by the player's velocity. As their velocity increases the animations will change from idle to forward. We had to set up this variable and have it working to detect when the player was moving backward so that the reverse animation would play as well. On top of this we added turn left and right animations to the player character. This change in animation is controlled by the state machine which has transition rules connected to tell the engine when to change between animations. Below are images of the blend spaces and other related components.
The AI animations are much simpler and just detect the velocity of the AI and changes the blend space between Idle, walking and running.
We wanted the audio for ‘ShopBot’ to be fun and energetic. This comes across in the main gameplay music which is intended to make the player feel happy, energetic and in a rush. We wanted to use the audio to make the player feel like they were in a rush and racing against the clock, which they are doing in game. I mixed the music together to try and create a funky theme that fitted the gameplay of ‘ShopBot’.
All of the sound effects have been made by myself, using ACID Music studio and a selection of sound clips that I owned. We wanted the sound effects to give the same effect as the music and have a robotic feel to them. Below is a screenshot of ACID music studio and its audio editing software.
These sound effects were then imported into Unreal Engine 4 and the WAVs were turned into sound clips. These sound clips were then further edited in Unreal Engine 4. For example the sound that can be heard when the robot uses its advertisement dispersal has been edited in Engine using a modulator. This modulator changes the pitch of the sound clip every time it is used, with this we are able to make a clip sound different so that the player doesn’t get bored hearing the same sound effect.
Overall during this project, I feel that my skills as a team mate, project manager, designer, scripter and artist have all improved. I also learnt invaluable knowledge about Unreal Engine 4 and how to use Blueprints.
Below is a list of the other team members who worked on this project, this project wouldn't have been completed without them so take a look at their portfolios if your interested in this piece of work;
Luke Norman:
Rob Green: robgotbanned.wix.com/portfolio
Michael Hindley: michaelhindley.prosite.com
My primary roles in the team were project management, level design, audio design, game design, a small amount of scripting and I assisted with some of the 3D modelling of props.
Overview
Detailed Information
Dreamscape Level Design Concept
Software Used
Roles
-Level Designer
-Project Manager
-3D modelling
Game Video
'With Lucid’ I aimed to create the feeling and mood of a dream. This is done by the use of colours, particle effects, symbolic objects and Items being out of place. As the game progresses this will become more apparent as the protagonist begins to realise that they are in a dream. The mood is set by use of a dark night sky with a strange colouring to it, the firefly particle effects and the use of fog to add a haziness to the scene. The fog and its haziness are used to make the player feel as if they have just woken up. The fog will change a get thicker and thinner are the game progresses thus changing the mood.
The mood board demonstrates the atmosphere I am trying to set and gives some indication for the feeling of the entire game and gives reasoning for my choice of mood in the screenshots provided.
Above is the colour palette for the scene and the rest of the game. I have used tertiary colours to create colours that are analogist. I feel these colours are best suited because of their odd combination and they are colours that create a restful feel due to the fact that they are analogous. This was intentional because it gives the player a relaxed feeling which is in keeping with the games theme of being set in a dream world.
Overview
This Level is the product of my Advance 3D Assignment at university. I was tasked with planning and building a part of a level that would act as a 3D concept for the rest of the level and the game. I chose to build a level that was set in a dream world. The game concept is for a puzzle adventure game about a child who is stuck in a dream. The player would have to make their way through the dream world and find a way to wake themselves up. The player would take on the role of this child and solve environmental puzzles to progress through the game.
Detailed Information
Below you can see the CAD style plan for the entire level. For the 3D concept I only constructed the Garden section of the level because this is where the majority of the gameplay will take place and the rest of the level would be used for setting the mood and tone of the game. I did plan on creating the entire level however, because of time constraints and other projects, I decided it would be best to make one high detailed area to demonstrate my concept.
This CAD plan shows the players travel path and where obstacles and puzzle elements would be placed. It also provides a sense of scale.
The players’ main objective in this scene is to destroy the teeth using the puzzle objects in the scene and cross the bridge to exit the level. The player will enter the Garden through a door and be faced with only one direction to walk forward. From this position the player can see the teeth blocking their path and a glimpse of the door behind them which is the only way to continue the level. There are only two directions from this point that the player can go.
The player must make their way to the seesaw and use it like a crank, jumping on either side. Doing this will cause the teeth to begin to crack. The player has to do this until the seesaw stops moving.
The player must also turn the roundabout to cause the teeth to crumble even more until they shake and are destroyed. The roundabout will stop moving after a certain number of turns. These last two steps can be completed in any order.
With the teeth gone the player will be free to exit the level.
However, the bridge has fallen into the stream and washed away. The player must now use the crates to create a floating bridge so they can cross. This is a timed event and the crates will float down river, so the player must be quick to act to complete this task, once across they can go through the door.
My production schedule relies heavily on my total hours work and the estimated amount of time needed to complete the project. I got my total time from deciding that I would work ten hours a week from the distribution of the assignment brief. After making my asset list and estimating the total time it would take me to complete my project I found it would take 130 hours to finish everything.
