Developing Pillars Of Eternity

tim-cain pillars-of-eternity obsidian kickstarter game-development rpg postmortem

Abstract

Problem: What was Tim Cain's role in the development of Pillars of Eternity, and what design ideas shaped — or didn't make it into — the final game?

Approach: Tim Cain shares his firsthand account of working on Pillars from the 2012 Kickstarter through the 2015 launch, covering his design contributions, programming work, and cut content.

Findings: Cain designed the Cipher and Monk classes, the crafting system, and an ambitious stronghold system — most of which were simplified due to budget constraints. He also programmed the entire combat/spell system. Several creative ideas, including Watcher-flavored ability visuals and an "Adventurer's Guild" with procedurally generated dungeons, were cut for time.

Key insight: Kickstarter funding is a double-edged sword — it forces all features to be defined before development begins and provides a fixed budget with no possibility of additional funding, requiring constant scope management.

Source: https://www.youtube.com/watch?v=su5wE2C5UWM

1. Background and Tim's Role

Tim Cain joined Obsidian in October 2011, initially working on South Park: The Stick of Truth. When Josh Sawyer and Feargus Urquhart approached him about the Pillars of Eternity Kickstarter in September 2012, he contributed early design work and appeared in pre-launch videos. He was not in a lead role on Pillars — Josh Sawyer was the lead designer, and Tim served as a side designer and programmer.

The Kickstarter asked for $1 million and hit that goal on day one. By the end of the month-long campaign, it had raised over $4 million.

2. The Kickstarter Constraint

Crowdfunding created a unique development dynamic: all features were defined as stretch goals before the game was funded. Unlike publisher-funded projects where some features can remain "TBD," everything was locked in publicly. The budget was also completely fixed — there was no "going back to the well" for more money. This meant rigorous scope management throughout development.

3. Design Contributions

3.1. The Cipher Class

The Cipher was directly inspired by the Esper class Tim had helped design for WildStar at Carbine Studios. The two classes share significant DNA.

3.2. The Monk Class

Tim designed the Monk around a compelling mechanical premise: a class powered by the damage it takes. The wound system captures this elegantly — monks accumulate wounds from damage taken, which they then spend to fuel abilities. Even if healed, the wounds remain as a spendable resource. Tim particularly valued how this mechanic explains the class fantasy: monks don't wear armor because they want to be hit. He loves when system mechanics organically justify a class's identity.

3.3. Crafting System

A straightforward design with different crafting stations for different item types — collect ingredients, visit the appropriate station, craft.

3.4. The Stronghold (Original Vision)

Tim's original stronghold design was far less abstract than what shipped. It featured buildable additions that granted passive or active bonuses, and companions assigned to the stronghold would go on quests through procedurally generated dungeons. Completing these quests fed back into the stronghold, making it bigger and better. Budget constraints led Josh Sawyer to make the system significantly more abstract.

4. Cut Content

4.1. The Adventurer's Guild

Tim designed a system for a town building where players could create custom companions using the character creation system, then run them through procedurally generated dungeons. This would let players experiment with class and race combinations and build companions specifically tailored to complement their main character. Someone described this concept as "Build-A-Bear but with bloodshed" — a description Tim loved. It was cut entirely due to lack of time for the procedural dungeon technology.

4.2. Watcher-Flavored Abilities

Tim felt the Watcher concept needed more systemic support. Rather than generic RPG abilities with a Watcher label, he wanted every basic mechanic to be expressed through the Watcher's spirit-seeing powers:

  • Find Traps: Instead of clicking a skill to highlight traps, a ghostly spirit would walk down a hallway and trigger a spectral version of the trap — both rendered in a ghost pixel shader, then fading out.
  • Secret Doors: Instead of highlighting, a ghost would walk over, pull a lever or book, open the ghost door, walk through, and vanish.

Tim had a personal rule with Josh: he would only bring up a design idea once, then drop it. He broke this rule exactly once during all of Pillars development — for the Watcher system. He still couldn't get it prioritized due to time constraints.

5. Programming Work

Tim was moved between South Park and Pillars multiple times. After the Kickstarter in September 2012 he moved to Pillars, then back to South Park in mid-2013 for bug fixing and optimization (~8-9 months), then finally returned to Pillars in March 2014 for the last year of development.

He coded the entire combat system. Internally, everything — class abilities, spells, item effects, creature attacks — was implemented as a "spell." The spell system managed initiating effects, maintaining them, and cleaning up when they ended. Status effects also went through this system since they similarly apply modifications to creatures and must eventually be removed.

This resulted in an enormous switch statement, reminiscent of what he'd heard about Baldur's Gate's implementation. He considered breaking it up but found no logical decomposition that would improve clarity — it was simply a massive list of supported status effects that needed to be executed.

6. Timeline and Aftermath

The development period from 2011 to 2016 was a continuous blur for Tim:

  • October 2011: Joins Obsidian, starts on South Park
  • September 2012: Kickstarter launches, moves to Pillars
  • Mid 2013: Moved back to South Park for bug fixing
  • March 2014: Returns to Pillars for the final year
  • March 2015: Pillars ships to great reviews; immediately moves to Tyranny
  • 2016: Tyranny ships

There was no breathing room between projects — just constant programming with occasional design work on the side.

7. References