Building a hidden object pipeline

Why Unity pulled me in

Once I was working as a game developer, Unity was hard to ignore. It gave me a way to think beyond one platform and one pipeline: desktop PC, Android, iOS, fast iteration in the editor, and C# as the language tying it all together.

Hidden object games were also a perfect fit for that mindset. On the surface they look like painted scenes and calm puzzle beats. Underneath, they are production systems: layered art, searchable objects, hint logic, inventory behavior, scene state, animations, localization, and a lot of repeated setup that should not require a programmer every time.

The first Unity hidden object push

With the knowledge I had from hidden object production, I wanted to build one in Unity from the ground up. I did that with the team at BraveGiant, first as the free-to-play mobile game Hidden Investigation: Who did it?. It followed Agent Sarah through detective cases, hidden object scenes, clues, puzzles, and progression built for phones.

The real challenge was not only making scenes playable. It was making scenes repeatable. A hidden object game needs many locations, many object lists, and many small interactions. If every scene requires bespoke code, the project slows down. If the pipeline is good, content starts moving.

Building the pipeline, not just the game

The core idea was to let the art file become the start of the playable scene. I built tools and scripts that could import PSD-based scene work into Unity, preserve the useful structure, and reduce the amount of manual rebuilding needed inside the editor.

From there, ScriptableObjects became the place to keep structured gameplay data: scene definitions, object lists, puzzle settings, rewards, modes, and reusable configuration. Unity editor tooling wrapped the rough edges so designers and content builders could work through buttons, inspectors, and templates instead of asking for custom code for every tiny variation.

That is where the project became more interesting to me. The output was a game, but the product inside the product was a content machine: import the scene, configure the data, attach a known behavior, test, adjust, repeat.

Reusing the shape across projects

That approach carried into more hidden object work. At Thorium Studios, HORUS Investigation used the same kind of thinking for a mystery game with rooms, clues, hints, zooming, rewards, and mobile-friendly progression. For my own studio, Ignion Entertainment, Hidden Scrolls: Floating Watchtower pushed the formula into a fantasy setting with classic hidden object scenes, coins, hints, stars, and a bonus game structure.

The products were different, but the production pattern kept rhyming. Artists wanted their scenes to survive the trip into Unity. Designers needed knobs they could safely turn. Developers needed a way to keep the game architecture clean while still letting content move quickly.

What it taught me

This period changed how I thought about being a Unity developer. It was not enough to write gameplay code after the content was already painful to assemble. The better move was to understand the whole pipeline and remove friction where the team felt it every day.

Good tools make non-programmers more independent without removing engineering discipline. The best version is not "no code ever"; it is "code only where code is actually needed." Everything else should be data, templates, editor workflows, and clear defaults.

That lesson stuck. Whether I am building games, AR, web products, or internal systems, I still look for the same pattern: model the domain, automate the repetitive path, expose the right controls, and leave an escape hatch for the weird cases.