Project: Ink

Overview

Project Ink is a physics-based puzzle game where players are free to draw their own path, but must manage every drop of Ink as a scarce, recyclable resource.

Inspired by the scope and simplicity of Mind Over Magnet, the concept was designed to be feasible within a small team and a constrained budget, without sacrificing depth or creative freedom.

What makes it different:

Creative Freedom: There is no single correct solution. If a drawn structure obeys physics and solves the problem, it is a valid strategy.
Strategic Resource: Creativity has a cost. The Ink System forces players to optimize their designs, balancing structural stability with resource efficiency.
Tactile Aesthetic: A “Living Sketchbook” visual style combining high-contrast readability with an organic, satisfying feel.

The Challenge

The Creative Challenge

Design a complete, feasible indie game from scratch within:

Budget and scope constraints
A core mechanic broken down with enough precision that programmers, artists, and designers could implement it without follow-up questions

The Brief

A 48-hour game design technical test requiring three deliverables:

High-Level GDD for an original indie game within a $100k budget
Low-Level GDD documenting one feature in implementation-ready detail
5-minute pitch presentation

The Result

All three deliverables completed within the 48-hour window:

High-Level GDD
Low-Level GDD
Pitch presentation delivered on camera

Technical test approved.

The Ink System

The Ink Tool is the player’s primary method of interaction with the world, enabling the real-time creation of physical geometry and the reclamation of resources.

The design intent is a core loop of Creation vs. Scarcity. By enabling freeform drawing but limiting the resource, every physics solution becomes an economic puzzle.

The player must constantly:

Assess the problem
Spend Ink to create a solution
Traverse the environment
Recycle to recover resources

The Pen: Draws freeform shapes that solidify into physical geometry. Every pixel costs Ink. The player has creative freedom, but every stroke is a calculated expense.

The Siphon: Reclaims drawn geometry, returning Ink to the gauge. The core strategy of the game: build a bridge to cross, then recycle it to solve the next puzzle.

Ink Vials: World-space collectibles that replenish fixed amounts of Ink. Designed as a designer lever to control pacing, gating, assistance, or reward depending on placement.

The Core Loop

Project Ink is structured around two interconnected loops that work together to create a complete gameplay experience.

The Macro Loop The player selects a world, enters a level, solves puzzles to collect Chromas, and restores the world’s color palette. Completing a world unlocks the path to the next region.

The Micro Loop Inside each level, the player analyzes the puzzle, draws physical structures using Ink, traverses the environment, and siphons geometry back to reclaim resources. Every loop is a cycle of creation, movement, and recycling.

Process

Every design decision starts before the first idea. The process behind Project Ink followed a structured methodology, from identifying the core problem and researching production constraints, through ideation and document construction, to final delivery. Each stage built directly on the previous one.

Each stage is detailed below.

Problem Definition

Design is fundamentally about identifying, understanding, and solving problems. Before generating any ideas, the first step was understanding what the real problem was.

The test briefing established a set of requirements, but the central problem to solve was clear: what kind of game can be designed within a $100k budget?

That budget constraint is not just a number. It defines the team size, the scope, the art style, the technology choices, and ultimately what kind of game is even possible. Every creative decision that followed was shaped by that single constraint.

The full checklist of requirements to fulfill:

Original indie game concept within a $100k budget
Feasible production scope for a small team
High-Level GDD of 2 to 3 pages, not counting images
Low-Level GDD documenting one feature in implementation-ready detail
5-minute pitch presentation
Quality and readability as the top priority. The document must be understood by anyone reading it, regardless of whether they are a game designer, programmer, or artist
Zero follow-up questions. Every decision must be explained clearly enough that no one needs to ask for clarification during implementation

Initial Ideation

The first instinct was to look at indie games as references, not AAA titles. The brief asked for an indie game, so the scope reference had to match. AAA titles could still serve as mechanical inspiration, but not as production benchmarks.

The initial ideas gravitated toward survival games. Titles like Valheim and Raft came to mind first: mechanically rich, systems-driven, and with examples of small teams achieving strong results.

But every idea came with an immediate question attached: can this be built for $100k?

That question did not discard ideas at this stage. It flagged them for the next step.

Research & Feasibility

At this point, everything was still unclear. The goal of this stage was to remove that uncertainty and find solid ground before committing to any direction.

The first attempt was external research: production budgets, development stories, team sizes. But concrete, reliable numbers are hard to find publicly, and what was available rarely provided enough certainty to confidently say a direction was within scope.

The approach that worked was combining that external research with personal experience as a player. Public information provided context, but the most actionable reference came from games already played and completed. What games had I already played firsthand that could confidently serve as a production reference within the budget?

That search led to Mind Over Magnet, a puzzle game developed by a single person, Mark Brown, over three years. The game features over 50 single-screen puzzles built entirely around one core mechanic: magnetism. No new systems are introduced throughout the game, only creative applications of the same mechanic across increasingly complex puzzles.

It checked every requirement on the checklist like:

One developer
Contained scope
Single core mechanic

The key insight was not to copy the game, but to extract a framework from it: a puzzle game defined by small, self-contained levels driven by a single core mechanic, where difficulty scales through creative application rather than additional programming. More levels, more creativity, less engineering cost.

The mechanic still needed to be defined. But the framework was clear.

Consolidation

Before returning to ideation, the goal was to take a step back and assess what had been established so far.

At this point, two things were clear:

Scope Framework:

Puzzle game structure
Small, self-contained levels
Single core mechanic
Difficulty scales through creative application, not additional engineering

Production Reference:

Mind Over Magnet as a strong parameter for what could be achievable within the budget and team size constraints

Focused Ideation

With the framework defined, the focus shifted to finding the right mechanic.

The reference point was personal: games already played and completed. Portal 1 and 2, The Talos Principle 1 and 2, Chants of Sennaar, Island of Insight.

The goal was not to copy any of them. The goal was to find something different.

The turning point came from an unexpected direction: years of working in animation. Not from drawing skill, but from a creative memory.

Classic Disney behind-the-scenes footage showing the Nine Old Men at their light tables, pencil on paper, creating physical marks that became living characters. Some examples:

“The Story of the Animated Drawing” (1955, Disneyland TV series)
“Tricks of Our Trade” (Disneyland TV series)
“Waking Sleeping Beauty” (2009 documentary)

The question became: what if that physical act of creation was the core mechanic of the game?

That thought led to Q Remastered, a game built entirely around freeform drawing. It became the mechanical reference point. But Q Remastered is purely about drawing, with no additional constraint or strategy layer.

The question became: what can be added to make it different?

The first instinct was a platformer in the style of Crash Bandicoot with drawing abilities. But that expanded the scope beyond the framework. The solution was to strip it back: drawing within the Mind Over Magnet framework. One level, one drawing mechanic, get from point A to point B. Each level is essentially a single screen. The player has the tool. The challenge is figuring out how to use it.

That was the mechanic.

Document Structure

The test provided no internal structure for the documents, only the requirement to deliver a High GDD and a Low GDD. Defining the structure was part of the challenge.

The approach was to combine references from previous game design and level design documents into a structure that served the specific needs of this project. The organizing principle was simple: every section answers a specific question.

High GDD structure:

What is the game? (Executive Summary)
How does it work? (Core Gameplay and Mechanics)
What does it look and sound like? (Art and Audio Direction)
How long will it take to build? (Production Timeline)

Low GDD structure:

What is the feature and why does it exist? (Feature Overview)
How does it work in detail? (Logical Flow and Behavior)
What are the limits and exceptions? (Constraints and Edge Cases)
What does the designer need to balance it? (Exposed Tuning Parameters)
What needs to be considered alongside the design? (State Machine, Inputs, and UI/UX)

The result was a custom structure, built by combining references from previous game design and level design documents into a format that served the specific needs of this project.

With the structure defined, the document was written iteratively. Throughout the process, the checklist from Problem Definition served as a constant reference point, with one question guiding every decision: is this solving the problem that was established?

The most significant iteration happened earlier, during ideation. The concept evolved from a platformer in the style of classic Mario or Crash Bandicoot with drawing abilities, to a focused puzzle game where each level is a single screen and the player goes from point A to point B. That shift was the critical design decision that brought the concept within scope and made everything else possible.

By the time the document was being written, the idea was stable. The iteration was in the clarity of communication, not in the concept itself.

Pitch & Delivery

With 48 hours as the hard deadline, something had to give. The visual presentation was that trade-off.

The pitch used a simple template designed to evoke the aesthetic of the game, a drawing ink style, without investing significant time in visual production. The focus was on communicating the three USPs clearly and confidently: Creative Freedom, Strategic Resource, and Tactile Aesthetic.

The priority was always content over presentation. A visually polished pitch with weak design reasoning is less valuable than a clear, well-argued case for why the game works. That was the bet made, and it was a conscious one.

Key Design Decisions

Decision 01: 100% Siphon Refund Rate

The Siphon returns 100% of spent Ink with no penalty.

A reduced refund rate was considered to add risk to every stroke, but rejected for one core reason: penalizing the refund discourages experimentation and punishes creative thinking, which is the central fantasy of the game.

Difficulty progression is handled through other levers instead:

Reducing the total Ink available per level
Introducing environmental constraints
Adding mechanics that force the player to rethink familiar solutions in new contexts

The refund rate stays untouched because creativity should never feel like a mistake.

Decision 02: Two Separate Control Modes

Movement and drawing are split into two distinct input contexts: Traversal Mode and Drafting Mode. While drawing, the character anchors in place. While moving, the drawing cursor is inactive.

This decision was made because Project Ink is not a game about testing player skill or reflexes. It is about testing creativity and problem-solving. Separating the two modes removes the pressure of platforming dexterity while the player is thinking, allowing full focus on the puzzle at hand.

The trade-off is a real constraint on level design:

Elements that rely on timing or skill, such as drawing while avoiding hazards, are incompatible with this system
Levels that combine movement pressure with drawing decisions become significantly harder to implement
The design space is narrower, but the creative space for the player is wider

The compromise was considered acceptable because the game’s core promise is creative freedom, not mechanical challenge.

Decision 03: Ink Vials as a Design Lever

Ink Vials are not just resource pickups. They are a balancing and guidance tool built directly into the level geometry.

The core idea is that every level has an expected Ink consumption range. A player who finds an optimal solution might spend 50% of their starting Ink. A beginner solving the same puzzle might need 125%. Vials bridge that gap without changing the difficulty of the puzzle itself.

This creates two distinct uses for the same mechanic:

Guidance: Placing a Vial near an easier but less optimal path gives the beginner the resources to complete it, while the experienced player ignores it entirely
Gating: Placing a Vial behind a challenge forces the player to spend resources first to earn more, creating a risk and reward loop that shapes how the level is explored

The trade-off is that Vial placement requires the designer to anticipate multiple solution paths for every puzzle. A misplaced Vial can either trivialize a challenge or create a soft-lock. Placement is never arbitrary.

Production Roadmap

Project Ink was scoped for 8 months and $100k. The timeline was structured around a single core principle: get the foundation right before scaling content.

The reasoning is straightforward. Project Ink has a small number of systems, but those systems are technically complex. Once the Pen, Siphon, and physics interactions are proven and stable, the rest of the game is essentially a level design problem. No new programming is required, only creative application of what already exists. Scaling 40+ puzzle levels becomes a design task, not a technical one, which is significantly faster and cheaper to execute.

This logic shaped the timeline directly:

Months 1-2: Prototyping. Prove technical viability of the core systems in a greybox environment. This phase carries the highest risk and receives the most time relative to its output.
Months 3-4: Vertical Slice. Finalize art direction and deliver a fully functional game loop. This is the quality benchmark that all future content must match.
Months 5-7: Production. Scale to 40+ puzzle levels, implement audio, and introduce advanced mechanics such as Variable Gravity. The foundation is stable, so the focus shifts entirely to creative output.
Month 8: Polish and Launch. Bug fixing, performance optimization, and Steam deployment.

Art & Audio Direction

The visual style is Monochrome Cutout. The entire world renders in Graphite Black and Paper White, with Cyan Blue reserved exclusively for the player’s Ink mechanics. This creates instant visual hierarchy while keeping art production costs low through modular 2D assets.

Audio follows the same philosophy of tactile simplicity. Sound design uses Foley feedback to ground the abstract visuals in a physical reality, and characters communicate through Gibberish and Instrumental Emotes, eliminating localization costs entirely.

Reflection

Finding the Concept

Looking back, the early stage was harder than it needed to be because ideation and problem definition were happening simultaneously. Trying to generate ideas while still figuring out the constraints created confusion rather than clarity. The cleaner approach would have been to fully define the problem first, clear the mind of any preconceptions, and only then let ideas emerge with a real filter already in place. The process got there eventually, but sequencing those two steps more deliberately from the start would have saved time and reduced noise.

The Reference Point

The turning point was Mind Over Magnet, a puzzle game built by a single developer that I completed in a few hours. It became a strong reference point: a small team, a focused mechanic, a contained scope. From that reference point, the direction for Project Ink became clear.

What the Document Was Missing

The document covers the systems correctly, but it does not explain how I got there. Looking back, quality and readability go beyond clarity of writing.

A truly complete document makes the reasoning visible:

How the problem was defined
Why one direction was chosen over another
What alternatives were considered and rejected

That visibility benefits everyone reading it:

A programmer understands not just what to build, but why certain constraints exist
An artist understands the intent behind the visual direction
A fellow designer can challenge or build on the reasoning rather than just executing it blindly

What This Page Is

This page exists to fill what the document was missing:

The Process section documents the methodology behind the concept, from problem definition to final delivery
The Key Design Decisions section makes the reasoning behind specific design choices visible, including the alternatives that were considered and rejected

Given More Time

If I had more time, I would have invested in stronger visual communication: diagrams, flowcharts, and a more developed art direction mockup. With 48 hours, content took priority over presentation. That is a trade-off I would make again, but one I would close given more time.

The Game Design Document

The following document contains the complete technical deliverables submitted for the design test: the High-Level GDD covering the full game concept, systems, art direction, and production roadmap, and the Low-Level GDD specifying the Ink Tool in implementation-ready detail, including logic, physics, edge cases, exposed parameters, and UX specifications.