Core Concepts KeyLoader

The SLASHkeyLoader and KeyCreationData: The Good, The Bad, and The Future

🛠️ What Is SLASHkeyLoader?

The SLASHkeyLoader is a modular ScriptableObject designed to define key properties in KLEP.

• It acts as a "template manager", allowing designers and developers to preconfigure key properties without directly coding them.
• When an executable generates a key, the key loader ensures that the key is populated with the correct properties.

🎮 The Original Vision:

Imagine a vending machine:

• Designers load up properties (originally keys themselves) into the vending machine (key loader).
• An executable then requests a key, and the vending machine dispenses a key with all the necessary properties.

This idea was intended to:

• Promote modularity by packaging key definitions into independent ScriptableObjects.
• Allow team independence, where Team A could work on Combat Keys and Team B on Inventory Keys without cross-pollution.

---

🚦 What Is KeyCreationData (KCD)?

KCD is the blueprint for keys, defining:

• The key's name (keyName).
• Its attraction value (attractiveness).
• The expected key loader (expectedLoader).
• The list of properties that the key should carry (Properties).

When an executable generates a key, it uses KCD to ensure the key is populated correctly, relying on the SLASHkeyLoader to fill in the blanks.

---

❌ Pain Points in the Current Design:

🧨 1. Breaks Without a Key Loader:

• If a key loader is not assigned, the system breaks.
• This rigid dependency forces every key to be tied to a specific loader, which limits flexibility.
• The system should default to a safe state, allowing keys to be generated without a loader when needed.

---

⚠️ 2. Complexity of "Dirty" Loaders:

• The allowForeignKeys setting creates a "dirty" loader that absorbs foreign properties.
• While this enables weak system integration, it muddies the water of which properties belong where.
• The original goal was to allow strong systems (Team A and Team B) to merge into a weak system, but in practice, this introduces ambiguity and inconsistent behaviors.

---

📚 3. Cumbersome Setup and Management:

• The current system is evolved from the vending machine concept, but has lost some of its simplicity.
• The manual setup of properties and the management of dynamic properties is difficult, leading to potential errors and dropped properties.

---

💡 Proposed Improvements:

🧠 1. Make Key Loaders Optional:

• Executables should be able to generate keys without needing a loader.
• If a loader is present, it fills in the properties; if not, the key is still generated, but without preset properties.

🛠️ Implementation Idea:

public static KeyCreationData CreateKeyData(string keyName, float attractiveness, SLASHkeyLoader expectedLoader = null)
{
    KeyCreationData kcd = new KeyCreationData
    {
        keyName = keyName,
        attractiveness = attractiveness,
        expectedLoader = expectedLoader
    };

    if (expectedLoader != null)
    {
        InitializePropertiesFromLoader(kcd, expectedLoader);
    }

    return kcd;
}

• By making the loader optional, executables can dynamically generate keys even in weak systems.
• The system defaults to a safe state, allowing more flexibility and preventing breaks.

🔍 2. Split Strong and Weak Systems More Clearly:

Introduce two modes for key loaders:

• Strict Mode: Only predefined properties are allowed.
• Open Mode: Automatically incorporates foreign properties when detected.

💡 How This Helps:

• Team A and Team B can work independently in Strict Mode, maintaining strong systems.
• When integrating their systems, the loader can switch to Open Mode, allowing for property cross-pollination.

🛠️ 3. Simplify Key Management:

• Instead of manually adding properties, provide utility methods to auto-populate properties based on key usage history.

public void AutoPopulateProperties(KeyCreationData kcd)
{
    foreach (var usedProperty in KnownPropertiesFromUsage)
    {
        if (!kcd.Properties.Any(p => p.PropertyName == usedProperty.PropertyName))
        {
            kcd.Properties.Add(usedProperty);
        }
    }
}

This would automate the dirty-loader behavior in a more predictable manner.

✅ Conclusion:

The SLASHkeyLoader and KeyCreationData system is a powerful concept but needs refinement to unlock its full potential.

By making key loaders optional, clarifying strong vs. weak systems, and simplifying setup, KLEP can achieve:

• True modularity, allowing designers and developers to work independently.
• Future-proofing, so new features (like elemental damage types) can be added seamlessly.
• Stability and flexibility, ensuring keys generate safely, even without predefined loaders.