Necesito enviar dos variables con SendMessageUpwards para, antes de destruir el objecto, enviarle al padre la posición y rotación de este.
no entiendo muy bien lo que quieres decir, pero intenta concatenar las variables y usar split, aunque seguro que hay algo mejor, como mandar eso antes de destruirlo jajaja
Cita de: Kvashir date=1502054738no entiendo muy bien lo que quieres decir, pero intenta concatenar las variables y usar split, aunque seguro que hay algo mejor, como mandar eso antes de destruirlo jajaja
Es una buena solución, sí. Condensarlos en una string con un delimitador...
Cita de: pioj date=1502178924Es una buena solución, sí. Condensarlos en una string con un delimitador...
Pues para mi es una solucion un tanto ... sin palabras; como aquel que intenta reinventar la rueda. Si se trata de enviar la posicion y rotacion de un gameobject, lo mas sencillo es enviar el propio objeto "transform" que ya tiene almacenados ambos datos.
Serializar el componente Transform y Deserializar....
Capturar un Evento por parte del Padre.
Etc...
Pero usar SendMessageUpwards() no es conveniente! ...
Tienes que dejar de pensar en componentes y más bien tratar de armar un ambiente estructurado y en sintonía, utilizar la mínima cantidad de MonoBehaviour y abstraer todo al máximo logrando así mantener tu aplicación limpia, optimizada y expansible.
Cita de: francoe1 date=1502212982Tienes que dejar de pensar en componentes y más bien tratar de armar un ambiente estructurado y en sintonía, utilizar la mínima cantidad de MonoBehaviour y abstraer todo al máximo logrando así mantener tu aplicación limpia, optimizada y expansible.
Amén, es la parte claramente que mas tiempo y planificacion lleva, el resto son triggers, vectors y quaternions, una papita.
Cita de: Arthure date=1502188060Pues para mi es una solucion un tanto ... sin palabras; como aquel que intenta reinventar la rueda. Si se trata de enviar la posicion y rotacion de un gameobject, lo mas sencillo es enviar el propio objeto "transform" que ya tiene almacenados ambos datos.
lo se, es una castaña eso, pero como tampoco se explicó mejor XD, tambien dije que seguro hay algo mejor que hacer eso, yo casi nunca uso MonoBehaviour, solo en casos que no hay otra manera de conseguir mi objetivo.
Cita de: francoe1 date=1502212982Tienes que dejar de pensar en componentes y más bien tratar de armar un ambiente estructurado y en sintonía, utilizar la mínima cantidad de MonoBehaviour y abstraer todo al máximo logrando así mantener tu aplicación limpia, optimizada y expansible.
Si algún día compartes un ejemplo de todo esto que fomentas, la Comunidad y to te lo agradeceremos efusivamente...
Cita de: pioj date=1502303919Si algún día compartes un ejemplo de todo esto que fomentas, la Comunidad y to te lo agradeceremos efusivamente...
Claro, siempre que puedo estoy compartiendo, pero en mis momentos libres creó material que luego pueda obtener ganancias, pero estoy muy limitado con el tiempo.
En este caso, no se explica claramente lo que está necesitando, pero supongamos que el tiene un objeto que emparenta a otro.
(Player):GameObject // Jugador
(Box Temp):GameObject // Caja temporal que se destruye al pasar por algún lugar.
Supongamos que el jugador necesita saber si la caja temporal se ha destruido, de ser así, obtener los valores del componente transform de la caja.
Por lo general, este tipo de problemas se plantean de la siguiente forma ¿La caja le avisa al Jugador que se destruyó?, ¿El jugador comprueba que la caja se existe? ... pero todas estas dudas no son más que malas ideas, partamos desde un inicio. ¿Por que el jugador necesita saber si la caja se destruyo?, ¿Y?¿Si otro componente tambien lo requiere? ... siempre estas son las preguntas futuras, las que hacen que el desarrollo de una aplicación se vuelva inestable. Entonces ¿Cómo realizarlo de la manera correcta?, bien, en primer lugar, vamos a tratar de centralizar los eventos, es decir, creamos una clase estática la cual puede llevar el nombre de GameEvents donde registramos todos los eventos del juego (con antelación deberíamos tener el diseño de nuestra aplicación, está más que claro que de lo contrario hay pocas posibilidades de éxito). Veamos un Ejemplo:
public static class GameEvents
{
public delegate DestroyObjectDelegate(GameObject go);
public static event DestroyObjectDelegate DestroyObjectEvent = delegate {};
public static void DestoyObject(GameObject go)
{
DestroyObjectEvent.Invoke(go);
//Unity ...
MonoBehaviour.DestoyObject(go);
}
}
De esta manera nosotros podríamos desde cualquier lugar de la aplicación capturar el evento requerido... Ejemplo.
public class Player : MonoBehaviour
{
private void Start()
{
GameEvents.DestroyObjectEvent += OnDestroyObject;
}
private void OnDestroyObject(GameObject go)
{
if(go.name == "Box Temp") Debug.Log("¡Objetivo destruido!");
}
}
Podríamos utilizar la misma implementación desde cualquier lugar del proyecto, debido a que estamos trabajando basado en eventos.
Todo esto es una mirada muy por arriba de como se hacen las cosas, en realidad tiene aun muchos pasas antes de llegar a esto, como son las cases de Argumentos, el diseño de delegados, componentes, clases, dependencias...
1º Aprender a utilizar eventos(event y delegate)
2º Aprender a utilizar enumeradores, entender como funcionan internamente (IEnumerator)
3º Aprender a utilizar clases Abstractas, Interfaces, Estructuras saber donde y cuando utilizarlas.
4º La decisión de utilizar un Componente MonoBehaviour es crítico, tratemos de no hacerlo.
En este punto me gusta mucho dar el ejemplo del movimiento de las actores dentro de un juego, por ejemplo, tenemos dos tipos de personajes con movimientos totalmente diferentes, muchos frente a este problema crearán un componente diferentes para cada uno, 2 prefabs, y se empieza a complicar todo, otros recurrirán a la abstracción, mi recomendación, utilizar clases no serializadas para los diferentes comportamientos, es decir.
public class Player : MonoBehaviour
{
private Motor _motorJumper = new MJumper();
private Motor _motorRunner = new MRunner();
private Motor _current;
private void SetMotor(int mode)
{
switch(mode)
{
case 0: _current = _motorJumper; break;
case 1: _current = _motorRunner; break;
}
}
private void Update()
{
_current.Run(Input.Axis*****);
}
}
public class Motor
{
public virtual void Run(Vector3 axis){}
}
public class MJumper : Motor
{
public override void Run(Vector3 axis)
{
movimientos..
}
}
public class MRunner : Motor
{
public override void Run(Vector3 axis)
{
movimientos..
}
}
Existen muchos ejemplos, en cuanto tenga tiempo voy a terminar una serie de tutoriales que tengo ya en edición, sobre un sistema de armas bastante completo, donde trato de explicar la importancia de cada técnica...
Cita de: francoe1 date=1502307684Claro, siempre que puedo estoy compartiendo, pero en mis momentos libres creó material que luego pueda obtener ganancias, pero estoy muy limitado con el tiempo.
En este caso, no se explica claramente lo que está necesitando, pero supongamos que el tiene un objeto que emparenta a otro.
(Player):GameObject // Jugador
(Box Temp):GameObject // Caja temporal que se destruye al pasar por algún lugar.
Supongamos que el jugador necesita saber si la caja temporal se ha destruido, de ser así, obtener los valores del componente transform de la caja.
Por lo general, este tipo de problemas se plantean de la siguiente forma ¿La caja le avisa al Jugador que se destruyó?, ¿El jugador comprueba que la caja se existe? ... pero todas estas dudas no son más que malas ideas, partamos desde un inicio. ¿Por que el jugador necesita saber si la caja se destruyo?, ¿Y?¿Si otro componente tambien lo requiere? ... siempre estas son las preguntas futuras, las que hacen que el desarrollo de una aplicación se vuelva inestable. Entonces ¿Cómo realizarlo de la manera correcta?, bien, en primer lugar, vamos a tratar de centralizar los eventos, es decir, creamos una clase estática la cual puede llevar el nombre de GameEvents donde registramos todos los eventos del juego (con antelación deberíamos tener el diseño de nuestra aplicación, está más que claro que de lo contrario hay pocas posibilidades de éxito). Veamos un Ejemplo:
public static class GameEvents
{
public delegate DestroyObjectDelegate(GameObject go);
public static event DestroyObjectDelegate DestroyObjectEvent = delegate {};
public static void DestoyObject(GameObject go)
{
DestroyObjectEvent.Invoke(go);
//Unity ...
MonoBehaviour.DestoyObject(go);
}
}
De esta manera nosotros podríamos desde cualquier lugar de la aplicación capturar el evento requerido... Ejemplo.
public class Player : MonoBehaviour
{
private void Start()
{
GameEvents.DestroyObjectEvent += OnDestroyObject;
}
private void OnDestroyObject(GameObject go)
{
if(go.name == "Box Temp") Debug.Log("¡Objetivo destruido!");
}
}
Podríamos utilizar la misma implementación desde cualquier lugar del proyecto, debido a que estamos trabajando basado en eventos.
Todo esto es una mirada muy por arriba de como se hacen las cosas, en realidad tiene aun muchos pasas antes de llegar a esto, como son las cases de Argumentos, el diseño de delegados, componentes, clases, dependencias...
1º Aprender a utilizar eventos(event y delegate)
2º Aprender a utilizar enumeradores, entender como funcionan internamente (IEnumerator)
3º Aprender a utilizar clases Abstractas, Interfaces, Estructuras saber donde y cuando utilizarlas.
4º La decisión de utilizar un Componente MonoBehaviour es crítico, tratemos de no hacerlo.
No es mi intencion ofender ... pero a mi me parece una chorrada como utilizas los delegados y eventos eh ! Sobretodo teniendo en cuenta que segun algun comentario se da a entender algo parecido a "para esto hay que recorrer un gran camino, estudiar muchos años y cuando crezcais podreis ser como dios" xDDD
El problema de querer hacer ver que el uso de los delegados es algo muy avanzado, es que los que somos programadores (no me refiero a Unity) los utilizamos desde hace mucho tiempo, y los que no pretenden ser programadores se las va a sudar ... Como si se quiere decir que es la panacea.
Dicho eso, comentare porque encuentro una chorrada ese uso de los delegados ... En primer lugar, una clase estatica para los eventos ??? Como se dice en mi tierra, "oh dios mio !" ... exceptuando mi sobrina que es muy chula ella y diria "ohh my god !" xDDD Para decir que hay que estudiar mucho y entender como y para que se utilizan las cosas, no vamos muy sobrados
Comenzando porque no se que pinta ese delegate ahi, pero eso es otra historia que no viene a cuento ... imagino que el codigo queda mas cool con la palabra delegate xDDD
Continuando porque un evento (no la captura y lo que se haga con ese evento) sino el evento se ejecute desde una clase estatica ... ademas de ser de chiste de por si, estas obligado a hacer la funcion publica, que ademas es un delegado, y eso para alguien que dice que hay que mantener
una aplicacion limpia, optimizada y expansible suena a chiste malo.
En mi mundo un evento (accion) lo ejecuta un objeto, y otros objetos capturan estos eventos ... en tu caso coges y llevas tanto la accion como la captura de dicha accion a una clase estatica, dices que asi hay que hacerlo porque evitas utilizas MonoBehaviour y te quedas tan ancho
Solo dire que si una vez "capturado" el evento por el Player este debe comprobar el tag, name o cualquier otro atributo del objeto destruido para saber si debe hacer una accion o no ...
es que se nota que es un codigo bien hecho, lo que cualquiera llamaria una aplicacion limpia, optimizada y expansible Cita de: francoe1 date=1502307684En este punto me gusta mucho dar el ejemplo del movimiento de las actores dentro de un juego, por ejemplo, tenemos dos tipos de personajes con movimientos totalmente diferentes, muchos frente a este problema crearán un componente diferentes para cada uno, 2 prefabs, y se empieza a complicar todo, otros recurrirán a la abstracción, mi recomendación, utilizar clases no serializadas para los diferentes comportamientos, es decir.
public class Player : MonoBehaviour
{
private Motor _motorJumper = new MJumper();
private Motor _motorRunner = new MRunner();
private Motor _current;
private void SetMotor(int mode)
{
switch(mode)
{
case 0: _current = _motorJumper; break;
case 1: _current = _motorRunner; break;
}
}
private void Update()
{
_current.Run(Input.Axis*****);
}
}
public class Motor
{
public virtual void Run(Vector3 axis){}
}
public class MJumper : Motor
{
public override void Run(Vector3 axis)
{
movimientos..
}
}
public class MRunner : Motor
{
public override void Run(Vector3 axis)
{
movimientos..
}
}
Existen muchos ejemplos, en cuanto tenga tiempo voy a terminar una serie de tutoriales que tengo ya en edición, sobre un sistema de armas bastante completo, donde trato de explicar la importancia de cada técnica...
Esto ultimo que se decia te hubiera podido quedar mucho mejor ... pero tambien es un poquito una cagada; porque el uso de la clase Motor, junto a sus derivadas, es muy bueno para hacer un codigo mas limpio y expansible (lo de optimizado vamos a dejarlo en el aire) pero cuando se trata de hacer una maquina de estados.
Pero si solo es para mover un personaje, por muy distinto que se muevan ... una clase abstracta, con la funcion abstracta encargada de movimiento para que obligue a implementarla en cada uno de los personajes, y marchando.
@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...
Cita de: francoe1 date=1502307684Todo esto es una mirada muy por arriba de como se hacen las cosas, en realidad tiene aun muchos pasas antes de llegar a esto, como son las cases de Argumentos, el diseño de delegados, componentes, clases, dependencias...
En esta parte especificó que en realidad esto es algo muy disparado...
De todos modos gracias por la corrección, pero antes la burla o "la mala manera de corregir" estaria bueno que muestres de que manera cada implementación sería mejor, y que al mismo tiempo, personas que no conocen mucho sobre el tema puedan llegar a entender.
Saludos.
Cita de: Arthure date=1502364702Comenzando porque no se que pinta ese delegate ahi, pero eso es otra historia que no viene a cuento ... imagino que el codigo queda mas cool con la palabra delegate xDDD
No se mucho, (bueno muy poquito) de delegates, a mi tambien me confundio su uso un poco (en Unity oficial) ya que lo especifico de c# no es mi palo, pero cuando se da el evento vos llamas a un "event delegate" por decirlo asi simple, y cada listener ejecuta su metodo propio, que suscribió previamente a la escucha, entonces como haces esto sin delegates? tenes multiples metodos distintos, esa es la idea del delegate en primer instancia, que haga de puntero de metodos por asi decirlo, porque el delegate asi como lo ves lo usan en Unity y en cada porcion de codigo que he visto. Lo ideal seria entenderlo al 100% que no es mi caso pero estaria bueno Arthure que si respondes diciendo que todo es chiste digas porque exactamente, si en vez de tirar esto y lo otro es chiste digas ese delegate no va ahi o de esa forma por tal y tal razon, es "mejor" usar tal por tal y tal razon. Me entendes? sino siempre suena a bardo y mas viniendo del famoso Arthure .
Mi manejador de eventos era super sencillo, un monobehavior de toda la vida con sus eventos creados, chequeando si de dan las acciones correspondientes para disparar el evento, quien lo escuche que haga lo suyo. Pero despues lo eliminé ya que no hacia nada y me metia un monobehaviour sin sentido, asi que cada autor del evento tiene su evento static, mas especifico su "static event -delegate-" (habra tres en el juego maximo, nada raro) por ejemplo:
public delegate void PlayerDeadDelegate ();
public static event PlayerDeadDelegate PlayerDead;
Cita de: Arthure date=1502364702Pero si solo es para mover un personaje, por muy distinto que se muevan ... una clase abstracta, con la funcion abstracta encargada de movimiento para que obligue a implementarla en cada uno de los personajes, y marchando.
El usar o no abstract o virtual(overrride) no depende si es lo mismo prefiero esto o lo otro (a veces por comodidad mmm si),en un caso (abstract) obligas como bien decis a implementar el metodo (lo ideal es que cada clase vaya tomando su forma y asi obligar cada funcionalidad, algo asi como el uso de interfaces) y en el otro ya esta implementado por la clase base (la idea es que no sea siempre un { } ), algo asi como si no pones un Start() o Update() Unity ya sabe que hacer aunque no lo implementes, en su behaviour. A lo que iba es que el usarlo sirve para tener distintas comportamientos entre base y derivada, pero si en este caso Motor no pincha ni corta me parece que lo correcto seria un abstract como decis.
Creo de @Arthure no entendió o yo me mal exprese en el sentido de cómo estaba interpretando el mensaje, la idea era dar como una "MALA IDEA" de cómo centralizar un poco las aplicaciones.
Cita de: lightbug date=1502376038public delegate void PlayerDeadDelegate (); public static event PlayerDeadDelegate PlayerDead;
Esto puede estar bien, o mal, dependiendo de cuántos jugadores estén dentro del juego, pero no por eso deja de ser una buena idea o solución.
Por lo general en el desarrollo de un juego se centralizan todos los eventos, esto hace que el "DEBUG" sea más sencillo, la recopilación de información sea más ordenada. ¿Como sabrás cuantas veces murio el jugador? o ¿Cuantos enemigos has matado? ...
Cita de: Arthure date=1502364702En mi mundo un evento (accion) lo ejecuta un objeto, y otros objetos capturan estos eventos ... en tu caso coges y llevas tanto la accion como la captura de dicha accion a una clase estatica, dices que asi hay que hacerlo porque evitas utilizas MonoBehaviour y te quedas tan ancho
¿Cómo lo implementamos mis preguntas basándonos en tu teoría?, ¿Eventos estáticos? - ¿Referencias? ... Pienso, no es mejor una clase "estática" que se encarge de obtener todos estos eventos, es decir, si muere el jugador llama a una función dentro de mi clase GameEvents y esta llama a un evento... El evento es capturado por quien quiera, pero la llamada tambien, eso se llama "Centralización" - ¡No creo que este mal este punto! Quizás el ejemplo no es el correcto, pero este mismo método de implementación utiliza VmWare para VCenter y dudo que ellos no sepan lo que hacen -
Sigamos en base a tu aclaración ... ¿Y si quiero simular 3000 muertes de enemigo?¿Debería entonces crear 3000 enemigos y matarlos?, ¿No existe la remota posibilidad de realizarlo con un comando? ... Mejor aún, vamos al Networking ... Como sincronizo todo un juego basado en componentes no referenciados ...
Creo, en cierta forma que has interpretado mal el mensaje, y tu forma de contestar no va con tus "conocimientos" ...
Como tambien lo dice @lightbug, deberias corregir, no simplemente insultar.
Cita de: francoe1 date=1502377107Esto puede estar bien, o mal, dependiendo de cuántos jugadores estén dentro del juego, pero no por eso deja de ser una buena idea o solución.
Buen punto, mi alcance nunca fue el multiplayer pero es cierto puede resultar en catastrofe, primero porque como lo tengo yo cualquier muerte daria lugar a la llamada del unico evento, epic fail.
Cita de: lightbug date=1502377461Buen punto, mi alcance nunca fue el multiplayer pero es cierto puede resultar en catastrofe, primero porque como lo tengo yo cualquier muerte daria lugar a la llamada del unico evento, epic fail.
Aun así, no lo vería como un "Error"... Pero la mejor forma de pensar es que en nuestra aplicación debe existir un árbitro, alguien que diga esto si esto no... pero si pensamos en que cada objeto lleve los eventos entonces pensamos en referencias, y si tenemos 20000 objetos lanzando eventos entonces tenemos un problema, no es lo mismo llamar un evento 20000 veces que instanciar 20000 eventos y capturarlos, y si él objetos se destruye se pierde la referencia
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]
Cita de: lightbug date=1502392352Es 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
Y mi culpa por queres hacerme el sabio...
Mierda :( ....
Este mundo esta poblado de inutiles como YO! ... Disculpas al Foro por tener que llevar este peso...
Cita de: lightbug date=1502392352Yo no quiero decir nada pero todo esto es culpa de @pioj
Pues mirandolo con perspectiva ... Que gran verdad has dicho !
La verdad es que si no hubiera pedido un ejemplo, no se habria liado todo esto ... es lo que tiene que te lo quieran dar todo hecho, en vez de buscar la informacion sobre delegates por el mismo ... habia que pedir un ejemplo ???
Cita de: francoe1 date=1502393194Y mi culpa por queres hacerme el sabio...
Mierda :( ....
Este mundo esta poblado de inutiles como YO! ... Disculpas al Foro por tener que llevar este peso...
En el foro somos muy buena gente, yo por lo menos te disculpo ... y si yo lo hago que tengo el dudoso honor de ser el mas follonero por estos lugares, el resto seguro que tambien te disculpara. Sobre ese peso tampoco te preocupes mucho, pero ya sabes lo que tienes que hacer :
Aprender a utilizar eventos (event y delegate).
Aprender a utilizar enumeradores, aprender como funcionan internamente.
Aprender a utilizar clases abstractas, interfaces y estructuras; saber donde y cuando utilizarlas ... y si ademas tambien el como ya es la ostia.
Y lo mas importante de todo, a no utilizar componentes que los manda el diablo.
Sigue esos pasos como si fueran la biblia y veras como ese gran peso cada vez se ira haciendo mas libiano hasta que al final desaparezca.
Fuera coña ... un saludo.
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 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
pues alguien me subió puntuación por ese comentario, según tu tendremos que ir alerta con los jabones por aquí, jajajajjajaja
Cita de: Kvashir date=1502395481pues alguien me subió puntuación por ese comentario, según tu tendremos que ir alerta con los jabones por aquí, jajajajjajaja
Que miedo !!!!!
El que te subio la re***cion por ese comentario ... lo hizo porque sabe que son anonimos los votos
Cita de: Arthure date=1502395592Que miedo !!!!!
Que miedo !!!!!
El que te subio la re***cion por ese comentario ... lo hizo porque sabe que son anonimos los votos
uuuuuuu parece que lo tienes todo muy bien estudiado!
bueno ya XDD que estamos desvariando del post original
PD: optimiza, tienes lineas repetidas en el comentario!
Cita de: Kvashir date=1502395887PD: optimiza, tienes lineas repetidas en el comentario!
Jajaja, eso seria tambien limpiar, aunque no se si seria expansible