What is Mu and The Little Reef?
Mu and the Little Reef is a third-person gardening adventure game where the player plays as Mu, a baby sea god, trying to restore a dying coral reef to life by cultivating coral and aiding the reef's denizens. The main goal is to complete quests for the inhabitants of the reef, which include bringing them fruits from certain plants, removing pesky fish from their gardens, cleaning up the bubble algae blocking their paths, or lighting up their homes because they got too dark.
Mu and the Little Reef was made in Unreal Engine 4 over the course of two semesters by a junior student team at DigiPen Institute of Technology. It was worked on by 6 programmers, 4 designers, 6 artists, and a sound designer.
What Did I Work On?
I worked on Mu and the LIttle Reef for the first of its two semesters of development during its preproduction phase as the Producer, Design Lead, and User Researcher.
- Researched production tools to create production pipeline to manage dependencies and focus on interdisciplinary collaboration.
- Worked with professors and TAs to manage milestone deliverables and find resources to empower our team to create our vision.
- Conducted check-ins with each member to remove issues blocking them and adjust production plans to fit how much bandwidth they had that week.
- Led milestone meetings to organize members into interdisciplinary teams focusing on specific features to promote interdisciplinary collaboration and ownership.
As design lead:
- Designed movement system to create the feeling of being underwater.
- Led weekly design meetings to track milestone progress and help brainstorm solutions for any features or content currently blocked.
- Served as the bridge between the design team and other teams as necessary.
As user researcher: - Conducted early usability tests on movement systems leading to a better defined movement system and level design guidelines.
- Visualized, analyzed, and wrote briefs on data to inform rest of team on the success of recently made features and content.
- Created playtesting documentation for best practices to easily collect unbiased data.
What Did I Learn?
1) When in doubt, playtest it. During preproduction, we were struggling to define our movement system and rules. We were running into issues with limiting the player enough to have cohesive and small levels while still giving them the freedom to swim and have the game feel like an underwater experience. To remedy this we took the current movement system we had, quickly built off it to prototype different types of movement, and tested them to find what was best. While this sounds simple, it took conscientiousness to examine what we were doing, why we were doing it, and finding workable solutions. We were walking a tight line to satisfy the player, the level, and our technical capabilities.
2) Always be ready to wear a different hat. The week of a milestone deliverable, DigiPen experienced an outbreak of norovirus. This absolutely devastated our team and left our 15-person team with 2 healthy members. As one of them, it was up to me and the single remaining programmer to put together our deliverable. We each had to wear a lot of hats, as I worked as a level, gameplay, and narrative designer for that week while my partner in crime took the tasks of three gameplay programmers and a technical designer to finish our milestone. We were only able to do this because everyone was on the same page of where the project was and what we needed for the milestone.
3) Ask for help as soon as you need it. This was the first time for all but one team member to work in Unreal. Previously the designers had Unity and C# experience while the programmers worked in C++ and made custom engines. Additionally, this was the first commercial engine project for the artists, so everyone was constantly learning as they went. A huge part of how I helped remove blocks as the producer was by finding more experienced students who had worked on something we were attempting to ask for help. I tracked down an artist who had done procedural material blending so we could blend sand and grass, found a programmer who did AI in UE4, and helped my connect my level designer and environment artist with a senior who had done a lot of lighting work.
4) Sometimes you need to do what's best for you. At the end of preproduction I decided to leave this team. It wasn’t anything to do with the team or project, I’m still good friends with nearly everyone from that team and play weekly D&D with a couple of them, but most of the work I was doing on the team was as a User Researcher and Producer. While this is fine, the classes I was taking next semester were all very User Researcher focused and this would mean I would spending an entire semester mostly out-of-engine and not getting my hands dirty. To some this would be a great thing, but as someone who really enjoyed working as a gameplay designer, I didn’t want to put that down and get rusty. This led me to leave Mu and Friends to join Spicy Dice Studios and work on Metamorphos (a project you can read more about on this website).
5) Don't leave your team hanging. Part of why I was comfortable leaving a project I enjoyed working on and a team I loved being around was because I knew I had done everything in my power to make the transition smooth. I created additional playtest guidelines and best practices to help make user research easier for the team to do, found my replacement as producer, and taught the production pipeline to the new producer and the designer who replaced me as design lead. Additionally, I made sure to bring everyone up to speed on the work I had done, why I had done the work that way, and made sure I was available to help them if they needed (which is how I ended up doing some data analysis and visualization for them).