The Door That Doesn’t Open Until Tomorrow

Sometimes a Door Is More Than a Door

Game developers spend a surprising amount of time thinking about doors.

Is it locked? Can the player open it? Does it have a key? Does it make a satisfying sound? Does it swing in the right direction?

But when you’re making a game about manipulating time, even something as ordinary as a door can become much more interesting.

Consider this:

The door is locked in the Present.

So you go looking for the key. Except there isn’t one. Then you notice something strange. The same doorway exists in the Past. And in the Past, the door isn’t locked.

Now you’ve got a puzzle.

The Obvious Solution

The first thing most players are probably going to try is traveling to the Past, walking through the open door, and continuing on their way. And that’s fine. But what if the game doesn’t let them? Maybe the player can enter the Past, but the doorway leads somewhere completely different.

Maybe the building didn’t exist yet. Maybe the room beyond the door was destroyed long ago. Or maybe the door itself is part of a mechanism that connects the Past and Present. This is where a simple mechanic can start becoming a real puzzle system.

Changing the Past

Imagine that the player enters the Past and discovers that the door isn’t actually a door at all. It’s part of a large mechanical security system. The player can’t simply walk through it. Instead, they need to activate a mechanism nearby. Doing so changes the state of the door. Then the player returns to the Present. The building is still there. The door is still there. But now something has changed.

The door is open.

The player has effectively used the Past to change the Present. That’s much more interesting than simply finding a key.

The Player Has to Understand the Connection

The important part of a puzzle like this isn’t necessarily the mechanism itself. It’s the connection between two points in time.

The player needs to realize:

Something I do here can affect something over there.

Once that idea clicks, the player starts looking at the entire environment differently. A broken machine might have been functional in the Past. A collapsed bridge might have been intact. A tree might not have existed yet. A building might have been constructed somewhere that is now an empty field. A seemingly useless object in the Present might have had a completely different purpose decades earlier.

Time becomes part of the player’s toolkit.

What Happens If the Player Changes Too Much?

This is where things can get really interesting.

Suppose the player repairs the machine in the Past. They return to the Present and discover that the machine is still there. But now something else has changed. Perhaps the repaired machine powered another system. That system opened another door. That door leads to an entirely different part of the level. The player didn’t directly open that second door. They changed something in the Past that eventually caused it to become accessible.

That’s the kind of cause-and-effect relationship that can make a time-based puzzle feel satisfying.

Not Every Change Should Be Obvious

There’s also something to be said for subtle changes.

The player could return from the Past and initially think that nothing happened. The room looks almost exactly the same. Then they notice something. A photograph on the wall is different. A clock is working. A broken light is now illuminated. A bookshelf has moved. A statue that was facing one direction is now facing another.

Nothing announces:

“YOU CHANGED THE TIMELINE!”

Instead, the player discovers it. Those moments can be much more memorable.

The Butterfly Effect

Of course, once you start allowing the player to change the Past, you have to decide how far those changes reach. If the player moves a chair in the Past, should the Present change? Probably not.

If they destroy a building, should the Present change? Probably.

But what if they move a machine? What if they repair something? What if they prevent an event from happening?

The game needs rules.

Those rules don’t necessarily have to be explained immediately to the player. In fact, discovering the rules could become part of the game.

Establishing Rules for Time

For Project Echo, one of the interesting design challenges is figuring out exactly what time manipulation means.

The player should eventually understand things like:

What can be changed?
What can’t be changed?
What persists between timelines?
What gets restored?
What objects are affected by time travel?
Can actions in the Past affect the Future?
Can the player create contradictions?
Can the player accidentally make a puzzle harder?

These questions aren’t just programming problems. They’re game-design problems. The rules of the time system become part of the rules of the world.

The Best Puzzles Make Players Feel Clever

There’s a particular moment that every puzzle designer hopes to create. The player has been staring at a problem. They’ve tried several things. Nothing works.

Then they suddenly realize:

“Wait…“

They remember something they saw earlier. They make the connection. They travel back in time. They change one small thing. Then they return.

And the impossible problem suddenly has a solution. That’s the moment worth designing for. The player shouldn’t feel like the game simply handed them the answer. They should feel like they figured it out.

A Locked Door Can Be Enough

Sometimes game developers feel pressure to make every puzzle complicated. But a good puzzle doesn’t necessarily need ten switches, three keys, and an elaborate sequence of events. Sometimes it’s just a door. The trick is making the player ask the right question.

Instead of:

“Where is the key?”

the game might encourage them to ask:

“When was this door last unlocked?”

That’s a very different question. And in a game about time, it’s exactly the kind of question we want the player to be asking.

Building the World Around the Mechanic

This is one of the reasons I’m enjoying the design process behind Project Echo. Time manipulation isn’t something that can simply be bolted onto the game at the end. If it’s going to be important, the levels need to be designed around it. The environment needs to give the player clues. Objects need meaningful histories. The Past needs to matter. The Present needs to matter.

And ideally, the player should gradually learn to think in terms of when something exists rather than simply where it exists. That’s a pretty powerful change in perspective.

Final Thought

So imagine you’re standing in front of that locked door. You’ve searched the room. You’ve checked the shelves. You’ve looked everywhere for a key.

Nothing.

Then you notice an old photograph. The photograph shows the same room. But the door is open.

And there’s something written on the back:

“Taken before the accident.”

Now you have a question.

Not: