The good point here was that we could rely on game systems that were already (more or less) working, so we were able to playtest the puzzles as we were creating them.

We didn't realize this then, but now it's as clear as day: on the top of all the other problems, we were trying to create inventory puzzles with a completely unfinished UI.

Creating puzzles without being able to properly playtest them is impossible. This is something naturally assumed when dealing with combat or action situations, but it proved to be also true for our slow-paced puzzles.

Our puzzles didn't need complex dynamic systems working; they needed a nice UI, responsive controls, and clear feedback -- all features we didn't have at that time. Designing them without these was useless, and yet we weren't aware of that.

You need to see your player reacting to the puzzles and not fighting the controls or missing key information because of the UI.

Dropping our messy, work-in-progress, inventory UI from the puzzle creation process was something that, in the end, sped up development and to sooner enter the iterative loop.

The New Approach

At first, our natural impulse was to preserve the progressive complexity of the puzzles. In our previous approach, with the inventory system, our first puzzle was a simple as "use the only object you have." Next: "find an object, use it." Later "find an object, examine, and use." Find object A, use A, find object B, use A again, combine both A and B, use the new one," etc., etc.

As you can see, we were trying to follow the path of our beloved old-school graphic adventures. Even after abandoning the inventory system, we tried to preserve this progression.

Our first puzzle was an "interact", then a "go there, interact," then "interact, make noise, run, interact," etc.

But when we, the designers, playtested our new puzzles with the rest of the team, we discovered that even our simplest puzzles were challenging, obscure, and unintuitive. People didn't really get stuck, but they didn't know what they were supposed to do. They were simply playing, but everything was "grey," noisy, boring.

And the main reason for that is that the navigation and combat system were just too ambiguous.

One of key things to keep in mind while designing a puzzle is to minimize the number of variables that the player should evaluate in order find the solution -- those needed in order to make the game state evolve to the state that solves the puzzle.

The other key thing is clear feedback each time the user tries a solution, to let the player evaluate if his actions are correct or not.

If you are creating inventory-based puzzles both things are much easier to do: Either you have the item or not. Either you have tried it or not. If you try it and it's the correct item, it works. If not, it doesn't.

In a realistic game, like Deadlight, with puzzles based on the position of the player and the enemies, on their speed... the user cannot evaluate anything. Most of the game states look the same and he cannot check if he is performing the correct actions or not.  The feedback is way too subtle to be useful.

Then, we tried to simplify our puzzles even more. To make them more binary: either you do the proper action or you won't be able to progress.

However, each time we playtested a simplified version of any puzzle with the team, we realized that it didn't work. At that moment the feedback we were receiving from our publisher, Microsoft, was exactly the same.