Mirage Rush
Project length: 4 weeks
My position: UI Programmer
Engine: Unity
Genre: Extreme Sports
Platform: Mobile
Team size: 17
About
Mirage Rush is a extreme sports third-person mobile game made in the Unity game engine and C# for Game Project 2 at Futuregames.
Contributions
In this project I was responsible for the scoreboard for keeping track of who was the fastest and menu UI. We used Perforce as source control, Miro for prototyping and Jira for project management.
​
​
Scoreboard
​When the player gets to the end the scoreboard gets the time and name of the player (which is assigned at the start of the game) and puts that into a list and sorts it all in the scoreboard. When the capacity of the list is met, the lowest scoring entry is deleted, updating the scoreboard to only show the best entries.
​
The scoreboard is saved on local device using Unity's Player Prefs and Json that way the score is saved between sessions.
Volume Editor
​The volume settings uses 3 sliders, each one of them are connected to an audio group inside the audio mixer that controls the volume of all sound effects. The values of each slider is stored in Player Prefs allowing the settings to persist between sessions.
Take Aways and Reflections
I communicated with the UI designer because I needed to know what UI I had to implement, and how to set up the alpha version of the main menu.​
​
I learned the importance of communicating with the other people in a team on what you are working on that way you don't accidently work on the same thing. This problem happened due to the lack of using Jira to keep track of what everyone was doing. W​e made a game for mobile devices, so we had to learn how to optimize the game. A problem that happened was that me and one of the UI designers accidently worked on the same thing, and we overwrote each others work and had to start over. This for me was a good lesson to learn, and for future projects I remembered to clearly communicate what I was working on.
​​​
A take away from this project is that you have to accept that not everything you make will be in the final build. Some things that I created had to be scrapped. Some things were scrapped because they weren't fully implemented, and other things because we decided that those features weren't needed anymore.​
​​
I learned the importance of using Jira to keep track of what everyone is doing so we don't start working on the same thing.
​​
​​​
​
​