Technical Specification: Player Entity for Labyrinth MUD - wwestlake/Labyrinth GitHub Wiki

Technical Specification: Managing Player and Character Entities in a MUD

Overview

This technical specification outlines the architecture and data management strategy for handling Player and Character entities in a MUD (Multi-User Dungeon) game. The proposed model distinguishes between the Character entity as a static template and the Player entity as a dynamic, mutable record that tracks the gameplay state for a specific user-character combination.

Key Entities

1. Character Entity:

   • Acts as a template or reference point.
   • Stores immutable or rarely changing attributes of a character, such as:
     • Character Class (e.g., Warrior, Mage)
     • Race (e.g., Elf, Human)
     • Base Stats (e.g., Strength, Dexterity)
     • Permanent Attributes (e.g., special skills or abilities)
   • Represents the character's initial state upon creation and can be used for resetting the game or starting new sessions.

2. Player Entity:

   • Represents the active, mutable state of a character being played by a specific user.
   • Identified by a combination of UserId and CharacterId.
   • Stores dynamic gameplay data, including:
     • Current Room ID: Where the player is currently located.
     • Health, Mana, and Other Stats: Current values that fluctuate during gameplay.
     • Experience Points: Tracks experience and level progression.
     • Inventory and Equipment: Lists current items and gear.
     • Quest Progress: Active, completed, and failed quests.
     • Status Effects: Temporary buffs, debuffs, and conditions.
     • IsOnline: Indicates if the player is currently in-game.

Data Model

Character Document (Stored in the Characters collection):

{
  "_id": "CharacterId123",
  "Owner": "UserId456",
  "CharacterClass": "Mage",
  "Name": "Merlin",
  "Description": "A wise mage.",
  "Race": "Elf",
  "Level": 1,
  "BaseStats": {
    "Strength": 10,
    "Dexterity": 15,
    "Intelligence": 20,
    "Constitution": 12
  },
  "Abilities": ["Fireball", "Teleport"],
  "BaseEquipment": ["Staff", "Robe"],
  // Other static attributes...
}

Player Document (Stored in the Players collection):

{
  "_id": "PlayerId789",
  "UserId": "UserId456",
  "CharacterId": "CharacterId123",
  "Name": "Merlin",
  "CharacterClass": "Mage",
  "Race": "Elf",
  "Level": 1,
  "CurrentRoomId": "RoomId001",
  "Health": 80,
  "Mana": 50,
  "ExperiencePoints": 1200,
  "Inventory": ["Potion", "Magic Scroll"],
  "ActiveQuests": ["QuestId001", "QuestId002"],
  "CompletedQuests": ["QuestId003"],
  "FailedQuests": [],
  "IsOnline": true,
  "StatusEffects": ["Blessing", "Curse"],
  // Other dynamic attributes...
}

Processes

1. Creating a New Character and Entering the Game:

   • Step 1: User creates a new character. A Character document is created in the Characters collection.
   • Step 2: A new Player document is created in the Players collection. This document references the CharacterId and initializes other fields like CurrentRoomId, Health, etc.
   • Step 3: The game session is initialized using the Player document, and the player enters the game world.

2. Selecting an Existing Character:

   • Step 1: User selects an existing character. The game fetches the corresponding Character and Player documents.
   • Step 2: The Player document is updated with any relevant session-specific data (if necessary).
   • Step 3: The player enters the game, and the game state is initialized from the Player document.

3. Switching Characters During Play:

   • Step 1: User decides to switch characters. The game saves the current state of the active Player document.
   • Step 2: The game fetches the new Character and Player documents.
   • Step 3: If a Player document does not exist for the new character, a new one is created using the Character template.
   • Step 4: The game session is transitioned to the new character's state based on the Player document.

Benefits of the Proposed Model

1. Separation of Concerns:

   • By distinguishing between Character and Player entities, the model allows for clearer management of game state versus character templates. The immutable Character template remains unaffected by gameplay, while the Player document captures all in-game changes.

2. Flexibility in Gameplay Management:

   • Players can have multiple Player records tied to different characters or sessions, allowing for complex game mechanics such as permadeath, different gameplay modes, or simultaneous multi-character play.

3. Efficient Data Management:

   • Using multiple Player documents reduces the need to constantly update the Character document, keeping it as a clean reference. It also minimizes data conflicts when switching between characters or managing multiple sessions.

4. Enhanced Game Features and Flexibility:

   • The proposed model supports various advanced game features, such as detailed tracking of quest progress, room states, and dynamic game interactions.

Conclusion

Adopting this model provides a robust framework for managing player and character data in a MUD game, aligning with best practices observed in other MUDs and RPGs. It allows for dynamic gameplay while maintaining the integrity and flexibility of the underlying data model.

By treating Character documents as templates and Player documents as mutable states, the game can efficiently manage multiple characters, dynamic game sessions, and complex gameplay features. This approach ensures both scalability and ease of management for future game expansions and modifications.