Attic Panic
"Attic Panic is a 2-4 player top-down supernatural rogue-lite shooter where you play as posessed toys that battle each other to entertain the Entity, which grants players unique powers and abilities at the end of each round."
​
Within the project I had two roles:
-
Game Design Lead: as the lead I managed the design team, played an active role during early designing and concepting, and made sure the games design was good and coherent.
-
UI/UX Designer: as the UI/UX designer, I researched and prototyped all UI elements and made placeholder art. Additionally I was the main contact point between UI Art and UI Programming.
32 weeks
(Sep '22- July '23)
24 People
Unreal Engine 5
UI/UX & Design Lead
Final state of the HUD as can be seen in game during combat
Main menu as found int he game with a dynamic background
Process of picking available upgrades and the menu closing
Final state of the HUD as can be seen in game during combat
Project Overview
My Role
-
Game design lead
-
UI/UX lead
-
UI/UX designer
-
Game designer
Goal
-
Make the HUD informative during combat without cluttering gameplay.
-
Give players all necessary information during the upgrade screen without overwhelming new players.
-
Make sure the design team works effectively and in tandem with the programmers and artists to create a cohesive experience.
-
Design a chaotic but fair arcade PvP game
Tools Used
Unreal Engine 5
Figma & FigJam
Perforce
Jira​
Miro
Understanding the Project's Needs
At the start of the project we were met with a creative brief. Based on the brief, the team's composition, and the team members' learning goals & portfolio needs, we proposed multiple game concepts and picked the most fitting one. Here it was important that the game had a unique selling point, both art wise and gameplay wise, and that the whole team would be motivated to work on this project.
Creative brief that our team had to work with.
Third concept gameplay proposal to the team that ended up getting developed further into what turned out to be Attic Panic. The proposal features some example features from other games, a simple game loop, a quick example map and a basic movement prototype.
Core Gameplay
Target Audience
Based on competitor research, we decided on a young target audience that would play a few rounds during school breaks.
To fit this, we wanted gamaeplay that felt fair for any skill level. Thus we decided to create a balancing game loop where, the worst performing players had first pick of upgrades. By adding randomness to the upgrade pool it prevented the power of meta-knowledge.
​
Based on our target audience and our generalised game pillars, we set up a couple of Gameplay Pillars, that we tried to keep into account while developing gameplay.
_gif.gif)
The core gameplay of players shooting eachother and collecting "essence" to gain points
Upgrade screen where last round's winning player can only pick 2 upgrades since the other 2 have been picked by the previous players already.
USP
When we started developing our game we wanted a unique selling point, to make our game stand out from our competitors. Besides our stylised but realistic supernatural graphical theme we decided on gameplay with rounds of combat, broken up by a upgrade select screen thats shared by all players.
​
On the Move
We wanted our game to have a controlled chaotic nature to it. In order to reach this during development we constantly paid attention to player feedback to at what point the game felt "too chaotic" and tweaked visuals and upgrade intensity to make sure the game was readable and a fun level of chaotic.
​
On top of that, we added a kill confirm mechanic in our game. This was added to discourage camping style player behaviour. Additionally this would increase rivalry and the pressure to race back to where you died to pick finish off your opponent.
UI Design Process
The Upgrade Screen went throught this design cycle the most in order to increase clarity and ease of use.
Steps
-
Analyse the Requirements. What do we need from this element? What are we trying to solve?
-
Empty the Head. What immediate solutions am I thinking of? Sketch it to get this idea out of my head and become open to other solutions.
-
Competitor Research. How do other games present this information or deal with these issues? What might work for us? Why or why not?
-
Sketch & Diverge. With this new information, how else can we fulfil the element's needs?
-
Gather Feedback. What do the team leads and developers most closely involved with this think? Do they think it's feasible? Do they think it is clear? Would they be motivated to work on/with this?
-
Converge & Prototype. Combine the best elements of the various designs, taking feedback in account. Prototype this with placeholder visuals.
-
Communicate & Implement. What will you need from the other developers? What has highest priority? Are there stretch goals? What will you implement yourself?
-
Test & Iterate. What do playtesters think of the element? Is anything unclear or missing? If so, return to step 1 or 4 depending on time.
Solving design issues
Testing​
To find issues within our game we would have bi-weekly external playtests. These tests would have specific questions we wanted to answer, and would involve a rotating cast of team members so the whole team is involved. We would observe the players and ask them questions after.
​
Discovering the root
Whenever we got feedback, we would try and figure out
what the underlying issue is that the playtesters were subconciously trying point out. e.g. "I would like a minimap" points at an issue with either navigation through the map or with finding players.
​
Finding appropriate solutions
After finding the root issues, we would take a step back, ideate what solutions there were, and look at how feasible they are, and how well they fit the game pillars.
​
Early screenshot from the Design Issues Document showing issues, potential solutions, priorities and how appropriate solutions were
Being a Lead
For the Designers
As a design lead it was important to be there for the designers. To make sure they remained motivated to work on the project, to make sure they can work as efficiently as possible to each persons own needs, and solve any issues that might arise. Additionally I was the voice for the design team when it came to lead meetings.
To achieve this I had (bi-)weekly individual meetings with each designer in which we discussed how they were doing, what they were looking forward to, what they thought of the project and if they had any worries. Based on this I would take action to deal with their worries, or to look into opporunities for them to hone in on what motivates them.
For the Design
As the design lead it was my duty as well to be there for the gameplay design of the whole project. To make sure I have an overview of all aspects of the project's design and as such communicate those priorities to the designers and to the other leads and producers as well.
On top of that, it was important to steer the project so that it remained cohesive and to be aware of issues that play testers brought up. To achieve this, I made sure that playtests had clear goals, and that these got arranged and prepared for properly.
​
Retrospection
Reflection
The project was a great learning experience, both from a UI/UX perspective and a design (lead) perspective. However, it did come with its fair share of challenges.
Project wise, working with a complexly built up game, due to the networking aspect, posed significant hurdles. It made implementation more challenging than any of my previous projects.
​
With all the responsibilities related to the project and those around it, taught me to evaluate my priorities better and to plan accordingly.
Takeaways
I learnt plenty during this project. Such as:
-
How to develop UI with online networking in mind.
-
How to present a high amount of information without overwhelming (first time) players.
-
How to properly analyse playtest & design issues, and find appropriate solutions.
-
The importance of a motivated and aligned team through external playtest attendance and frequent internal playtests.
-
How to represent a part of the team, and how to make sure can play up to their strengths.
​
End Results
Results
I'm incredibly proud of the team. We managed to strike a great balance between working hard and goofing around. Additionally, we started as the underdog team and came up on top as a great project.
​
The steam reviews (97) are "Very Positive". Most reviews hit exactly on the notes of what we were aiming to achieve: the game being competitive, chaotic, and great for a few rounds. On top we got reviews along the lines of "This game does not seem like a student game, but more like an early access indie game".
​
Core complaints involved a lack of player base, some upgrades feeling unbalanced, and a lack of maps.
​
Rewards
Our game was presented and played during our university's annual industry showcase day where industry professionals are invited. After the event we received the following awards:
​
Get in Touch
Thank you for checking out my Portfolio. If you're interested in my work, if you want to know more or just have any questions in general fill in my submission form, or find me online at: