Case Study 2: Hollow Knight --- Three People, One Masterpiece, and What Tool Selection Actually Means

The Numbers Don't Make Sense

Hollow Knight was made by three people.

Not three people plus a dozen contractors. Not three people at a studio with infrastructure, QA teams, and production support. Three people: Ari Gibson (art, animation), William Pellen (programming, design), and Christopher Larkin (music, sound). That's it. A team of three, working out of Adelaide, South Australia, under the name Team Cherry.

They produced a game with over 150 interconnected rooms across a continuous, hand-drawn world. A game with 47 unique enemy types, each with distinct behavior and animation. A game with 30+ bosses, some of which are among the most challenging and precisely designed boss fights in the action-platformer genre. A game with a dense, melancholy lore told almost entirely through environmental design, NPC dialogue fragments, and item descriptions. A game with an original orchestral soundtrack that stands on its own as a musical work.

Hollow Knight took approximately three and a half years to develop. It launched in February 2017 at a price of $15 USD. It has since sold over five million copies.

How did three people make this?

The answer involves scope discipline, iterative design, obsessive quality standards, and --- critically --- smart tool selection.

The Tool Choice

Team Cherry used Unity.

This was not a fashionable choice in 2013 when development began. Unity at the time was primarily associated with mobile games and small-scale projects. The "serious" 2D engines were GameMaker (for pixel art games) and custom technology (for teams with programming expertise). Unity's 2D tools were relatively new and widely considered inferior to its 3D capabilities.

Team Cherry chose Unity anyway, for practical reasons:

1. William Pellen knew it. He had used Unity on previous projects and was comfortable with its workflow. Switching to a different engine would have meant learning a new tool instead of making the game.

2. It could handle what they needed. Hollow Knight is a 2D game with hand-drawn art, frame-by-frame animation, precise hitboxes, and a large interconnected map. Unity could do all of this. It wasn't the best tool for any single aspect, but it was a sufficient tool for all of them.

3. It could scale. Team Cherry didn't know at the start that Hollow Knight would grow to 150+ rooms with dozens of enemy types. Unity's architecture supported that growth without requiring a ground-up rewrite.

💡 Intuition: Team Cherry's engine choice illustrates a rule that experienced developers know but beginners ignore: the best engine is the one you already know. Time spent learning a new engine is time not spent making your game. William Pellen could have learned Godot, GameMaker, or custom technology. Instead, he used the tool he knew, started making the game immediately, and shipped one of the best games of its generation.

Prototyping: Find the Fun First

Hollow Knight's development began with a Game Jam --- Ludum Dare 27 in August 2013. The theme was "10 Seconds," and Ari Gibson and William Pellen (Christopher Larkin joined later) created a small prototype called Hungry Knight. It was rough, but it established the foundational elements: a small character with a nail-like weapon, responsive melee combat, and a dark, insectoid aesthetic.

Hungry Knight was not Hollow Knight. It was a proof of concept. The art was crude. The movement was unpolished. The "game" was a single arena where enemies spawned. But it answered the most important question: is the core fun?

The answer was yes. The feel of swinging the nail --- the weight of it, the satisfying impact, the recovery time between swings --- felt right even in the jam prototype. The core mechanic worked. Everything else could be built around it.

🎮 Design Connection: Compare this to the Celeste PICO-8 prototype from Case Study 1. Different tools, different constraints, same approach: find the core mechanic, test it cheaply, and validate before investing years of development. The Hungry Knight jam game cost Ari and William 72 hours. It told them their game was worth making. That information was priceless.

The Iterative Loop

After the jam, Team Cherry entered a multi-year iterative development cycle. The pattern was consistent:

1. Build a small section (a few rooms, a new enemy, a new boss)
2. Play it repeatedly --- not once, not twice, dozens of times
3. Identify what doesn't feel right --- is the enemy's telegraph too fast? Too slow? Is the room's pacing off? Is the player's jump arc satisfying in this space?
4. Adjust until it does feel right --- sometimes this took days, sometimes weeks
5. Move to the next section

This loop is invisible in the finished game. Hollow Knight feels effortless --- like it emerged fully formed. It didn't. Every enemy behavior, every room layout, every boss phase was iterated to the point where it felt inevitable. The smoothness is the product of relentless grinding, not natural talent.

Art and Animation: Constraints by Choice

Ari Gibson drew every frame of Hollow Knight by hand. Not by choice of medium --- digital tools can automate much of this work. By choice of quality standard. Each enemy has a full set of hand-drawn animations: idle, walk, attack, telegraph, damage, death. Each boss has multiple phases with unique animations for every attack. The player character has distinct animations for walking, jumping, falling, dashing, attacking in four directions, healing, and taking damage.

This is an enormous amount of work for one artist. It's possible because of two deliberate constraints:

1. A unified art style. Everything in Hollow Knight exists in the same visual language: high-contrast black outlines, muted color palettes, hand-drawn textures, and insectoid anatomy. This consistency means Ari never had to make stylistic decisions --- only quality decisions. The "look" was established early and applied uniformly. This saved enormous time.

2. A limited character size. The Knight (the player character) is small relative to the screen. Many enemies are also small. Small characters require fewer pixels per frame of animation, which means each frame takes less time to draw. The game's aesthetic --- tiny characters in vast, detailed environments --- is not just an artistic choice. It's a production choice. It scales the art workload down to what one person can actually produce.

🛠️ Design Note: Production-aware design is a skill that most textbooks ignore and most professionals consider essential. Ari Gibson did not choose the small-character-in-vast-environment aesthetic purely because it looked good (though it does). He chose it partly because it was achievable. One artist, three and a half years, hundreds of unique animations --- the math only works if individual frames are small enough to draw efficiently. Understanding your production constraints is design.

Sound: The Unsung Layer

Christopher Larkin's soundtrack is one of the most praised aspects of Hollow Knight, and it demonstrates a principle that Chapter 30 will explore in depth: sound design is game design.

Each area of Hollow Knight has a unique musical theme that establishes mood, signals danger level, and creates a sense of place. The Forgotten Crossroads' melancholy piano tells you this is a ruined civilization. Greenpath's lush strings tell you this is a living, overgrown place. City of Tears' mournful, orchestral sweep tells you this was once grand and is now devastated.

The soundtrack was produced with a combination of live instruments (Larkin plays multiple instruments himself), digital orchestration, and ambient sound design. The live instrumentation gives the music an organic, breathing quality that synthesized scores lack.

But the critical design insight is this: Larkin composed for gameplay, not for listening. Boss fight music escalates with the fight's phases. Area themes loop seamlessly without noticeable repetition. Transition zones use ambient sound to bridge musical themes. The soundtrack is designed to be experienced while playing --- it reinforces gameplay emotion rather than competing with it.

🔗 Connection: This connects to Chapter 8 (Feedback Systems) and Chapter 30 (Sound Design). Sound is feedback. When Hollow Knight's music shifts from melancholy exploration to urgent boss combat, the player's emotional state shifts with it --- not because they're told to feel tense, but because the music makes them feel tense. Sound is one of the most powerful design tools available, and it's the one most indie developers neglect.

Scope: The Hardest Discipline

Hollow Knight's scope grew significantly during development. The original Kickstarter campaign (launched November 2014, funded December 2014 with AUD $57,000) promised a game with far fewer areas, enemies, and bosses than the final product delivered.

Team Cherry could have shipped the original scope and released a good, small Metroidvania. Instead, they kept expanding because the work was good and they could afford to (the Kickstarter and early access sales funded continued development). The final game is two to three times larger than what was promised.

This sounds like scope creep --- the villain of game development. But Team Cherry managed it through three principles:

1. Quality over quantity, always. They never added content that wasn't at the quality level of existing content. If a new area didn't meet the standard, it was cut or reworked, not shipped. This prevented the common problem of late-game content feeling rushed.

2. Modular architecture. Because the game is composed of discrete rooms and areas, new content could be added without breaking existing content. Room 151 doesn't need to know about Room 1. This architectural decision --- made early, in the engine's scene structure --- is what allowed the scope to grow safely.

3. Three people, one vision. There was no design-by-committee. Ari, William, and Christopher shared an aesthetic and design sensibility that kept the growing scope coherent. A team of 50 expanding scope like this would produce a mess. A team of 3 with unified vision produced a masterpiece.

⚠️ Common Pitfall: Do not read this case study and conclude that scope expansion is fine. Team Cherry is an extreme outlier. They are world-class at their respective crafts, they had external funding, and they spent three and a half years on the project. For your first game --- and your tenth game --- scope discipline means cutting features, not adding them. Chapter 37 covers this in detail. For now, remember: Team Cherry earned the right to expand scope by first building a tight, focused core. Start where they started, not where they finished.

What Hollow Knight Teaches Designers

1. Use What You Know

William Pellen didn't evaluate seventeen engines. He used Unity because he knew it. This saved months of learning time and let him start building immediately. For your progressive project, you're using Godot. Learn it well. Don't second-guess the choice. The engine is the means, not the end.

2. Validate the Core Early

Hungry Knight was a 72-hour proof of concept. It wasn't pretty, it wasn't polished, and it wasn't a "real" game. But it proved that the core mechanic --- the nail, the movement, the combat rhythm --- was fun. Team Cherry didn't invest years into a game whose core hadn't been tested. Neither should you.

3. Iterate Relentlessly

Every room in Hollow Knight was played hundreds of times before it shipped. Every boss fight was tuned through repeated testing. The game feels effortless because the team invested effort that the player never sees. When your game feels "not quite right," the answer is almost never "add something new." It's "keep adjusting what you have."

4. Constraints Enable Focus

Three people. Hand-drawn art. A single, unified aesthetic. Small characters. No voice acting. No procedural generation. Hollow Knight is built from constraints --- some imposed by team size, some chosen deliberately. Each constraint forced focus, and focus produced quality.

5. Sound Is Not Optional

Christopher Larkin's music elevates Hollow Knight from a great Metroidvania to an unforgettable experience. The soundtrack is not decoration. It is load-bearing. If you're building a game and planning to "add music later" --- stop. Design with sound from the beginning, or at minimum, design for sound by leaving emotional space that music can fill.

The Tool Selection Lesson

The meta-lesson of Hollow Knight is this: tool selection is not a creative act. It is a practical one.

Team Cherry didn't choose Unity because it was inspiring or cutting-edge or philosophically aligned with their vision. They chose it because it worked, William knew it, and it wouldn't get in the way. The creativity happened in the tool, not because of the tool.

Your tool is Godot. It is good enough. It will not be the reason your game succeeds or fails. Your design will.

Now go make something.