Project Overview
Overgrown is a 2.5D RPG set in a museum that has been overrun by sentient plants. You play as Lily, a botanist searching for her missing father inside the museum’s overgrown corridors.
Along the way, you’ll befriend unexpected allies, battle plant-like monsters, and uncover the mystery behind the museum’s rapid, lush transformation.
Trailer for our GDC-Demo. I will be uploading our final Cinematic and Gameplay trailers once they are completed on 5/30
Why is Overgrown so special?
Overgrown represents a landmark collaboration at SCAD. It is the first time two distinct majors have run a single project side by side across three consecutive quarters.
On one side, twenty Game majors tackle the core build: programming, systems design, game design, narrative design, asset implementation, and the pipelines that anchor every discipline.
Right next us were twenty Animation majors take charge of art direction and animation workflows, refining our visual language and bringing each character and environment to life.
This close proximity of expertise has broken down traditional silos and forged real studio workflows where feedback is immediate and iteration cycles move much faster.
Overgrown stands out because of its sheer scale and technical ambition. Over one hundred students have contributed, making it the largest and most complex game SCAD has ever undertaken.
Each week I have led the team to produce a playtestable build, enabling our design team to hold rapid playtesting and give us feedback for refactoring. We operate in weekly Scrum sprints and have integrated the Animation department’s traditional workflow into our software development pipeline.
The game’s RPG elements feature twenty-four distinct skill-tree abilities, a wide variety of enemies, numerous NPCs with branching questlines, and three boss fights. Every gameplay component, including combat, progression, and world interaction, fits into a unified framework and required close collaboration between designers, programmers, and animators.
Fall Quarter
Overgrown Fall-Quarter Team. Fall quarter was 10 weeks of experimentation in order to create an initial MVP of the project.
In Fall Quarter I served as Lead Systems Developer and led a Combat Strike Team to bring our game’s combat online and refine it as quickly as possible.
I also served as Co-Implementation Lead, where I optimized workflows and partnered with the Animation team to streamline the import of their 2D assets and animation into Unreal Engine.
Fall Quarter Class Picture
We live and breathe weekly builds. Every single week, without exception, we ship a playable milestone.
In week 1, even before we’d settled on a core concept, we delivered a build solely to test camera angles and get our character controller up and running. That requirement has kept us aligned, let us gather feedback early, and ensured steady, iterative progress throughout the project.
First ever sprite sheet given to us by Animation for in engine implementation.
Original testing of our character controller using PaperZD to drive animation.
Early testing with normal maps on 2D planes.
Tests of cell shading. This was scrapped due to conflict with art direction.
From the beginning we recognized combat would be essential, so we focused our efforts on those systems right away.
Quarter 1 Enemy Lineup
Our first ever version of "combat" This was the start of the modular enemy base that drives every single enemy in overgrown to date.
Because animation shapes combat feel, I partnered closely with our animation team from the start to nail down our style. Over two weeks we commissioned several prototype moves and had each animator create their own version. Every few days we gathered together, played the clips on a big screen, and discussed what worked and what didn’t. This rapid, parallel process let us lock in a cohesive animation style far sooner than a traditional, one-at-a-time workflow would have.
In our earliest combat iterations, attack animations felt too close to the character model. To address this, we held a meeting focused on combat references and taught our animators how to separate attack motion from the character’s body.
I collected examples from Super Smash Bros showing how characters exaggerate proportions during strikes to sell impact and avoid claustrophobic framing. Applying these insights led directly to the creation of our standard three-hit combo.
Our Final deliverable for Fall Quarter.
Winter Quarter
Winter quarter marked a dramatic shift in pace compared to fall quarter. The main difference was that we knew exactly what game we were making and had finally left the experimental phase behind. We spent far more time executing and far less time trying out new ideas. With a clearer vision, far less work ended up being scrapped.
At the start of the quarter we faced a crucial decision. We could focus on getting most of the actual gameplay online with two to four hours of content at sixty to eighty percent quality so that every element was functional for early playtesting. Alternatively we could deliver a single playable demo at full production quality. We chose the latter because with only twenty weeks of development remaining we wanted to avoid creating content that might be cut or leaving parts of the game incomplete. We also wanted a polished demo to generate hype and build a community around the game something a buggy incomplete version of the full game could not achieve.
A major hurdle on the systems side was that only three of our eight-person team from Fall Quarter returned for Winter Quarter because most of the others were seniors starting their capstones or needed their elective credits elsewhere. To address this we spent the first two weeks on onboarding and gradual integration. Week one was dedicated entirely to training.
Everyone from systems to the wider game team learned our revision-control workflow under my guidance since many had never used it before. In week two we assigned small, isolated tasks so new members could ease into the project at a manageable pace.
We also onboarded most of the team to Scrum, training them in weekly sprint cycles and getting them used to delivering a playtestable build every week.
Early version of the Ram enemy
Ram enemy documentation from our Design team
Shortly thereafter we began receiving new enemy designs from the design team, along with colored animations for Lily and several of our first-quarter enemies, and the project started to take shape. The first winter-quarter enemy to go live was the Ram. While it can damage the player, its primary purpose is to charge through breakable walls and unlock new exploration paths. This was the first enemy we developed collaboratively, I onboarded Greta Thomas onto the enemy base framework I built in the first quarter so she could contribute to enemy creation.
Silhouette system i made for revealing Lily when she is behind objects.
Cleanup animation of one of our new enemies from winter quarter.
GDC
Around week five we learned we’d been selected to represent SCAD at GDC. That news put us into overdrive as we raced to polish the demo to its absolute best.
By GDC we had a polished 15-minute demo complete with six skill-tree abilities, six unique enemies, and an entire museum wing at final production quality.
Showing our work at such a major event was a life-changing moment. Not only did I get to attend GDC, but I also had the chance to share the game I helped lead with industry professionals from around the world.
Spring Quarter
Spring Quarter has focused on full-speed production and careful scope management. We evaluated what was worth keeping and what to cut. We ramped up QA and marketing efforts, built our Steam presence, and ran extensive playtests while participating in events like Steam Next Fest. We also launched our Steam page and are preparing for release.
We are currently in week 8 of 10 in development and our animation team has halted all production for the game so that we have enough time to get all of their assets integrated. Soon we should have a full cinematic and gameplay trailer that I will post here as soon as I can.
Overgrown Steam Page