Rpg-Simulator

Documentation

User

World

Biomes Desert Shrubland Grassland Forest Swamp

Classes

Wanderer Stamina The Wanderer embodies determination and willpower, perservering despite impossible odds through their innate ability to withstand immense blows, recuperate, and press on in an instant.

Brute Strength The Brute cares not for survival, but for feats of strength and courage in the face of adversity. They rely on raw power to crush their foes, and they often find themselves in risky situations because of it.

Tactician Perception The Tactician is a siezer of opportunities. What they lack in brawn they more than make up for with their keen sense of awareness. Their gambles may not always pay off, but when they do they could spell death for your enemies instead of you.

Dev

MVP

Create a procedurally generated RPG simulation that embraces chaos and instability, balanced by user input and natural in-game forces

• player systems
  • class system: allow player to choose a player class that forms a unique, distinct way of interacting with the world
    • ability system: players/enemies utilize an ability-based combat system
      • neutral abilities: BasicAttack, HeavyAttack
      • class-specific
      • abilities incur a cycle-based cooldown and are used in order of priority within the player's abilities table
  • skill system: players accumulate skill points for specific skills by doing specific actions
    • weapon skills accumulated in combat while using a particular weapon type
      • the idea is that cumulative stats like this can form the character in some way according to each individual seed.
  • inventory system: players can manage their own inventory items
    • equipping and unequipping equippable items
    • deleting items
    • reordering items
  • item system: players have a chance to randomly find items including weapons, armor
    • weapons: any class can equip any type of weapon; the only determinant is weapon skills
    • armor: any class can equip any armor type, but each armor type has benefits and drawbacks, relying mainly on armor skill of that particular type
    • items are randomly generated from a list of stat modifiers on creation
• enemy system: player encounters enemies across the world when attempting to interact with resources
• environmental system: create a dynamic environment with terrain, weather, and organic life simulation that directly impacts the player's world interaction somehow
  • simulates a basic world environment using procedurally generated terrain samples
    • player resources are generated according to tile conditions related to terrain
• ui system: create a basic, functional UI that displays data relevant to a playthrough and allows the user to make necessary decisions regarding their character
  • world panel
    • terrain: allows user to see stats related to world generation, including biome and resources left
  • player panel
    • stats
    • abilities: shows all abilities available to the player, including the ability's stats
    • skills: shows all player skills
    • inventory
      • equipment viewer/editor
        • equipment slots
        • equipment stats
  • combat panel: shows only high-level data regarding the entities in a combat encounter
    • entity vitals
    • vital stats -> name, level, health

Further

• subclass system: once a particular stance threshold is reached, player can choose to specialize in an associated subclass
  • stance system: player has 3 "stances" that can be cycled through, allowing experience to be accumulated for that particular stance
    • stances represent strategy/role types: defensive, offensive, utility
    • only one stance can be active at a time, but players can switch stance when a new party member is acquired
• party system: player has a random chance to encounter neutral entities, within particular progress thresholds, that can be adopted into the player's party
  • progress thresholds are determined by player : enemy stat ratios
    • thresholds act primarily as a way to smooth out world randomness by giving agency to the player at specific progress levels
  • neutral entities are a type of player starting with a randomized class
  • player can choose to adopt this player into their party or pass
• environment simulation
  • implement organic matter to terrain with basic life simulation

Reference

Tasks

• [ ]

DONE

• scrap current encounters system
  • remove from time controller
  • revert player controller logic
  • revert enemy controller
• revert time controller
• timecontroller only controls time system, not dependencies - _routing dependency systems through time_controller results in too many states and sub-states to manage effectively - instead of trying to rewrite the internal _process system, utilize it
• make dependency controllers call _process directly
• validate dependency controllers at controller-level during processing
• rework encounter system
  • remove current encounter data in tiles
  • every resource has r chance to spawn an enemy encounter before the resource is collected
  • on encounter, encounter controller makes calls to involved entity controllers until an entity is defeated
• ensure entity controllers are checking for defeat conditions at all times
• implement logging to log file per game
• implement fundamental systems: resource collection, encounters, player stat progression
• refactor codebase
• add base entity controller and reorganize player/enemy controller functions according to class hierarchy
• re-implement actions controller on player/enemy entities
  • I have considered how to implement time in this game, and I believe the best model is this:
    • the time controller asserts when time cycles occur and how long they are
    • entity actions have a certain duration consisting of time cycle integers
    • entity actions are carried out until completion, but are only evaluated during time cycles
      • since entity actions are whole integers, action completion will be determined by the number of time cycles, rather than the length of the events occuring during a time cycle
      • this also means we can clear up any errors before the start of the next cycle, but after (and not during)events/actions have occurred
• implement basic attack action
• implement basic class structure
• implement food surplus mechanic
  • if player health full when food resource is acquired, resource goes into food surplus
  • food surplus is checked after combat and regen rate applied to health if surplus exists
• re-implement single-tile movement for player
• implement basic item system with a Sword weapon
  • player is given a random weapon within Maps 1-2 that directly prolongs life cycle
• implement basic skill system, starting with Weapon Skill
  • player builds skill points by utilizing items of a specific proficiency
    • i.e. player builds x sword skill every time player attacks with sword
• restructure controller initialization process
  • too much controller data is being routed through entities before validation/initialization
    • results in mismatched data references and cumbersome validation processes
  • in sequence, controllers should...
    • initialize entities and entity data they control
    • validate entity data
      • initialize + validate ALL entity data, including sub-system controllers, before updating parent entity data
        • i.e. WorldController should initialize and validate World + ALL dependency data in World.data before main processing loop starts, not during
    • if controller entity data references are kept on system controllers, they should have callback functions for when said data reference changes
    • start processing ONLY IF all data + parent entity data is validated

Copilot Sessions

Session: Fundamental Systems Implementation

Implemented core RPG systems and hardened architecture:

• Controller Architecture: Fixed initialization order and reference assignment for WorldController, TimeController, and dependency controllers
• Time System: Refactored to use delta-time, robust cycle timing, and configurable frame rates
• Combat & Abilities: Added cycle-based action durations (BasicAttack: 1 cycle, HeavyAttack: 2 cycles), cooldown management, and attack queueing
• Inventory System: Created InventoryManager for equip/unequip, add/remove, and reorder operations on Player and Enemy inventories
• Resource & Encounter: Validated procedural resource generation and encounter spawning logic
• Logging: Confirmed robust file logging with timestamps
• Procedural World: Verified terrain generation with soil composition, erosion simulation, normalization, and biome detection
• Code Quality: Fixed all compilation errors and standardized GDScript patterns