Inspiration
We wanted to create a mystery game where the player doesn't simply follow a list of objectives, but gradually realizes that the environment itself is telling a story.
The inspiration for ECHO came from the feeling of being alone in a familiar room and suddenly noticing that something is not quite right. A telephone rings when it shouldn't. A clock changes. A chair seems to move. Ordinary objects begin connecting to something much larger.
Instead of relying on monsters or constant jump scares, we wanted to create tension through uncertainty, observation, and the player's own imagination.
What it does
ECHO is a short psychological mystery game built around environmental investigation and interconnected puzzles.
The player explores a mysterious room and discovers that seemingly ordinary objects contain pieces of the same hidden message. By investigating the telephone, tuning a radio, examining a clock, studying a painting, interacting with a chair, opening a locked box, and solving the final door mechanism, the player gradually reconstructs the sequence behind the mystery.
The clues eventually connect to the number 2817 and a recurring telephone call.
At the end, the telephone rings again, giving the player a choice: answer or leave it unanswered. The choice leads to different endings.
The game is designed so that the environment, sound, visual changes, and puzzles work together rather than functioning as separate systems.
How we built it
ECHO was built as a lightweight browser game using HTML, CSS, SVG, and JavaScript.
We created the room as an interactive SVG environment instead of using a traditional 3D engine. This allowed us to build a detailed atmospheric space while keeping the game lightweight and easy to run directly in a browser.
JavaScript handles the game's state, puzzle progression, interactions, audio events, hints, notebook clues, ending branches, and persistence.
The experience also uses:
- Interactive SVG objects
- Procedural visual effects
- Spatial camera-focus animations
- Atmospheric sound and heartbeat effects
- Progressive puzzle states
- Local save persistence
- Keyboard and mouse interaction
- A dedicated demo mode for showcasing the game
A major design principle was to make the player's actions affect the atmosphere. As more puzzles are solved, the room itself begins to feel less trustworthy.
Challenges we ran into
One of our biggest challenges was creating tension without relying on conventional horror mechanics.
Because ECHO takes place primarily inside one room, we had to make a relatively small environment feel interesting and progressively more unsettling. We solved this by giving ordinary objects different meanings as the player progresses.
Another challenge was connecting the puzzles so that they felt like one investigation rather than a collection of unrelated mini-games.
We also had to balance difficulty with the limited time available in a hackathon. A puzzle can be satisfying when a player solves it, but frustrating when the solution is technically correct and the game simply doesn't recognize it. We therefore focused heavily on forgiving interactions, clear feedback, state management, and preventing players from becoming permanently stuck.
Finally, building the entire experience as a browser-based game meant carefully managing animation, audio, SVG rendering, and game state without the structure of a full game engine.
Accomplishments that we're proud of
We are proud that we were able to turn a simple room into an entire mystery without needing a large world, combat system, or dozens of characters.
The strongest part of ECHO is the way the clues connect:
Telephone → Radio → Clock → Painting → Chair → Box → Door → Second Ring
Each discovery changes how the player interprets what came before it.
We are also proud of the atmosphere we created through relatively simple technology. The heartbeat, radio static, camera focus, changing objects, environmental disturbances, and final telephone sequence are all designed to make the player feel that the room is gradually becoming aware of them.
Most importantly, we wanted the ending to leave a question rather than simply provide an explanation. The player has to decide what to do when the telephone rings for the second time.
What we learned
We learned that creating a good game is not only about adding mechanics.
Small details can have a much larger impact when they are connected to the player's actions. A clock changing from one time to another can be more memorable than a complicated system if the player understands why that moment matters.
We also learned the importance of state management and playtesting. When multiple puzzles depend on one another, a small logic error can break the entire experience.
Most importantly, we learned to treat sound, visuals, narrative, and interaction as parts of the same system. In ECHO, the goal was not to make a puzzle, an animation, and a sound effect separately. The goal was to make them feel like one moment.
What's next for ECHO
ECHO is designed as the beginning of a larger mystery.
The next step would be to expand beyond the first room and reveal more of the world surrounding the events of Act One. Future chapters could introduce new locations, deeper investigations, additional characters, and new forms of environmental storytelling while keeping the same focus on psychological tension and interconnected clues.
We also want to expand the consequences of the player's choices. The decisions made in one chapter could change what the player discovers later, allowing different perspectives on the same mystery.
For now, however, ECHO ends where the mystery truly begins:
The phone rings a second time.
And the player has to decide whether to answer.