Miercoles dia 14, a las 22.30h (hora española) toca directo. Creacion de un Core simplificado primera parte, Recordad que el nivel es intermedio/avanzado, https://www.twitch.tv/events/qJ1lY77PRlWLzLWDWSu7uQ
 
Con este post podremos discutir dudas o cosas sobre el stream

Recordatorio añadido para no perdermelo. Ahora la espera se me hara eterna... ¿Tienes canal de youtube y los subes luego ahi?, ¿o se quedan en twitch?. Es que aunque ahora el programa de partners de youtube lo han modificado pese a necesitar miles de reproducciones para ganar un par de euros, y ahora es una odisea conseguir acceder a ser partner, creo que deberias hacer como un feedback subiendolos luego a youtube y poniendo en las descripciones el enlace al canal de twitch, a ver si se anima mas gente por un lado, y por otro lado a ver si consigues alcanzar los requisitos para ser partner y conseguir un incentivo, aunque el incentivo sea una mierda en comparacion con el esfuerzo.
 
No es necesario grabar el stream al mismo tiempo que lo realizas, hay extensiones del navegador para descargar los videos de internet, asi que seria hacer el stream, descargar el video, editarlo si es necesario, y ponerlo en youtube. Yo uso la extension "ant videodownloader" en firefox para descargar los tutoriales que suelo revisar con frecuencia para ahorrarme busquedas y tiempos de carga.
 
Dicho todo esto, espero con ansia viva el stream. Un saludo!!

Suelo "postear automatico" el video conforme termino el stream y asi se queda en youtube. Busca "eskemaware" que soy yo

Stremear en San Valentin, que romantico , allí estaré !!

Bueno, Miercoles dia 21 (por la noche como siempre) seguimos con el Core y esta vez nos toca hablar del SceneManager, https://www.twitch.tv/events/8NEopKOPRQuNi5dtGXgO6A (pioj no estas invitado xDD)

El primer stream ha estado genial, todo bastante simplificado para que luego cada cual se apañe con sus manias de programar, aunque vienen muy bien las orientaciones en cuanto a la metodologia de nombrado y estructuracion para mantener un codigo limpio y legible.
 
Al menos voy a aprender eso de los "delegados" ya que jamas he tocado una facultad y todo lo que he aprendido de programacion ha sido por cursos, un modulo, y a base de equivocarme hasta la saciedad hasta que las cosas terminan funcionando.
 
Si pudieses explicar con el SceneManager a actualizar la barra de progreso me vendria genial, ya que eso lo he hecho en Java usando Threads y no se me ocurre como habria que plantearlo en C#.
 
Un saludo y gracias por dedicar tu tiempo a compartir tu experiencia 

Los delegados tambien llamados "callbacks". Basicamente tu te "suscribes" a un evento como el ongamepaused, y cada vez que ese evento se dispare, quien se haya apuntado (un listener) recibe la llamada y hace lo que quiera con esa informacion, pausar el juego, saber que una escena se ha cargado, saber que mi enemycontroller ha spawneado un enemigo nuevo, etc, etc. Las posibilidades son infinitas.....
 
 
 
la barra de progreso es parte del scenemanager, asi que hablaremos de ello. El scenemanager se encarga de cargar una escena de unity, y de updatear el progreso de carga de unity, tras el 100% tenemos la escena y entonces cargamos nuestras actions (como se ve en los otros videos) y estamos listos para hacer lo que sea con la escena.
 
Aparte claro de tener una clase que nos sirve de ancla y donde podemos almacenar datos, nuestro "menuscene" (o la que sea), muy muy util el scenemanager

Cita de: Eskema date=1518717346Los delegados tambien llamados "callbacks". Basicamente tu te "suscribes" a un evento como el ongamepaused, y cada vez que ese evento se dispare, quien se haya apuntado (un listener) recibe la llamada y hace lo que quiera con esa informacion, pausar el juego, saber que una escena se ha cargado, saber que mi enemycontroller ha spawneado un enemigo nuevo, etc, etc. Las posibilidades son infinitas.....
   

Curiosidad: Me llamó mucho la atención la forma en la que declaraste el Action/Delegate directamente desde System.Action...  Hasta ahora había visto cómo hacían lo de los Delegates y Events en muchos sitios, y declaraban 2 variables, en vez de una directamente, como haces tú...
 
Complementando lo anterior, también me fijé que creas el Singleton de una forma distinta a cómo lo he visto hacer en otros sitios, también con una o dos líneas de código, en lugar de las 4-5 típicas de otros ejemplos...
 
 
 
¿Existe algún motivo de rendimiento o ahorro de memoria, para que implementes esas dos cosas de la manera concreta que usas?

El singleton como es propenso a que lo tengas en muchos proyectos o que crees varios (aunque no se deba), se suele hacer en una clase generica y asi te ahorras el duplicar el codigo, no tiene ninguna ventaja mas (en el sentido de ahorro)
 
Los delegados depende, es lo mismo action que delegate, de hecho action es un "pseudonimo", osea un delegate declarado por encima, simplemente es mas comodo de usar y mas rapido porque tecleas menos.
 
Es mas comodo poner System.Action OnManolitoDied; que no poner public delegate void ManolitoDied; public delegate void OnManolitoDied(); (2 lineas frente a una), mas alla de eso..... de hecho el .net lo define asi, public delegate void Action(); ergo es un shorcut.

Muy buenas de nuevo @Eskemalas instancias del core consultadas desde los hilos consevan el hashCode y no crea nuevas instancias que consumen memoria.
 
Dejo el ejemplo bastante comentado de las pruebas que he estado haciendo con los hilos de C# para aquellos inquietos como yo que les gusta hacer experimentos aunque la maquina termine explotando.
 

using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using System.Threading; // la libreria de los Threads de C#
// cada uno que importe el espacio de nombres de su core
using CKN.core;
public class TestThreads : MonoBehaviour {
private Thread _th1; // hilo 1
private Thread _th2; // hilo 2
private ThreadStart _delegado;   // un delegado para hacer el hilo 1 sin lambda
private bool _threadKey = false; // para asegurarme que no lanza el hilo mas de una vez
void Awake() {
   _delegado = new ThreadStart(Metodo1);
   
   // Thread.Start() inicia el hilo
   // Thread.Join() espera a que el hilo finalice
   // realizo la prueba de fuego pintando el hashcode del Singleton
   Debug.Log("Awake: " + Core.GetInstance().GetHashCode().ToString()); 
   
}
void Start () {
   // Dentro de los hilos que se ejecuten en el metodo Awake
   // lanzara un error al obtener el GetInstace del core
   _th2 = new Thread( () => { // este hilo es de unica ejecucion
      for(int i = 0; i < 100; i++){
         Thread.Sleep(10);
      }
      // esto es curioso, conserva el hashCode de la clase Singleton
      // cuando en Java hay que sincronizar los hilos
      // para evitar sobrecargar la memoria
      // ya que el hilo termina pero la instancia permanece cargada
      Debug.Log("Lambda: " + Core.GetInstance().GetHashCode().ToString());
   });
   // segunda prueba de fuego con el hashcode, no deberia haber diferencias
   // ya que se ejecuta fuera de un hilo
   Debug.Log("Start:" + Core.GetInstance().GetHashCode().ToString());
   _th1 = new Thread(_delegado);
   _th1.Start();
}
void Update(){
   Debug.Log("Hilo 1 IsAlive: " + _th1.IsAlive.ToString());
   Debug.Log("Hilo 2 IsAlive: " + _th2.IsAlive.ToString());
   if(Input.GetKeyDown(KeyCode.A) && !_threadKey) {
      _threadKey = true; // impido lanzar de nuevo el hilo ya que arrojaria error
      _th2.Start();
   }else if(Input.GetKeyDown(KeyCode.A) && _threadKey && !_th2.IsAlive){
      _th2 = new Thread( () => {
         for(int i = 0; i < 100; i++){
            Thread.Sleep(10);
         }
         // nuevamente conserva el hashCode todas las veces que se ejecute
         Debug.Log("Lambda2: " + Core.GetInstance().GetHashCode().ToString());
      });
      _th2.Start();
   }
   if(Input.GetKeyDown(KeyCode.B) && !_th1.IsAlive){
      _th1 = new Thread(_delegado);
      _th1.Start();
   }
}
void Metodo1(){
   for(int i = 0; i < 100; i++){
      Thread.Sleep(10);
   }
   Debug.Log("Metodo1: " + Core.GetInstance().GetHashCode().ToString());
}

}

 
Lo unico que se me ocurre para usar los hilos es para guardar la partida con autosave como hacen los juegos actuales mostrando el icono en la esquina o esperar la carga de datos complejos.
 
Espero que este post le resulte interesante a alguien. Seguire investigando mientras espero con ansia viva la siguiente clase magistral. Un saludo!!!!

Yo no dije que C# no fuera multihilo. Dije que unity NO es multihilo, cuidado con ese matiz que en unity todo va al mismo hilo, por eso el lock que puse no tiene mucho sentido, pero lo pongo a nivel previsor
 
Btw, tu codigo tiene una cantidad interesante de "problemas". Sincronizar el hilo "externo" entre unity y tu hilo no es facil. Los hilos no aparecen en el debugger y si peta tu hilo unity no se entera. Asi que cuidado con eso.
 
¿Recomendacion?, no usar hilos para NADA, salvo que tengas una tarea tipo "generar mundo procedural que tarda mucho y lo asigno a un hilo para hacer calculos de los datos antes de volver a unity para generar las mallas o lo que sea"

Cita de: Eskema date=1519316882Yo no dije que C# no fuera multihilo. Dije que unity NO es multihilo, cuidado con ese matiz que en unity todo va al mismo hilo, por eso el lock que puse no tiene mucho sentido, pero lo pongo a nivel previsor
   
   
      Btw, tu codigo tiene una cantidad interesante de "problemas". Sincronizar el hilo "externo" entre unity y tu hilo no es facil. Los hilos no aparecen en el debugger y si peta tu hilo unity no se entera. Asi que cuidado con eso.
   
   
      ¿Recomendacion?, no usar hilos para NADA, salvo que tengas una tarea tipo "generar mundo procedural que tarda mucho y lo asigno a un hilo para hacer calculos de los datos antes de volver a unity para generar las mallas o lo que sea"
   

Ok, entonces fallo mio al no enterarme bien.

De momento no tengo la mas minima intencion de usar hilos salvo que no me quede otra que usarlos, pero si unity se pasa los hilos por el forro entonces es tonteria de la buena. Antes de todo eso ya habia observado que cuando el hilo peta, el debbuger no te dice ni pio, simplemente no se ejecuta y te quedas viendolas venir. De momento es lo que te decia, hacer uso de esto unicamente para salvar la partida en segundo plano mientras el juego sigue en ejecucion, aunque si peta estamos en las mismas. Lo de los mundos procedurales aun es demasiado para mi, hay mucho camino por aprender e investigar todavia.

Me ha parecido interesante esto de los hilos y liarla unas cuantas veces antes de publicarlo, no obstante lo dejo aparcado, te hago caso y me espero al siguiente stream. Un saludo!!!!

@Eskema queremos más sesiones! Hay mucho por aprender todavía...
 
Por ejemplo,a mí me gustaría mucho saber cómo haces tú un sistema de atributos, etc.. 

Es que no se que pasa que no he recibido los jabugos aun.... en cuanto los reciba me pongo xDDDDD
 
Coñas aparte no hay mas streams en castellano, lo proximo ya viene en ingles. Y el sistema de atributos mas un bullet renderer como estoy haciendo ahora los tocare, que mucha gente sigue usando gameobjects para disparos, cuando perfectamente se los pueden ahorrar

Pregunto, un sistema de atributos? atributos de C# o en general?