Museum.exe is a project I facilitated and directed to the best of my abilities as a game design student. It is a game that combines game design and museum design to a great extent - something that hasn't been done before and which is a work I'm proud of the most.
It is also a thesis project I worked on together with a team of 4 - all game design students at Uppsala University. It earned us a pass with distinction for the course and it was awarded "Jury Spotlight" at the Gotland Game Conference 2024.
Team: 5 People Software: Unity, Draw.io, Jira Roles: Facilitation, Management, Research, Design, Testing Duration: 17 Weeks
A GAME IS A GAME IS
Museum.exe is an interactive museum experience that showcases the best of the indie games industry and talks about gamemaking - how it started and how it is done today. The game contains a selection of 30+ games, scattered across themed exhibitions filled with puzzles and secret locations. No goals or objectives - explore it at your pace, any way you like!
A GAME IS A GAME IS
My Roles
Producer
-
I found and recruited team members and presented a vision to work with.
-
Established a team contract to follow for meetings, communication, and scheduling.
-
Created a high-level plan in the diagram software to set deadlines and keep track of the deliverables.
-
Conducted all scrum rituals and meetings.
-
Maintained a Jira board, created stories, and evaluated them with the team.
-
Was always on the lookout for improving the team dynamic, workflow, and organization.
-
Found voice actors and directed the voice lines needed for the game.
Vision Holder
-
I created and maintained the concept document throughout the development.
-
Curated the list of the presented games and categorized them into 5 exhibitions.
-
Designed and implemented exhibits during both the ideation and closing phases.
-
Conducted research and wrote the description of each game and explained in-depth why they are important for the game industry.
-
Worked on the layout of the museum and its environment.
Additional: Playtest Coordinator
-
I gathered participants and organized most of the playtest sessions.
-
Created surveys, held interviews, and collected and analyzed feedback.
-
Tracked and maintained the bug list.
Project Documents
This link leads to the diagram software I used throughout the development. It contains high-level planning, all of our deadlines and milestones. It also contains layouts I created that mostly served us as guidance.
The document outlines our initial thoughts when we dived into the project. It has descriptions of the vision statement, the general aesthetic, and the core principles I wanted to be realized in the project.
This spreadsheet has everything from research papers to QA, the assets and the game selection. It was our main way to track and evaluate all of our data.
A GAME IS
Facilitation
Being inspired by games like Monuments to Guilt, Kid A Mnesia Exhibition, and others, I wanted to make something that doesn't fit a typical definition of a game. I wanted to work with concepts that are unrelated to games and that can be explored by the general public through the game medium. Kind of like video essays on YouTube (that I greatly enjoy), except you also get to do something, though not mechanically intense.
Some team members, including myself, had a vast knowledge of indie games in particular, which helped with choosing the new theme of the project. Besides, making a game about a familiar topic also allowed everyone to creatively contribute - while following a vision that was clear and concise.
Ventilation presentation of Museum.exe and our thesis work.
A GAME IS A GAME IS
A GAME IS
Design
All team members contributed to the game's design in some way or another, since we were all game design students. My design work was more about the general design and the textual content rather than exhibit/puzzle design since, as a team leader, I was more preoccupied with vision and direction. Though there are some exhibits I designed that made it into the project.
One exhibit I am most proud of is the Outer Wilds exhibit. Outer Wilds revolves around discovery and curiosity, but most importantly, there is no progression. You explore things on your own that were always there, making it possible to complete the game in less than 20 minutes. Outer Wilds is a uniquely designed game that took a completely different approach to making a fun experience, which is what I tried to encapsulate here.
-
The player first discovers the dialog wall and learns about a *bug* in the game.
-
They see an exhibit on top of the ceiling.
-
They collect two boxes needed for the bug to happen and reach the exhibit.
-
If the boxes are left on top without the player, they can be returned back to the ground floor by pressing a button next to the dialog wall.
-
The box that comes with this design can be used to "light up" the supernova.
Many nuances of working on a museum game were discovered "on the go", like the approach toward its layout. I started making designs in diagram software but then switched to Unity since greyboxing still proved to be essential even for a somewhat minimalist and cubic space. The same was with lighting: while museums pay great attention to how their exhibits are illuminated, halfway into the development we decided to drop their methods once our "game exhibits" became more interactive.
A snippet from our Lighting Style Guide
A GAME IS
Management
There was a lot of management and documentation work done on my part to keep track of the conference deadlines, keep thesis research organized, and make working on the project more efficient. The project roadmap was maintained in diagram software and the backlog was always kept updated in Jira. At some point, an Excel sheet was added where the team could keep track of the exhibits and their level of completion.
Since I had a lot of experience with Scrum, I chose to use it as our main framework for the project, as it fits best a project that requires a lot of experimentation. We followed the Scrum guide thoroughly but didn't keep our sprints fixed-length. When the design was less apparent, I kept sprints 1 week long, and when the design was figured out and the remaining work required less frequent communication, we agreed on 2-week sprints.
One thing I'm proud of regarding executing scrum was planning poker. In my experience, planning poker does not motivate the team to ask questions by itself, which is why I believe asking about the first steps toward finishing a task can manifest a proactive mindset. This is useful even if the developer and the task they evaluate are not related (f.e. an artist evaluating a programming task) because this approach doesn't postpone working on the problem until after the meeting and encourages everyone to think about it now - a skill often attributed to senior developers.
Conclusion
-
This is the most significant project I worked on throughout my university education. While there were larger projects I took part in, they were facilitated by others and I was usually given the role of a manager or designer in them. Museum.exe wasn't an exception to that, yet I was also able to direct my own ideas and iterate on them. Games are never released the way they are envisioned from the start, even those with a large budget, and I cannot stress the importance of experiencing that first-hand enough.
-
Throughout the development of Museum.exe, we also reached out to some of the developers who worked on the games we showcased. While some appreciated their game being included in our project, Steve Gaynor - the creator of Gone Home, Tacoma, and other games - enjoyed our project the most. He sent us a lot of feedback on what could be improved or done better. He mentioned a "high conceptual and implementation quality" but he also explained in detail how the in-game text looked unprofessional in comparison. Since I worked on the text the most, I can't avoid saying that his feedback was one of my main takeaways as well. Check out his newsletter where he talks about our game here!