Kalyani: A Stepwell Water-Level Puzzle Adventure — Game Vertical Slice (Unity/Blender)

Kalyani is a third-person puzzle-adventure vertical slice set inside a fictional stepwell inspired by the tiered stone tanks of the Deccan, such as those seen around Hampi. The player is a young caretaker who must restore water to a dried-up village tank. Each terrace of the stepwell has sluice gates, channels and counterweights; raising or lowering the water changes which steps are walkable, which platforms float and which carved passages open. Water level is the single core mechanic, and every puzzle is a variation of it.

The degree project delivers a 15–20 minute playable slice of three terraces with a tutorial, two full puzzles and a final combined puzzle, plus a game design document (GDD), a process document and a portfolio. It is built in Unity 2022.3 LTS with the Universal Render Pipeline and C#, with environment assets modelled in Blender from measured sketches and photographs of stepwell geometry and carved stone.

The process follows design-school practice: research on stepwell architecture and on puzzle-game design, paper and board prototypes of the water mechanic, a greybox in ProBuilder, four rounds of playtesting with think-aloud protocol, completion-time and fail-point logging, and an art pass. The project demonstrates that a culturally rooted setting can be more than decoration when the architecture itself — terraces, symmetry, water — is the puzzle.

Abstract

Indian architecture appears in games mostly as backdrop. This project explores whether the spatial logic of a stepwell — descending terraces, symmetrical flights of steps and seasonal changes in water level — can become the core mechanic of a puzzle game. The result is a vertical slice in which the player manipulates water level to change the traversable space, documented through a GDD, paper prototypes, greybox iterations and structured playtests.

Introduction

Stepwells (vav, baoli, kalyani, pushkarini) were built across western and southern India to store water through dry seasons. Their form changes meaning as the water rises and falls: a flight of steps becomes a shoreline, then disappears. This is a natural puzzle space. The project's target audience is players aged 15 and above who enjoy slow, observation-based puzzle games, on PC with keyboard-mouse or gamepad.

Literature and precedent gap

Puzzle games built around one physical rule — portals, time rewind, perspective — show that a single mechanic explored in depth can carry a full game. Game-design texts such as Schell's lenses and Fullerton's playcentric process describe how to iterate such mechanics through prototypes and playtests. However, few games from Indian design schools document the path from architectural research to mechanic with measured playtest evidence. This project addresses that gap.

Existing vs proposed

• Existing approach in student games: setting chosen for look, mechanics borrowed from generic platformers, playtesting informal.
• Proposed: architecture analysed first; the mechanic derived from how stepwells work; paper prototypes before code; greybox before art; four playtest rounds with a fixed protocol and metrics; art pass last.

Feasibility

• Technical: Unity's personal licence, Blender and ProBuilder are free; the water system uses a scripted plane with discrete levels rather than fluid simulation, keeping it stable on mid-range laptops.
• Scope: one environment, three terraces, one mechanic — sized for a single designer in 20 weeks.
• Evaluation: playtesters are classmates and first-year students recruited with informed consent.

Games that use Indian heritage architecture usually treat it as scenery — the player jumps and fights through temples and forts with mechanics unrelated to what those buildings were for. The design intelligence of structures such as stepwells, which were engineered around changing water levels, is lost. At the same time, student game projects often skip structured iteration: they go straight to art and code, discover late that the core loop is confusing, and have no evidence of what players actually experienced.

This project asks: can the functional logic of a stepwell — terraces that appear and disappear as water rises and falls — be turned into a clear, learnable puzzle mechanic, and can a single designer take it from research to a polished, playtested vertical slice in one semester? Success is measured by whether playtesters learn the mechanic without text instructions, complete the slice, and describe the stepwell as part of the puzzle rather than as backdrop.

In scope

• One stepwell environment with three terraces: a tutorial, two puzzles and one combined final puzzle.
• Core mechanic: sluice gates and counterweights that raise or lower water across discrete levels, floating platforms, submerged passages.
• Third-person controller, camera with Cinemachine, interaction prompts, pause menu, save at terrace checkpoints.
• PC Windows build; keyboard-mouse and gamepad through the Unity Input System.
• GDD, playtest reports and process document.

Out of scope

• Full story campaign, combat, collectables economy.
• Console or mobile builds.
• Realistic fluid simulation (the water is a stylised, stepped system).
• Localisation beyond English UI text.

The project uses an iterative, playcentric design process: research → concept → paper prototype → greybox → playtest loop → art pass → polish. It runs for 20 weeks with guide reviews every two weeks.

Playtest protocol: consent form; no instructions beyond controls; tester thinks aloud; observer notes confusions; the game logs time per puzzle and each reset to a CSV; a short post-play questionnaire covers clarity, difficulty and how testers perceived the setting.