Specter Inspector

My Roles

I worked as a level designer, and design lead. I owned encounter flow, gameplay pacing, and design cohesion across gameplay systems.

Level Designer

My goal and primary responsibility as the level designer was to ensure that the mechanics, systems, and intended gameplay of Specter Inspector were all exceptionally showcased and emphasized within the spaces where gameplay occurred.

We programmed 3 varieties of enemies? Well, then they all need to be utilized in meaningful ways that highlights their differences. We created a tool that uses consumable batteries? Well, lets make finding the batteries engaging, and put the player in interesting spots when they need to stop and load them!

Design Lead

Ensuring design cohesion & consistent progress was being made towards development was my primary responsibility as a design lead. This meant:

• Ensuring our designers had relevant and impactful tasks to complete.
• The overall direction of game design aligned with our game pillars.
• Working with the tech team to realize and match prototype gameplay into our engine.
• Support my fellow designers and teammates.

Music

I created the original soundtrack for the game. Three tracks were created, one for the main menu, one for gameplay, and the other for a now scrapped final boss, that now serves as the trailer music! Listen to the OST below:

Level Design Process

My process started with top-down concepting, conducting rapid Unity prototyping, to final polish and level integration in our custom engine!

Concepting & Top-Down Maps

In our initial early prototyping phases, I didn't plan out much level wise. I was mostly focused on getting a basic level space where we could test our mechanics and get a sense for how navigating spaces felt. There were bigger fish to fry.

But once preproduction was over, and the scope and size of the levels I had to make was defined, top-down planning and concepting served as the essential blueprint for our level spaces.

Being able to break down a level into chunks that separate scripted events, gameplay beats, and difficulty was so useful — it makes an initially daunting process much more manageable!

Testing in Unity

I learned a lot in this phase. It was a lot of playtesting, implementing new mechanics and seeing how they jived with the rest of the game, and iterating based on that feedback. For the first half of development, programmers were building our custom engine from only a handful of libraries — so while the tech team was figuring out how to make a rectangle render on screen, us designers were rapidly prototyping gameplay in Unity that we hoped would one day have functionality in our engine…

The structure of our level during initial prototyping was one long gauntlet with no checkpoints, gradually getting more difficult. However, this format led to player frustration, uneven pacing, and an overtly stressful experience. We wanted the player to feel tension — not punishment.

To fix these pacing issues, I decided to separate the game into three distinct modules:

• Inspector Training — Movement & base game tutorial, 4 screens of levels.
• E.M.F. Training — E.M.F. tool usage & simple but progressively more difficult encounter design, 10 screens of levels.
• E.M.P. Training — E.M.P. tool usage, 10 screens of levels featuring more involved, difficult, & thoughtful encounter design, climaxing in a challenging finale!

Structuring the flow this way chunked our mechanics into individual, understandable sections of gameplay that allowed us to build tension and engagement in a cohesive arc.

Refining & Polish

Before shipping the finalized tilemaps into the custom engine, I was able to polish and change most of what I needed within the Unity tile editor. This phase was mostly eliminating soft locks, streamlining flow, and making difficulty adjustments before my time was up.

A fun addition was adding skeletons and the presence of previous inspectors in the level — their colored footprints can guide players to their final resting place.

Integrating in Engine

Roughly 15 weeks into the project, the custom engine became ready for serious gameplay integration. Our programmers opted not to build editor tools, and instead went for a more direct route: serializing every UI piece, tilemap, enemy, and game asset directly from Unity into the custom engine through JSON files.

This was an engineering choice we had in mind from the start — our engine's structure intentionally matched Unity's component-based system. Why build it all from scratch when we could bring it over directly?

Unsurprisingly, serializing large chunks of tilemaps did result in some friction. Identifying broken geometry, tweaking collisions, consistently testing, and staying in constant communication with the tech team were all key to getting these levels functional in the final build.

Production Details

Scope

Custom engine built by 5 programmers. Two semesters (about 30 weeks) of development time. About 13 minutes of gameplay. Three distinct modules of gameplay.

Team Collaboration

With 3 designers and 5 programmers, we cohesively settled on the theme and concept for Specter Inspector very early in development. Us designers sorted ourselves into UX, tech design, and (for me) level design roles.

For the first half of development, programmers were building our custom engine from only a handful of libraries. This would take them roughly half of dev time to build the engine itself.

So while the tech team was figuring out how to make a rectangle render on screen, us designers were working together rapidly prototyping gameplay in Unity, that we hoped would one day have functionality in our engine…

Prototyping in Unity

Once the concept of a draggable window that you see your character and the game world through was implemented in Unity, level iteration and ideation began.

I started creating 2D tile maps, and iterating on enemy behavior, level pacing, and balancing encounter design. Some lessons were learned early on, while others took much more time and investment to make themselves known. More on this later…

Much of these early tile maps never saw the light of day in the final game, but watching players navigate through these spaces while contextualizing with our mechanics helped me define and narrow down the types of spaces that served our unique concept well!

Mazes and complicated route-finding led to player frustration, while linear but open and wide levels were easier to understand and more compelling to navigate. Because the player can only ever see a small window of the game world, finding the right balance between involved route-finding and branching paths vs. entirely linear design was one of my many challenges to solve.

Implementing Levels in a Custom Engine

Roughly 15 weeks from when the project started, the custom engine became ready for serious gameplay integration. Our programmers decided not to create editor tools for us designers to use, and opted for a more direct route in regards to integrating gameplay into the custom engine.

Instead of building it all from scratch in engine based on the prototypes us designers had been creating, we had an illuminating thought: why should we build it all anew if we can instead just bring it over directly from Unity? We would serialize every UI piece, tile map, enemy, and game asset directly from Unity into our custom engine through JSON files.

Our programmers had this in mind from the start, so the structure of our engine intentionally matched the component-based system that Unity is built like. Serializing every asset was a tedious process, which mostly fell to the purview of our producer.

Unsurprisingly, serializing large chunks of tile maps from Unity to a custom engine did result in some friction. On my part, identifying broken geometry, tweaking collisions, consistently testing, and being in constant communication with the tech team helped us get these levels functional! Getting objects properly rotated was especially difficult to nail down, and even in the final build some of the tiles were never properly rotated.

Steam Polish & Release

After academic submission, we resumed development in summer 2025 for release polish, store assets, and final platform delivery.

After Specter Inspector was officially submitted in an academic capacity, development stopped entirely. The team took about a year away from Specter Inspector to work on another academic project called Barton (which you can read more about in my projects page!). Knowing the potential Specter Inspector had, and not wanting to squander it, I rallied a few of our most dedicated teammates behind me, and we spent the summer of 2025 paving the way for a Steam release.

Final Touches

We integrated the main menu, a few UI changes, and fixed a few minor bugs. The temptation to revisit my tile maps was certainly there, and there are changes I still wish I could have made to this day. But given the limited time and capacity we had, I deemed doing any additional level polish too risky, and settled for what we had.

Release

Then it was only a matter of creating all the required Steam assets, content for the store page, and library page. Creating the trailer, and all of these assets fell to me. Tasks which I happily completed. And soon enough, Specter Inspector released to the world on August 15th, 2025.

Below is a full gameplay video of Specter Inspector. Check out the level spaces I created, and see what the experience is like!