UI/UX Designer
A “reverse tower defense” game where you play as the waves of minions attacking the fortified towers of a dwarven fortress. Upgrade and build several kinds of zeppelins and watch them lay waste to your enemies.
Unity and Custom Engine
10-person team - designers, programmers, artists, and sound designer
Fall 2022 - Spring 2023
Released
The Game
Design Goals:
Develop a game in a custom C++ engine
Learn to work with a large interdisciplinary team
Prototype and iterate quickly
Find an appropriate project scope through self-assessment
The game began as a digital board game, but we pivoted early in development to a more active mode of gameplay due to concerns with the UI-heavy engine requirements. It was an interesting challenge to redesign the core gameplay while still maintaining the elements that first excited us about the game, but through a lot of communication with the team, we settled on a concept that made the best use of all our combined talents while still fitting into our semester deadline.
We created a shared document containing a list of every visual and audio asset in the game and held regular meetings to share our progress and discuss concept art and ideas.
Our design team was responsible for creating and maintaining the Unity prototype for our game while our programming team worked on building a custom C++ engine. We worked closely with our programming team to keep the prototype in scope so that the engine could be completed within our time constraints, but in the latter half of the year, we switched over to working and testing fully in the engine.
Throughout the project we also learned industry processes like formal presentations, strike team development, and time management for strict deadlines.
My Role
Responsibilities:
Prototyped and designed the game’s UI
Developed a Unity prototype to help guide engine development
Implemented several VFX in custom engine
Maintained a Game Design Document
As a designer, I helped guide the team by thinking ahead and planning out core gameplay elements and general game structure, as well as its theme and aesthetics. I also conducted regular playtests to gather constant feedback and iterate on the game.
As the UI/UX designer on the team, I have learned a lot about screen layouts and player learning. The UI went through several iterations, and I used Figma to quickly prototype different layouts. I also worked closely with our UI artist to give the UI a strong theme and feel, to make the game feel more alive and tangible.
I worked with my Lead Designer to quickly prototype the core gameplay elements and find a place for every art and sound asset our team had made, and the prototype served as the roadmap for the engine and a sandbox to playtest and adjust gameplay.
One of the most important things I learned during this project was the importance of strong design pillars. We didn’t start the project with them, but when we introduced them into our workflow and discussions later on in development they had an immediate and noticeable effect on decision-making and cohesion.
-
![]()
Asset Tracking
Zeppelin Rush was a project involving four different disciplines, and required a lot of different art and audio assets to be created and managed.
To make this easier for everyone, I created a spreadsheet to track the required assets and their progress. It includes multiple sections for different kinds of art split up based on which artist was handling it, as well as all the game's audio for our sound designer.
The document kept track of progress, implementation, and basic descriptions and priorities for future assets.
-
![]()
ASF Document
One of the key development tools our design team used for the game was a document containing each interactive component in the game and its associated affordances, signifiers, and feedback.
This document let us see at a glance how each component would be implemented and affect each other, as well as what art or audio assets would need to be made for it.
It also reminded the rest of the team to be conscious of how players would experience the game and how to guide them towards intended play patterns and details.
This document was created and maintained by myself and my design lead. The basic format and about half of the content, particularly the UI elements, were written by me.
-
![]()
Figma UI Prototyping
Despite my little experience with UI design, I found myself primarily working as the UI/UX designer of the team. I learned how to use Figma to rapidly conceptualize and prototype UI elements throughout the year.
I used these prototypes to design and discuss the UI with the team's main UI artist, and would modify it as necessary to fit any changes to the art.
I also playtested the game's UI several times using the Figma prototypes, as it was possible to create a rudimentary game by connecting various buttons and UI elements to specific functions. Many of the game’s controls were difficult or impossible to simulate this way, but I was still able to receive feedback on the UI without needing to spend time implementing it in game first.
-
![]()
User Research
A big focus while creating this game was user research and playtesting. My design lead and I conducted regular playtests throughout the year, and we recorded and discussed this data in playtest reports.
I tested many different aspects of the game such as the UI, early art assets, and game system balance at several stages of development. The playtest reports were a great way to consolidate data into shareable conclusions which we used to guide development and communicate with our team.
