Unityben statikus dolgok adatbázisszerű tárolása?

XML helyett lehet, hogy jobban jársz a JSON formátummal, az praktikusabb.

Bár kicsit premature optimalizáció-szagú, de megfelelően megtervezett dictionary-k használatával gyorsíthatsz a betöltött táblákban való keresésen, hogy ne kelljen iterálnod, ráadásul egy valamirevaló JSON lib általában közvetlenül tud JSON objektumot dictionary-be parse-olni.

Az utólag feldobott kérdésedre sajnos most nem tudok választ, talán valaki, aki járatosabb a Unity projektek háza táján.

#3: Ezek az adatformátumok eléggé elterjedtek, találsz hozzájuk kiforrott, jól támogatott libet/frameworköt, egyáltalán nem kell sztringes/regexes mókolásokkal bajlódni.

Ennyi vele a dolgod:

- Létrehozod a megfelelő osztályokat, amelyek fogadják az adatot (pl. Item)

- Bizonyos API-k esetén meg kell annotálni (igazán nem megterhelő, de a Json.NET nem kéri ezt sem)

- A libet behúzod dependenciának

- A lib parse-olja a JSON-t és feltölti a tartalmával az objektumodat

Ennyi az egész, és oda-vissza kiválóan működik:

[link]

Nemhogy nem kell újrafordítani változtatásnál, de ügyesen megoldva akár a futás kellős közepén is frissítheted a JSON-t anélkül, hogy látható teljesítményromlást okozna.

Nem vagyok persze a scriptable object ellensége, de a kérdező alternatívát kért, így kínáltam neki egy rentábilis megoldást. Scriptelni nem tudsz vele, csak adatot tárolni, de a kérdés épp adattárolásra irányul.

Az újrafordítást csak és kizárólag a static változókba mentésre értettem, nem is akartam azt a látszatot kelteni hogy xml\jason esetén is ez lenne a helyzet.

Elsősorban amit én problémásnak találok a szöveg alapú tárolásnál az az, hogy stringekkel kell dolgoznod, az ilyen előbb-utóbb elíráshoz vezet(szemben ha mondjuk scriptable objectet használsz simán behúzod inspectorban amit szeretnél, azt ha akarnád sem tudnád elrontani). Egyértelműen van létjogosultsága persze, és nagyon sok adatnál(vagy már meglévő adatbázisnál) én is ezt a megoldást használnám, de nulláról írva nekem személy szerint(~szó nincs kőbe vésett igazságról, illetve eseti kivételt gondolkodás nélkül tennék ha arról van szó) hatékonyabbnak tűnik a scriptable object.

Igen, IDE support nélkül megvan ez a kockázata a dolognak sajnos, mint gyakorlatilag bármiféle konfiguráció, vagy adatbázis esetén. Mérlegelni kell, hogy ezt a kockázatot vajon megéri-e a hozzáadott érték.

Egyébiránt tényleg adja magát a ScriptableObject.

Kérdező, a te esetedben mi teszi macerássá?