Post-Mortem: RuinVerse

In 2021, our three-person team set out to create RuinVerse, a third-person adventure game for mobile devices. We aimed to build a small, polished experience within a three-month development window. The game explored the concept of colliding universes, where the player collected scattered note pages and used motion-based magic to restore balance to a fractured world. We successfully delivered a playable build on schedule, but ultimately decided not to release the project. Even so, it became an important milestone in my early career and taught us valuable lessons about scope, tools, and teamwork.

Team & Roles

We had a small but motivated team of 3 developers. All of us came from production-related backgrounds, so while we were strong at planning and organization, we were less experienced with hands-on development work.

• Team Size: 3 developers

• Roles Covered:

  • 2 Programmers

  • 1 Designer/Producer (me)

• Shared responsibilities: Additional design and art tasks distributed across the team

• Tools Used: Unity, GitHub (with LFS), Trello, Discord, Audacity, Maya

What Went Well

We built and submitted a functioning prototype within the timeline, which was an achievement considering our relative inexperience. The core concept of a fractured universe expressed through shifting art styles gave the project a strong creative foundation. We also communicated effectively as a remote team, using daily check-ins to stay aligned and motivated.

Key positives:

• Clear division of roles from the start reduced confusion

• Compelling central theme that unified mechanics and narrative

• Consistent communication over Discord kept progress on track

• Early prototyping and playtesting provided useful feedback

What Went Wrong

A few major issues slowed us down and limited the final scope. My decision to use GitHub for version control worked fine in smaller past projects, but the introduction of large purchased asset packs caused severe performance and syncing problems. Even with Git LFS, one teammate had persistent commit issues, and we lost nearly three weeks just stabilizing the repository.

We also over-scoped the design. Our original idea included multiple art styles and puzzle mechanics, but implementing them in Unity proved slower than expected. Although we got the motion-based magic working, we didn’t have the time to create puzzles around it. In the end, we had to cut back to a simpler “collect the pages” gameplay loop, which reduced the uniqueness of the final build.

Main challenges:

• GitHub wasn’t suitable for large asset-heavy projects

• Persistent version control issues hurt productivity

• Over-ambitious scope in the early stages

• Limited Unity experience slowed down implementation

• Cutting a core mechanic (gesture-based puzzles) late in development

What We Learned

The experience underlined the importance of making technical and scope decisions that match the team’s actual strengths and constraints. I also learned how costly it is to underestimate infrastructure setup time, and how critical it is to recognize when a problem is consuming too much of the schedule.

Key takeaways:

• Choose the right version control system early (Perforce would have been more appropriate)

• Establish consistent file and asset management practices from the start

• Prioritize delivering a polished core loop first, then add extra features if time allows

• Protect time at the end for integration and bug-fixing

• Daily communication is vital for keeping a remote team aligned and motivated

Conclusion

While RuinVerse was not released, completing a playable build with a small, relatively inexperienced team under time pressure was still a meaningful accomplishment. More importantly, the project gave us practical lessons about scope, tooling, and process that continue to influence how I lead and structure projects today.