Looking Up: Our First Game
We didn’t just build our first game — we learned how to make games by making it.
From Idea to Game: How Looking Up Came to Life
Before Looking Up became the cozy puzzle game it is today, it existed in many completely different forms. At one point, it was a game about playful monsters. Another version leaned into a witchy atmosphere. Some concepts even focused on crafting mechanics instead of puzzles. Like many first projects, we started with ideas that were exciting, ambitious, and far beyond what our team could realistically build at the time. That became our first major challenge: figuring out not only what kind of game we wanted to make, but what kind of game we were actually capable of making.
Learning While Building
Oh, did we mention this was our first game ever? We had to learn everything from scratch– and by everything we mean EVERYTHING. Nearly everyone on the team came from non-game design related backgrounds which meant we had a very broad outlook on the world, but also not much knowledge when it came to actually making a game, which meant we were learning almost everything from scratch while developing the project: game design, prototyping, production workflows, playtesting, sprint structures, engine limitations, narrative pacing, marketing, every part of the process was new territory for us. This didn’t discourage us however. We researched, documented what we learned, experimented, and built lightweight prototypes to test ideas before fully committing to them. Some puzzle concepts were tested using paper drawings and physical objects long before they ever entered Unity. Over time, the team slowly developed its own production rhythm:
weekly sprints, shared documentation, iterative prototyping, and feedback loops.
Learning How to Scope
One of the hardest lessons was scope.
Our earliest concepts were significantly larger than what a junior team could realistically produce. Through lightweight game design documents and discussions, we started learning how to identify which ideas were achievable and which were not.
That process helped us narrow the game into something more focused:
-3 environments
-3 puzzle categories
-15 puzzles total
This was a smaller scope than we first had in mind, but a more solid base ground that we could work with and achieve.
Iteration and Change
Looking Up changed constantly throughout development.
The game shifted from earlier browser-game concepts into the cozy puzzle experience it eventually became. At times, those changes were difficult because it felt like we were repeatedly abandoning previous ideas. Instead of relying only on internal opinions, we started making decisions based on playtesting, external feedback, and observation. PlaytestCloud sessions, internal testing, convention showcases, and streamer feedback all helped with the direction of the game.
Many parts of the final experience changed because of this process:
-storytelling adjustments
-puzzle redesigns
-visual reworks
-demo pacing
-the addition of a stronger ending hook
The more we tested, the more clearly we understood what the game needed.
The Question Every Team Asks
Throughout development, one question kept returning:
“Is this actually fun?”
That question is difficult to answer from inside the team itself.
The only way we could answer it properly was through repeated testing, iteration, and observation. Slowly, the game started feeling more complete. The systems connected together, the environments felt cohesive, and the puzzles began supporting the emotional tone we wanted the experience to have.
Eventually, we reached a point where Looking Up no longer felt like disconnected prototypes.
It felt like a real game.
What We Ended Up Building
The final version of Looking Up contains:
-15 puzzles
-3 unique environments
-multiple puzzle iteration cycles
-full visual redesigns based on feedback
-and most importantly, a team that learned how to make games by making one together.
For us, Looking Up was not only about building a game.
It was about learning how development works, how ideas evolve, how teams collaborate, and how iteration slowly turns uncertainty into something real.