Campus Chaos

Team Members Aira Kirana Nurrizqi: 1733447 Farrell Aurelio William: 1750940 Sandhya Mahendra Dhaneswara: 1764255

Description of the game

Campus Chaos is a student-life survival game built in Python and Pygame. The player tries to survive a full 7-day academic week while managing energy, stress, money, and focus. Each day lasts a short amount of real time, and the player must move across campus, complete missions, make risky or safe choices, use powerups carefully, and respond to shifting academic pressure.

The game is built around constant decision-making:

take a safe mission or a riskier high-reward mission
spend time recovering or keep pushing productivity
deal with random temptations and stress spikes
survive dream phases between days
decide whether to follow Mika, the in-world friend NPC, into short social interactions or stay on task

The player wins by completing enough missions before the end of Day 7.

Explanation of how AI is integrated

AI is integrated directly into the game loop using Groq.

The AI is not used as a generic chatbot. Instead, it acts as a structured game director that generates constrained gameplay content the engine can safely validate and apply.

Current AI usage:

Day mission generation
- generates the two mission options shown to the player
- safe mission: lower pressure
- risk mission: higher pressure
Dynamic difficulty control
- adapts mission pressure based on the player state
- considers energy, stress, money, focus, day, time left, mission score, combo, current location, and route timing
Modifier and enemy planning
- generates the current daily student-life problem/modifier
- generates the enemy pressure plan for the day
Dream phase generation
- generates short dream missions between days
- dream missions create tension between one day and the next
Mika encounter generation
- generates Mika’s mood, one short line, and 2-3 structured choices
- Mika can escort the player after an interaction, and the destination can now be AI-directed as well within validated room choices
- all stat effects still remain decided by the game engine, not the AI

Important design choice:

the AI never directly edits save state or chooses arbitrary stat numbers
the AI only generates structured content
the engine validates the output and applies the consequences safely

How live AI is enabled:

put a Groq API key in the project .env file
use:

GROQ_API_KEY=your_key_here

if the key is present and valid, the HUD will show LLM: LIVE

What happens if there is no live AI:

if Groq is missing, invalid, offline, or rate-limited, the game automatically falls back to built-in structured offline content
this means the game still generates missions, dream sequences, modifiers, and Mika interactions using its own internal fallback logic
the game remains fully playable even when the API is unavailable
the HUD clearly shows whether AI is LIVE or OFFLINE

Any additional info your team wishes to add

Tech stack:

Python
Pygame
Groq API

Design highlights:

AI is used as a dynamic director, not just flavor text
the game uses route-aware mission timing
the map changes across the week
dream phases create a day-night tension loop
Mika adds adaptive social pressure without turning into a full chatbot
Mika is an in-world friend NPC who can interrupt the player, offer structured choices, and physically guide the player to locations across campus
the cafe interior is a separate playable space with its own interaction points, including buying coffee and taking a seat to recover
the game includes a built-in offline fallback system, so the run still works even if the live API is unavailable

What makes the project interesting:

combines systems gameplay with structured AI generation
uses AI for adaptive pacing and mission design
keeps game consequences engine-controlled for stability
mixes campus survival, navigation, interiors, dream sequences, and social interruptions into one short-run loop

Operational notes:

to enable live AI, add GROQ_API_KEY=your_key_here to .env
if the API key is missing or invalid, the game automatically switches to its built-in offline fallback content
if the API is rate-limited, the game also falls back temporarily instead of breaking gameplay

Demo video notes:

the gameplay recording has noticeable lag introduced by screen recording overhead
because of that recording lag, some dream-state moments are shorter or appear skipped in the captured footage
during the recorded demo, the AI appears OFFLINE because the Groq API hit a rate limit at recording time
this is a live API limitation, not a gameplay blocker, because the project is designed to continue running using built-in fallback content

Potential future improvements: