Non Player Character

Project overview

Non Player Character was created in 48 hours for the 2023 Game Maker’s Toolkit Game Jam. The theme was “Roles Reversed.” Instead of playing as the hero exploring a dungeon, you play as the one running the dungeon: placing enemies and hazards while an AI-controlled hero attempts to fight through your layout.

I was responsible for the game’s interface and player experience: how players understand their role, how they place enemies, and how the game communicates what’s happening on screen under tight time constraints. My girlfriend handled pixel art, and two friends implemented the game systems and AI in GameMaker 1 while we collaborated through GitHub.

You can play the game here:

Play Non Player Character on itch.io

Design goals

With only a weekend to work, I focused on a few practical goals for the UI:

• Make the “role reversal” obvious immediately. Players needed to understand that they control the dungeon, not the hero, without reading a wall of text.
• Keep the placement flow fast and readable. The UI had to make it easy to see where enemies could go, what was already placed, and when the run was ready to start.
• Match the pixel art style. The interface needed to feel like part of the world, not a generic overlay dropped on top of Rachel’s art.
• Be forgiving for new players. We knew most jam judges would only spend a few minutes with the game, so the learning curve needed to be as short as possible.

Process

1. Sketching the core loop

Before touching GameMaker, I sketched the core loop on paper: choose enemies, place them in the dungeon, start the run, watch the hero attempt to clear it, then adjust the layout. This helped define the minimum UI we needed—an enemy selection area, a dungeon grid, and clear “build” and “run” states.

2. Information hierarchy

I separated the screen into three conceptual zones:

• Top: game state and simple instructions (“Build your dungeon” vs “The hero is attacking”).
• Left or bottom: enemy palette / tools for building.
• Center: the dungeon itself, with as little UI clutter as possible.

This gave players a consistent place to look for “what can I do?” versus “what is happening right now?”

3. Visual language & feedback

To support Rachel’s pixel art, I leaned into a simple, flat UI with:

• framed panels that echo the outline of the dungeon tiles,
• highlight states when hovering/placing enemies,
• subtle color shifts to distinguish build mode from action mode.

Even with limited time, I tried to ensure every action—selecting an enemy, hovering over a tile, starting the run—had a visual response so the player never felt like the game ignored their input.

Key design decisions

1. Two clear modes: Build vs Run

Mixing placement and action at the same time was confusing in early tests, so we split the experience into two clear modes. In Build mode, the UI emphasizes the enemy palette and available tiles. In Run mode, those controls recede and the focus shifts to the hero’s path and combat feedback.

2. Let the art do the worldbuilding

Rachel’s pixel art established the tone of the game—a slightly ominous, dungeon fantasy setting. I kept UI text minimal and let the sprites carry most of the personality, so players could focus on the strategy of placement instead of reading lore.

What I learned

Working on Non Player Character reinforced how much UI/UX design in games is about communication under constraints: limited screen space, limited time for players to learn, and in this case, a very limited development window.

I also gained experience collaborating quickly across disciplines—balancing the needs of art, code, and player clarity. The jam format forced me to focus on what mattered most for the experience and to let go of nice-to-have ideas that didn’t fit the weekend.