Milan Chandegara | Game Designer

ABOUT

PROJECTS

Core Design / Game Concept

TWEAKARC is a 2D physics puzzle game where the ball must reach a target, but the player has no direct control over its movement. Instead, the player places and angles props to create a path that guides the ball toward the target. Ball speed is an important part of the puzzle—poor prop placement or angles can cause the ball to gain or lose too much speed, preventing it from reaching the target.

Design Principles

Player Freedom & Experimentation

The game is designed to give players freedom to explore each level and discover their own solution. Players are given limited resources, but the level layout allows multiple ways to reach the target.

Experimentation Loop

The core gameplay loop is based on experimentation: place and angle props → launch the ball → observe its path → reset if it fails → adjust the setup → try again.

Limited Resources, Multiple Solutions

Each level provides a limited number and selection of props. Levels are designed around these constraints while still allowing more than one possible solution.

Systems Design

Ball Movement System

The ball uses a physics-based movement system and is not directly controlled by the player. It starts with no initial velocity and begins moving in the direction of gravity. The height and distance of each bounce depend on the ball's speed, while different surfaces affect how much speed the ball gains or loses after impact.

Control System

The game uses a streamlined control scheme built around simple mouse interaction. The player does not need to learn complex controls, allowing the experience to stay slow and deliberate so attention remains focused on solving the puzzle.

Level Loading System

Levels are loaded and unloaded at runtime. Each level is stored as JSON data and instantiated into the scene when required, allowing the game to manage different puzzle layouts without creating a separate scene for every level.

Scoring System

Each level defines a baseline for the number of tries and bounces expected to complete it. The player's performance is compared against these values. Completing the level within both limits awards 5 stars, while exceeding the try or bounce limits adds a proportional penalty. As the combined penalty increases, the final star rating gradually decreases from 5 to 0.

Challenges & Solutions

Level Creation & Management

Challenge:
Creating every level as an individual Unity scene would make level creation and maintenance more complicated. Each new level would require a separate scene and repeated environment setup, making the project harder to manage as more levels were added.

Solution:
I created a custom Unity Editor tool that saves each level as JSON data. At runtime, the game reads the JSON file and generates the required level inside the main gameplay scene. This keeps the level system lightweight and makes levels easier to create, edit, and modify without maintaining a separate Unity scene for each one.

Scoring System

Challenge:
Using the same scoring requirements for every level would not work well because each level has a different layout, difficulty, and multiple possible solutions. A fixed number of tries or bounces could unfairly reward or penalize the player.

Solution:
Each level defines its own baseline for tries and bounces. The player's performance is compared against these level-specific values. Staying within both baselines gives the best score, while exceeding either one adds a proportional penalty that gradually reduces the star rating. This allows the scoring system to adapt to the expected difficulty and solution space of each level.

Technical Work

Custom Unity Editor Tool:
built a tool to create/save level data as JSON.

Runtime Level Loading:
loads and unloads level data into the gameplay scene at runtime.

Gameplay State Management:
handles states like Edit, Play, Reset, Completed

Prop Interaction System:
code for selecting, moving, rotating, and manipulating props.

Pooled Particle System:
Implemented an object-pooling system for particle effects, reusing existing particle objects instead of repeatedly instantiating and destroying them during gameplay.

What I Learned

Design:
I learned the importance of constraints in a gameplay loop. Even with a limited number of mechanics and resources, their interactions can create complex decisions and multiple ways for the player to solve a problem.

Technical:
I learned that a good technical system flow starts with a clearly defined design flow. Understanding exactly how the game should behave before implementing the system made it easier to structure the code and connect different systems together.

Core Design / Game Concept

AmazeNet is a 2D casual puzzle game where the player navigates procedurally generated mazes. Every maze is generated at runtime, allowing the game to create an unlimited number of maze layouts.

The game has two modes. In Session Mode, the player must complete a set of mazes within a limited amount of time. In Casual Mode, there is no time limit, and the player can choose the maze size and play at their own pace.

Design Principles

Focus-Based Gameplay:
AmazeNet is designed to keep the player's attention focused on solving the maze. The core gameplay follows a continuous loop where the player completes a maze and the next maze is generated immediately. This structure is shared across both game modes, while minimal interactions and UI keep unnecessary distractions away from the maze-solving experience.

Systems Design

Procedural Maze Generation:
AmazeNet generates its mazes using the Recursive Backtracker algorithm. The maze begins from a randomly selected starting cell and does not have a predefined endpoint during generation. Once every cell in the maze has been mapped, the generator searches for cells that are blocked on three sides and treats them as possible endpoints. From these candidates, an endpoint farther from the starting position is selected, preventing the exit from being placed too close to the start while still allowing variation between generated mazes.

Game Modes:
AmazeNet has two game modes, Rush Mode and Casual Mode, designed around two different play styles. Casual Mode is for players who want to solve mazes at their own pace without time pressure, while Rush Mode is designed for players who want a more challenging experience where they must solve mazes under a time constraint. Both modes use the same core maze-solving gameplay but change the conditions around how the player experiences it.

Challenges & Solutions

Maze Navigation

Challenge:
Moving through a generated maze created a control problem. Continuous movement would require the player to manually navigate every corridor, while moving one cell at a time would make traversal slow and repetitive. This was especially problematic in Rush Mode, where time is a major gameplay constraint.

Solution:
I created a navigation grid alongside the maze-generation process. As the generator moves from cell to cell, it compares the current movement direction with the next direction. When the direction changes, that cell is marked as a navigation point. Dead ends are also collected during generation and added as navigation points after the maze is completed. This results in navigation points at corners, intersections, and dead ends.When the player gives a movement input, a ray is cast in that direction. If it reaches a valid navigation point, the player moves directly to it; if the ray hits a wall, the movement is blocked.

Time Reward System

Challenge:
Rush Mode uses a time limit, but maze difficulty can vary because the mazes are procedurally generated. A larger or more complicated maze can take significantly longer to solve, leaving the player with too little time for the remaining mazes in the wave. This could make failure frustrating when the player has no way to recover lost time.

Solution:
I introduced collectible time dots that allow the player to recover time during a wave. Each wave contains 3 mazes and has a maximum of 4 time dots, with no more than 2 appearing in a single maze. Each collected time dot adds 20 seconds to the timer.Time dots are placed during maze generation. The generator already identifies dead-end cells while creating the maze, so eligible dead ends are randomly selected as time-dot locations, excluding the cell selected as the maze endpoint. This places the reward away from the main objective and can require the player to decide whether spending time reaching it is worth the additional 20 seconds.

Technical Work

Procedural Maze Generator:
Implemented a Recursive Backtracker-based procedural generation system for creating randomized maze layouts at runtime.

Navigation System:
Built a navigation-point system during maze generation that identifies corners, intersections, and dead ends for streamlined player movement.

Dynamic Endpoint & Reward Placement:
Implemented dead-end detection to dynamically select maze endpoints and valid time-dot spawn locations from generated maze data.

Runtime Maze Regeneration:
Generates and replaces maze layouts during gameplay, allowing the continuous maze-solving loop without requiring predefined levels.

What I Learned

Design:
I learned how meaningful constraints can give direction to a simple gameplay loop. In AmazeNet, adding a time limit created a failure condition for continuous maze solving, which later led to the time-reward mechanic and the risk/reward decision of taking a detour to collect additional time.

I also learned that solving a technical problem can influence the game design itself. The navigation-point system started as a solution for making movement through procedurally generated mazes faster and less repetitive, but it ultimately became part of how the player interacts with the maze.

Technical:
I learned that procedural generation can do more than create level geometry. Data produced while generating the maze—such as dead ends, intersections, and direction changes—can be reused by other systems for navigation, endpoint selection, and time-dot placement. This taught me how one core system can provide data that supports multiple gameplay systems.< /p>

ABOUT

PROJECTS

TWEAKARC

Core Design / Game Concept

Design Principles

Player Freedom & Experimentation

Experimentation Loop

Limited Resources, Multiple Solutions

Systems Design

Ball Movement System

Control System

Level Loading System

Scoring System

Challenges & Solutions

Level Creation & Management

Challenge:Creating every level as an individual Unity scene would make level creation and maintenance more complicated. Each new level would require a separate scene and repeated environment setup, making the project harder to manage as more levels were added.

Scoring System

Challenge:Using the same scoring requirements for every level would not work well because each level has a different layout, difficulty, and multiple possible solutions. A fixed number of tries or bounces could unfairly reward or penalize the player.

Technical Work

Custom Unity Editor Tool: built a tool to create/save level data as JSON.

Runtime Level Loading: loads and unloads level data into the gameplay scene at runtime.

Gameplay State Management: handles states like Edit, Play, Reset, Completed

Prop Interaction System: code for selecting, moving, rotating, and manipulating props.

Pooled Particle System: Implemented an object-pooling system for particle effects, reusing existing particle objects instead of repeatedly instantiating and destroying them during gameplay.

What I Learned

Design: I learned the importance of constraints in a gameplay loop. Even with a limited number of mechanics and resources, their interactions can create complex decisions and multiple ways for the player to solve a problem.

Technical: I learned that a good technical system flow starts with a clearly defined design flow. Understanding exactly how the game should behave before implementing the system made it easier to structure the code and connect different systems together.

AmazeNet

Core Design / Game Concept

Design Principles

Systems Design

Challenges & Solutions

Maze Navigation

Time Reward System

Technical Work

Procedural Maze Generator: Implemented a Recursive Backtracker-based procedural generation system for creating randomized maze layouts at runtime.

Navigation System: Built a navigation-point system during maze generation that identifies corners, intersections, and dead ends for streamlined player movement.

Dynamic Endpoint & Reward Placement: Implemented dead-end detection to dynamically select maze endpoints and valid time-dot spawn locations from generated maze data.

Runtime Maze Regeneration: Generates and replaces maze layouts during gameplay, allowing the continuous maze-solving loop without requiring predefined levels.

What I Learned

Challenge:
Creating every level as an individual Unity scene would make level creation and maintenance more complicated. Each new level would require a separate scene and repeated environment setup, making the project harder to manage as more levels were added.

Challenge:
Using the same scoring requirements for every level would not work well because each level has a different layout, difficulty, and multiple possible solutions. A fixed number of tries or bounces could unfairly reward or penalize the player.

Custom Unity Editor Tool:
built a tool to create/save level data as JSON.

Runtime Level Loading:
loads and unloads level data into the gameplay scene at runtime.

Gameplay State Management:
handles states like Edit, Play, Reset, Completed

Prop Interaction System:
code for selecting, moving, rotating, and manipulating props.

Pooled Particle System:
Implemented an object-pooling system for particle effects, reusing existing particle objects instead of repeatedly instantiating and destroying them during gameplay.

Design:
I learned the importance of constraints in a gameplay loop. Even with a limited number of mechanics and resources, their interactions can create complex decisions and multiple ways for the player to solve a problem.

Technical:
I learned that a good technical system flow starts with a clearly defined design flow. Understanding exactly how the game should behave before implementing the system made it easier to structure the code and connect different systems together.

Procedural Maze Generator:
Implemented a Recursive Backtracker-based procedural generation system for creating randomized maze layouts at runtime.

Navigation System:
Built a navigation-point system during maze generation that identifies corners, intersections, and dead ends for streamlined player movement.

Dynamic Endpoint & Reward Placement:
Implemented dead-end detection to dynamically select maze endpoints and valid time-dot spawn locations from generated maze data.

Runtime Maze Regeneration:
Generates and replaces maze layouts during gameplay, allowing the continuous maze-solving loop without requiring predefined levels.