AIDEN BARRETT
Game Designer
Portfolio Projects
Eternity's Second
Objective:
After a recent rewatch of Doctor Who, I wanted to challenge myself to create a game utilising time-travel as a puzzle mechanic. So, I decided to attempt to make a puzzle game as that is a genre I have never attempted before.



Time Travel:
When creating the time travel mechanic, I ideally wanted to create something that isn't as complicated as actual time travel. So, I wanted to relate it back to something that reflects simplicity, so I looked back at TV’s and VCRs as their rewind and fast forward being simple to understand and relatable. Within the time machines UI, I wanted to make sure that the mirrored TV controls so that the user can get used to them quicker.
With regards to the time machine itself, I wanted to make it a HUB area so that the user can separate themselves from the puzzle and its location to gain a clearer view. It was to also use it as a plot device as the player will gain trinkets for each puzzle they solve, and they will live in the time machine. In which all the trinkets come together to form a new doorway into the protagonist's past.

Level Design:
To begin with I wanted all the starting levels to have a similar design with the box layout as I first want the player to understand base mechanics of time travel first. Going forward though, I wish to expand in the size and shape of each map and incorporate a tracking camera to follow the player to other parts of the level. This way the player is challenged to remember where they have been and what they have done because rewinding time will affect them on a larger scale.
Each level needs to avoid having complex platforming sections, as I believe that removes focus from the puzzle solving elements. As I want it to challenge your mind and not skills with a controller.

Difficulty:
Over the duration of the game want there to be wide range of puzzle mechanics but I don't want so many that the player becomes overwhelmed. I instead wish to opt for a select few puzzle mechanics that can interact with each other differently. So that way the user won't be forced to remember too many mechanics but instead be forced to think about them differently.
A curveball level I am looking to Implement is “paradox” levels where the player will create a copy of themselves each time they rewind. Each copy will have a cone of vision visible to the player, this cone needs to be avoided or else it will cause a paradox which restarts the level. This way the player sets their own limit as to how many times they can restart the level, creating difficulty by player set limitations
Reflections:
In creating this game, I found that one of the biggest issues I encountered was with the fact I mad the rewindable assets physics based. This is because in doing so each instance of them moving is random and with this means that each level needs to take in to account each possibility. Which means that each level becomes more complex in its design. Although it can create new and interesting developments due to each instance being unique it does limit each levels design
Another issue with each asset being physics based is that the collisions can sometimes mean that multiple assets will explode when their collisions overlap. Which means currently there is a limit to how many physics assets are in a level to avoid this issue. Even if it is possible to fix said issue, I haven't been able to solve it, yet which has cost a lot of development time.
Going forward It will be better for me to also play a variety of different puzzle games as I realised that a lot of my inspiration for puzzles were action games like God of War (2018). Which is made evident by choice of push mechanics and moving platforms. I think doing this will broaden my horizons and enable me to make a more well-rounded game with deeper challenges.
Documentation :
This project was created in Unreal Engine 5, with some 3D assets from Bridge
Card Game Asset Pack
Objective:
In my Third year if university at the Confetti Institute of Creative Technologies, I was tasked with Creating an asset pack that we would want to put on the unreal marketplace. To achieve that objective I wanted to add a Card Game Asset pack that would allow people to implement minigames into their games.
Documentation :
This project was created in Unreal Engine 4, with all 3D assets made in 3D's Max.
Planetary Liquidation



Objective:
In my second year if university at the Confetti Institute of Creative Technologies, i was tasked with the creation of a game with one playable level with a genre of my choosing, either in a group or on my own. I decided this would be a good opportunity for me to do my first collaborative effort and decided to create this project with another student so we could share the workload.
Design:
Planetary Liquidation is a real time strategy inspired by games such as warcraft 3 and Lord of the rings: Battle for middle Earth 2. The original objective was for the player to crush the enemy team by destroying all their buildings and units. In doing this we found this achieved the basic requirements for it to be a real time strategy, but we found that this meant the player could take as long as they want without much of a challenge.
To combat this, we planned on giving the player incentive via adding a timed objective. Yet instead of adding a timer that is relatively unengaging, we instead provided the player with the objective of destroying the enemy team before they destroyed the friendly village. To achieve this, we provided the friendly team with limited recourses and removed their ability to create additional buildings.
In doing this we found players had more urgency to complete the level and created more Pressure.
Mechanics
World Clock:
For a lot of our base mechanics to work the way we wanted to, we had to create a world clock. This clock would then be used for all the building and unit production timers. As the time specified for production would all operate on the world clock, which also meant that when mechanics needed to be tested the time could be sped up to reduce testing time.
Base Building:
We wanted base creation to be simple and intuitive, making it so player could place buildings where they wanted with some restrictions. These restrictions were if there was an obstruction or uneven ground, to prevent the buildings from looking messy. The player would be able to select where they wanted a building to be placed and then move a worker unit over to begin construction.
Unit Types:
There were a variety of different unit types all of which having their own unique abilities and some having unique buildings they could be spawned from. We ranged from having warriors and archers from the barracks and siege engines from the siege works. We found that having one dedicated area for unit spawns meant there was less micromanagement for the player and easier to group up newly made units.


This project was created in Unreal Engine 4, with all 3D assets coming from Quixel bridge and Mixamo.