Despite the popularity of Portal, first-person puzzle games are a rare breed. Croteam’s philosophizing environmental Rubik’s Cube wasn’t really on our radar, but once we got our hands on the finished product we were impressed with its overall polish and somber story. To learn more about this interesting indie project we spoke with Croteam CCO and lead game designer Davor Hunski about the The Talos Principle’s origin in the Serious Sam franchise, its abundance of story text, and how the team created an A.I. program to beta test their own game.
Croteam has a history developing the Serious Sam shooter series, so Talos Principle seems like a change of pace for the company. Where did the desire to work on a philosophical puzzle game come from? Most of us in the team are very “science-logic” type people. From the dawn of computers, we enjoyed many gaming genres, especially ones that stretch our intellectual boundaries.
The first game the team ever made was a puzzle game. And actually, the jammer device in Talos was originally invented to be part of the Serious Sam 4 universe. Back then we created a series of test puzzle levels to show what complexity is appropriate and enjoyable and how long it will take players to solve them. One of our level designers, DavorT, deliberately made very complex puzzles that surpassed what would be appropriate in the Serious Sam universe, but it turned out that our teammates enjoyed these levels the most. So we started thinking what to do with that discovery and tried to brainstorm about further expanding on that field.
I heard that you guys used Lego bricks to prototype some of the levels. Can you talk about how that worked? Yes, I stole some Legos from my kids while they were sleeping, and we used them at the beginning to form labyrinths and play around with locations of elements that could make an interesting spatial formation. We used candy as a goal. Once we formed a shape of the puzzle, we used a phone to take photographs from the most exciting designs and re-created them in 3D for user testing. This process liberated us from the time-consuming 3D production pass, allowing us to quickly prototype numerous variations of the same puzzle on logic level. It was almost effortless and enjoyable to try different approaches and completely new variations for the same basic idea.
The game has a lot of puzzles. How did you make sure that none of them felt too similar?Well, by removing ones that were similar. I am kidding a bit, but we had a pass of puzzle reduction where we cut puzzles that were too easy and felt repetitive. If a puzzle didn’t introduce some new concept, then we marked it for removal. We spent quite some time fine-tuning the difficulty ramp, but we think that we finally found that sweet spot.
Some of the late-game puzzles get pretty complex. How did you playtest to ensure they were all solvable? We developed an automatic program for testing that all the puzzles are solvable. We call him “The Bot.” When any of our team members submitted a change into a database, our automatic build system takes off and creates a new build for that change. When a build is finished, Bot grabs it and starts playing the full game in the same way a player would, but in fast forward 16 to 32 times faster. If Bot is not able to solve any [part] of the puzzle or his checks discover any anomaly that is not allowed, he immediately reports a bug that is automatically assigned to the developers. This system saved us an unbelievable amount of time and gave us confidence to freely develop and risk certain implementations because we knew that hard-working robot would scream if something broke.
Can you describe a couple of the tools or mechanics that didn’t make it into the game? We discarded more than a few different mechanics that were not functioning and got rejected in the process. For example, we had a third type of mine, one that tracks you down. Also, we physically built a 3D version of the tetromino arranger out of glued wood pieces, but it was practically impossible to arrange these 3D shapes even using hands in the real world. Although we spent some time and developed some carpentry skills along the way, the idea was rejected in a matter of minutes.
The game is text-heavy. Did you ever worry that that might turn off some players? Yes, but we designed the game so that people almost don’t have to read the texts at all, or could read them in the second playthrough. Some of our internal testers just played the puzzles, skipping the story entirely. We were okay with that. We designed puzzles and game structure in general to be self-fulfilling, but it was essential that those who invest into reading and communicating with terminals dug out some real gold. When I felt that both the mechanics and story clicked, I was sure that we had created something special. The best indicator for that was how anxious our team members were for people to get to play our game.
Croteam has a history developing the Serious Sam shooter series, so Talos Principle seems like a change of pace for the company. Where did the desire to work on a philosophical puzzle game come from? Most of us in the team are very “science-logic” type people. From the dawn of computers, we enjoyed many gaming genres, especially ones that stretch our intellectual boundaries.
The first game the team ever made was a puzzle game. And actually, the jammer device in Talos was originally invented to be part of the Serious Sam 4 universe. Back then we created a series of test puzzle levels to show what complexity is appropriate and enjoyable and how long it will take players to solve them. One of our level designers, DavorT, deliberately made very complex puzzles that surpassed what would be appropriate in the Serious Sam universe, but it turned out that our teammates enjoyed these levels the most. So we started thinking what to do with that discovery and tried to brainstorm about further expanding on that field.
I heard that you guys used Lego bricks to prototype some of the levels. Can you talk about how that worked? Yes, I stole some Legos from my kids while they were sleeping, and we used them at the beginning to form labyrinths and play around with locations of elements that could make an interesting spatial formation. We used candy as a goal. Once we formed a shape of the puzzle, we used a phone to take photographs from the most exciting designs and re-created them in 3D for user testing. This process liberated us from the time-consuming 3D production pass, allowing us to quickly prototype numerous variations of the same puzzle on logic level. It was almost effortless and enjoyable to try different approaches and completely new variations for the same basic idea.
The game has a lot of puzzles. How did you make sure that none of them felt too similar?Well, by removing ones that were similar. I am kidding a bit, but we had a pass of puzzle reduction where we cut puzzles that were too easy and felt repetitive. If a puzzle didn’t introduce some new concept, then we marked it for removal. We spent quite some time fine-tuning the difficulty ramp, but we think that we finally found that sweet spot.
Some of the late-game puzzles get pretty complex. How did you playtest to ensure they were all solvable? We developed an automatic program for testing that all the puzzles are solvable. We call him “The Bot.” When any of our team members submitted a change into a database, our automatic build system takes off and creates a new build for that change. When a build is finished, Bot grabs it and starts playing the full game in the same way a player would, but in fast forward 16 to 32 times faster. If Bot is not able to solve any [part] of the puzzle or his checks discover any anomaly that is not allowed, he immediately reports a bug that is automatically assigned to the developers. This system saved us an unbelievable amount of time and gave us confidence to freely develop and risk certain implementations because we knew that hard-working robot would scream if something broke.
Can you describe a couple of the tools or mechanics that didn’t make it into the game? We discarded more than a few different mechanics that were not functioning and got rejected in the process. For example, we had a third type of mine, one that tracks you down. Also, we physically built a 3D version of the tetromino arranger out of glued wood pieces, but it was practically impossible to arrange these 3D shapes even using hands in the real world. Although we spent some time and developed some carpentry skills along the way, the idea was rejected in a matter of minutes.
The game is text-heavy. Did you ever worry that that might turn off some players? Yes, but we designed the game so that people almost don’t have to read the texts at all, or could read them in the second playthrough. Some of our internal testers just played the puzzles, skipping the story entirely. We were okay with that. We designed puzzles and game structure in general to be self-fulfilling, but it was essential that those who invest into reading and communicating with terminals dug out some real gold. When I felt that both the mechanics and story clicked, I was sure that we had created something special. The best indicator for that was how anxious our team members were for people to get to play our game.