Pavan Karoliya

Lanos

Published 17 July 2026·21 min read

Executive Summary

Solo Leveling’s “System Architect” (Kandiaru) created “The System” – a game-like leveling interface guiding the protagonist’s growth. It provides quests, stats, skills and rewards to transform an ordinary hunter into a super-powered vessel. The System’s core philosophy is forced, narrative-driven progression: it uses quests and automatic bonuses to push the user from zero toward a final goal (initially Ashborn’s vessel) in a structured, quest-based learning framework. Translating this to real-world learning, we propose an immersive AR/MR educational system: a single learner dons mixed-reality gear to enter virtual “dungeons” and “gates” where each scenario is a self-contained lesson. Like The System, it will gamify education with quests and stat-based feedback, but powered by modern technologies (HMDs, sensors, cloud AI, etc.).

This report outlines a rigorous, PhD-level blueprint for such a system. We review Solo Leveling’s lore and mechanics (the System’s design and algorithms) and then present a full technical design for an AR/MR adaptive learning platform. We include detailed architecture diagrams (Mermaid), comparison tables of hardware/engines/frameworks/sensors, algorithmic flow (pseudocode), data schemas, and a development roadmap. Finally we analyze risks, propose evaluation metrics and testing protocols, and recommend key references (open-source and literature) for implementation. All statements are supported by authoritative sources in game-based learning, VR/AR education, adaptive AI, and immersive hardware.

Solo Leveling: The System Architect & “The System”

Background: In Solo Leveling, Kandiaru the Demonic Spectre (the Architect) created The System as an automatic progression engine. Candiaru’s goal was to help the Shadow Monarch Ashborn find a suitable human vessel by accelerating a hunter’s growth. The System is conceived as a video-game interface: it appears only to the chosen player (Jinwoo) and grants levels, stats, quests, and items. In lore, every time the player gains XP or completes quests, The System prompts level-ups and rewards (e.g. stat points, inventory items, gear). For example, Jinwoo’s first encounter with The System was during a dungeon raid, after which he could “train with the System” and found his strength increasing explosively.

Core Philosophy (Game-Based Growth): The System’s philosophy is mastery through gamification. Its interface is explicitly designed to look like an RPG (levels, skills, stats, gold, shop) so the user isn’t confused. Every element encourages continuous improvement:

Quests & Rewards: The System issues timed quests (kill X monsters in Y minutes) with high-stakes: failure often means in-story death. Completing quests yields stat bonuses and items. This enforces a 0→end progression by tying each step to a narrative task.
Levels & Stats: Each level-up passively increases all base stats by 1 and grants extra stat points to allocate. (E.g., +5 points per level, +3 for daily quests). Stats cover Strength, Agility, Stamina, Intelligence and Sense. This lets the player shape their growth (e.g. focus on Intelligence for magic skills). In effect, it’s a point-based progression system with both automatic and user-directed upgrades.
Skills & Abilities: Leveling unlocks new skills and powers. The System even provides passive survival abilities (automatically triggered shields, warnings of danger) to “keep the player alive” until they reach the end goal. In other words, it continuously adapts the character’s capabilities as needed.
Inventory & Shop: An unlimited inventory and an in-system shop (with game-gold currency from kills) let the player acquire equipment and consumables. Special “random loot boxes” can yield desired or necessary items, akin to rewards or skill packs. This encourages exploration and grinding, mirroring how a learner explores topics and earns resources in gamified learning.

Forced Learning & Adaptation: Importantly, The System is forcing evolution: it deliberately designs challenges that Jinwoo must overcome (often life-or-death) and automatically adapts to ensure he survives and learns. It uses his emotional state and performance to adjust difficulty (e.g. issuing increasingly harder quests as he grows). When threats appear (enemies intent on killing him), it even warns him. This “closed-loop” design is a prime example of adaptive, reinforcement-like progression in fiction.

Narrative Arc (0-to-End Story): Over the story arc, the System takes Jinwoo from Level 1 to 100 and beyond, culminating in world-changing events. Each story Dungeon Arc (D-Rank, Double Dungeon, War Arc, Epilogue) corresponds to phases in the progression. For instance, after reaching Level 100, Jinwoo faces a final test from Kandiaru (the Architect) in the Double Dungeon arc. Later, after epic battles, Ashborn (the Shadow Monarch) ultimately deletes the original System once its purpose was achieved. In the “Ragnarok” sequel, the System is resurrected with new properties (testing a new character with “very different quests”). This demonstrates the System’s flexibility (e.g. offering job-choices, merging classes).

Key References: We base this analysis on the Solo Leveling lore (fan wiki sources). For instance, the wiki states:

“The System was designed like a video game… provided Jinwoo with quests, a leveling system with skills and stats, an unlimited inventory… and an in-built store”.
“As later revealed, the System was originally created by Kandiaru to help Ashborn develop a human vessel… [and] was deliberately designed with its video game interface”.

These details form the conceptual requirements for our AR/MR system: it must be game-like, adaptive, quest-driven, and goal-focused.

Proposed AR/MR Adaptive Learning Platform

We propose a Mixed-Reality (MR) educational system inspired by Solo Leveling’s System. A single learner (the “player”) wears MR gear and enters virtual “dungeons” or simulations for individual learning tasks. Each “gate” or “level” is a lesson or project in science, engineering, or technology. The system uses AI/ML to adapt content and difficulty in real time, mirroring The System’s dynamic adaptation and progression.

System Architecture

graph LR
  %% User-side devices
  subgraph USER_DEVICE [User Device / Wearables]
    Direction LR
    HMD["MR Headset (HMD)"]
    HAPTICS["Haptic Feedback Suit/Gloves"]
    SENSORS["Sensors (Motion, Eye, Bio)"]
  end

  %% Local processing
  subgraph LOCAL_PC [Local Compute]
    EDGE["Edge/PC/Console"]
    XR_ENGINE["Game/AR Engine (Unity/Unreal)"]
    LOCAL_AI["On-device AI Models"]
  end

  %% Network / Cloud
  subgraph CLOUD [Cloud/Server Infrastructure]
    CONTENT_DB["Content & Asset DB"]
    ADAPT_AI["Cloud-based AI/ML Engine"]
    REINFORCE_AGENT["RL Training Agent"]
    USER_DB["User Profiles & Progress DB"]
    AUTH["Security & Auth Services"]
  end

  %% Connections
  HMD --> XR_ENGINE
  HAPTICS --> EDGE
  SENSORS --> LOCAL_AI
  LOCAL_AI --> XR_ENGINE
  XR_ENGINE --> EDGE
  XR_ENGINE -->|XR Streaming / Synchronization| CLOUD
  EDGE --> ADAPT_AI
  ADAPT_AI --> REINFORCE_AGENT
  REINFORCE_AGENT --> ADAPT_AI
  EDGE --> CONTENT_DB
  ADAPT_AI --> CONTENT_DB
  EDGE --> USER_DB
  AUTH -.-> EDGE

Diagram: A high-level architecture. The User Device block shows the learner’s gear: an MR headset (e.g. HoloLens, Meta Quest Pro) plus haptic suit or gloves and various sensors. These connect to local compute (an edge server or high-end PC) running an XR engine. The engine streams the immersive world to the headset and processes user input. Complex AI (reinforcement learner, curriculum manager) may run partially on-device and partially in the cloud. A cloud service houses the content database (3D assets, lesson plans), AI training services, and user data for persistence and security. Biometric/sign-in services (AUTH) ensure only the proper learner accesses the content. Components communicate over high-speed network (e.g., Wi-Fi 6, 5G) for low-latency.

Key Points (annotated):

User Wearables: MR Headset with high resolution and wide FOV; motion capture/haptic peripherals; eye-tracking and biosensors (heart rate, EEG, etc.) to gauge engagement and cognitive state.
Local Compute (Edge): Ideally a ruggedized PC or mobile edge device (console or on-board chip) running the XR engine (Unity or Unreal) and local AI inference (e.g. on-device neural nets). This minimizes latency and offloads initial heavy VR rendering.
XR Engine: The core VR/AR software, likely Unity or Unreal (see below), handling graphics, physics, and user interaction. It integrates with AI modules via an SDK (e.g. Unity ML-Agents) for adaptive logic.
Cloud Backend: A scalable cloud cluster (AWS/GCP/Azure) hosts the adaptive AI/ML engines and stores content/assets. It runs multi-agent reinforcement learning and curriculum algorithms to generate or select new challenges, and stores user progress. Cloud services also handle persistent user authentication, data encryption, and content streaming.
Adaptive AI: This includes a reinforcement learning agent (possibly multi-agent) that tunes lesson difficulty and content distribution, and a procedural content generator (see algorithms below) that creates new scenarios. A curriculum manager sequenced by learner profile.
Data & Services: Databases for user profiles, performance logs, 3D assets. Web APIs serve new lessons and record results. Security (encryption, OAuth) protects privacy.

This architecture follows recent MR education prototypes. For example, Li et al. (2026) describe an IMPACT platform that uses MR headsets, motion-capture suits, and a closed-loop edge-cloud setup with multi-agent RL to enable real-time feedback and adaptation in immersive training. Similarly, Kishor et al. (2025) implemented an “Agentic AI” VR tutor where a Python-based RL agent integrates with Unity3D to adapt pedagogy via multi-modal sensors. Our design generalizes these ideas: we plan for all modalities (speech, gesture, gaze, biofeedback) and scalable deployment.

Components Comparison Tables

To choose technology stacks, we compare leading options in each category:

Table 1. Hardware Options for AR/MR Headsets and Input Devices

Component	Options	Key Features	Pros/Cons
HMD (VR/AR)	Microsoft HoloLens 2	MR (see-through), hand-tracking, spatial mapping	+ AR pass-through, enterprise support; – expensive, field of view limited.
	Meta Quest 3 (Oculus)	VR/MR mode, inside-out tracking, controllers	+ Standalone, affordable, strong dev ecosystem; – lower resolution than PC VR.
	Varjo XR-4	High-end VR/MR, ultra-HD, eye-tracking	+ Best visuals and eye-tracking; – very high cost, requires PC.
	Magic Leap 2	AR, eye/body tracking, sdk for enterprise	+ AR immersion; – limited content, smaller field-of-view.
Motion Sensors	HTC Vive Trackers	External trackers for full-body pose	+ Accurate, standard for motion capture; – requires base stations, wires.
	Xsens MVN (inertial suit)	IMU-based full-body motion capture	+ Wireless, portable; – calibration drift over time.
	Kinect / Depth Camera	Body tracking via depth sensor	+ No suit needed; – limited precision, indoor only.
Haptics	HaptX Gloves / Teslasuit	Full tactile feedback (pressure, vibration)	+ High realism; – very expensive, weight.
	bHaptics TactSuit (vest/glove)	Vibration motors, lightweight	+ Affordable, wireless; – limited feedback fidelity.
Eye Tracker	Tobii Pro VR Integration Kit	Infrared eye tracking for HMDs	+ Accurate gaze data; – adds weight, cost.
	Pupil Labs Core (open source)	Modular eye tracker for HMDs	+ Flexible, affordable; – requires calibration.
Bio-feedback	Empatica E4 wristband	Heart rate, GSR, temperature sensor	+ Wireless, multi-sensor; – coarse location (wrist only).
	OpenBCI Cyton Board (EEG)	EEG brainwave monitoring, open hardware	+ Research grade, extensible; – setup time, intrusive.

Discussion: Emerging hardware is rapidly evolving. As Bonnet (2025) observes, “lightweight HMDs, immersive haptic systems, and wearable sensors are transforming traditional learning into highly interactive and experiential processes”. High-resolution, untethered headsets (Quest, Varjo) improve mobility. Haptic suits and gloves (HaptX, Teslasuit, bHaptics) can simulate touch and force feedback, useful for engineering and lab simulations. Eye trackers (e.g. Tobii VR) allow gaze-based assessment (where is the learner focusing?) and interaction. Motion trackers (Vive or Xsens) capture body movements, enabling whole-body learning tasks (e.g. assembly training). Biometric sensors (heart/GSR/EEG) feed into affective computing modules to gauge stress or focus, enabling the system to adaptively calm or challenge the user.

Table 2. Software Engines and Frameworks

Category	Options	Notes (License, Platforms, Strengths)
Game Engine / XR	Unity 3D	C#/Unity XR SDK. Strong AR/VR support, ML-Agents, large library. (Free for small teams; multi-platform including HoloLens, Quest)
	Unreal Engine 5	C++/Blueprints. High-fidelity graphics, UnrealXR tools, MetaXR. (Free up to revenue threshold; PC/Console/Quest)
	Godot (open-source)	GDScript/C#. Lightweight, evolving XR support via OpenXR. (MIT license; fewer AR features yet)
	Microsoft Mixed Reality Toolkit	(Unity/Unreal plugin) Enhanced MR/AR features for HoloLens and other XR.
AR Framework	ARCore (Google)	Android-centric AR (phones, Quest), SLAM, plane detection.
	ARKit (Apple)	iOS AR (iPhone/iPad), LiDAR/TrueDepth support.
	Vuforia, EasyAR	Cross-platform AR SDKs (image targets, environments).
AI/ML Framework	TensorFlow / TensorFlow Lite	Widely used, supports mobile inference (e.g. tf-lite for on-device).
	PyTorch / PyTorch Mobile	Flexible Python API, evolving mobile support (MPS, Android).
	Unity ML-Agents	Plugin allowing RL training and inference within Unity (PyTorch backend).
	OpenAI Gym / RLlib	Libraries for building RL environments and agents (RLlib can scale on clusters).
Procedural Gen.	Wave Function Collapse (WFC)	Algorithm for generating puzzle-like maps/levels.
	PCG libraries (Unity, Unreal)	Built-in or third-party tools for dungeon/terrain generation.
	GPT / LLM APIs	For on-the-fly text or quest generation (e.g. story/dialog).
Networking	Photon Engine, Mirror, or WebRTC	Real-time multiplayer/networking libraries (even if single-player, needed for cloud sync).
	AWS/GCP/Azure SDKs	Cloud services (compute instances, serverless functions, real-time databases, CDN).

Discussion: Unity and Unreal dominate XR development. Unity’s ML-Agents toolkit lets us integrate RL directly in the environment (training agents or NPCs). Unreal offers top-notch visuals (Varjo XR heavy clients) but has steeper learning curve. We will likely prototype with Unity due to community support and easier scripting. For machine learning, TensorFlow or PyTorch can be used. RLlib or similar frameworks allow distributed training of agents that manage curriculum or difficulty. Game content (dungeons, quizzes) may be procedurally generated with known algorithms (e.g. cellular automata, Perlin noise, or modern LLMs to write puzzle text).

Table 3. Machine Learning and Adaptive Algorithms

Algorithm / Technique	Role / Function	Example Use-Case
Reinforcement Learning (RL)	Adapt difficulty and strategies via reward feedback	A Q-learning agent chooses to escalate challenge or provide hint based on learner responses.
Curriculum Learning	Sequence lessons from easy to hard	Auto-adjust topic sequence: if learner excels, move to next concept; else repeat with variation.
Meta-Learning	Learns to adapt learning strategy	E.g., MAML or adaptive optimizers to personalize faster to each new learner’s style.
Affective Computing	Analyze emotions/engagement (via sensors) to adapt pace	E.g. if increased heart rate or frustration detected, slow down or give encouragement.
Procedural Content Gen (PCG)	Dynamically generate environments, puzzles, challenges	E.g. generate a random “engineering dungeon” layout with relevant tasks, using RL-based or grammar methods.
Vision/Recognition	Object recognition for real-world interaction	E.g. camera-based detection of physical tools or lab apparatus, using ML image models.
Speech & NLP	Voice commands or LLM-driven hints	AR overlay voice help; generate story/dialog with GPT.

References: Reinforcement learning is key. Sloan & Zhao (2022) used Q-learning for a VR virtual assistant that learns when to interrupt students with hints. We will implement similar RL agents: states = (learner’s current task, stress, quiz score); actions = (increase challenge, give hint, remain silent); rewards = (correct answer, engagement improvement) as in their Table 2. Other approaches include deep RL (DQN, PPO) for complex state spaces.

PCG algorithms will generate the “dungeons” on demand. Maleki & Zhao (2024) define PCG as “automatic creation of game content using algorithms” and note that modern PCG employs search-based, GAN/RL-based, or even LLM-based methods. For example, a search-based algorithm (genetic or DFS/MCTS) could lay out obstacles and labs, or a GAN could generate level geometry, while an LLM (e.g. GPT) could generate context or problems. Combining these ensures virtually infinite, tailored scenarios.

System Algorithms and Pseudocode

Below is illustrative pseudocode for core adaptive functions. (This is conceptual and not production code.)

Adaptive Learning Loop (High-Level):

initialize student_profile
initialize learning_objectives
while not course_completed(student_profile):
    # Evaluate current learner state
    state = observe_state(student_profile)
    # Choose next content or challenge
    action = select_action(state)   # from RL policy: increase_difficulty, give_hint, change_topic, etc.
    # Execute action: update environment
    if action == 'increase_difficulty':
        current_challenge.level += 1
    elif action == 'give_hint':
        display_hint(current_challenge)
    elif action == 'change_topic':
        current_challenge = next_learning_module(student_profile)
    # Simulate learner response (or wait for actual user input)
    reward, next_state = evaluate_response(action)
    # Update RL agent with new experience
    rl_agent.learn(state, action, reward, next_state)
    # Save state and performance
    log_interaction(student_id, action, reward)

Procedural Quest/Dungeon Generation:

function generateDungeon(student_profile):
    # Define difficulty and content based on profile
    level = determine_level(student_profile.knowledge_level)
    themes = choose_engineering_topics(student_profile.focus_area)
    layout = randomDungeonLayout(level)   # e.g. using cellular automata or WFC
    challenges = []
    for room in layout.rooms:
        task = generateTask(themes, room.difficulty)
        challenges.append(task)
    return Dungeon(layout, challenges)

Curriculum Adjustment (example using simple thresholding):

function adaptCurriculum(student_profile, performance):
    if performance >= mastery_threshold:
        # accelerate curriculum
        student_profile.next_topic = get_next_topic()
    elif performance < struggle_threshold:
        # reinforce current topic with variations
        student_profile.next_topic = get_revised_topic(student_profile.current_topic)
    else:
        # continue at current pace
        student_profile.next_topic = student_profile.current_topic
    return student_profile

These algorithms capture the real-time closed-loop learning. The RL loop selects pedagogical actions based on states (similar to Kishor et al.’s neuro-symbolic RL tutor and Sloan’s VR assistant). The procedural generation ensures new content each session. All decisions (what to teach next, how hard) are logged to the student’s profile database for persistence.

Data Model / Schemas

Data is central: we maintain user progress, content metadata, and system logs. Key data entities might be:

Users Table: { user_id, name, email, enrolled_courses, auth_token, current_stats, learning_profile }.
Progress Log: { record_id, user_id, session_id, timestamp, challenges_completed, rewards_earned, quiz_scores, physiological_data }.
Challenges (Quests): { challenge_id, name, topic, difficulty_level, instructions, assets_refs }.
Curriculum/Modules: { module_id, topic, prerequisites, content_refs, learning_outcomes }.
AI Models/Parameters: { model_id, type (RL, CNN, etc.), hyperparameters, last_trained }.
Environment Instances: { dungeon_id, layout_params, seed_values }.

For example, a Users schema may track the learner’s allocated stat points (knowledge in domains), current level, and completed quests (mirroring Jinwoo’s stat block). A Progress log stores performance on each quest (accuracy, time taken) and sensor readings (e.g. average heart rate during task). This supports evaluation and continuity: learners can pause and resume without losing progress, and we can analyze their history.

Security Note: All personal data (e.g. biometrics, performance) should be encrypted and comply with privacy standards. Access control ensures only the authenticated student or instructor can view the data.

Project Roadmap and Milestones

A feasible two-year development plan might be:

Phase 1: Concept & Design (Months 1–3)
– Requirements gathering (educational goals, user demographics).
– System design: finalize architecture (this document), choose tech stack (Unity + TensorFlow or PyTorch).
– Assemble a small multidisciplinary team (developers, AI researchers, instructional designers).
Phase 2: Prototype Core (Months 4–9)
– Develop a minimal MR environment (one “dungeon” level) in Unity with basic VR interactions.
– Implement basic quest system (goals, stat points, simple rewards).
– Integrate sample HMD (e.g. Quest or HoloLens) and motion tracking.
– Build a stub adaptive agent: maybe a rule-based initial tutor.
– Milestone: Demo of a single learner completing a simple module with state tracking.
Phase 3: AI/ML Integration (Months 10–15)
– Integrate RL framework (Unity ML-Agents or external RLlib) for adaptation.
– Collect data in simulation or from real users (beta testers) to train the agent.
– Add procedural generation for a variety of “dungeons” and questions.
– Incorporate additional sensors (eye-tracker, heart rate) for multimodal adaptation.
– Milestone: System autonomously adjusts challenge based on user performance in a closed-loop user study.
Phase 4: Content Expansion (Months 16–20)
– Work with subject-matter experts to create a library of learning modules (STEM topics).
– Develop multiple “quests” per module, with branching outcomes.
– Polish AR visuals and UI.
– Test scalability: add multi-user management (if needed) and cloud deployment (AWS/Azure).
– Milestone: 5 complete modules with diverse content, running on targeted hardware with full cloud backend.
Phase 5: Evaluation & Refinement (Months 21–24)
– Conduct pilot studies with target learners to measure learning gains and engagement.
– Compare against baseline (e.g. traditional e-learning).
– Iterate on AI parameters, difficulty curves, and UX based on feedback.
– Finalize documentation, open-source or commercial release.
– Milestone: Achieve target metrics (e.g. +X% retention over control, as per [23]) and secure adoption commitments.

Throughout, we follow agile sprints and parallelize tasks where possible. We plan continuous integration/testing with unit tests for software modules, and periodic safety reviews (see next section).

Risk Analysis, Evaluation, and Testing

Technical Risks:

VR Sickness: Poor frame rates or mismatched visuals can cause nausea. Mitigation: use high-refresh displays and motion comfort techniques (vignetting, teleportation vs smooth motion). Choose hardware with low latency.
Tracking Failures: Loss of sensor data (e.g. occluded trackers). Mitigation: redundant tracking (multiple cameras, IMUs) and fail-safes (pause session if loss detected).
System Latency: Adaptive feedback must be near real-time. Use edge computing to minimize delays; also as in Li et al., a “closed-loop edge” architecture addresses latency by doing critical inference near the user.

Safety & Ethics:

Physical Safety: AR user may collide with real-world objects. Mitigation: enforce safe play area, boundary warnings, supervised sessions.
Data Privacy: Biometric and performance data are sensitive. Use encryption, anonymize as possible, and follow data protection laws.
Psychological Impact: The system is “strict” by design (quests carry consequences). Ensure content is appropriate to age and context; include opt-out/hard tasks only with consent. Include ethical guidelines from VR usage (e.g. limit continuous wear time, use disorientation breaks).

Anti-Avoidance & Security:

Cheating: In single-player AR, cheating is less about other players and more about the user skipping learning. Use integrity checks: sensors can detect if user is present and attentive. We may also lock progression until tasks are genuinely completed (e.g. must perform required motions or verbal answers).
Authentication: Use strong user login (biometrics or secure tokens) so the profile can’t be tampered with.
Scalability: Sudden load (many learners) could overload servers. Architect cloud to auto-scale (use Kubernetes, serverless) and limit concurrent heavy computation.

Evaluation Metrics:
We will quantify success with:

Learning Gains: Pre- vs post-tests on the taught subjects.
Engagement: Time-on-task, session length, voluntary replays. Kishor et al. saw +35.7% retention and Shaowei et al. +20% engagement; we will target similar improvements over traditional methods.
Task Completion Rate: Percent of quests/challenges completed successfully.
Cognitive Load: (via secondary measures or self-report). Kishor’s adaptive VR showed –42.1% cognitive load.
User Feedback: Qualitative surveys for enjoyment, frustration, perceived learning.

Testing Protocols:

Unit/Integration Tests: Automated tests for each software component (e.g. correct quest generation, sensor input handling).
VR Prototype Pilot: Internally test with staff first to catch usability issues.
Small-Scale User Study: 10–20 learners complete a module; collect metrics and adjust (Kishor did similar n=10 controlled trials).
A/B Experiment: Compare the adaptive MR system to a control (e.g. video lessons or non-adaptive VR). Randomly assign learners and measure outcome metrics. Shaowei’s study with 50 participants is a model.
Iterative Feedback: Use analytics from each test (how often do users die/fail quests? where do they drop out?) to tune difficulty curves.

Failure Modes:
If a user “loses” a quest (e.g. hits a wrong answer), the system may simply give constructive feedback and a chance to retry (the mythology suggests The System would kill the character, but for real learning we translate this to “try again with aid”). We ensure no real harm – rather than an absolute fail, we log the attempt and adapt (if user repeatedly fails, the curriculum may regress to a simpler sub-skill, analogous to giving extra stat points).

References

Kishor et al., “Agentic AI-Enhanced Virtual Reality for Adaptive Immersive Learning Environments” (2025). This work describes an RL-based VR tutor that dynamically adjusts learning content and style using multi-modal feedback.
Shaowei et al., “Reinforcement learning enhanced virtual reality training in intelligent family education platforms” (2026). Reports on a VR platform where RL tailors difficulty and content to each learner, yielding significant gains (+20% engagement, +25% retention).
Sloan & Zhao, “Adaptive Virtual Assistant for VR-based Remote Learning” (2022). Presents an adaptive NPC in a VR engineering game, using Q-learning to decide when to interrupt the learner with hints.
Bin Li et al. (PSU), “IMPACT: Mixed-Reality Platform for AI-Driven Task Training” (2026). Describes an MR training system with VR/MR headsets, motion capture, and edge-cloud RL agents for real-time adaptation.
Bonnet, “Emerging Hardware & Prototype Devices for AR/VR in Training & Education” (2025). Survey of HMDs, haptics, sensors: “lightweight head-mounted displays, immersive haptic systems, and wearable sensors are transforming traditional learning”.
Maleki & Zhao, “Procedural Content Generation in Games: A Survey” (2024). Defines PCG and reviews methods (search-based, ML-based including GAN/RL) for game-level and asset generation.
Solo Leveling Wiki (fan wiki). Entries on Kandiaru and The System detail the lore. Notably: “The System was designed like a video game… it provided Jinwoo with quests, a leveling system with different skills and stats, an unlimited inventory… and an in-built store”, and “As later revealed, the System was originally created by Kandiaru… it was deliberately designed with its video game interface”. These primary lore details guided our system design approach.

Found this useful?

Comments (0)

No comments yet. Be the first to share your thoughts!

The System : ii