Pinku Swargiary
GAME DESIGNER
M.DES DIGITAL GAME DESIGN · NID BANGALORE
B.E. COMPUTER SCIENCE · EX-SOFTWARE ENGINEER
GAMEPLAY, LEVEL DESIGN & RAPID PROTOTYPING
Showreel
BATTERY
GDD SHOWREEL // GBA II
TUNINGVOL (BROKEN)
Awards & acknowledgement.
XR Creator Hackathon - Finalist
WAVES 2025 · Create in India Challenge · Ministry of I&B
Xbox Discovery Day
Gummy's Summit featured as part of the showcase event
Most Distinguished Paper Award
IPDIMS 2022, NIT Rourkela · Springer/Elsevier · Hand-Held Mango Cutting Tool
Unity Open-Source Contribution
Chop Chop · Identified and resolved an audio-preference persistence bug
Jungle Guardian Jungle GuardianXR Hackathon
Aquapoint AquapointSerious Game
Fallen Calf Fallen CalfFolklore Narrative & Companion Puzzle Game
Sunlit Grove Sunlit GroveRes-Management
Re-Imagining Water Cycle Re-Imagining Water CycleSerious Game
A Particle A ParticleZen
Obsolete ObsoleteCo-op Action
Gummy's Summit Gummy's SummitPuzzle Game
More Coming More ComingArchiving In Progress
More in cooking
New projects & design docs coming soon!
PROJECT DOSSIER // 2025
FINALIST · XR CREATOR CHALLENGE
Jungle Guardian
Jungle Guardian
Overview
Jungle Guardian is a jungle-themed educational AR game for children, built in Unity using AR Foundation for Android. Children draw animals and characters on paper, scan their drawings with the phone camera, and watch their sketches come to life as 3D characters in augmented reality, which then enter a living story about the jungle ecosystem. Built as a hackathon entry for the XR Creator Challenge at WAVES 2025 (Create in India, Ministry of Information & Broadcasting), advancing to Round 2 of 2 with a working XR prototype.
Platform: Android Engine: Unity 6 (AR Foundation) Type: AR / Educational Audience: Children (ages 6–10) Team: Pinku Swargiary, Suhas Dhanrale, Manish Kumar Sethi Context: Hackathon, XR Creator Challenge, WAVES 2025
Gameplay Demo
The Central Idea
The design question was: how do you make a child genuinely care about a jungle ecosystem? The answer was ownership. If a child draws the animal themselves, studies its shape, puts pencil to paper, and then watches it come to life in AR and step into a story, the connection is immediate and personal. The mechanic and the learning are the same thing.
Drawing an animal requires the child to observe it closely. The AR feedback rewards the effort. The narrative gives the animal a role in a living ecosystem, not as a fact to be memorised but as a character with a purpose. For example, a bunny that is hungry or a deer that is threatened. Each new animal the child draws becomes part of an unfolding story about balance, interdependence, and what happens when that balance is disrupted.
The problem the game was designed around: there are few creative mediums that combine storytelling, hands-on making, and environmental awareness in a single experience. AR enables a form of play that physical books and passive apps cannot. The child’s own drawing becomes the trigger for the story.
Mechanics & Systems
Screen Flow & Core Interaction Loop
The full sequence of screens from launch to the game world:
- Start Screen - Language selection (Hindi / English) sets the voice-over narration language for the session. A bear avatar mascot is present throughout the experience as the child’s guide.
- Progression Map - A circular arc UI displays the story nodes as character/element bubbles. Completed nodes are visible; upcoming nodes are locked. The background changes to reflect the current story context: lush and green when the jungle is thriving, barren and dry when the narrative is at a point of ecological stress. The active node shows the current drawing prompt (e.g. Let’s Draw: Bunny Hop, Let’s Draw: A Tree).
- Onboarding (first session) - A 3-step instruction screen: grab drawing materials, draw what you see on screen, scan your drawing to bring it to life.
- Draw Screen - The reference drawing is displayed alongside a step-by-step drawing guide. The bear avatar speaks contextual narration explaining what the character is and how it contributes to the ecosystem (e.g. “Trees give us air to breathe and provide homes for animals.”). The child draws on paper.
- Bring to Life - The child taps Bring to Life. The camera opens, and when the drawing surface is detected, the 3D character is spawned.
- AR Appearance - A character appears in AR over the paper. The bear avatar is visible in the corner.
- Add to Jungle - The child taps Add to Jungle. The character transitions from the AR view into the game world scene.
- Level Scene - A jungle environment. The bear avatar continues narration. The story progresses and the next drawing prompt is queued.
After the narrative beat resolves in the level scene, a character unlock prompt appears (e.g. Level 2: Rabbit, Let’s Draw), sending the player back to the draw screen for the next character. The loop repeats for each story node until the narrative completes.
Drawing Recognition System
In the current build, when the child taps Bring to Life and points the camera at their drawing, AR Foundation’s plane detection identifies the flat surface (the drawing paper) and spawns the 3D character on it.
Verifying the drawing against the reference before spawning, building tolerance for varied styles, and giving accuracy-based feedback are design intentions for a future iteration.
Narrative & Progression
The prototype follows a single linear narrative. Each drawing prompt is triggered by the story’s next event: a new character appears because the ecosystem needs them at that moment. The sequence below is the example narrative used in the prototype:
- Rabbit goes in search of food, drinks from a river, hears danger
- A deer is threatened. Rhino is drawn to intervene.
- Grasses grow. Zebra joins the jungle.
- Taller growth brings Giraffe. A new threat arrives. Tiger is drawn to drive it away.
- The giraffe needs taller plants. Tall plants are drawn; Monkey takes up home there.
- Night falls. Draw Moon or Sun as the scene shifts.
Each character has a reason to be there rooted in the story. The narrative is linear in the current build.
Characters
The prototype uses available Unity asset characters. The broader concept envisions an expanded cast spanning the kinds of animals, birds, and insects children encounter in school curriculum, but this remains a design proposal rather than a built feature.
Progression
Each drawing advances the story, unlocking the next character prompt and keeping the player moving through the narrative. The circular arc progression map tracks this journey visually: completed nodes show how far the story has come, locked ones mark what is still ahead.
Design Intent & Pedagogy
Jungle Guardian is designed for children as its primary audience. The learning goals are direct:
- Drawing skills - motor development through guided, reference-based drawing practice
- Animal knowledge - familiarity with common animals, birds, and insects through repeated drawing and narrative encounter
- Ecosystem understanding - basic concepts of jungle balance, interdependence, and how species support each other
- Environmental awareness - awareness of challenges the jungle faces, explored through the narrative
The pedagogical mechanism is ownership through making and consequence. A child who has drawn a rhino, watched it appear in AR, and seen it step into a story where it matters has a different relationship to that animal than one who read about it. The drawing is not a gateway to the content, it is the content. Making the character, and then watching it exist and act in a world that needs it, is the learning.
The bear avatar and voice-over narration deliver this educational content throughout. Before each drawing, the avatar explains what the character is and how it fits into the ecosystem, so the child hears the ecological context before they draw. Language can be selected at the start (currently Hindi and English), making the experience accessible across language contexts without changing the mechanics. The game is designed to be played independently by children without an adult mediating the content.
Process
Research and Ideation
The team began by identifying a gap in the children’s educational app space: existing AR tools either lacked ecosystem themes (Khan Academy Kids, QuiverVision) or lacked drawing and motor skill development. No product combined AR interaction, guided drawing, ecosystem storytelling, and environmental awareness in a single experience for younger audiences.
The hackathon context pushed the team toward a technically ambitious AR mechanic early. The drawing-to-AR pipeline became the central concept: a child’s physical drawing as the input that triggers a digital output.
Development and Testing
Built in Unity using AR Foundation for Android. Additional tools used across the project: Adobe Photoshop, Adobe Illustrator, Adobe Firefly (asset generation), Figma (UI), Notion (project management).
A working prototype was developed and tested during the hackathon, demonstrating the full core loop: reference on screen, draw on paper, surface detected, 3D character appears in AR, Add to Jungle, character enters the level scene. Feedback during the build led to refinements in the scanning UI and the plane detection setup.
Playtest & Findings
Testing during the hackathon was primarily functional: the priority was getting the core loop working end-to-end within the competition window. The team tested the draw-to-AR pipeline iteratively as it was built, identifying friction points in the scanning UI and plane detection setup and refining both before submission.
The key finding from functional testing: plane detection on varied drawing surfaces (different paper types, lighting conditions, angles) was inconsistent enough to require explicit guidance to the user. This led to the onboarding screen’s instruction to place the drawing on a flat, well-lit surface, and to the camera UI making it clearer when a surface had been detected before the character spawned.
Formal playtesting with the target audience children aged 6–10 was not possible within the hackathon timeline. That is the most important next step: observing whether children can navigate the draw-scan-add loop independently, how they respond to the AR moment, and whether the narrative holds their attention across multiple drawing prompts.
Reflections
The core mechanic held up well. Watching a sketch become a 3D character in AR, appearing on the notebook and then stepping into the jungle world, was the emotional anchor of the experience.
Drawing recognition is the next technical challenge. The current build uses plane detection to place the character on the drawing surface. The intended behaviour, verifying the drawing against the reference before spawning and adjusting for varied skill levels, would make the experience significantly more engaging and is the most meaningful technical step forward.
The narrative carries more potential. The linear story structure works, but each character’s ecological role could be more explicitly connected to the world state. A system where what you draw has visible, cascading effects on the jungle is where the concept is pointing.
A more systemic game is the interesting version. Right now progression is linear and the jungle changes as a backdrop. A richer design would connect each drawing to a living ecosystem state: animals that interact, a jungle that responds, consequences that are visible and felt. That kind of reward system, where drawing the right character at the right moment actually matters, is the direction worth pursuing as a future scope.
Media
| Asset | File | Status |
|---|---|---|
| Cover image | /gdd/jungle-guardian/media/cover.png | ⏳ needed |
| Achievement banner | /gdd/jungle-guardian/media/achievement-banner.png | ✅ added |
| Start screen, language selection | /gdd/jungle-guardian/media/screen-start.png | ⏳ needed |
| Progression map, circular arc UI | /gdd/jungle-guardian/media/screen-progression-map.png | ⏳ needed |
| Onboarding 3-step screen | /gdd/jungle-guardian/media/screen-onboarding.png | ⏳ needed |
| Draw screen with avatar narration (1) | /gdd/jungle-guardian/media/screen-draw.png | ⏳ needed |
| Draw screen with avatar narration (2) | /gdd/jungle-guardian/media/screen-draw-2.png | ⏳ needed |
| AR scan, 3D character over drawing | /gdd/jungle-guardian/media/screen-ar-scan.png | ⏳ needed |
| Add to Jungle transition | /gdd/jungle-guardian/media/screen-add-to-jungle.png | ⏳ needed |
| Character unlock prompt card | /gdd/jungle-guardian/media/screen-unlock-prompt.png | ⏳ needed |
| Character entering level with sparkle | /gdd/jungle-guardian/media/screen-sparkle-entry.png | ⏳ needed |
| Prototype demo image 1 | /gdd/jungle-guardian/media/prototype-1.png | ⏳ needed |
| Prototype demo image 2 | /gdd/jungle-guardian/media/prototype-2.png | ⏳ needed |
| Prototype demo image 3 | /gdd/jungle-guardian/media/prototype-3.png | ⏳ needed |
| App demo video | https://youtu.be/hboTAXS6TBg | ✅ done |
| Prototype demo video | https://youtu.be/hboTAXS6TBg | ✅ done |
PROJECT DOSSIER // 2025
Aquapoint
Aquapoint
Overview
Aquapoint is a resource management serious game about water body ecosystem management. The game takes a stance from the start: there is no single correct path. Players succeed or fail based on the consequences of their choices within a living ecosystem – not by following a prescribed solution.
Platform: PC
Engine: Unity
Type: Serious Game / Educational
Team: Pinku Swargiary, Tara Dhurba, Spandan Biswas Context: Academic, 4th Semester, NID Bangalore
Gameplay Demo
The Central Idea
The design challenge was to make water conservation feel consequential without being didactic. Most educational games about the environment tell you what to do. Aquapoint works differently: it gives players agency over a water body ecosystem and lets the consequences teach.
The central design principle, that lake conservation must be ecosystem-centric, not human-centric, emerged from studying how Bengaluru’s lakes have been degraded over time: not just by neglect, but by well-intentioned development and beautification projects that treated the lake as a visual or utility resource rather than a living system. Research and observation pointed to a key idea: a lake functions as an interconnected system, where actions that ignore these relationships can create new problems even when solving existing ones.
That principle is structurally embedded in the game. Players cannot win by optimising for a single metric. Infrastructure that improves water quantity may damage biodiversity. Clearing forest for a treatment plant solves one problem and creates another. The game rewards the player who learns to balance competing demands across the ecosystem, not the one who finds a single optimal sequence.
Mechanics & Systems
Core Loop
- Environment Assessment. Review current ecosystem state: Water Health, Water Volume, Biodiversity, and active objectives
- Browse and Place Objects. Select from three categories (Infrastructure, Ecology, Operations) and place on the hexagonal tile map
- Ecosystem Update. Every placement immediately updates the three core metrics and can trigger warnings or fail states
Core Metrics
Three interconnected global variables representing ecosystem health, all dynamic, all affected by every action:
- Water Health: purity and drinkability
- Water Quantity: physical volume in reservoirs and aquifers
- Biodiversity: ecological balance of the area
Level Design & Placement System
The world is built on a hexagonal tile system. Each tile has a type that determines what can be placed on it, and every placement ripples outward, affecting neighbouring tiles and the global ecosystem metrics simultaneously. Space is a resource in itself: tiles are limited, every action competes for the same real estate, and the wrong placement in the wrong spot can cascade in ways that aren’t immediately visible.
Tile types:
- Shoreline: boundary tiles where land meets water; key placement zones for filtration and buffer ecology
- General: open land available for most placements
- Water Body: open water tiles; only aquatic or water-specific objects can be placed here
- Forest Occupied: tiles with existing vegetation; must be cleared before most infrastructure can be placed
- Concrete: already-developed tiles; limits what ecology objects can be planted
Some objects don’t occupy space; they remove it. Cutting trees clears a Forest tile and opens it for new placements, but that clearing itself is a consequence the ecosystem registers.
Objects fall into three categories:
- Infrastructure: dams, pipes, treatment plants
- Ecology: vegetation, wildlife corridors, natural filters
- Operations: extraction, monitoring, intervention
Warning & Failure System
Ignoring a warning (e.g. “Algae rising”) doesn’t pause the game: it escalates. Unaddressed warnings trigger disaster scenarios: Floods, Algal Blooms, ending the run. The risk is real and compounding.
Information Card System
When specific thresholds are crossed (wins or losses), the game surfaces real-world fact cards. Losing to an algal bloom surfaces content on eutrophication and hypoxic conditions. Placing a shallow aquifer triggers information on groundwater recharge. The learning is embedded in consequence, not instruction.
Win / Fail Conditions
- Win: Complete all objectives while keeping all three metrics within healthy target ranges
- Fail (Warning): First threshold crossed; warning issued
- Fail (Disaster): Second threshold crossed; disaster state triggered, run ends
Progression System
Note: The current prototype demonstrates the core placement and ecosystem simulation loop. The progression architecture below represents the full designed system, what the game is built toward.
Progression is objective-driven and level-based. Every level has a defined set of objectives; tiles are finite and every action has consequences that carry into future levels. The system is designed along two axes simultaneously.
Horizontal progression: breadth across levels
Each new level introduces a new water context and higher system complexity. Mechanics and tools expand from basic cleanup to policy and structural interventions, while threats escalate from sewage and encroachment to industrial waste, invasive species, and drought.
Vertical progression: depth within levels
Each level also increases in systemic complexity across four tiers:
- Tier 1: Surface complexity. Single-variable objectives (Water Quality only). Minimal cascading consequences. The system introduces itself.
- Tier 2: Multi-system interaction. Actions influence Water Quantity and Quality simultaneously. Soft failure states (warnings, early imbalances) become possible.
- Tier 3: Systemic interdependence. Biodiversity, hydrology, land-use, and public response feed into each other. Mistakes from a previous level carry over as changed conditions in the next.
- Tier 4: Full ecosystem management. Every action has short and long-term effects. Balancing environmental, social, and resource constraints simultaneously is required to succeed.
Design Intent & Pedagogy
Aquapoint is designed around player exploration. The game gives players a deteriorating ecosystem, a set of tools, and the freedom to discover, through their own decisions, how the system responds. Basic controls are introduced at the start, but the learning happens in play.
Learning through consequence. When a run ends in an algal bloom, the game surfaces a real-world information card about eutrophication. The player has just lived through the consequence; the information arrives at the moment it is most meaningful. Ecological concepts are introduced this way throughout: tied to thresholds, events, and outcomes rather than presented upfront as instruction.
Open solution space. The game is designed with multiple viable paths to success. Real ecological management involves trade-offs, uncertainty, and unintended consequences, and the mechanics reflect that. Players are encouraged to experiment, and different strategies will produce different results in the same ecosystem.
Ecosystem-centric design. The game is built on a core framing that emerged from research: the lake is a system to be understood, not a resource to be optimised. Metrics are interdependent, actions have cross-system consequences, and spatial decisions, what goes where on the tile map, carry ecological weight.
Real concepts, embedded in play. The ecological concepts the game teaches (eutrophication, groundwater recharge, algal blooms, dissolved oxygen, exotic vs. native species, shoreline integrity, desilting) were drawn directly from interviews and secondary research on Bengaluru’s lake systems. Each one is mechanically represented: placing an object on a shoreline tile affects water quality in a way that models real filtration dynamics. The game is an abstraction of a real ecological system.
The intended audience is older students and young adults in educational or civic contexts: workshops, environmental studies programmes, awareness events.
Process
Ideation
The brief was to design a serious game around a chosen domain. The team picked lake ecosystems, specifically the challenge of conservation and awareness around water bodies in Bengaluru. Three distinct concepts were explored before converging on a direction.
The first was a digital card game with resource management mechanics: cards representing ecosystem interventions that players combine to affect the lake’s state.
The second concept was an interactive discovery tool: a zoomed-out view of a lake ecosystem where players could add or subtract elements and observe knock-on effects by zooming in. No strategy required, no right or wrong way to play, just exploratory cause and effect. Inspired loosely by Grow Island’s state-combination logic. This version was conceived for a younger audience (ages 8–14, museum context).
The third concept, and the one that became Aquapoint, was a management game where players inherit a dying water body and work to revive it. Unlike the discovery tool, this version required strategy: decisions have consequences, and the ecosystem can fail.
Reference Games
Two games were studied closely as design references:
Terra Nil (ecosystem builder) was valuable for how it trusts the player: no heavy instruction, no forced context. Player exploration is the primary mode of understanding.
Frostpunk (society builder) showed how storytelling can happen entirely through UI and events, and how choices affecting metrics in conflicting ways creates genuine tension without explicit moralizing.
Primary Research
The team prepared a structured questionnaire and conducted interviews with birdwatchers and local observers familiar with the lake ecosystem.
Key findings from those conversations:
- Lakes are not isolated; they are hydrologically connected to other water bodies and groundwater systems.
- All lake development, maintenance, and conservation must be ecosystem-centric, not human-centric. This became the foundational design principle.
- Specific concepts the expert flagged as important: desilting, shoreline integrity, exotic vs. native species, the consequences of beautification projects, algal bloom dynamics and dissolved oxygen levels, Raja Kaluve drainage channels, and eutrophication.
- Their direct suggestion: keep gameplay simple, and use it to teach these concepts through experience rather than explanation.
Secondary Research
Much of the game’s mechanics are drawn directly from the real-world challenges documented around Bengaluru’s lakes. Waterbodies here have historically supported complex ecosystems: algae and aquatic plants produce oxygen and form the base of aquatic food chains. But those ecosystems have been disrupted over time by unchecked urbanisation, sewage and wastewater pollution, encroachment, and mismanaged beautification projects. Many lakes now suffer collapsed or severely weakened ecosystems, and traditional livelihoods tied to them, fishing and local agriculture, have declined as a result.
By rooting mechanics in these dynamics (pollution, groundwater depletion, ecosystem collapse, human pressure), the gameplay models real ecological tension: balancing water quality, water quantity, and biodiversity against development demands and waste mismanagement.
Source: A to Z Guide to Bengaluru’s Lakes, Mongabay India
Playtest & Findings
The game went through three build iterations, each shaped by feedback.
Iteration 1
The first playable had the core placement system and tile system implemented. Playtesting revealed significant readability problems: players struggled to parse the tile map and understand what was happening in the UI.
Iteration 2
Visuals were overhauled: scale was adjusted and the colour palette reworked to increase clarity. Effects and transitions were added to improve game feel. The content scope was also narrowed, with fewer items, tighter focus on the core concepts. Assets and UI were rebuilt from the feedback.
Final Iteration
The final round of changes addressed how the game communicates without over-explaining:
- Visual feedback on placement: a +/− popup appears near each item when placed, showing at a glance how it affects each metric.
- Ambiguous instructions: the game deliberately withholds detailed guidance to encourage player exploration and discovery.
- Numbers removed from metric UI: replacing numerical values with visual indicators prevents players from min-maxing and keeps attention on cause and consequence rather than optimization.
- Pre-failstate feedback: additional warning signals added earlier in the escalation chain so players have more time to respond before disaster strikes.
- Failstate loop: when a disaster is triggered, an information popup surfaces the relevant real-world concept before the run restarts.
Reflections
The prototype proves the core loop works. But there are several things I’d approach differently if the project continued.
Add a narrative layer. Objectives are currently given as directives: the player is told what to fix. That works mechanically, but it keeps the player at arm’s length from the ecosystem. A light storytelling layer (even just contextual events, a voiceover, or a character whose livelihood depends on the lake) would make objectives feel motivated rather than prescribed. Frostpunk’s event-driven storytelling is the reference here: the player understands why something matters because they see it through someone’s experience, not through a task list.
Push the systemic depth further. The three-metric model was always intended to produce longer consequence chains, where a decision made early in a run surfaces as a problem several turns later, not immediately. That’s closer to how real ecological damage actually works: slow, delayed, non-obvious. The prototype demonstrates the system exists; what remains to be tested is whether those delayed consequences land the way they were designed to. That’s something I’m genuinely curious to explore in the next build.
Media
| Asset | File | Status |
|---|---|---|
| Cover image | cover.png | ✅ done |
| Gameplay screenshot | gameplay-01.png | ✅ done |
| Core loop diagram | core-loop.png | ✅ done |
| Metric dashboard / UI | metrics-ui.png | ✅ done |
| Tile map with cell types | tilemap-celltypes.png | ✅ done |
| Warning state in action | warning-state.webm | ⏳ needed |
| Failure screen | failure-screen.png | ✅ done |
| Information card example | info-card.png | ✅ done |
| Progression diagram | progression-diagram.png | ✅ done |
| Ideation sketch, cards | ideation-sketch-cards.png | ✅ done |
| Ideation sketch, discovery | ideation-sketch-discovery.png | ✅ done |
| Ideation sketch, management | ideation-sketch-management.png | ✅ done |
| Reference game screenshots | reference-games.png | ✅ done |
| Playtest iteration 1 | playtest-iteration-1.png | ✅ done |
| Playtest iteration 2 | playtest-iteration-2.png | ✅ done |
| Final UI and feedback | final-ui-feedback.png | ✅ done |
PROJECT DOSSIER // 2026
Fallen Calf
Fallen Calf
Overview
📌 Note: This page is a condensed portfolio summary of the Fallen Calf Master of Design thesis. It distills the thesis’s research foundations, cultural design approach, companion AI architecture, and selected playable systems.
Fallen Calf is a top-down folklore narrative puzzle game set in a fantasy village inspired by the oral traditions, material craft, and everyday life of a Boro community in Assam. The game explores how living cultural practices form the structural architecture of gameplay, weaving traditional craft and social ethics directly into its interactive systems.
The player controls Jormay, a former mahout working as a village carpenter, accompanied by the Forest Ranger, a government field operative. What begins as a tracking mission evolves into a meditative journey centered on attunement, care, and collective community labor.
Platform: PC
Engine: Unity
Type: Folklore Narrative & Companion Puzzle Game
Team: Pinku Swargiary (Solo Project)
Context: M.Des Thesis, NID Bangalore, 2026
Central Idea
Fallen Calf investigates structural cultural design: deriving its narrative, visual language, interactive mechanics, and companion logic from the oral folklore, material craft, and community life of a Boro village.
The game centers on coexistence and shared labor, integrating cultural practices directly into its interactive architecture. Player agency is expressed through meditative, way-of-life spatial puzzles like repairing community structures, directing wetland water channels, weaving ceremonial textiles, and coordinating two-person harvesting tasks alongside an autonomous companion.
Background Research & Context
Core Design Problem
Translating regional cultural heritage into interactive media presents an ongoing design challenge: ensuring that interactive mechanics, narrative framing, and visual presentation feel naturally aligned with the living practices of a community. Fallen Calf explores this challenge by investigating how Boro oral traditions, material craft such as carpentry and handloom weaving, and practices of mutual aid and shared labour, including saori, can inform mechanics and companion dynamics, creating a cohesive, culturally grounded interactive experience.
The Research Gap
A review of culturally grounded games and companion design reveals two connected gaps in interactive media:
- The Limitation of Cultural Representation: Games increasingly represent cultures beyond dominant Western settings, but smaller communities are often absent or represented through generalized regional imagery. Cultural elements may also be applied as surface dressing over generic loops, what MacLeod (2024) terms “spicy” design. Never Alone (2014) and When Rivers Were Trails (2019) demonstrate that cultural logic can shape a game’s structure, while Venba (2023) and Raji: An Ancient Epic (2020) show the value of regionally specific material. However, this research identified no narrative game structurally grounded in Boro community life or Northeast Indian cultural knowledge.
- The Limitation of Companion Systems: Companions typically function either as tools directed by the player or as reactive narrative characters. Less explored is the co-equal traveler: an autonomous presence that shares the player’s movement, witnessing, and interpretation of the world.
- The Intersecting Opportunity: Fallen Calf addresses both gaps through a story-first design grounded in Boro oral tradition, material craft, and shared labor. The Ranger participates as a cooperative co-traveler, while cultural references inform the game’s world and mechanics. This frames the design problem as an exploration of how culture can become part of a game’s architecture.
Project Objectives
- To design a narrative game where cultural identity grounds the world, story, and presentation system: Ensuring that the game world, narrative, and presentation system emerge from the cultural logic of the Boro community of Northeast India (specifically its oral folklore tradition and handloom craft). Each mechanic is designed to serve the story’s thematic concerns, grounded in the world and narrative that precede it.
- To design a companion system where the accompanying character plays alongside the player: The companion in Fallen Calf is a simple, readable AI character whose behaviour is cooperative: physically present during gameplay moments, active in co-play mechanics, and present as a character whose perspective shifts across the journey.
- To develop a playable prototype demonstrating both design contributions: Producing a functional Unity prototype that instantiates the cultural-structural design approach and the companion co-play system in playable form.
Research Questions
- RQ1 (Cultural Design): How can the cultural identity of a specific community (its oral tradition, material objects, and ways of relating to the non-human world) be used as the structural foundation of a narrative game’s world, story, and presentation system?
- RQ2 (Companion Design): What design approaches produce a companion who feels like a co-traveler sharing the player’s journey?
- RQ3 (Design Sequence): How does beginning from narrative and cultural worldbuilding shape design outcomes, and how does this design sequence affect the player experience compared to mechanical-first design?
Theoretical Framework: Procedural Rhetoric & Cultural Integration
When designing a game drawing from a specific real-world community, a central challenge is deciding where cultural material can meaningfully inform interactive systems while allowing each system to serve its own narrative and play function. MacLeod’s (2024) framework on cultural integration provides a useful vocabulary for thinking about this relationship through three levels of representation:
- Odorless: Games designed to be culturally neutral.
- Spicy: Games using cultural elements primarily as surface dressing or cosmetic ornament.
- Fragrant: Games where cultural logic is deeply embedded into interactive mechanics, audio, and narrative structure.
This spectrum is considered alongside Ian Bogost’s (2007) concept of procedural rhetoric, which describes how games communicate ideas through the rules and processes players enact. In Fallen Calf, these theories help map different degrees of cultural influence across the game’s systems. The dialogue system, companion behaviours, and individual puzzle systems were developed for narrative, interaction, and readability needs. Some draw closely from practices such as shared labour and handloom rhythm, while others support spatial reasoning, pacing, or progression. Together, these layers form a culturally grounded design in which cultural references, narrative intention, and game function remain connected at different levels.
Precedent Study I: Culture-Based Games
Fallen Calf builds upon insights from precedent games that translate cultural, emotional, and spatial material into play:
| Game Precedent | Key Cultural & Structural Design Insight |
|---|---|
| Never Alone (2014) | Structural Translation & Co-Production: Developed with Iñupiat community elders, translating traditional relational stories into cooperative mechanics where cultural elders retain editorial authority. |
| When Rivers Were Trails (2019) | Indigenous Authorship: Demonstrates insider perspective and cultural refusal, anchoring narrative choices in lived community identity. |
| Venba (2023) | Cultural Core Mechanic: Takes a specific daily practice (cooking authentic South Indian recipes) as an interactive metaphor for cultural recovery and memory restoration. |
| Florence (2018) | Tactical Emotion: Uses micro-puzzles (jigsaw assembly, speech bubble alignment) to communicate changing emotional states and interpersonal dynamics without words. |
| Melatonin (2022) | Abstracted Cultural Rhythms: Translates everyday contemporary life into rhythm, color, and repeated visual patterns. |
| Disco Elysium (2019) | Culture as Systems of Thought: Embeds social history, political memory, and ideological discourse into dialogue trees and interior psychological mechanics. |
| Journey (2012) | Non-Verbal Pilgrimage: Communicates spiritual journey, shared presence, and non-verbal companionship through landscape movement and minimal sound. |
| Carto (2020) | Geography as Interaction: Connects community relationships and cultural identity directly to map manipulation and spatial navigation. |
| Wytchwood (2021) | Folkloric Quest Structure: Translates storybook fairy-tale logic and symbolic material gathering into episodic quest loops. |
Precedent Study II: AI Companion-Based Games & Academic Frameworks
Companion design in Fallen Calf addresses the academic framework established by Emmerich et al. (2018) and expanded by Bouquet et al. (2021), focusing on five core traits: appearance, behavior, emotions, personality, and significance to the player.
Markus et al. (2024) and Lundstrom (2024) describe effective companion autonomy through meaningful co-agency: the companion’s ability to participate while preserving player agency.
Precedent Breakdown: Companion Models
- God of War (2018): Atreus balances narrative weight with mechanical utility (arrow firing, translation), showing how companion growth can drive primary dramatic focus.
- The Last of Us (2013): Ellie anchors relational protection and emotional investment without requiring explicit player commands.
- A Plague Tale: Innocence (2019): Hugo establishes caretaking as the primary verb of companion interaction through physical fragility.
- BioShock Infinite (2013): Elizabeth realizes self-sufficient autonomy, supplying resources and opening tear points while respecting player control.
- Planet of Lana (2023): Mui sustains emotional attachment entirely through non-verbal gesture, proximity, and behavioural responsiveness.
- The Last Guardian (2016): Trico inverts player authority; as an autonomous creature, the player must observe, wait, and adapt to Trico’s pace.
Worldbuilding, Cultural Logic & Structural Representation
The setting of Fallen Calf is a fictional fantasy village inspired by Boro community life in Assam. It is shaped as a selective, story-driven interpretation of cultural knowledge. Set in an unnamed village within a timeless folklore era, the world operates across two interwoven layers:
- The Everyday Layer: The practical, working life of the village (bamboo joinery, thatch granaries, wetland channels, and carpenter workshops where physical structures require continuous care and repair).
- The Mythic Layer: A subtle world of sky herds, river spirits, and environmental wisps that exists alongside village life as part of its local oral tradition.
The worldbuilding follows a soft-worldbuilding approach: cultural research provides a field of materials, practices, relationships, and stories, while the narrative determines which elements enter the game. These elements serve different roles across the experience. Some become mechanics, some establish the social and material context of the village, and others shape the presentation and atmosphere of the world.
Jormay’s work as a carpenter informs the spatial repair puzzles. Shared labour and community cooperation inform the two-person activities and the wider movement of the story; saori, understood as voluntary reciprocal community labour, is one reference point within this broader network of mutual support. The handloom provides the framing structure for chapter transitions, while details such as bamboo joinery, wetland fish traps (jakoi), and loom shuttles give the world specific material texture. The design selects details where they can carry narrative, mechanical, or atmospheric weight.
Visual Aesthetic & Moodboard
The visual direction of the game targets warm, stylized environments with a folkloric or fairytale-like register, defined by soft, illustrated handpainted textures. This tonal target is drawn from contemporary children’s book illustration.
The references below are drawn directly from Boro village, handloom textile traditions, and local daily activities.
Narrative Design & Core Themes
📖 Narrative Setup (Without Spoilers):
In an unnamed folklore village among Assam’s riverine wetlands, Jormay, a former mahout who now works as a carpenter, repairs storm-damaged communal structures. When environmental disturbances affect the surrounding marshes, the Ranger, a government field operative equipped with tracking tools, arrives to investigate.The two characters investigate the disturbances across the village and its surrounding wetlands. The narrative follows their changing relationship, the community’s response to the Calf, and the shift from a capture-oriented task toward cooperation and care.
Mechanics & Systems
The interaction framework deploys five core mechanics, balancing unilateral solo repair tasks (establishing Jormay’s carpenter agency) with two-agent companion coordination (expressing community attunement and shared labor):
1. Placement Puzzle (Carpentry Repair)
A grid-based covering system derived from carpentry labor. The player repairs broken fences, wall supports, and granary structures damaged during early events.
- Grid Logic: Each cell holds an integer repair state from 0 (Missing/Broken) to 4 (Complete/Repaired).
- Token Placement: Players pick wood, bamboo, or thatch tokens from an inventory tray and place them on target cells.
- Propagation & Decay: Placed tokens add their power value to the target cell and propagate to adjacent footprint neighbors with a distance-decay factor.
- Budget Constraints: Placements are limited by a move budget or point budget per puzzle.
- Visual Feedback: Cell states visually reflect material repair stages (bare frame, cross-supports, woven bamboo fill, solid planking).
Reference
Initial Prototype
Current Implementation
2. Toggle Puzzle (Wetland Flow & Escort Traversal)
Adapts Lights Out state-switching logic into a spatial pathmaking and companion escort puzzle across flooded terrain.
- Stone Throwing: The player throws stones from their current tile to target distant grid cells within Manhattan-distance reach.
- State Flipping: Striking a tile reverses the walkability state (flipping between Blocked and Open) for the target and adjacent neighbors.
- Companion Trailing Constraint: The Ranger companion trails step-for-step exactly one tile behind Jormay.
- Dual-Character Pathfinding: Because the Ranger steps onto the tile Jormay just vacated, the player must plan routes that remain continuously walkable and safe for both characters simultaneously.
Reference
Initial Prototype
💡 Design Pivot: Initial testing revealed severe usability friction: top-down camera height and dense grass models visually obscured cell boundaries and character feet. Shifting the setting to open water with flat 2D lily pad stepping stones restored immediate spatial legibility.
Current Implementation
3. Wisp Hunt (Sensory Perception & Pincer Tracking)
A two-agent spatial pursuit where Jormay and the Ranger work together to herd and collect autonomous environmental wisps.
- Two-Agent Pincer: Trapping a wisp requires positioning Jormay and the Ranger on opposite sides of the target (forming a flanking angle of at least 130°) and holding the position for a short duration.
- Stance Control: The player manually toggles the Ranger between a Flanking stance (stalking to block escape routes) and a Hiding stance (retreating to cover to reduce wisp alertness).
- Behavioral Phases: Wisps cycle through Quiet (feeding at energy pools), Alert (expanding warning rings that punish hasty approaches), and Panic (fleeing).
- Pool Energy Management: Players siphon energy from stable pools and deposit it into active feeding pools to sustain the capture window.
Reference
The concept originated from rural livestock management: catching stray cattle in rice fields requires two people approaching from opposite arcs to close escape paths.
Initial Prototype
Current Implementation
4. Rhythm Crossing System
Built on attuning to an external tempo, inverting the companion dynamic by positioning the Ranger as the leader and the player as the follower across two expressions:
- In-Game Hazard Traversal (Root Bridge Crossing): The Ranger leads across living root bridges over rising waters to composed musical beats. Synchronized taps execute sure-footed leaps; mistimed inputs trigger stumbles.
- Inter-Chapter Framing (Loom Shuttle): The same rhythm-matching cadence governs the handloom shuttle interface at chapter boundaries, linking narrative transitions to the physical rhythm of manual weaving.
- Authority Inversion: Unlike solo or escort mechanics, the score and companion dictate the pace, requiring the player to read and match an existing pulse.
Reference
The rhythm system draws on physical cadences associated with Boro daily life, including the back-and-forth of the handloom reed, the cadence of the rice-husking pedal, and the shared timing of communal labour. Each scene asks the player to join a pulse already in progress. The system is fully realized in the bridge crossing, while the same rhythm-matching structure also governs the handloom weaving sequence.
Initial Prototype
Current Implementation
5. Catching Lotus (Two-Agent Coordination)
Inspired by traditional Boro communal wetland fishing (jakoi), where tasks physically require multiple people.
- Shared Net Mechanics: Jormay (left bank) and the Ranger (right bank) hold opposing ends of a harvesting net across a drifting river channel.
- Dynamic Net Tension: Moving apart stretches the net to cover a wider harvesting span, while drawing close narrows the net to let drifting river hazards pass safely.
- Dynamic Visual Feedback: The player reads net states organically through line color, sag, and tension without cluttering the screen with UI meters.
- Spatial Negotiation: The player reads the Ranger’s autonomous movement along the opposite bank and continuously adjusts Jormay’s positioning to maintain optimal net width.
Real-World Reference
Current Implementation (Prototype)
The mechanic has been prototyped and visually explored, but is not yet fully integrated or polished within the main game build. Its interaction model and presentation remain subject to further implementation and refinement.
Companion Architecture: The Ranger
The Ranger is designed around a Co-Traveler Model: a continuous companion whose role changes across traversal, cooperative tasks, and guided movement. This structure gives the character a persistent social presence while reserving more active forms of cooperation for specific gameplay moments.
1. Co-Traveling Baseline
During exploration, the Ranger follows Jormay’s movement, maintains proximity, and contributes contextual dialogue. This baseline establishes the companion as a continuing presence in the world while keeping the player’s movement and attention primary.
2. Cooperative Task Configurations
At selected gameplay moments, the Ranger becomes an active participant in configurations that rely on spatial coordination:
-
Toggle Escort Traversal: The Ranger follows one tile behind Jormay as the player opens a path through the flooded terrain. Because each movement changes the available position for both characters, the player must plan a route that remains safe and traversable for the pair.
-
Wisp Hunt: The Ranger autonomously positions himself to block one escape route while Jormay approaches from another angle. The player reads the Ranger’s position and can signal him to hide, making the companion’s behaviour part of the puzzle.
-
Catching Lotus: Jormay and the Ranger operate opposite ends of a shared net, with the player adjusting Jormay’s position in response to the Ranger’s movement. This mechanic has been prototyped and visually explored, but is not yet fully integrated or polished in the main game build.
-
Rhythm Crossing, Role Inversion: The Ranger leads across the hazardous bridge, and the player follows his movement and timing. The player joins a pulse established by the companion, creating a cooperative task in which mechanical authority temporarily shifts from player-led coordination to companion-led pacing.
Across these configurations, the Ranger’s role shifts from following during escort traversal, to coordinating during shared tasks, to leading during rhythm crossing. His movement remains readable and responsive, supporting both exploration and higher-tension mechanics.
Level Design & Progression Framework
Session Flow
The intended session flow connects narrative presentation with interactive exploration:
- The Handloom Interface: The player begins at an interactive Boro handloom. Operating the shuttle advances story milestones along the vertical fell line (the boundary where unwoven warp threads meet finished woven textile).
- Illustrated Storybook Transitions: Completing a textile section shifts camera perspective, aligning with the woven pattern to transition into the world map via watercolor mask reveals.
- Exploration & Puzzle Scenes: The player explores top-down village environments, interacting with structures, wetlands, and villagers while solving spatial puzzles alongside the Ranger.
- Chapter Resolution: Resolving chapter objectives returns the player to the handloom interface, reinforcing craft as the unifying container of the journey.
Reference
Initial Prototype
Current Implementation
Level Progression & Map Flow
Placement Puzzle Progression
The placement puzzle scales the same repair logic across different structures, including fences, granaries, and bridge elements. Larger footprints and changing spatial constraints increase the planning demand while keeping the core interaction consistent.
Toggle Puzzle Progression
Wisp Hunt Progression
Reflection & Key Design Learnings
The design of Fallen Calf developed through story revision, focused prototypes, and repeated checks against the intended player experience. The current build and prototype work support the following provisional observations. They describe the project’s present design position, while the complete eight-chapter experience and external validation remain unfinished.
- Story verbs provide the point of cultural connection: In the current design, cultural material enters through the world logic and the actions the story requires, such as repairing, tracking, tending, and weaving. The underlying puzzle systems can remain familiar game structures; their cultural grounding comes from their narrative motivation, setting, and relationships.
- Companion presence is being explored through coordination: The Ranger’s co-traveler role is tested through three structures: shared-object coupling in Catching Lotus, pincer positioning in Wisp Hunt, and companion-led pacing in Rhythm Crossing. These prototypes provide different ways to study how the player reads and coordinates with the Ranger’s behaviour.
- Story-first design has shaped both compatibility and constraint: Beginning with narrative and cultural worldbuilding has helped connect mechanics to the story’s logic, through actions such as repair, tracking, and tending. It has also narrowed the design space by giving priority to mechanics with a clear narrative motivation, resulting in a smaller set of systems that carry several functions at once.
- Cultural scope requires selection and responsibility: The world uses a limited set of researched details, including carpentry, handloom weaving, wetland work, and shared labour. The original folklore narrative and selective worldbuilding form a specific interpretation of Boro community life. The current work documents that interpretation; broader validation with Boro community members and cultural practitioners remains to be undertaken.
Key Takeaway: The project followed a clear design sequence: mapping cultural domains, writing a story within the tradition’s narrative logic, identifying its core verbs, deriving suitable mechanics and presentation structures, and selecting world details according to narrative need. Focused prototyping then assessed how those choices functioned in play, while further validation remains part of the project’s future scope.
PROJECT DOSSIER // 2024
Sunlit Grove
Sunlit Grove
Overview
Sunlit Grove is a first-person resource management and restoration game set in a solarpunk world where sustainable energy systems have failed after a sudden disaster. The player takes on the role of an assistant engineer tasked with bringing power back online by rebuilding solar, wind, and hydropower systems through mining, crafting, and machine repair.
Platform: PC
Engine: Unreal Engine
Perspective: First-person
Type: Serious Game / Systems Design
Context: Academic, NID Bangalore
Gameplay Demo
The Central Idea
Most resource management games are played from above. You look down at a factory or a city, watch numbers move, and make decisions through menus. Sunlit Grove asks what that same system feels like when you are inside it, at eye level, walking between machines and carrying resources by hand.
The solarpunk framing is recovery-focused. The player restores systems within one interconnected environment. Solar, wind, and hydropower share the same resource loop: mining supplies materials, raises pressure on the forest, and trees contribute resources in return.
Core Fantasy
Restore a broken sustainable ecosystem by physically interacting with interconnected energy systems.
Mechanics & Systems
Core Loop
The player activates resource production, collects materials, converts them into parts, and repairs machines to progressively restore energy systems.
Resource Production
Mining nodes generate one resource type over time. Each miner has a fixed mining rate and a limited active duration, so the player has to return, reactivate, and rotate between nodes. This gives the world a sense of pace without relying on a global timer.
Resource Collection
The player manually collects resources from miner output. Collection is limited per interaction (for example, two units per pickup), and the player carries resources via an inventory system. The friction is intentional: it forces the player to plan routes and make trips rather than hoarding everything in one go.
Crafting
A builder station converts raw resources into finished parts. A simple example: 3 Silicon becomes 1 Solar Panel Part. The UI surfaces available resources and recipe requirements, but does not lead the player through the sequence. Deciding what to build next is part of the gameplay.
Machine Repair
Machines need specific crafted parts to be repaired. A repaired machine unlocks the next step in restoration, connecting the crafting layer to the energy layer.
Energy Restoration
Three restoration paths exist in the world: solar, wind, and hydropower. Each has its own requirements and can only be activated once the machines feeding into it are online. Restoring a path is the closest thing the game has to a “win condition” for a given system, but the three paths are not equivalent. They require different resource chains and different spatial journeys.
Level Design & Spatial Thinking
The level design of Sunlit Grove is built to communicate gameplay systems through spatial organization and visual cues.
System-Based Layout
The level is structured around functional clusters that reflect the gameplay loop: Miner → Collector → Builder These elements are positioned in proximity to:
- Establish a clear interaction sequence
- Reinforce system relationships through space
- Support fast, repeatable gameplay loops
Functional Clusters
Systems are grouped by function in space. A miner, its collector, and the builder that consumes its output are placed close together. There is still travel friction between clusters, but grouping reduced enough of it that the relationships between systems became visible before the player read any text.
Cables as Signifiers
Early playtests revealed that players did not always understand which lever controlled which machine. Objects that were functionally linked looked visually separate. Introducing cables as visual connectors resolved this without adding UI. The environment itself became the communication layer.
First-Person Composition
Layouts were initially planned top-down and felt fine on paper. At eye level they often broke down: key interactables were hidden, paths were ambiguous, and scale felt wrong. Redesigning from the first-person camera, rather than translating a top-down plan into 3D, made interactables readable and movement natural.
This reframed level design for me. It is not object placement. It is a tool for directing attention and behaviour.
Assets
The assets were all created in blender
Reflections
The project shifted my understanding of resource management games from a system-centric view to a player-centric, spatial one. I began the project designing systems in isolation, defining mining, crafting, and restoration as discrete subsystems with clean dependencies between them. What playtesting revealed is that a working system does not automatically produce a meaningful experience. Clarity, feedback, and spatial arrangement had a stronger impact on whether players understood what was happening than the underlying system design specially in first person play.
What worked
The core loop functioned end to end. Systems connected correctly and the player could, in principle, progress from mining through to energy restoration without intervention. Spatial grouping improved how players read the environment, though travel friction between clusters remains a problem worth solving. Functional clustering made relationships between systems legible. Cables replaced what would otherwise have been tooltip text. The first-person perspective turned out to be a genuine design constraint rather than a stylistic choice, one that forced clearer layouts and more deliberate object placement.
What didn’t land as intended
The loop is linear. Most tasks follow a predictable optimal path, and the player is rarely asked to prioritise or choose. There is no system pressure: actions can be completed sequentially without consequence, and the world does not push back. Trade-offs between systems exist in theory (mining impacts trees) but are too weak to register as decisions. The environment does not dynamically respond to player behaviour, so the experience stays at task execution rather than developing into system management under constraints.
What I’d explore next
- System pressure: time-based mechanics, resource decay, machine degradation, something that makes doing nothing a losing strategy
- Stronger trade-offs: actions that benefit one system should meaningfully hurt another, so that the player has to choose rather than execute
- Spatial decision-making: greater distances between systems, multiple routes, scenarios where movement and planning become part of the strategy
- World reactivity: visible environmental changes, systems that evolve based on player behaviour, so the world communicates its own state back to the player
Design takeaways
- Clarity is more important than complexity
- Player experience emerges from interaction, not from system design alone
- Spatial layout shapes how players read and navigate systems
- Visual communication reduces cognitive load more reliably than any UI popup
- Feedback is the mechanism through which players understand systems
A system becomes engaging only when the player is required to think, choose, and adapt within it. The current build establishes the groundwork.
Media
| Asset | File | Status |
|---|---|---|
| Cover image | cover.png | ✅ done |
| Core loop diagram | core-loop.png | ✅ done |
| System dependency diagram | system-dependency.png | ✅ done |
| Decision loop diagram | decision-loop.png | ✅ done |
| Ecosystem interaction diagram | ecosystem-interaction.png | ✅ done |
| Level flow | level-flow.png | ✅ done |
| Moodboard / visual style | moodboard.png | ⏳ needed |
| Gameplay video | https://youtu.be/pXbO0b47roE | ✅ done |
| Gameplay screenshot, exterior | gameplay-exterior.png | ⏳ needed |
| Gameplay screenshot, mining | gameplay-mining.png | ⏳ needed |
| Gameplay screenshot, crafting | gameplay-crafting.png | ⏳ needed |
| Gameplay screenshot, restoration | gameplay-restoration.png | ⏳ needed |
PROJECT DOSSIER // 2023
Re-Imagining Water Cycle
Re-Imagining Water Cycle
Overview
Re-Imagining Water Cycle is a physical board game designed to represent the journey toward making water universally accessible. Players navigate a water droplet piece along a river-shaped path toward the centre of the board, encountering obstacle blocks that represent real-world barriers to water access, each concealing a corresponding solution or policy response on the other side. Designed and built during a two-week open elective at NID Bangalore in December 2023.
Platform: Physical Board Game Type: Serious Game Team: Darshan, Neel, Pankhuri, Pinku, Ritvik Context: Open Elective, NID Bangalore, December 2023
Gameplay Demo
The Central Idea
The game was designed around a single question: why does water, which falls freely from the sky and flows through the land, remain inaccessible to so many people? The answer is not geography or scarcity. It is the systems, policies, and social structures that sit between water and the people who need it.
The board is a river. The player’s piece is a water droplet. The goal is to reach the centre, a point that represents universal access. But the path is blocked.
Most obstacles can be navigated through: they represent problems that have been at least partially addressed by law, policy, or civic initiative. Crossing an obstacle reveals the solution beneath it, surfacing the real-world response that exists. The game’s structure argues that these solutions exist and have made progress, but they are not enough on their own.
The final obstacle is different. It cannot be navigated through. The caste system, as the game frames it, is not a problem with a card on the other side. It is a structural barrier that must be physically removed from the board entirely before universal water access becomes possible. The mechanic makes the argument that policy alone cannot resolve this: the barrier itself has to go.
Mechanics & Systems
Board and Movement
The path players navigate is shaped as a river, running from the outside of the board toward the centre. The destination at the centre is labelled Social Democracy: Universal Access of Water, Free of Social Barriers. The board itself is a richly illustrated isometric landscape: agricultural fields and water infrastructure on one side, a dense urban city on the other, a coastal sea at the edge, a rural settlement and industrial zones in between. The river path winds through all of it. The world the water droplet travels through is not abstract; it is a cross-section of the real conditions that shape who gets water and who does not. The player piece is a water droplet shape. Movement is along the river path, from obstacle to obstacle.
Obstacle Blocks
Seven obstacle blocks are placed along the river path, plus the final Caste System block at the centre. Each block has the problem name on top. When a player crosses it, the government’s policy response is revealed printed on the board beneath the block’s position. The solutions are what the government has done or attempted.
| # | Obstacle | Solution revealed beneath |
|---|---|---|
| 1 | Denial of Access | Article 15: Prohibition of discrimination on grounds of religion, race, caste, sex or place of birth |
| 2 | Limited Ownership of Land | Article 23: prohibition of traffic in human beings and forced labour |
| 3 | Vulnerability to Climate Change | Jal Jeevan Mission: Water Relief and Water Supply Programmes |
| 4 | Discrimination in Employment | Reservation in Employment |
| 5 | Privatization of Water Resources | Government Water Schemes |
| 6 | Caste-Based Ghettoization | Urban Planning and Development |
| 7 | Caste-Based Occupations | PEMS Act: Prohibition of Employment as Manual Scavengers and their Rehabilitation Act, 2013 |
| x | Caste System | No solution. The block must be physically removed from the board. |
Cards
Separate from the obstacle mechanic, 8 “Pick Card” spots are marked at points along the river path. When a player lands on one, they pick a card and read it. The cards are reading material encountered during the journey: documented real-world cases that show how water access barriers play out in practice.
The 8 cards cover:
- Water as a site of caste violence (Mahad Satyagrah, Irayur village)
- Untouchability in everyday life (Indra Meghwal, Karnataka school)
- Land, labour and caste (agricultural land ownership, bonded labour)
- Climate change and caste (aquifer depletion, Mathnaa village)
- Employment and media exclusion (reservation policy, affinity bias)
- Privatisation and the water-caste nexus (Bangalore water access)
- Settlement, disaster and discrimination (Nepal floods, relief distribution)
- Manual scavenging and invisibilisation (PEMS Act, deaths in 2023)
The Final Challenge
The final obstacle, positioned at the centre of the board, represents the caste system. Unlike every other block on the path, it cannot be crossed by navigating through it. The only way past is to physically remove or unplug the block entirely.
This is the game’s central mechanical argument: systemic barriers of this kind are not problems with solutions on the other side. They are structural. The only resolution is removal.
Design Intent & Pedagogy
The game is intended to provoke thought and reflection. The obstacle-reveal structure surfaces real policies and initiatives; it acknowledges that progress has been made. But the final obstacle reframes the whole board: progress on individual problems does not resolve a systemic one.
The core learning is structural. Players leave the game having navigated seven real barriers to water access and discovered that each has at least a partial response, and then encountered one that does not. The sequence is deliberate: the game builds a sense of possibility before confronting a limit that policies alone cannot cross.
The physical format is part of the design. The act of physically removing the final block, rather than clicking past it or reading about it, is the point. The medium carries the message.
Process
Research and Brainstorming
The process began with open research and group brainstorming to map every possible barrier to water access: untouchability, social segregation, absence of sanitation facilities, exclusion from water management, inequitable distribution, climate vulnerability, caste-based occupation and ghettoisation, denial of access, privatisation of water resources, discrimination in employment, religious discrimination, and more. The list was then narrowed to the seven obstacles most legible within the game’s format, plus the final structural barrier.
Paper Prototype
The first playable was built quickly on paper: yellow card blocks with obstacle names, sketched river path, and a water droplet. The goal label at the centre read “Social Democracy.” This version was used to test the layout, the obstacle sequence, the reveal mechanic, and whether the movement felt like a river journey.
Map Illustration
The board surface was designed as a full illustrated isometric map: agricultural land, a rural settlement, an urban city, a coastal sea, and industrial zones all rendered in the same landscape. The river path was planned first as a rough overlay on the initial illustrated concept, then refined into the final art. The map makes the stakes of the game visible: the journey passes through every kind of environment where the water access problem plays out.
Board Building
The physical board was fabricated on MDF. The river path was routed as a groove into the board surface defining the track.
Card Making
The 8 cards were hand-fabricated from kraft board, laser-cut to size and printed with a decorative pattern.
Playthrough and Reactions
Reflections
The moment that confirmed the design worked was when players reached the caste block. Most tried to push or slide it the way they had crossed every obstacle before. When it didn’t move, some paused; a few asked if it was stuck. The realisation, whenever it came, landed the same way: the whole board suddenly read differently. The mechanic didn’t need explaining. The physical resistance communicated the argument on its own.
The research process was as much a learning experience for the team as the game is intended to be for players. Mapping the connections between caste, water access, land ownership, and climate vulnerability surfaced things that are rarely discussed together, even though they operate as a single system. Designing the game required understanding it first, and that understanding shifted how we thought about the subject.
With more time, the tactile experience of the board could have been more refined. The water droplet sliding along the path, the action of moving an obstacle, the physical feel of the journey, these interactions were functional but not fully considered as UX. A stronger version would make the physicality itself more deliberate.
Media
| Asset | File | Status |
|---|---|---|
| Cover / hero board photograph | /gdd/re-imagining-water-cycle/media/cover.png | ⏳ needed |
| Full board photograph | /gdd/re-imagining-water-cycle/media/board-full.png | ⏳ needed |
| Obstacle block with solution revealed | /gdd/re-imagining-water-cycle/media/obstacle-reveal.png | ⏳ needed |
| Cards 1-4 | /gdd/re-imagining-water-cycle/media/card-01-04.png | ⏳ needed |
| Cards 5-8 | /gdd/re-imagining-water-cycle/media/card-05-08.png | ⏳ needed |
| Brainstorming session, obstacles list | /gdd/re-imagining-water-cycle/media/process-brainstorm.png | ⏳ needed |
| Paper prototype, full board | /gdd/re-imagining-water-cycle/media/process-paper-prototype.png | ⏳ needed |
| Testing movement and content | /gdd/re-imagining-water-cycle/media/process-testing.png | ⏳ needed |
| Map, initial concept with path overlay | /gdd/re-imagining-water-cycle/media/process-map-initial.png | ⏳ needed |
| Map, final board illustration | /gdd/re-imagining-water-cycle/media/board-illustration.png | ⏳ needed |
| Board building (1) | /gdd/re-imagining-water-cycle/media/process-board-build-1.png | ⏳ needed |
| Board building (2) | /gdd/re-imagining-water-cycle/media/process-board-build-2.png | ⏳ needed |
| Card making, fabrication photographs | /gdd/re-imagining-water-cycle/media/process-cards.png | ⏳ needed |
| Demo video | https://youtu.be/TXhfgqZEZNk | ✅ done |
| Playthrough and reactions video | (link TBD) | ⏳ needed |
PROJECT DOSSIER // 2024
Thirty Thousand Feet
Thirty Thousand Feet
Overview
This page discusses the game’s structure in full. If you’d prefer to go in blind - play it first.
Thirty Thousand Feet is a short experimental point-and-click game about presence, inevitability, and the absurd. You are a passenger on a plane. Choices appear in front of you. The game is about what you do with them, and what you find out about yourself in the process.
Platform: Browser / PC Engine: Unity (Prototype v2), Wick Editor (Prototype v1) Mechanic: Point and Click Duration: 1–7 minutes Context: Games as a Medium for Art, NID Bangalore Play it: itch.io
Gameplay Demo
The Central Idea
The future is fixed. The player does not know this yet.
The experience places the player in a situation where every choice they make leads to the same outcome. But the goal is not to inform them of this upfront, the game lets them arrive at that realization themselves.
If you cannot change the outcome, how do you choose to live through it?
Traditional player agency - the ability to change outcomes is removed. In its place the game offers three kinds of agency:
- Behavioral agency: what the player chooses to do
- Emotional agency: how the player responds
- Expressive agency: what the player wants to say or leave behind
The player is not solving the system. They are revealing themselves through it.
Theme: Absurd
Psychological Journey
Repetition is how the game teaches. Each loop creates familiarity, familiarity exposes patterns, and patterns lead to realization.
The player moves through five phases:
- Control: the situation feels solvable. The player tries to prevent the crash.
- Resistance: there must be a correct path. The player keeps searching.
- Recognition: every path leads to the same place. Patterns become visible.
- Re-evaluation: “Why am I trying to stop this? What actually matters here?”
- Shift: the player moves away from control toward meaningful action, personal expression, and emotional choices.
By the end, the player should not feel like they failed to stop the crash. They should feel a shift in perspective, recognition that meaning is created through action, not outcome.
Mechanics & Systems
Core Loop
The core loop represents the fundamental structure of the experience. The player begins in the airplane, makes a choice, observes the outcome, and inevitably reaches the crash. After each crash, a reflective message is shown, and the loop restarts from the same initial state, with the player now aware of previous outcomes.
The loop is intentionally repetitive and deterministic. Its purpose is not to provide multiple outcomes, but to allow the player to explore different choices within the same fixed result. Over time, this repetition reinforces the inevitability of the situation while encouraging the player to reconsider their approach and intentions.
Each loop resets the world but not the player’s knowledge. New options unlock over time.
Choice Architecture
The game has three layers of choices, each deeper and further from “solving” the situation.
Layer 1: Seat (Primary)
- Listen to music and sleep
- Talk to Nanny (philosophical dialogue)
- Get away from seat (opens Layer 2)
- Write farewell letter (locked, unlocks after multiple loops)
Layer 2: Movement (Secondary)
- Tell everyone about the crash (passengers ignore or mock)
- Call emergency
- Go Instagram live
- Perform push-ups (surreal branch)
- Head to cockpit (crew dismisses all warnings)
- Go to emergency section (opens Layer 3)
Layer 3: Emergency Section (Tertiary)
- Perform moonwalk (surreal branch)
- Count passengers (interrupted by crash)
- Break emergency exit (immediate crash)
- Go to kitchen (critical path trigger)
Surreal Branches
Not all choices are grounded. Some fracture the reality of the cabin entirely:
- Push-ups: the player gains superhuman ability and briefly flies before returning to the plane
- Moonwalk: the cabin transforms into a stage with an audience; the player can sing or dance before returning
These branches do not break the loop. They demonstrate the absurdity of trying to escape. The crash still comes.
Memory Scenes
A hidden critical path exists through the kitchen. Taking the fire extinguisher triggers a reality shift:
Restaurant Scene: the player becomes a server, holding a tray where the extinguisher was. A voice calls “Jonathan.” The player’s parents are at a table. The ordinary world intrudes.
Home Scene: seated at a dining table with parents. Two choices:
- Tell them the plane is going to crash: they dismiss it as a joke
- Say “Everything is fine”: the acceptance path
Choosing acceptance does not prevent the crash. But it changes the ending message and closes the loop with a sense of resolution rather than futile struggle.
Post-Crash Message System
After every crash, a contextual message displays based on the choices taken:
- “You allowed fear to dictate your choices”
- “You tried to change what cannot be changed”
- “You found meaning in the madness”
The message is the game’s only direct editorial voice. It reflects the player’s behavior back at them without judging it.
Farewell Letter
Unlocks after multiple loops. The player can write a message to someone before the crash. It is the only choice in the game that is purely expressive. It changes nothing mechanically, but it gives the player something to do with acceptance that is not just clicking through to the end.
Playtest & Findings
Prototype v1: Wick Editor
Player A, the explorer
Explored intervention choices first, then drifted to absurd options out of curiosity, not because they accepted the premise, but because they were still looking for an escape route. After the playtest, suggested that if the ending is inevitable, players should be given a way to pass something on: a farewell, a message to someone. The insight: a meaningful ending requires a meaningful last act.
Player B, the problem-solver
Took a problem-solving approach, clicking rapidly through options before reading them, treating it as a challenge to be solved under the countdown pressure. Couldn’t get to the intent. After explanation: “Even if I know I’m going to die, why would I choose these absurd choices? The choices should be meaningful, something close to what I’d actually do.” Then: “I tried everything. I lived my life.” An unintentional reflection of their own values through the choices they’d made.
Prototype v2: Unity
Player C, the one who accepted
Notably different response. After the first crash, didn’t try to escape on the second run. Accepted it and went directly to writing the farewell letter. The mechanic landed.
Player D, the one who gave up
Tried all intervention choices. When those failed, stopped entirely and didn’t explore the absurd options at all. The farewell mechanic was not reached.
Reflections
The project establishes a clear conceptual foundation: place the player in a situation where the outcome is inevitable, and allow meaning to emerge through choice rather than consequence. The loop structure supports this by reinforcing repetition and gradually exposing the limits of control. The memory layers (restaurant and home) add emotional depth and shift the experience beyond a mechanical loop into something more personal.
What worked
The farewell letter was the strongest single mechanic. It gave players something to do with acceptance that wasn’t just clicking through to the end. It directly engaged them in personal expression, which is closest to the core intent. A small subset of players demonstrated this shift quickly, validating that the underlying idea works when players reach it.
What didn’t land as intended
Most players interpreted the experience as a problem to solve. They prioritized choices that appeared logical, ignored narrative cues in early loops, and explored absurd choices only out of curiosity rather than as meaningful alternatives. The system strongly signals traditional game logic, where multiple choices imply a correct path, which works against the intended realization.
The uniformity of outcomes compounds this. When most choices lead immediately to the same crash, the system can feel flat rather than intentional. Some of the more performative branches (push-ups, moonwalk) feel disconnected from the central theme, which weakens the transition from control to reflection.
The deeper issue is one of opacity. The design relies on players discovering the philosophy through interaction, but currently leans too far toward opacity. Players recognize repetition but don’t consistently connect it to a shift in values. The gap between intent and player perception is real and needs structural work, not just content additions.
What I’d explore next
- Subtle loop variations: small environmental or dialogue shifts across loops to signal that something is changing, even when the outcome isn’t
- Nanny as a guide: the Nanny character has untapped potential as a soft interpretive voice; stronger dialogue here could help players reframe their approach without being told outright
- Reweight the home scene: currently it feels like another branch; it should feel like a point of arrival, the moment the loop offers something different
- Countdown pressure: reduce it, not remove it; it currently pushes players into problem-solving mode immediately, which works against the meditative intent
- Cabin as world: ambient detail, ambient sound, things to notice that aren’t choices; the world feeling real is what makes the inevitability land
- Farewell letter expansion: the most validated mechanic deserves more room; more expressive options, more weight given to what’s written
Media
| Asset | File | Status |
|---|---|---|
| Core loop diagram | core-loop.png | ✅ done |
| Player realization progression | behaviour-progression-state-transition.png | ✅ done |
| Gameplay screenshot, exterior | screenshot-exterior.png | ⏳ needed |
| Gameplay screenshot, interior / choices UI | screenshot-interior.png | ⏳ needed |
| Farewell letter screen | screenshot-farewell.png | ⏳ needed |
PROJECT DOSSIER // 2025
What About Me?
What About Me?
Overview
What About Me? is a social game for 4 to 8 players, designed as an ice-breaker for people who want to get to know each other without the pressure of being put on the spot. Inspired by Codenames, it uses a question-and-clue structure to create low-stakes, self-directed conversation between strangers, classmates, or coworkers.
Platform: Physical Card Game Type: Social Game Team: Pinku Swargiary, Tara Dhurba, Spandan Biswas Context: Sem 4, Serious Games: Game for Social Inclusion, NID Bangalore
The Central Idea
Most people who find socialising difficult are not unwilling. They want to connect. The barrier is the mechanics of social interaction itself: not knowing how to start, not knowing how much to share, fearing how they will be perceived. A game can create a structure that lowers that barrier by giving everyone a reason to talk and a level of control over what they reveal.
What About Me? is built for anyone who wants to connect but finds the mechanics of connection difficult. It does not require anyone to perform or compete for attention. It gives each player a question to answer in their own way, as briefly or as expansively as they choose, and turns that answer into something the group engages with together. The social interaction is the game.
Mechanics & Systems
Setup
Two teams (red and blue), minimum 2 players each. A 3x3 grid of 9 question cards is laid out face up on the table. A separate deck of number cards (1-9) is shuffled and placed face down. Coins are set aside for scoring.
Core Loop
Each round, one player from the active team is designated as the Spymaster. The Spymaster draws the top number card from the face-down deck and keeps it hidden. The number corresponds to one of the 9 questions laid out on the table.
The Spymaster answers that question in 1 or 2 words, without revealing which question they are answering. Their teammates listen to the answer and try to identify which question on the board it corresponds to. If they guess correctly, the team earns a point. Conversation is permitted: the Spymaster can expand on their answer once the initial clue has been given.
The Spymaster role rotates every round until all players have been Spymaster at least once.
Optional Double Bet
A Spymaster may choose to draw 2 number cards and answer both questions with a single answer. If teammates correctly identify both questions, the team earns 2 points. If they identify only one, no points are awarded.
Winning
The game continues until one team reaches 15 points. If scores are tied, tiebreaker rounds are played.
Question Categories
Questions are grouped into three types to allow a range of sharing depth. Fun and lighthearted questions (weirdest habit, dream superpower, best advice received) keep the tone loose and low-stakes. Personal and relatable prompts (favourite childhood memory, most prized possession) invite a little more openness, but remain optional in how much a player reveals. Creative prompts (title of the movie about your life, a nickname for yourself) give players room for self-expression without requiring disclosure of anything real.
1. Fun and Lighthearted Questions
2. Creative Questions
3. Personal and Relatable Questions
(Encourages sharing but remains light and optional)
Design Intent & Pedagogy
The game is designed around one constraint: no player should be put in a position where they feel exposed or stereotyped. The Codenames-inspired structure gives everyone objective grounding. Not all gameplay is subjective; the question card exists, and the answer has to correspond to something real on the board. This keeps the game from becoming a test of personality or social confidence.
The 1-2 word answer rule is intentional: it lowers the barrier to participation for players who struggle to articulate or fear being misunderstood. The subsequent conversation allows sharing to happen naturally, on the Spymaster’s own terms, rather than being required up front.
The Spymaster mechanic also ensures that introverts are not permanently in the background. Everyone takes the role at least once, but the structure of the role is designed to make that manageable: you answer one question, briefly, and the group does the interpretive work.
Process
Research
The brief was social inclusion. Research began with user interviews and persona development to understand who actually struggles with socialising and why. Two personas anchored the design: Spandan, a 25-year-old who finds it hard to articulate himself and is intimidated by new people, and Tara, a 22-year-old who enjoys socialising but fears rejection and dislikes being under pressure to perform.
The key insight from the research was that the problem was not motivation but mechanism. Both personas wanted connection. Neither had a comfortable way to initiate it.
Market research supported the relevance of the brief: the social gaming market is projected to grow at 16.4% CAGR through 2031, with Asia Pacific leading at 34.3% market share, precisely the region and demographic the game is designed for.
Iteration 1
The first version used Identifier Cards (A, B, C, D) assigned to players. One player would pick a card and give the opposing team a clue about the person holding that identifier, and the opposing team would guess who it was. Wrong answers could be redeemed via a question card mechanic involving a dice roll.
The iteration failed on two counts. Because players did not know each other, guessing defaulted to appearance, which introduced stereotyping. More significantly, players had no control over how they were described. For anyone with social anxiety, being characterised by someone else in front of a group was a direct deterrent to participation.
Iteration 2
The redesign shifted from describing people to answering questions about yourself. The Codenames structure was retained but repurposed: instead of guessing a word on a board from an agent’s clue, players guess which personal question a Spymaster answered from their brief answer.
This resolved the core problems. Players describe themselves on their own terms. There is no direct personal description by others. The objective question grid gives the game structure without making the content impersonal. An optional pressure-relief mechanism allows players who are feeling overwhelmed to see the question number deck and choose which question to answer.
Playtest & Findings
Testing Iteration 1 surfaced two problems quickly. Because players did not know each other, guessing who held an identifier card relied almost entirely on physical appearance. The mechanic produced stereotyping rather than connection. The second problem was agency: players had no say in how they were described by someone else. For anyone already anxious about social situations, that absence of control was a barrier rather than an invitation.
Iteration 2 was tested with the revised Codenames structure. The shift from describing others to answering about yourself resolved both issues. Players were more willing to participate when the content of the interaction was under their own control. The 1-2 word answer created an entry point; the subsequent conversation was where the actual connection happened.
Reflections
The central insight from this project was that agency is the variable that determines whether a social game feels safe. The content of the questions matters less than who controls the answer. A game that puts players in situations where others define them, even in a playful context, will feel threatening to exactly the people it is meant to include. Shifting that control to the player changes the texture of the interaction entirely.
The Codenames structure worked well as a borrowed frame because it already had the right relationship between clue-giver and audience. Repurposing it with personal questions gave the game objective grounding without making it impersonal.
The competitive structure, teams and points and a winning condition, gives the game shape and keeps it moving. In practice, nobody playing this kind of game is counting coins. The structure creates occasions for conversation, and the conversation is what people leave with.
Media
| Asset | File | Status |
|---|---|---|
| Cover / hero photograph | /gdd/what-about-me/media/cover.png | ✅ done |
| Board layout and components | /gdd/what-about-me/media/components.png | ✅ done |
| Question cards laid out | /gdd/what-about-me/media/question-cards.png | ✅ done |
| User persona, Spandan | /gdd/what-about-me/media/persona-spandan.png | ✅ done |
| User persona, Tara | /gdd/what-about-me/media/persona-tara.png | ✅ done |
| Iteration 1 concept | /gdd/what-about-me/media/iteration-1.png | ✅ done |
| Playtest video | (link TBD) | ⏳ needed |
PROJECT DOSSIER // 2023
A Particle
A Particle
Overview
A Particle is a 2D side-scrolling runner about escaping the Big Bang. The player controls a particle that can change its own shape, and that shape directly controls how it moves and interacts with the world. Horizontal stretch accelerates it. Vertical stretch slows it down. Everything in the game, speed, obstacle navigation, trigger interaction, flows from this single ability.
The prototype spans three levels structured around a simple progression: introduce, combine, stress.
Platform: PC & Mobile
Engine: Unity
Camera: 2D side-scrolling
Type: Runner
Gameplay Demo
The Central Idea
Shape manipulation is the entire game. The player is not pressing jump or dash. They are reshaping the particle itself, and that transformation is simultaneously a movement tool, a collision solution, and an interaction key. The idea is that form and function are the same thing.
The game is set at the origin of everything. The particle is escaping the Big Bang, which pursues it from behind as a blast. The setting is mostly aesthetic but it gives the shape system a thematic foundation: a particle in the earliest moments of the universe has no fixed form.
Core Loop
The player moves forward continuously. The blast chases from behind. The player shifts shape to adjust speed, pass through obstacles, and trigger interactions. The loop repeats with increasing obstacle complexity.
The blast system applies elastic pressure: it accelerates toward the player by default, temporarily slows if the player slows, then re-accelerates. The player can never fully stop.
Mechanics & Systems
Shape Manipulation
The player has three core forms:
- Default (square): baseline movement speed
- Horizontal stretch: increased speed, wider collision profile
- Vertical stretch: decreased speed, taller collision profile
Shape is not just a speed dial. It is also the player’s collision profile and their interaction key. Certain obstacles can only be passed in specific forms. Certain triggers respond to the shape that hits them. The same input has different consequences depending on what the player is currently pressing and what is in front of them.
Environment triggers
Environmental triggers can also force shape changes: size reset triggers return the player to the default square, stretch triggers shift to horizontal or vertical. Blackhole zones act as transformation gateways.
Speed Reset Speed Reduce Speed BoostBlast Chaser
The blast follows the player and adapts to their speed. Slowing down narrows the gap. Speeding up temporarily creates more room. The pressure is elastic rather than constant, which prevents the experience from becoming a pure sprint.
Obstacles
Four types of obstacle appear across the three levels:
- Static: require the player to be in the correct shape to pass through
- Cuttable blocks: can be passed through via a form-based interaction
- Trigger-based: blue bars activate the system, pink blocks deactivate when triggered
- Dynamic: vertical bars that close in when a trigger is hit
Pickups
Collectibles exist in the levels but their function was not fully defined in the prototype. They do not currently affect survival, speed, or the blast.
Level Structure
Design Evolution
Moodboard (Space theme, cinematic, grand, minimal)
Concept 1
The game started as a static puzzle. The player would manipulate the size of multiple objects simultaneously with a fixed camera. The problem: no sense of motion, low energy, nothing pulling the player forward.
Concept 2
To simplify, size manipulation was limited to only one object
With the above concepts, the motion was missing as initially thought as per mood board. Both the motion and size manipulation after blended together, the current player movement mechanic was created. The shift to a continuous runner came from recognizing that the shape manipulation system only feels interesting under movement. Reshaping to fit a gap while something is chasing you from behind is a different experience from reshaping at rest. The runner format gave the mechanic urgency.
The consequence is that the systems feel slightly misaligned. They were not originally designed together and it shows in places.
Some experiments taking the branches as a pathway for level.
Reflections
The shape manipulation mechanic is genuinely interesting at a mechanical level. Changing form to change behavior, using the same input for speed control, obstacle navigation, and system interaction, is a readable and expressive core ability. The prototype communicates this cleanly.
What didn’t land
The game’s intended tone was cozy. The blast chaser produces constant urgency. These two things are in direct conflict and the prototype does not resolve them. The current experience is a pressure runner, not a cozy one. Committing to one or the other would sharpen the design considerably.
Systems do not interact with each other. The blast responds to the player. Obstacles respond to the player. Triggers respond to the player. But the blast does not affect obstacle timing. Shape does not change how triggers respond. Speed does not influence the blast’s behavior in a nuanced way. Everything is parallel rather than interconnected.
The pickup system has no defined purpose in the prototype. Without a function, it is noise.
The blast system also flattens mastery. Because blast speed adapts to player speed, there is no incentive to optimize movement. A faster player does not gain distance, they just stay even. This removes the skill ceiling.
What I’d explore next
- Commit to a tone: either slow the game down into a flow/puzzle experience or tighten it into a skill runner with fixed blast behavior and a genuine mastery curve
- Shape with consequences: horizontal stretch should carry a meaningful cost beyond being a wider target; vertical stretch should offer something beyond slowdown
- System interaction: shape affecting how triggers respond; speed affecting obstacle timing; blast state influencing the environment
- Pickup purpose: tie pickups to blast management, shape duration, or speed modifiers so every pickup is a decision
- Pre-planning layer: obstacle sequences complex enough that the player needs to anticipate two or three shapes ahead, not just react
Media
| Asset | File | Status |
|---|---|---|
| Cover image | cover.png | ✅ done |
| Core loop diagram | core-loop.png | ⏳ needed |
| Shape forms diagram | shape-forms.png | ⏳ needed |
| Obstacle types overview | obstacle-types.png | ⏳ needed |
| Gameplay video | https://youtu.be/heXg4auuqhc | ✅ done |
| Gameplay screenshot, level 1 | gameplay-level1.png | ⏳ needed |
| Gameplay screenshot, level 2 | gameplay-level2.png | ⏳ needed |
| Gameplay screenshot, level 3 | gameplay-level3.png | ⏳ needed |
PROJECT DOSSIER // 2024
Obsolete
Obsolete
Overview
Obsolete is a third-person couch co-op bullet hell set in a dystopian future where outdated human mecha suits are the last line of defense against advanced autonomous robots. Two players share a screen and coordinate in real time: dodging dense projectile patterns, switching targets, and managing pressure without getting separated.
The game is a visual slice and proof of concept, developed as a team project across full production cycles from initial prototyping to a dressed build with audio and visuals.
Platform: PC
Engine: Unity
Camera: Dynamic third-person
Type: Couch Co-op Bullet Hell
Team: Ashirwad Gogoi, Manish Sethi, Paulomi Joshi, Pinku Swargiary, Suhas Dhanrale, Tara Durbha
Gameplay Demo
The Central Idea
The premise is in the title. The machines the players pilot are obsolete: outdated, outclassed, and still fighting. The aesthetic contrast between degraded mecha suits and the sleek autonomous enemies they face is the thematic core. The game is about coordination under impossible odds, not power fantasy.
Key Features
Innovative co-op camera system
The third person camera dynamically responds to player movement, maintaining a clear view of the game area, players, and enemies at all times. This allows for one of the first Third person, couch co-op, shooter game experiences.
Fast-paced co-op based shooting
The game uses an aim lock system, and players can shift aim lock from enemy to enemy. And different enemies have different fire rates making the players to think on their feet ans strategize on the go.
Cinematic art direction
The game uses a geometric art style paired with atmospheric lighting and soundtrack to deliver a cinematic experience. The menu and in game UI / UX is minimal and blends perfectly with the art style allowing for complete immersion.
Dynamic in-game music
The music is made in layers and matches the intensity of the game play by detecting the enemies that are currently active. (Each enemy has an activation range and only activates once either player enters that zone).
Core Loop
Co-op advantage is implicit. Players who coordinate target priority and positioning survive longer and clear encounters faster. Players who operate independently can still function, but the game rewards shared spatial awareness.
Mechanics & Systems
Shooting
Players use an aim-lock system that allows dynamic target switching between enemies. Different enemies fire in different patterns, which forces players to constantly re-evaluate which target to prioritize. Switching targets is a micro-decision made continuously throughout combat.
Dodging
Dodging is the primary survival mechanic. It is timing-based and spatially dependent: players need to read enemy projectile patterns and move accordingly. Positioning relative to both the enemy and the co-op partner is a constant consideration.
Co-op Coordination
There is no hard dependency between the two players. Either player can survive independently for a period. But coordinating target selection, positioning, and ability use creates a meaningful efficiency advantage. The design targets implicit coordination rather than forced dependency, closer to how It Takes Two or Unravel 2 handle co-op than Overcooked’s explicit task division.
Camera System
The shared third-person camera dynamically adjusts to keep both players and active threats visible. Maintaining readability across different player positions and enemy configurations was a key production challenge. The camera is not cosmetic: it is what makes the co-op experience legible.
Dynamic Music
Music layers are tied to combat intensity and proximity. Enemy proximity activates additional layers. Zone-based activation creates an audio landscape that escalates with the encounter. The intention is to reinforce moment-to-moment pressure without relying on UI indicators.
Progression
XP and Leveling
Enemies drop XP. The XP requirement scales down over time, accelerating the pace of progression mid-session to maintain momentum.
Ability Upgrades
On level-up, the player selects one upgrade from a set:
- Speed
- Fire rate
- Reload speed
- Damage
- Health
The upgrade system is designed to accommodate different player skill levels. A player with lower mechanical skill can compensate through ability investment. A more skilled player may not need upgrades to survive and can optimize differently.
Enemy Design
Five enemy types cover a range of behaviors and co-op responses.
Minor Minion: fast, low health, medium damage. Forces constant movement. Countered by reading dodge timing.
Major Minion: slow, high health, high damage. Requires sustained coordinated fire to bring down efficiently.
Aggressive Minion: fast, medium health, high damage. Repositioning pressure. Countered by positioning combined with power-up management.
Mini Boss: slow, high health, high damage. Forces use of cover and deliberate positioning. Most effective against coordinated players.
Final Boss: very high health, multiple weapon systems, large attack coverage, high fire rate. Requires full system mastery: positioning, coordination, and upgrade synergy simultaneously.
Enemy encounters are triggered by proximity within activation zones. This creates a non-linear pacing structure where the players’ movement through the space determines when each encounter begins.
Level Design & Pacing
Pacing and Balancing
Balancing is achieved through 3 parameters :
- Player Power Curve - We maintain players “SKILL : ABILITY” balance :
-
XP drop (enemy drops): Every enemy killed gives the player an XP pickup. As the level progresses, the number of XP pickups required to fill up the XP bar reduces.
-
Abilities (strategic upgrades): When XP bar is full, players get to choose an ability power-up (speed, fire rate, reload speed, damage, or health)
-
Skill (player execution): The controls are intuitive and simple, allowed players to quickly upgrade their own skill level
-
Co-op Strategy Mechanics - The players have to think quickly and strategize differently to take down different enemy types.
-
Enemy placement - The distribution of the enemies, and the radius of their activation range throughout the level in combination with the first two points creates a non linear pacing.
Research and Ideation
- Analyzed successful co-op games like Overcooked, It Takes Two, and Unravel 2
- Identified market opportunity for accessible yet engaging co-op experiences
Comparison Table
| OVERCOOKED | CHAINED TOGETHER | IT TAKES TWO | CUPHEAD | UNRAVEL 2 | |
|---|---|---|---|---|---|
| RELEASE DATE | August 2016 | June 2024 | March 2021 | September 2017 | June 2020 |
| GROSS REVENUE | $ 12.7 mil | $ 3.4 mil | $ 123.7 mil | $ 73.7 mil | $ 2 mil |
| UNITS SOLD | 1.3 mil | 875 k | 5.2 mil | 4.9 mil | 197 k |
| POSITIVE REVIEWS | 90.50% | 89% | 95% | 96.30% | 80.4% |
In terms of scope, “OBSOLETE” is placed in the bracket of Unravel 2. The target audience includes co-op enthusiasts, and casual and mid-core gamers seeking accessible yet engaging gameplay. It’s designed for pairs, whether couples or friends.
- Based on the analysis, we developed core gameplay loop: SHOOT ↔ DODGE
- The game is at its core a bullet hell game where players must dodge projectiles to survive, and shoot to kill the enemies.
Prototyping and Iterations
-
The game went through different iterations in regards to level structure, skill trees and enemy abilities until the final design
-
Initial prototypes focused on core mechanics and controls
-
Multiple cycles of play testing and refinement took place
-
Final iteration was developed into a “DRESSED PROTOTYPE” with visual and sonic elements
-
Based on player testing and refinement of the dressed prototype, the final “VISUAL SLICE / PROOF OF CONCEPT” was made
Reflections
The prototype succeeds in establishing a readable and engaging core loop. Shoot and dodge is immediately legible, the pacing structure works well in practice, and the co-op framing is strong without forcing players into a rigid dependency. The dynamic music system adds genuine atmosphere without relying on UI to communicate intensity.
Co-op coordination is implicit by design, but it stays implicit throughout. There are no moments where the game specifically requires two players to act in synchrony, where success depends on coordination rather than just benefiting from it.
Future Scope
- Enforced co-op moments: encounters or mechanics that require both players to perform a specific coordinated action, making the co-op a structural requirement rather than a soft advantage
- Meta progression: something that carries between sessions to give the experience a reason to return
Media
| Asset | File | Status |
|---|---|---|
| Cover image | cover.png | ✅ done |
| Core loop diagram | core-loop.png | ⏳ needed |
| Intensity curve diagram | intensity-curve.png | ⏳ needed |
| Enemy type overview | enemy-types.png | ⏳ needed |
| Gameplay video | https://youtu.be/sQibc_xSsbc | ✅ done |
| Gameplay screenshot, combat | gameplay-combat.png | ⏳ needed |
| Gameplay screenshot, co-op | gameplay-coop.png | ⏳ needed |
| Camera system screenshot | camera-system.png | ⏳ needed |
| Visual style / moodboard | moodboard.png | ⏳ needed |
PROJECT DOSSIER // 2024
Gummy's Summit
Gummy’s Summit
Overview
Gummy’s Summit is a top-down puzzle game built around a single core mechanic: the ability to instantly swap positions with interactable objects in the world. The player is a character cursed with this ability, navigating a guarded mountain region to find a cure.
The game is structured as a prototype across two maps, introducing mechanics progressively and combining them in later challenges. The central design question was whether a single spatial mechanic could support traversal, puzzle-solving, and stealth without needing to be extended or complicated.
Platform: PC & Mobile
Engine: Unreal Engine
Camera: Top-down
Type: Puzzle Game
Gameplay Demo
Narrative Context
The player is cursed with a position-swapping ability and must break it. The path leads through a guarded mountain region toward two objectives: drinking from a mystical fountain and consuming the sacred fruit of a purple tree. Neither objective is handed to the player. Both require navigating puzzles and enemies.
Core Loop
Each section is gated. All challenges ultimately lead to activating a switch. Variation comes from how the swap mechanic is applied: sometimes as a traversal tool, sometimes as a puzzle solution, sometimes as a way of slipping past a patrol.
Mechanics & Systems
The Swap
The player can instantly swap positions with any designated interactable object in the environment. Only marked objects can be swapped. Hovering over one highlights it. The swap is immediate and positional.
Three applications:
- Traversal: swapping through a blocked area instead of navigating around it
- Puzzle-solving: repositioning objects spatially to satisfy conditions
- Evasion: placing distance between the player and an enemy in a single action
The mechanic does not grow or evolve in the prototype. Its power comes from being applied in different spatial configurations.
Movement
Point-and-click navigation. The player clicks a destination and moves there via pathfinding with obstacle avoidance. A click indicator confirms the target. There are no additional movement abilities or resources in the prototype.
Enemy System
Enemies follow fixed patrol paths with looped movement. On detecting the player (vision cone, instant detection within range) they switch to chase, then attack at close range with a short cooldown. If the player escapes the detection range, the enemy resets to patrol.
Patrolling
Enemy patrols on the given patrol points
Attacking
On Seeing Player, Chases Player and Attacks when on Attack Range. Attack has a cooldown timer for 0.4 seconds, so that they do not attack continuously to the Player and give some time for player to perform there next action.When Player is out of range again, Enemy goes back to patrolling state.
Puzzle Types
Stealth navigation: the player moves through patrol zones without triggering detection. Solution requires reading enemy timing and positioning the character in gaps.
Color lock and key: colored key objects must be swapped into matching lock positions to open a gate. Locks are fixed in place. The puzzle is about working out the sequence of swaps needed to solve the spatial arrangement.
Launchpads: traversal sections requiring the player to align direction correctly and land on the target platform. Missing a jump fails the attempt.
Level Progression
Two maps cover the full prototype scope. Each introduces mechanics before combining them.
Map 1 (Introduction): movement onboarding, basic swap usage, first enemy encounter, multi-patrol scenario. Ends at the fountain objective.
Map 2 (Expansion): lock-and-key puzzles, launchpad mechanics, swap combined with stealth. Final challenge combines a complex swap puzzle with positional pressure. Ends at the purple tree objective.
Difficulty increases through spatial arrangement rather than new mechanics. Later levels ask the player to apply the same tools in tighter configurations with more variables in play.
Design Iteration
Mechanic Inspiration
Interations
Moodboard
Stylized Characters
Cell Shaded Environments
Reflections
The prototype establishes a clear core mechanic with consistent application across multiple puzzle types. Swap works as a traversal tool, a puzzle verb, and a stealth solution, and the two-map structure gives it enough room to be introduced and then combined. The shape-to-color iteration was a meaningful improvement in player readability, and the result is a prototype that communicates its mechanic quickly and clearly.
What didn’t land as intended
The systems function in parallel rather than interacting with each other. Swap solves puzzles. Enemies create pressure. But the two rarely force the player to use the swap tactically in response to enemy behavior. Multiple solution paths exist in most sections, making the swap feel optional rather than essential.
Enemy detection is binary. Patrol or full chase, nothing in between. This makes stealth readable but removes the space for deliberate, layered play. There is no tension in almost being seen.
The narrative and mechanic are thematically connected (the curse is the ability) but mechanically disconnected. The swap does not evolve as the player progresses toward breaking the curse, and player actions do not reflect or affect the story. The connection stays at the concept level.
What I’d explore next
- Mechanic evolution: the swap ability could change as the curse weakens, giving the progression arc a mechanical shape
- Forced interaction: puzzle configurations that require using swap specifically to manipulate enemy patrol paths, not just avoid them
- Enemy depth: an intermediate awareness state between patrol and full chase; an enemy that slows, reorients, or searches before committing to pursuit
Media
| Asset | File | Status |
|---|---|---|
| Cover image | cover.png | ✅ done |
| Core loop diagram | core-loop.png | ⏳ needed |
| Level progression diagram | level-progression.png | ⏳ needed |
| Swap mechanic screenshot | swap-mechanic.png | ⏳ needed |
| Enemy system diagram | enemy-system.png | ⏳ needed |
| Puzzle type: stealth | puzzle-stealth.png | ⏳ needed |
| Puzzle type: color lock | puzzle-color-lock.png | ⏳ needed |
| Gameplay video | https://youtu.be/8tgIjANRRo0 | ✅ done |
| Gameplay screenshot, map 1 | gameplay-map1.png | ⏳ needed |
| Gameplay screenshot, map 2 | gameplay-map2.png | ⏳ needed |