Nakshatra
BACK TO PROJECTS

SHATTERED REALMS

A 2D action platformer developed for the Inter-IIT Tech Meet 14.0 Game Development problem statement. Features modular architecture, an innovative death power-up system, and consistent color theory across game states.

Godot EngineGDScriptGame DesignState MachinesGame AI

Overview

Shattered Realms is a 2D action-adventure platformer developed as a competitive entry for the Inter-IIT Tech Meet 14.0 Game Development problem statement. Playing as a weakened wizard who has lost his magic after a crushing defeat, the player journeys through a corrupted forest, a maze-like town, and a puzzle-filled castle to regain his abilities and confront the Evil Wizard once more.

The game achieved the 4th highest technical score among 23 IITs, validating the robust system architecture, game design principles, and gameplay mechanics built under strict competition constraints.

Game Design & Aesthetics

Color Consistency & State Communication

A major design focus was using environmental color palettes to communicate the game state and narrative progression to the player seamlessly:

  • Start Menu (Defeat): Features a stark red background with the player lying defeated on the ground, emphasizing the loss of power.
  • Pause Menu: The player is standing against a brownish, neutral background, indicating a momentary halt in the journey.
  • Win Screen (Restoration): The player is seen running forward across a vibrant green background, symbolizing that peace and balance have been restored.

Death Power-Up System

To balance accessibility for beginners with challenges for skilled players, we introduced a unique Death Power-Up System. Every death grants the player a choice of boosts—such as increased health, movement speed, jump height, burn damage, or stronger sword attacks. This keeps each playthrough fresh and rewarding while pushing advanced players to attempt difficult "no-death" runs.

Consistent Progression

The game features a steady progression curve where narrative logic ties directly to player abilities. For instance, defeating a Fire Beast mini-boss in Level 1 grants the player Fire Powers. These powers are then immediately contextualized in Level 2 through environmental puzzles and finally tested comprehensively in Level 3 during the multi-ability boss fight.

Core Technical Systems

Modular Architecture

The game relies on a highly modular architecture where combat, puzzles, and traversal exist as entirely separate modules. This decoupling allowed parallel development during the tight competition timeframe and simplified debugging.

Puzzle Sequencing Logic

Puzzles utilize a signal-based input system designed to prevent soft-locks. The interconnected logic safely manages gate-button interactions and state resets without trapping the player.

Enemy AI Framework

Player and enemy behavior is governed by robust finite state machines running on distinct physics layers and detection zones. This cleanly separates movement, attacks, collisions, and interaction states, allowing distinct enemy archetypes to present varied timing challenges to the player.

The Journey (Game Flow)

  1. Level 1 — The Forest: The hero awakens weakened, relying solely on his sword. The player learns basic movement, timing-based combat, dodging, and how to use inventory items like potions. The level concludes with a Fire Beast mini-boss, rewarding the player with the Fire Power ability.
  2. Level 2 — The Town: An abandoned, maze-like environment featuring twisting routes and stronger roaming enemies. Players must utilize their newly acquired abilities to solve button-gate puzzles and unlock map sections.
  3. Level 3 — The Castle + Final Boss: The Evil Wizard's stronghold. This area tests everything the player has learned, combining traps, elite enemies, and multi-step puzzles. The final confrontation with the Evil Wizard requires utilizing every regained ability to dodge, counter, and strike during tight attack openings.

Key Learnings & Challenges

Developing a complete game for a competition brought several technical hurdles:

  • Cinematic Camera Cuts: Implementing smooth game-to-camera cuts required strict player-control locking and highly accurate camera tweening to prevent sequence breaking.
  • Collider Stability: Providing player freedom often exposed edge-case collider problems, including misaligned hitboxes and unstable triggers that required meticulous layer masking and physics tuning.
  • Inventory Management: Engineering the inventory system was significantly challenging, specifically ensuring that consumable items (like speed, healing, and attack buffs) were properly stored, updated, and applied at runtime without state desynchronization.