Client-Server Architecture

Implemented a clean separation between server and client logic using RemoteEvents and RemoteFunctions. The server validates all player guesses via chat input, ensuring game integrity, while the client handles UI updates and visual feedback. BindableEvents facilitate communication between local scripts (GUI ↔ Workspace logic).

Modular Code Organization

Scripts are organized into logical folders: server scripts in ServerScriptService, client scripts split into GUI and Workspace handlers, and ModuleScripts storing word chain data. This structure promotes maintainability and scalability.

Dynamic World Interaction

Using CollectionService with tagged objects (StartWalls, WordWalls, StageWalls), the game dynamically manages physical walls that display word chains via SurfaceGui. Walls become passable when answers are correct, with smooth transparency transitions.

Progressive Hint System

Hints reveal letters incrementally—each use exposes one more character of the answer. The system tracks hint state per stage and integrates with MarketplaceService for optional in-game purchases.

Data Persistence

Player progress is saved using Roblox's DataStoreService. Each difficulty level tracks the player's current word list independently, allowing players to resume where they left off across sessions.

Polished UI/UX

Buttons feature hover animations using TweenService with easing functions. Sound effects toggle on/off per player preference, and the interface updates reactively based on game state (stage number, difficulty, completion status).

Custom Game Loop

Implemented a threaded game loop running at 60 ticks per second. The loop handles all game logic—entity updates, collision checks, state management, and rendering—in a controlled, frame-independent cycle. This taught me the fundamentals of real-time game architecture.

Java Swing & AWT Rendering

Used JFrame and JComponent for window management, with Graphics2D handling all sprite rendering. Each entity draws itself using custom drawSelf() methods, with sprite selection based on direction and state (hurt, attacking, idle). No external rendering libraries—just Java's built-in capabilities.

Object-Oriented Architecture

Clean separation of concerns with dedicated classes: User (player), Slime (enemies), Arrow (projectiles), and Map (game manager). Each class encapsulates its own state, behavior, collision logic, and rendering—demonstrating strong OOP principles.

Custom Collision Detection

Wrote collision detection algorithms from scratch using Euclidean distance calculations and bounding box checks. The system handles player-enemy collisions (with knockback), attack hitbox detection, and arrow impacts—all without physics engine assistance.

Enemy AI & Variant System

Four distinct slime types—Regular, Fast, Tank, and Boss—each with unique stats (health, speed, size). Slimes move randomly using tick-based direction changes and bounce off walls. The type system uses constructor parameters to configure variants, keeping the codebase DRY.

State Management & Invincibility Frames

Implemented damage states with invincibility frames—players and enemies can't take repeated damage within a cooldown window. Attack states freeze player movement during swings. These mechanics required careful tick-based timing and boolean state tracking.

Custom Sprites & Visual Feedback

All sprites were custom-made and loaded via ImageIcon. Characters have directional sprites (up, down, left, right) and hurt states. Arrows display warning icons before entering the screen, and attack hitboxes render visually to give players feedback.

Sprites by Pratyush Karki