Architektura systemu ekwipunku: ScriptableObjects vs. Baza danych

marcin

W tworzeniu gier RPG system ekwipunku to coś więcej niż tylko lista przedmiotów w plecaku. To złożona struktura danych, która musi obsługiwać statystyki, rzadkość występowania, efekty wizualne i logikę użycia. Jako deweloperzy Unity stajemy przed kluczowym pytaniem: Gdzie i jak przechowywać te dane?

Dziś przyjrzymy się dwóm najpopularniejszym podejściom: elastycznym ScriptableObjects oraz zewnętrznym bazom danych (np. JSON/SQLite).

1. ScriptableObjects: „Unity-Way” do zarządzania danymi

ScriptableObjects (SO) to kontenery danych, które nie muszą być przypisane do GameObjectu. Są idealne do definiowania „wzorców” przedmiotów (np. Miecz Stalowy, Mikstura Zdrowia).

Zalety:

  • Integracja z Inspektorem: Możesz tworzyć nowe przedmioty kliknięciem prawym przyciskiem myszy w edytorze i wypełniać ich pola bez dotykania kodu.

  • Wydajność pamięciowa: Jeśli 100 NPC-ów posiada ten sam typ miecza, wszyscy odwołują się do jednej instancji ScriptableObject w pamięci.

  • Łatwość referencji: Możesz przeciągać SO bezpośrednio do slotów w UI czy skryptów handlarzy.

Wady:

  • Brak trwałości (Persistence): Zmiany dokonane w SO w trakcie działania gry (Runtime) nie zapisują się po wyjściu z aplikacji (w buildzie). SO świetnie nadają się do definicji przedmiotów, ale nie do przechowywania stanu „ile gracz ma ich aktualnie w plecaku”.

2. Zewnętrzna baza danych (JSON/SQLite)

Podejście bardziej tradycyjne, gdzie dane o przedmiotach trzymamy w plikach zewnętrznych lub lokalnej bazie danych.

Zalety:

  • Łatwa edycja masowa: Możesz edytować statystyki 500 przedmiotów w Excelu i wyeksportować je do JSONa.

  • Przenośność: Dane są oddzielone od silnika, co ułatwia np. tworzenie narzędzi zewnętrznych lub modów.

Wady:

  • Brak wizualnego podglądu: Trudniej podpiąć teksturę (Sprite) czy prefab modelu 3D bezpośrednio w pliku tekstowym.

Moja rekomendacja: Podejście hybrydowe

W moich projektach RPG najczęściej stosuję model hybrydowy, który łączy zalety obu rozwiązań.

  1. ScriptableObjects jako definicje (Items Database): Każdy unikalny typ przedmiotu w grze ma swój SO. Przechowuje on nazwę, opis, ikonę, model 3D i bazowe statystyki.

  2. System ID: Każdy SO posiada unikalne ID (string lub int).

  3. JSON do zapisu stanu (Save System): Plecak gracza to prosta lista ID oraz zmiennych dynamicznych (np. aktualna wytrzymałość przedmiotu). Podczas zapisu gry serializuję tylko tę listę do pliku JSON.

Przykład kodu (C#)

Oto jak może wyglądać bazowa klasa dla przedmiotu w Unity:

C#

[CreateAssetMenu(fileName = "New Item", menuName = "Inventory/Item")]
public class ItemData : ScriptableObject
{
    public string itemID;
    public string itemName;
    public Sprite icon;
    public GameObject prefab;
    
    [Header("Stats")]
    public int weight;
    public int goldValue;
}

Podsumowanie

Dla projektów indie i średniej wielkości RPG w Unity, ScriptableObjects są niemal bezkonkurencyjne ze względu na szybkość iteracji i integrację z edytorem. Pozwalają designerom na tworzenie contentu bez znajomości struktury plików, co znacząco przyspiesza produkcję.

A jak Wy rozwiązujecie kwestię ekwipunku w swoich projektach? Stawiacie na czyste dane, czy wykorzystujecie narzędzia wbudowane w Unity? Dajcie znać w komentarzach!