Rough Road – Building an RPG from Scratch

Introduction: From Students to RPG Developers 

Did you know that a group of first-year college students created an open-world RPG from the ground up? With only a few months of Unity experience, three programming students—Long Nguyen, Evan Flikkema, and Bashaar Ali—came together to develop a short and sweet turn-based RPG. While it wasn’t heavy on graphics, the game emphasized systems like level progression, stat-building, and elemental combat, making for an engaging gameplay experience. 

Each of us brought different strengths to the table. Long acted as lead producer and programmer, Evan focused on UI and storytelling, while Bashaar wore multiple hats, taking on level design and asset management. Despite none of us having formal training in art or design, we leaned on Unity’s asset store to help bring our world to life. 

Built over the span of a single semester—just three months—our project took shape while we juggled other coursework and assignments. With tight schedules and limited opportunities to meet virtually, coordination was a challenge, but our shared passion for games kept us pushing forward. 

Unity’s ease of use and integration with GitHub proved crucial. By streamlining our workflow, we could collaborate more efficiently, working on separate branches and syncing our progress when ready. Our development cycle was structured around key milestones: beta checkpoints, critical stage analysis, and final testing—all contributing to a process that was messy, educational, and ultimately rewarding. 

Production: What Went Right (and What Didn’t) 

What Went Well 

1. Familiar Mechanics = Faster Development 
Some of the main frameworks—like the turn-based system, stat mechanics, and save/load functions—were easier to implement thanks to Long’s prior Unity C# experience. We had a working battle system within the first two weeks, giving us a strong start.   

2. Leveraging Pre-Made Assets 
From the get-go, we chose to use existing Unity assets. This decision saved us time in visual planning and let us focus on gameplay. We designed our world around what we had, rather than spending weeks conceptualizing art from scratch. 

3. Small Team, Simple Communication
With just three of us on the team, communication felt more like chatting with friends than running meetings. It was easier to share ideas and coordinate tasks, even with different schedules. 

What Didn’t Go So Well 

1. Time Management Struggles
Balancing coursework with game development was tough. Our time commitment varied week to week, and there were moments when we just had to power through and hope for the best. 

2. Lack of Genre Familiarity
Not everyone on the team was familiar with RPGs. Common genre elements felt confusing at first, slowing down design and gameplay planning. 

3. Design Vision Was Missing Early On
As programmers, we naturally focused on building systems. But we lacked a clear game design from the beginning. Our mechanics worked—but didn’t come together into a fun, cohesive experience until much later. 

From Milestone to Milestone: How Things Evolved 

At the start, we felt confident in our plan—until we hit the first milestone. That’s when the cracks started to show. We had built some cool features but forgot essentials like a story or a tutorial. We assumed players would “just get it,” forgetting that not everyone plays games the way we do. 

Moving into the alpha, we had more to show. The battle system looked good, but we hadn’t figured out how players would get into battles. The main map wasn’t functional yet, and our ideas were far too ambitious for our scope. 

By the beta, we had something much closer to a finished product: a working map, a narrative that gave purpose to gameplay, and more polished battles. We also started doing deeper evaluations, including a Critical Stage Analysis, which helped us pinpoint and resolve persistent issues. Our communication improved too—we increased our check-ins and made sure everyone was on the same page. 

Each milestone made us stronger. We didn’t just grow as developers—we started to think more like game designers. 

Conclusion: Lessons Learned 

Looking back, the result was better than our expectations. Since we began without a solid game design, we weren’t entirely sure what the final product would look like. Simply completing the game felt like a major accomplishment in itself. One of the biggest takeaways from this experience is how valuable it is to have a strong design plan from the beginning. Without it, we found ourselves frequently reworking mechanics or discovering too late that some features didn’t fit well with the rest of the game. A clear, thought-out design would have given us a better roadmap to follow, saving us both time and effort. 

Despite the challenges, there were aspects of the development that made the process smoother and more enjoyable. Building the mechanics was a fun challenge that was made easier by Long’s previous experience. Working with Unity assets also helped streamline level design, giving us more time to focus on how to build the level. Communication was another strength—having a small team made it easier to share ideas quickly and stay aligned on goals. 

Of course, not everything went according to plan. Time management proved to be a recurring issue, especially with the demands of our other coursework. We had to rely heavily on our passion for programming to stay motivated and push through the tougher moments. We also spent a lot of time getting everyone up to speed with the genre itself, which slowed down early development. Most importantly, our lack of initial vision meant that while the mechanics were solid, it took longer for them to come together into a cohesive and enjoyable gameplay experience. 

In the end, Project RPG wasn’t just a game—it was a crash course in teamwork, time management, and creative problem-solving. We all walked away with stronger programming skills, and for some of us, a newfound appreciation for game design. Despite the rough road, we’re proud of what we built—and excited for what comes next.