I recently had the opportunity to participate in a semester-long project as part of Michigan State University’s Game Design and Development minor. This capstone course (MI 498) paired student teams with industry alumni mentors for a 15-week development cycle. It’s the final requirement for the Games and Interactive Media program and provides students with a valuable opportunity for growth before entering the job market. To make the most of this experience, I stepped into the leadership role on Daemon.

Before Daemon

Daemon’s story began a full year before the official development cycle. I was fortunate to participate in MI 498 early as part of a team partnered with Rockstar Games. Together, we developed the multiplayer cooperative chaos-management game Cloud 9-5. That experience was my first exposure to such effective project management, and it showed me how much easier development can be with solid planning and communication.

After Cloud 9-5, I realized it would be possible to take MI 498 again. Over the summer, while working with classmates, we brainstormed ways to create projects with teams that align with specific career goals. One idea-building a PvE-style hero shooter-emerged to support students aiming for roles in AAA development. The following semester, a group of these students created Project Mercury in Unreal Engine 5. With the momentum growing, the stage was set to build a AAA-style game in UE5 with industry mentorship.

As I continued to conceptualize possibilities for the next project, the hero shooter idea resurfaced and was refined. The time-intensive heroes were replaced with customizable classes and armors that dynamically reflect load-outs. PvE was swapped for PvP, as the programmers from Project Mercury wanted to have networking in Unreal Engine 5 on their portfolios. I held off from designating any art styles to ensure the artists and audio designers would be able to work on things that best aligned with their portfolio and employment goals.

Pre-Production

Since the 15-week production timeline left little room for pre-production, I began pre-production ahead of time using a flexible approach. The team wasn’t official yet, but I estimated 120 development hours per teammate (based on university credit-hour guidelines) and avoided reinventing the wheel in terms of PvP mechanics.

Drawing from successful PvP genres, I conceptualized a rotating king-of-the-hill game mode, and potential elements to fit within a customizable class system. I intentionally designed our core systems to minimize time-to-prove-fun, an essential step in pre-production. I often turned to industry decision-making when possible, following the example of successful projects with far greater budget and production schedule than student teams. This best allowed us to develop game features and assets that were most critical to our portfolios. A key design principle was building simple systems composed of many modular components, allowing players to feel empowered by a variety of meaningful options.

By documenting everything in an Obsidian vault, we were ready to start building in-engine in Week 1. This head start proved critical for the scope we were targeting. I also developed a graph mapping potential class elements to gameplay impact and perceived fun, allowing us to build the game in modular layers. I began documenting our first set of items for review by a designer once the team was locked in.

Recognizing the limitations of free project management tools for our team size, I created a custom solution: Obsidian Project Management (OPM). Integrated directly into our Obsidian vault, OPM allowed anyone working in the engine to access live documentation. Designers could also make direct gameplay tweaks, ensuring seamless collaboration between disciplines.

Using OPM, I created a roadmap that included milestones, sprints, and tasks built around our modular item system:

Sprint 1: Deliver a first-playable version featuring multiplayer matchmaking, core FPS combat, respawning, basic environment, and visual concepts.

Sprint 2: Build the game prototype, focusing on the main gameplay loop and first batch of items.

Sprint 3: Achieve a minimum viable product (MVP) that could stand alone if needed.

Sprint 4: Add polish and standard AAA features-refined movement, UI/UX, and gameplay balancing.

Sprint 5: Final polish and ensure every team member has features to showcase in their portfolio.

To avoid over-scoping, something I’d seen doom many student projects, I firmly committed to early MVP delivery. The true end of any student project is to put it on your portfolio, so I made sure to include a final sprint dedicated to polishing individual contributions.

Early Production of Daemon

When the semester started, our teams were finalized, and I officially became the team lead, responsible for a 12-member crew (which later grew in size to 15). Despite early communication hurdles and onboarding challenges with OPM, Sprint 1 was a success. Our first-playable and concept art impressed both teammates and our mentors from Blizzard Entertainment. Although they were initially concerned we had only one idea in motion, our early progress helped earn their confidence.

We also made important decisions about asset creation. To maximize time and portfolio value, our artists focused on props unique to our game while we used general asset packs for less important elements of the environment (buildings + facades, sidewalks, foliage). This introduced restrictions in world-building and narrative, but with no narrative-focused team members, this trade-off was acceptable.

Unfortunately, I became seriously ill during Sprint 2. Fortunately, the detailed pre-production tasks I’d set up allowed the team to continue progress. I released our item-set tasks for development and focused on recovery. The team delivered, even though we began to feel the weight of over-scoping.

One major misstep:

I underestimated the development time for our item sets, leading to programmer crunch during this MVP sprint. I hadn’t adjusted work load to reflect correct time estimates before getting sick, which also left minimal bandwidth for bug-fixing. Although the game remained playable, it was rough.

During Sprint 3, I prioritized locking in gameplay systems and adopted a “we’ll fix bugs later” mentality. Crashes were common, especially during sequential matches, but I trusted the team to resolve these issues as they had proven capable of doing so in previous sprints. The key was cutting off development of additional gameplay content at the right time and shifting to iteration.

We began running two play-testing sessions per week and iterated gameplay balance once or twice weekly. This process resulted in 13 balance patches across the second half of the semester. Our goal was to replicate the balancing challenges that even AAA teams face-with far more time and budget. This provided excellent experience for our gameplay designer. Near the end of Sprint 3, we wrapped up the final approved item set, aiming to squeeze it in during Sprint 4 while prioritizing stability.

Final Sprints and Release Prep

Sprints 4 and 5 progressed at a much more sustainable pace. Watching the team polish the aspects of the game they were most proud of was immensely rewarding. My responsibilities at this time mostly consisted of organizing the ongoing play-testing sessions and leading our weekly check-ins with faculty and mentors.

We met a total of 5 times per week.

Twice for class, once with our Blizzard mentors, and once online over the weekend between class sessions. One class session per week we would also meet briefly with a faculty advisor so they may share their experiences with us and to receive their perspective about our project.

As we neared the end, I shifted focus toward preserving the project and sunsetting production. Since most teammates were graduating and moving on, continued development wouldn’t be sustainable. I migrated the project to GitHub, made closing announcements, and supported team members as they wrapped up their portfolios.

Not-Quite-After Daemon

At the end-of-semester showcase hosted by MSU’s College of Communication Arts and Sciences, Daemon had all 8 seats filled and a line the entire time. That moment convinced me we had something worth sharing beyond hiring managers and close friends.

We were honored to be selected as one of MSU’s submissions to the inaugural Collegiate Games Challenge (CGC), and are proud to take home second place in the “Interactive” category! Working on preparing our game for steam release and CGC submission became my highest priority after finishing the semester.

Following the original 15-week cycle, we added 12 more weeks of part-time development. Our two final sprints focused on polish:

Sprint 6: Eliminate remaining bugs and refine audio/visuals for CGC submission.

Sprint 7: Add new features: game modes, melee attacks, and a new weapon-all previously considered during development.

Sprint 8 (Optional): Contingency sprint for additional polish or content after our steam release. This sprint would run without a project manager or producer.

At the time of writing, we’re days away from launching on Steam. I couldn’t be more proud of this team. Please wishlist Daemon on Steam and check it out on release!

---

← Back to blog