Object Management System Specification

Overview

The Object Management System (OMS) is responsible for managing all interactive, non-NPC objects in the game world. This includes instantiating objects, maintaining their state, managing their lifecycle (e.g., spawn/despawn), and ensuring consistent behavior across gameplay sessions.

The OMS is implemented as a GameInstanceSubsystem, ensuring it persists across map loads and is available throughout the entire game lifecycle.

Core Responsibilities

• Maintain a registry of all GameObjects in the game.
• Instantiate and destroy GameObjects as needed.
• Track and manage object state (position, inventory contents, etc.).
• Handle saving and loading of GameObjects.
• Interface with inventories, loot generators, and crafting systems.

GameObject

A GameObject is a base class derived from AActor that supports Blueprint overrides for core interactions:

• OnUsed()
• OnPickedUp()
• OnDropped()
• SaveState()
• LoadFromSave()

All in-game objects derive from this class and are expected to override these methods to implement their specific behavior.

ObjectEntity

Instances of objects in the world, tracked by the OMS. An ObjectEntity may have the following states:

• Placed: Physically in the world.
• Inventory: Stored within an inventory component.
• Dropped: Temporarily dropped into the world, subject to despawn logic.

Inventory System

Inventories are implemented as components that can be attached to actors (e.g., players, containers). They:

• Store collections of ObjectEntities.
• Interface with OMS to ensure state is tracked.
• Support interactions like adding, removing, and transferring items.

Loot Generator

Used for resource nodes (e.g., rocks, trees). Configured via:

• A set of ObjectDescriptors with associated drop chances.
• Drop logic that spawns items into the world as Dropped ObjectEntities.

Object Lifecycle

1. Spawn: OMS instantiates an object from its Blueprint based on naming convention GO_ObjectId.
2. State Restoration: If from save data, OMS calls LoadFromSave().
3. Usage/Interaction: Blueprint handles gameplay-specific logic.
4. Save: OMS calls SaveState() for each object on save.

Initialization

• OMS has an Initialize() method callable from BeginPlay().
• Loads all relevant GameObjects.
• Ensures any persistent world items are re-instantiated.

Notes

• GameObjects handle their own description, visuals, and behavior.
• The OMS does not store blueprints directly but uses naming conventions to resolve them.
• Reflection and registration of Blueprint classes may be necessary for dynamic indexing.

---

This spec outlines the foundational design for the Object Management System. Further extensions will include support for dynamic content generation, editor tools for crafting and loot configuration, and network replication support.