The Talos Principle was never supposed to happen. That it exists is a testament to developer Croteam's refusal to ignore a game that wanted to be made and devise a new, iterative way of developing. That's the story that CTO Aren Ladavac and CCO Davor Hunski told today at a GDC 2015, at a presentation that kicked off the Independent Games Summit.
The Zagreb, Croatia-based studio is best known for the Serious Sam series of shooters, which it has been creating for decades. The Talos Principle is precisely nothing like Croteam's previous games. First, it's a puzzle game. Second, it's built on a foundation of philosophy — and deeply so. One cannot exist without the other. They also couldn't exist without Serious Sam.
It began, Hunski said, with a mechanic from another game. When working on Serious Sam 4, they created the Jammer, a portable device that can disable objects like forcefields, weapons and enemies. To test it, they created a series of levels for the internal team to playtest. While doing so, they discovered that the mechanic was so fun that it could be its own thing.
"We started working on Serious Sam 4 and ended up making The Talos Principle," Hunski said.
The "philosophical first-person puzzle game," as Hunski describes it, is a product of what Ladavac calls "reactive" game development. Croteam created a game mechanism and had the foresight to understand that it inspired a game different from one they set out to make. Yet they knew what the end product would look like (a truth particularly acute for a new intellectual property).
And they also knew that, several times during the project, they would realize what they were doing was completely wrong. Croteam made peace with that. They didn't know know what they wanted until they saw it.
Why? Reactive development is not based on a plan. It's based on a prototype.
They knew they'd realize what they were doing was wrong, and need major changes. Croteam made peace with that.
Now that they were creating a completely new game, they had to figure out what was next. The obvious step was to create puzzles. At this point, the game was visually homogenous — a lot of its features looked the same. The idea at this stage was to create the structure, not to make the game look pretty, and learn what they could.
In this early stage, designers tested each other's puzzles and fixed the problems they found. That process informed the game's eventual non-linear design. Just as the developers could hop from puzzle to puzzle, so could players of The Talos Principle.
Next, they got an alpha version of the full game working, with a barebones structure and even some narrative hooks. They introduced Gates of Eternity, and the idea of adaptive narrative guidance. That godlike character plays a very important part of the game, particularly at the beginning, and it grew out of their desire to teach the game to the people they invited to play it. Croteam changed The Talos Principle that based on what they learned from the select few who were invited in.
Then came a limited, external, closed beta with local testers and the community, where they discovered even more. For example, the game was boring because it took too long to get from the first to second area. In response, they removed puzzles and shortened the game's version of Rome. That was no small feat. It required them to rework the Sigil system that unlocks progress. It took several days, and nothing short of a replacing of the game's original plan, but it was worth it. Croteam no longer had a boring beginning.
This is reactive development: First from inside, then from outside.
An E3 demo and a public test served similar purposes. Croteam's constant willingness to put the game in players' hands and listen to their feedback changed the final product. Of course, The Talos Principle's test helped raise awareness before release. But it also produced about a thousand forum posts and replies each day, which Croteam also used to inform the evolving design.
Again, this is reactive development: First from inside, then from outside, changing at every stop of the way.
The final release included improved visuals, which they see as part of a system that rewarded players for completing puzzles that Ladavac admitted could be "exhausting." They added secrets, easter eggs and hidden terminals and more. In effect, these were built-in breaks let players do anything other than solve puzzles that they knew would burn them out.
They classify The Talos Principle's philosophical narrative as "value-added" content, where the visuals and easter eggs also live. The puzzles are good on their own, they said, but the narrative elevated and changed the game. Those things like music, secrets and QR codes made the game bigger than they'd planned and created more work, but Hunski's advice to developers was that they "should be generous" with this value-added content, because it rewards players.
Those extras made the game 20-50 hours long. A fast playtester could finish it in about 10 hours, and this created problems as they continued to iterate. Their solution: Croteam created a bot to beat the game in four hours.
They built a bot that could long 15,000 hours of playtesting for them.
By the end, they could experiment, change the game, and submit the changes to testing in less than an hour. Croteam's stress tests were the equivalent, Ladavac said, of 15,000 hours of human testing, about eight years of full-day testing. Croteam is a small studio. They couldn't have done it without what Ladavac calls the "robot system," which was designed to make sure The Talos Principle didn't break.
For Hunski and Ladavac, looking back isn't entirely about celebrating their successes. Post-release, there's plenty they wish they could change, and they're as honest about their failures as their successes. They would change the ending, lessening the requirements for completing The Talos Principle. They would remove the the Axe mechanic, which wasn't used enough to justify its existence. They'd trim more puzzles. They would change the hint system, which is less clear than they think it should be. Internally, they would have been more honest about their initially "unrealistic deadline," as they described it on a slide. Knowing what they know now, they couldn't have spent time on creating a mobile companion app that very few players used.
In an effort to condense their experience and help developers, Ladavac says that others could benefit by listening to feedback, reacting based on that, iterating on a game until you're satisfied, creating tools to iterate fast and that developers should "be generous with value-added content." In short, practice reactive game development.
Would they do it again? The final bullet point on the final slide sums up the experience: "10/10, would react again :)"