Cita de: francoe1 date=1502375905@Arthure Lo comente abajo, que es algo complicado de explicar, cuando alguien está comenzando se le hace muy dificil entender como funcionan los delegados, los eventos, los argumentos, para que y porque se utilizan. Por ejemplo, si vamos a lo teórico, un delegado se parece mucho a un puntero de C, este vendría a ser una referencia a un método cualquiera, es decir no está explícitamente declarado para el compilador. Pero, ¿Quién podría entender estas palabras?, muchos ni siquiera saben que es un compilador... 
   

Pido disculpas con mis maneras ... pero a estas alturas no les sorprenderan a nadie (aunque eso diga muy poquito de mi persona jajaja) aunque ni mucho menos intentaba ser una burla o critica; aunque el hecho de no pretender ser una burla, no significa que no me parezca una chorrada el sistema eh !!
 
Como dije, lo primero que me parece una chorrada es utilizar una clase estatica ... y lo pondre con un ejemplo : en unos juegos deportivos, pongamos por simplificar mucho, el salto a la pata coja donde el ganador es quien de el salto mas alto sin moverse del sitio (nos podemos reir, pero ese deporte un dia llegara a los juegos olimpicos jajajajajajaja).
 
Pues quien realiza el evento (la accion) en este caso seria el deportista y al resto de entidades no les importa como realiza esta accion, simplemente la accion en si. Despues existen dos entidades, quien se encarga de controlar la altura a la que se salto y los espectadores que aplaudiran por el salto.
 
Pues el ejemplo tan chorra anterior, pasado a codigo ... las acciones de saltar, medir altura y aplaudir estaran implementadas en sus propios objetos no en una clase estatica. Del mismo modo que los manejadores de eventos (en este caso el "arbitro" y espectadores) tendran el codigo en sus propios objetos.
 
Pero la muestra mas clara de que es una chorrada el sistema, es que cuando se ejecuta el evento y el objeto player lo maneja tiene que comprobar un atributo para saber si debe ejecutar una accion o no. Eso es la cosa menos limpia, optimizada y expansible que alguien se pueda tirar a la cara por una sencilla razon ... en el ejemplo puesto por @francoe1 el player comprobaba el name del gameobject para saber si tenia que ejecutar un codigo, pero que pasa si se le cambia el atributo name cambia por cualquier razon ? en el mismo ejemplo solo se comprueba si el name coincide con "Box Temp" pero que sucederia si hubieran 100 names distintos (pongamos que un nombre para cada tipo de caja) ? Que sucederia si encima si al destruir una caja te dieran puntos y cada tipo de caja tuviera una puntuacion distinta ?
 

• 
     Si cambiando un atributo interno de un objeto, en este caso el name del objeto caja, el codigo va a dejar de funcionar entoces es un indicador de que no se trata de un codigo expansible.
  


• 
     Si un codigo tiene 100, 1.000 o 10.000 condicionales innecesarios entoces no se trata de un codigo limpio ni optimizado.
  

@lightbug cada cual utilizara las cosas como mejor crea, pero en el caso de los delegates que era lo que me preguntabas ... para mi es una pasada precisamente para tener un codigo mas limpio y expansible (lo de optimizado luego depende de las funciones), puesto que solo llamando a una funcion puedes hacer que un objeto tenga cierto comportamiento segun una circumstancia.
 

public class Jugador : Monobehaviour {
private delegate void ComportamientoJugador ();
private ComportamientoJugador comportamiento;
private void Update () { comportamiento (); }
private void Esperar ();
private void Correr ();
private void Saltar ();
private void Atacar ();
private void Morir ();
}

 
En el codigo que he puesto, la funcion "comportamiento" que se ejecuta en el Update podria adoptar el codigo de cualquiera de las funciones que hacen referencia a los estados segun convenga.
 
Al final no se trata mas que de un sencillo uso de maquinas de estado ... entre eso y el metodo utilizado por clases no serializadas de @francoe1 (la clase Motor y sus derivadas), la unica diferencia es que su codigo esta en clases separadas y en mi caso el codigo esta "dividido" en diferentes funciones dentro de la misma clase ... pero el resultado es el mismo, dentro del Update solo existe una funcion, consiguiendo que sea mucho mas facil de leer.
 
A parte de todo eso, los delegates despues se utilizaran para el manejo de eventos pero como una parte y no por si solos (estudiar event y EventArgs) ... del mismo modo que el tipo float por si solo no sirve para guardar la posicion de un objeto, pero el Vector3 que si se utiliza con esa finalidad esta compuesto por float.

@Arthure La manera en la que piensas de cómo deben comportarse los componentes no es la correcta, este error surge de utilizar Unity, se trata de ver todo como un "Único", cuando en realidad tratamos de manejar todo de manera arbitraria. 
 
El decir, en Pro evolution, cuando se acciona el evento del botón "X" ¿De qué manera un componente podría interpretar la acción?, es decir, que a partir de un evento se accionar diferentes decisiones arbitradas por un "Entidad" de mayor jerarquía. 
 
Dejemos de lado un poco los eventos y vayamos a otro ejemplo. ¿Programaste alguna vez un juego fuera de Unity, comenzando de cero?, si es así te darás cuenta que la programación basada en componentes es algo chocante, no termina de convencerte y por lo general da más problemas que soluciones, Unity hace que lo "recién llegados" lo vean de manera equivocada... Ejemplo...
 
Crear un juego 2D (hablando en simples palabras, sin entrar a la parte técnica en cuanto a "gráfica" API como DirectX, OpenCL, etc), primero comenzamos a diseñar un sistema de almacenamiento para "slot", lo que llamaríamos grilla, técnicamente un arreglo de tipo entero (o cualquier otro tipo que nos sirva para indexar la información necesaria), luego, por cada frame, estaríamos dibujando el escenario.
 
Jerarquía de función : CORE->Draw(GRID) ... El núcleo de nuestro juego, dibuja el mapa, basándose en los datos de nuestro arreglo.
 
Qué sucede con Unity, nos "obliga" a trabajar con "Componentes", por lo que, cada "tile" estaría siendo una instancia de un GameObject que contiene un Componente encargado de renderizar un "sprite", esto hace que la aplicación deje de tener "armonía", porque no solo dependemos de los datos de la grilla si no tambien, de los componentes que componen el "mapa del juego".
 
No digo que Unity está mal diseñado, pienso que basar toda una aplicación en componentes es poco práctico.
 
Me gusta debatir sobre técnicas, por lo general se aprende mucho... 
 
 

Cita de: francoe1 date=1502384143@Arthure La manera en la que piensas de cómo deben comportarse los componentes no es la correcta, este error surge de utilizar Unity, se trata de ver todo como un "Único", cuando en realidad tratamos de manejar todo de manera arbitraria.
   
   
      Dejemos de lado un poco los eventos y vayamos a otro ejemplo. ¿Programaste alguna vez un juego fuera de Unity, comenzando de cero?, si es así te darás cuenta que la programación basada en componentes es algo chocante, no termina de convencerte y por lo general da más problemas que soluciones, Unity hace que lo "recién llegados" lo vean de manera equivocada...
   

A la pregunta ... ¿Programaste alguna vez un juego fuera de Unity, comenzando de cero? La respuesta es ... (me ha quedado tope concurso de la tele jajajaja) NUNCA he programado un juego en Unity, pero llevo mas años de los que me gustaria a veces programando aplicaciones para empresas (y hay empresas de todo tipo). Lo siento, no se si tendre idea o sere un zoquete pero en cualquier caso mi ignorancia no vendra porque empece a programar cuando descubri Unity con la idea de hacerme millonario con los juegos, por lo tanto no soy un "recien llegado"
 
Cuando hablo de programacion no lo hago pensando en el poco tiempo que llevo utilizando Unity, si no en el mucho tiempo que llevo haciendo programacion orientada a objetos (mayormente C++, C# y java). Cuando quieras te menciono alguna de las caracteristicas de la POO, o te hago un copy / paste para que las palabras no sean mias y asi no de la sensacion de vacilada xDDD
 
Con tan solo una de las caracteristicas fundamentales de la POO ves que el metodo que pusiste no llega ni a chiste, pero de buen rollo (no es algo que diga yo, lo dice el paradigma de la POO que no lo invente yo). A ver si averiguas cual es esa caracteristica
 
Utilizo mucho Unity a nivel personal porque me permite por un lado hacer lo que me gusta mas, que es programar, al mismo tiempo que lo que programo es muy distinto a lo del curro por lo que me permite desconectar sin dejar de programar. Pero aunque lleve relativamente poco tiempo en Unity, te aseguro que no fueron los de Unity los que inventaron los delegados en este caso ... algunos utilizabamos los delegados antes de que existiera Unity, mientras que otros no programaron hasta que aparecio Unity. No preguntare a que grupo perteneces porque tampoco interesa mucho.
 
Un saludo.

venga, vamos a sacarnos todos el rabo a ver quien lo tiene mas grande XD

Cita de: Kvashir date=1502390025venga, vamos a sacarnos todos el rabo a ver quien lo tiene mas grande XD
   

Jajajajajajaja  ... el comentario de @Arthure me hizo recordar a un usuario TheCode de hace un tiempo que quería programar un sistema revolucionario en unity.

Me da gracia porque si preguntan "q son los delegates? como usarlos en eventos? que es un evento? Componentes?" nadie constesta nada, ahora si preguntas "como envio la posicion y rotacion?" termina en delegates, eventos, componentes ...
 
Los programadores y su lucha de ego... tratando de resolver problemas que probablemente no se van a encontrar nunca ... mientras tanto un recien llegado saca un juego exito hitaso con unos if's, eso si, "esa delegate no va ahi" ,"guarda estas faltando el respecto al paradigma bla bla bla" ....ah no me canso.
 
 
 
 
 
 

Cita de: lightbug date=1502390782Me da gracia porque si preguntan "q son los delegates? como usarlos en eventos? que es un evento? Componentes?" nadie constesta nada, ahora si preguntas "como envio la posicion y rotacion?" termina en delegates, eventos, componentes ...
   
      Los programadores y su lucha de ego... tratando de resolver problemas que probablemente no se van a encontrar nunca ... mientras tanto un recien llegado saca un juego exito hitaso con unos if's, eso si, "esa delegate no va ahi" ,"guarda estas faltando el respecto al paradigma bla bla bla" ....ah no me canso.
   

Jajaja, es la realidad, uno va tratando de perfeccionarse y llega un "NOOB" y destruye todos tus paradigmas!!!.. Nadie conoce la verdad, siempre hay una forma diferente de hacer las cosas, a veces mejor o peor, pero a fin de cuentas diferente.
 
 
 
Viva la ley de la relatividad.. jajaja
 
 
 
 

"limpia, optimizada y expansible"
 
Segun mi experiencia a veces estas tres cosas son completamente incompatibles.

Cita de: francoe1 date=1502390969Nadie conoce la verdad, siempre hay una forma diferente de hacer las cosas, a veces mejor o peor, pero a fin de cuentas diferente.
   

Eso es lo lindo de programar.

limpia, optimizada y expansible.
 
Segun mi experiencia a veces estas estas tres cosas son totalmente incompatibles
 
Si quieres optar por un codigo "expansible" para poder ahorrarte escribir y modificar codigo en el futuro, para crear un codigo que valga para todo.... estas seguramente perdiendo optizacion

Cita de: Igor date=1502391778limpia, optimizada y expansible.
   
   
      Segun mi experiencia a veces estas estas tres cosas son totalmente incompatibles
   
   
      Si quieres optar por un codigo "expansible" para poder ahorrarte escribir y modificar codigo en el futuro, para crear un codigo que valga para todo.... estas seguramente perdiendo optizacion
   

¡Vivan las API poco optimizadas!

Cita de: francoe1 date=1502390969Jajaja, es la realidad, uno va tratando de perfeccionarse y llega un "NOOB" y destruye todos tus paradigmas!!!
   

Creere que soy el "NOOB"

Cita de: francoe1 date=1502390969Nadie conoce la verdad, siempre hay una forma diferente de hacer las cosas, a veces mejor o peor, pero a fin de cuentas diferente.
   

Sin embargo eres tu mismo quien dijo cosas como "olvidaros de utilizar Monobehaviour", "nunca hay que utilizar SendMessage", "estas muy equivocado en como entiendes Unity".
 

Cita de: lightbug date=1502390782Me da gracia porque si preguntan "q son los delegates? como usarlos en eventos? que es un evento? Componentes?" nadie constesta nada, ahora si preguntas "como envio la posicion y rotacion?" termina en delegates, eventos, componentes ...  Los programadores y su lucha de ego...
   

Nadie dijo nada de delegates, hasta que alguien quiso darse de listo con el tema de los delegates porque queda muy "PRO" ... y al final para poner un ejemplo que mas que quedar pro quedó bastante de "NOOB"
 
En realidad la pregunta era : Como enviar dos variables en un SendMessage ? El que no tiene ni idea, solo por sentido comun y viendo que las dos variables se encuentran dentro de un mismo objeto, contesto "enviando el transform".
 

Cita de: francoe1 date=1502390696Jajajajajajaja  ... el comentario de @Arthure me hizo recordar a un usuario TheCode de hace un tiempo que quería programar un sistema revolucionario en unity.
   

Pues yo volveria a leer el comentario de Arthure porque me parece que te perdiste algo ... utilizo Unity para uso personal a ratos, empiezo un proyecto y cuando cierro unity borro el proyecto. Unity lo utilizo para desconectar del trabajo; donde da a entender que quiera hacer algo grande y revolucionario con Unity, cuando dejo claro que no intento hacer ni algo pequeño ?
 

Cita de: Kvashir date=1502390025venga, vamos a sacarnos todos el rabo a ver quien lo tiene mas grande XD
   

Nooo porfavor !!!!!
 
Con un tio podria hacer una comparacion de a ver quien los tiene mas grandes, entiendase los huevos pero para eso no hay que sacarselos ni tocar ni nada por el estilo.
 
Pero medirse a ver quien tiene el rabo mas grande ?? Sinceramente, prefiero que me de su opinion cualquier tia ... pero tu te imaginas una colla de tios sacandose la polla y ponerse a medirla ? Que pensarias tu si entras en un cuarto y te encuentras con esa imagen ?
 
Ya se que es una frase hecha, que no es literal ... pero hay cosas que quedan un poquillo ... del ambiente digamos
 
 
 
 
 
 

Cita de: Arthure date=1502391934Creere que soy el "NOOB"
   
      Sin embargo eres tu mismo quien dijo cosas como "olvidaros de utilizar Monobehaviour", "nunca hay que utilizar SendMessage", "estas muy equivocado en como entiendes Unity".
   
   
      Nadie dijo nada de delegates, hasta que alguien quiso darse de listo con el tema de los delegates porque queda muy "PRO" ... y al final para poner un ejemplo que mas que quedar pro quedó bastante de "NOOB"
   
      En realidad la pregunta era : Como enviar dos variables en un SendMessage ? El que no tiene ni idea, solo por sentido comun y viendo que las dos variables se encuentran dentro de un mismo objeto, contesto "enviando el transform".
   
   
      Pues yo volveria a leer el comentario de Arthure porque me parece que te perdiste algo ... utilizo Unity para uso personal a ratos, empiezo un proyecto y cuando cierro unity borro el proyecto. Unity lo utilizo para desconectar del trabajo; donde da a entender que quiera hacer algo grande y revolucionario con Unity, cuando dejo claro que no intento hacer ni algo pequeño ?
   
   
      Nooo porfavor !!!!!
   
      Con un tio podria hacer una comparacion de haber quien los tiene mas grandes, entiendase los huevos pero para eso no hay que sacarselos ni tocar ni nada por el estilo.
   
   
      Pero medirse a ver quien tiene el rabo mas grande ?? Sinceramente, prefiero que me de su opinion cualquier tia ... pero tu te imaginas una colla de tios sacandose la polla y ponerse a medirla ? Que pensarias tu si entras en un cuarto y te encuentras con esa imagen ?
   
   
      Ya se que es una frase hecha, que no es literal ... pero hay cosas que quedan un poquillo ... del ambiente digamos

Solo para decir que no te dije "NOOB" ... 
 
 ...
 
 
 
...
 
 
 
 
 
...

Acabo de ver que he publicado dos veces lo mismo, la primera no se que ha pasado que se me ha ido y pensaba que no se habia publicado...
 
Esta claro que cada cual tiene su "estilo", y siempre va a existir la batalla de los "espacios" contra los "tabulados", jejeje, yo soy de tabular, pero esto de la programacion es un mundo tan amplio y tan en evolucion y en crecimiento que cualquiera que valla de experto no sabe ni la mitad del todo

Cita de: Igor date=1502391778Si quieres optar por un codigo "expansible" para poder ahorrarte escribir y modificar codigo en el futuro, para crear un codigo que valga para todo.... estas seguramente perdiendo optizacion
   

Es un buen punto, ahora, es como si estas sentado en el asiento del conductor, ajustas los espejos y luego desplazas el asiento hacia adelante, el ajuste de espejos tiene que rehacerse. Uno entiende que si tenes pensado un codigo expansible esta claro que tengas un cierto alcance, una vez llegado a ese punto se deberá optimizar, esta claro que todo junto no se puede lograr.
 
Yo no quiero decir nada pero todo esto es culpa de @pioj
 

   
      Si algún día compartes un ejemplo de todo esto que fomentas, la Comunidad y to te lo agradeceremos efusivamente...
   

[/quote]