➔ Binouz - 28 Dec 2017
Merci, oui c'est ce que je lis un peu à droite à gauche aussi.
Quand même dingue de devoir réassigner soi-même des réferences et que ça save pas des GUID par défaut au runtime (dans l'éditeur y a une classe qui permet de le faire mais pas au runtime, surement une raison qui m'échappe).
Pour ta première remarque ce que tu proposes c'est de passer complètement à côté de l'intérêt des SO...
Les SO c'est quand même très cool dans l'éditeur (et quand tu commences à foutre des custom inspectors c'est la surpuissance) et pour gérer de la donnée de jeu (en prime t'as même quelques callback et des méthodes). Tu peux faire des changements à la volée (qui sont conservés par défaut). Tu peux même en faire des singletons sauf que là au moins tu vois tout dans l'éditeur.
Et l'autre intérêt pour moi des SO c'est justement la facilité de serialiser/déserialiser en JSON pour pouvoir bosser aussi en dehors de Unity.
Je crée une BDD en SO, je la sérialise en Json via un bouton dans l'éditeur.
Et si je suis au bureau à Paris, ou n'importe où en fait, je peux bosser sur ma base de données en éditant le json (même directement dans github si je veux) et la désérialiser dans le SO via un autre bouton dans l'éditeur une fois de retour à la maison. Super pratique si je veux faire un mass edit aussi.
Ca fait environ 2 mois que je me gave de tutos/présentation sur les SO donc je suis assez chaud dessus.
Les meilleures prés pour comprendre la puissance du truc:
Edit: Enfin jusqu'à présent j'étais bien mais là le souci que je rencontre avec mon SO qui liste des SO édités au runtime, et que je dois sérialiser est pas hyper simple.
Edit2: Je vais peut-être me simplifier la vie et stocker dans mon SO GameProgress une liste de satisfiedConditions et qui sera juste la liste des GUID de conditions satisfaites. Comme ça au Load je refous le bool à true pour toutes les conditions dont le GUID matche. Simple efficace.
