Skip to content

Project Architecture

The architecture of "Train Your Foes" is built on a standard Unity project foundation but features a clear separation between its distinct gameplay systems and a unique pipeline for its AI engine. This document outlines the project's structure, key scripts, and the flow of data and scenes.

1. Unity Project Folder Structure

The project's assets and code are organized into a logical folder structure within the main Assets directory. This ensures that different types of assets are kept separate and easy to manage. Based on the project screenshots, the structure is as follows:

Assets/
├── Animations/       # Animator controllers and animation clips for player and enemies.
├── Fonts/            # Font files used for UI elements.
├── GOTHIC ASSETS/    # Art assets for the gothic/cyber-horror theme.
├── MMDevelopers/     # (Placeholder for developer-specific assets or tools)
├── PlatformerSet1/   # Art and tile assets for the platforming levels.
├── Prefabs/          # (Assumed folder for reusable GameObjects like Player, Enemies, UI)
├── Results/          # Output folder for training data.
├── Scenes/           # All playable game scenes.
│   ├── F LEVEL.unity
│   ├── O LEVEL.unity
│   ├── E LEVEL.unity
│   ├── S LEVEL.unity
│   └── final_fight.unity
├── Scripts/          # All C# source code files.
│   ├── Enemy/        # Scripts related to enemy behavior.
│   ├── Player/       # Scripts related to player behavior.
│   └── ... (Other scripts like Battle_System, SceneController, etc.)
├── Sprites/          # 2D art assets for characters, UI, etc.
├── TextMesh Pro/     # Assets and resources for the TextMesh Pro package.
└── Tilemap/          # Tile assets used for building the platforming levels.

2. Core C# Scripts

The game's logic is driven by a collection of specialized C# scripts, each with a distinct responsibility.

Battle_System.cs

This is the "brain" and central manager for the final boss encounter. It operates as a state machine, controlling the entire flow of the battle. * Responsibilities: Manages the battle state (PLAYERTURN, ENEMYTURN, etc.), instantiates combatants, receives UI input, and coordinates between the player, the AI, and the HUD.

QLearning.cs

This is the core of the artificial intelligence. It is a self-contained class, likely part of the Battle_System.cs file, that handles all the logic for the Q-Learning algorithm. * Responsibilities: Initializes and manages the Q-Table, provides a function for the AI to query the best action, handles reward calculation and Q-Table updates during training, and loads the pre-trained Q-Table from a .txt file.

PlayerController.cs (or similar script in Player/ folder)

This script manages the player's actions during the 2D platforming levels. * Responsibilities: Handles player input (movement, jumping, attacking), controls the player's physics, and communicates with the player's Animator component to trigger animations.

PlayerUnit.cs & EnemyUnit.cs

These are data-centric "model" scripts attached to the player and enemy prefabs. They hold the core stats and state for each combatant. * Responsibilities: Store variables like maxHP, currentHp, damage, etc., and contain methods like TakeDamage() and Heal() that are called by the Battle_System.

PlayerBattleHUD.cs & EnemyBattleHUD.cs

These scripts are responsible for updating all the UI elements on the screen during the battle. * Responsibilities: Update health bar sliders and text, manage the player's "Aura Meter", and display dialogue text.

SceneController.cs

This script manages the loading and transitioning between the different game scenes. * Responsibilities: Contains the logic to load the next level in the sequence when a player completes the current one.

FinishPoint.cs

A simple but crucial script attached to the exit "door" GameObject at the end of each platforming level. * Responsibilities: Detects when the player has reached the end of the level and then calls the SceneController to load the next scene.

3. Scene Management and Flow

The game follows a linear progression through the platforming levels to the final confrontation. There is no main menu; the game begins directly in the first level.

Scene Flow: F LEVEL.unity → O LEVEL.unity → E LEVEL.unity → S LEVEL.unity → final_fight.unity

A unique aspect of the game's design is that the tilemap layouts of the four platforming levels are shaped like the letters F, O, E, and S, creatively spelling out the game's title.

4. Animation System

Character animations are controlled using Unity's built-in Animator system. * The system uses an Animator Controller to function as a state machine for animations (e.g., Idle, Run, Jump, Attack). * C# scripts do not directly play animations. Instead, they set parameters (e.g., animator.SetBool("IsJumping", true)) in the Animator Controller, which then automatically handles the transition between animation states.

5. AI Data Pipeline: From Training to Gameplay

A key architectural feature is the separation of the AI's training and gameplay phases, ensuring high in-game performance.

1. Training Phase (Offline): * A headless C# simulation (a version of the game logic that runs without graphics) is executed for thousands of episodes. The QLearning agent updates its Q-Table in memory. * At the end of the training, the final, optimized Q-Table data is saved (serialized) to a .txt file inside the Assets/Results/ folder.

2. Gameplay Phase (In-Game): * When the final_fight.unity scene loads, the Battle_System script creates an instance of the QLearning class. * The QLearning class's constructor reads the .txt file, deserializes the data, and populates its in-memory Q-Table with the fully trained values. * The boss AI then uses this static, pre-trained table to make all of its decisions, resulting in intelligent behavior without any real-time learning overhead.