Los ScriptableObjects son unmecanismo de Unity que solemos descubrir más o menos a nivel medio. Son una forma de serializar y almacenar información, ya que las estrucutras de datos normales no guardan los valores que les pones en el editor o entre corridas del proyecto.
Casi todo el mundo empieza utilizando XML o JSON hasta que descubre los SriptableObjects. No voy a entrar en detalles técnicos, porque los tutoriales sobran por ahí. Mejor hablaré de cómo me ha ido con ellos.
Nuestra relación ha tenido altas y bajas, y probablemente las seguirá teniendo. XML fue mi primera opción para guardar definiciones de personajes, objetos y habilidades: es flexible y todos lo conocemos a fondo. En cambio, los ScriptableObjects son clases, por tanto tienen una estructura fija. Como ventaja, ofrecen que son más "naturales" para Unity: pueden ser asignados desde el editor y utilizados como cualquier otro asset. Otro detalle que puede causar problemas es que un ScriptableObject retiene los valores asignados. Por ejemplo, en mi caso tenía la definición de las habilidades en ScriptableObjects y me sucedía que cada vez que ejecutaba el juego, el jugador empezaba con unos valores raros en los niveles de cada una, en vez de inicializados a cero. Luego de romperme la cabeza durante un largo tiempo, descubrí que como estaba usando los objetos directamente, éstos retenían el valor de la última ejecución. Y no solo el asignado por el jugador, como los NPC también usaban la misma instancia del objeto, el reguero era épico.
O sea, que no deberías usar un ScriptableObject directamente, sino como base desde donde sacar información. O solo hacerlo en caso de que no cambies los valores.
Mi último experimento con ellos fue crear un sistema de items, donde cada definición de un item ocupa su propio asset. Como les decía, el item puede ahora tener sus propias funciones, y también aprovechar la herencia, derivando de una clase padre BaseItem otras clases especializadas, como ItemWeapon.
Después de todo esto, si me preguntan qué opción es mejor, ScriptableObjects o XML/JSON, pues yo diría que cualquiera de las dos. Al final terminas haciendo lo mismo: instanciar objetos a partir de la información. Los ScriptableObjects son marginalmente superiores por ser assets, en mi opinión (que podría cambiar en el futuro y no debería ser tomada como verdad absoluta) y por ello los seguiré utilizando, pero no dudo que cualquier programador podría encontrar alternativas a esto usando XML/JSON. Lo recomendable es conocer ambos métodos.
Casi todo el mundo empieza utilizando XML o JSON hasta que descubre los SriptableObjects. No voy a entrar en detalles técnicos, porque los tutoriales sobran por ahí. Mejor hablaré de cómo me ha ido con ellos.
Nuestra relación ha tenido altas y bajas, y probablemente las seguirá teniendo. XML fue mi primera opción para guardar definiciones de personajes, objetos y habilidades: es flexible y todos lo conocemos a fondo. En cambio, los ScriptableObjects son clases, por tanto tienen una estructura fija. Como ventaja, ofrecen que son más "naturales" para Unity: pueden ser asignados desde el editor y utilizados como cualquier otro asset. Otro detalle que puede causar problemas es que un ScriptableObject retiene los valores asignados. Por ejemplo, en mi caso tenía la definición de las habilidades en ScriptableObjects y me sucedía que cada vez que ejecutaba el juego, el jugador empezaba con unos valores raros en los niveles de cada una, en vez de inicializados a cero. Luego de romperme la cabeza durante un largo tiempo, descubrí que como estaba usando los objetos directamente, éstos retenían el valor de la última ejecución. Y no solo el asignado por el jugador, como los NPC también usaban la misma instancia del objeto, el reguero era épico.
O sea, que no deberías usar un ScriptableObject directamente, sino como base desde donde sacar información. O solo hacerlo en caso de que no cambies los valores.
Mi último experimento con ellos fue crear un sistema de items, donde cada definición de un item ocupa su propio asset. Como les decía, el item puede ahora tener sus propias funciones, y también aprovechar la herencia, derivando de una clase padre BaseItem otras clases especializadas, como ItemWeapon.
Después de todo esto, si me preguntan qué opción es mejor, ScriptableObjects o XML/JSON, pues yo diría que cualquiera de las dos. Al final terminas haciendo lo mismo: instanciar objetos a partir de la información. Los ScriptableObjects son marginalmente superiores por ser assets, en mi opinión (que podría cambiar en el futuro y no debería ser tomada como verdad absoluta) y por ello los seguiré utilizando, pero no dudo que cualquier programador podría encontrar alternativas a esto usando XML/JSON. Lo recomendable es conocer ambos métodos.
Comentarios
Publicar un comentario