Cita de: zopas tv date=1510086833pero en other. tags lo dejo tal cual o que
   
   
       
   

Yo dire mas que @OldGuy son copia exacta, cambiando nombre de tag, de la documentacion). Y si no has mirado la documentacion de Unity, que deberia ser lo primero, llamame desconfiado pero es que me cuesta creer que hayas buscado por internet.
 
Dicho eso, permitidme hacer una observacion que para cualquiera que sea programador (y para quien no lo sea tambien) deberia ser de sentido comun ... si buscas en google cosas como "hacer script de puntuacion en unity que solo interactue con el objeto pelota y no afecte al coche" pues no vas a tener mucha suerte.
 
Pensaba que lo mas triste era intentar programar un juego sin saber programar ... pero ahora que lo pienso, intentar utilizar el buscador de internet sin saber utilizarlo es aun peor xDDD
 
Un consejo que hacia mucho que no daba: aprende programacion y veras que luego sera algo super sencillo adaptar los codigos que encuentres a tus necesidades, sin necesidad de buscar exactamente lo que tu quieres hacer por no ser capaz a modificar nada a tu gusto.

hola @zopas tv,
 
siento comunicarte que tu problema no es con el sistema de oxido nitroso del coche, y tampoco con la velocidad ... por lo menos con la velocidad del coche; el problema mas preocupante aqui es la velocidad de trabajo si es cierto que llevas varios dias intentando hacer que se incremente la velocidad del coche, y en ese periodo de tiempo lo maximo que has hecho ha sido un script que contiene dos condicionales. Por lo tanto me atreveria a decir que :
 

• 
     como he comentado, tienes un problema a la hora de programar ...
  


• 
     ... o te tiras un farol con eso de que llevas dias y solo has puesto dos condicionales hechos en un momento, esperando que se te haga todo desde cero (lo que has puesto y nada es lo mismo) ...
  


• 
     ... o tienes un script mucho mas currado que eso pero te da miedo enseñarlo por si alguna mala persona del foro te roba el codigo y se aprovecha de tu trabajo, con lo que es sumamente dificil ayudarte (por no decir imposible).
  

ya nos contaras que opcion es la correcta,
 
un cordial saludo

Cita de: lightbug date=1508164419Es cierto, pero no creo que estas pruebas se hayan realizado, para "ponerse en contra" de los Time.deltaTime, simplemente se desmostró lo obvio. Además, un factor de mejora es un factor de mejora, independientemente de la cantidad de llamadas que tengas, distinto es hablar de una mejora general (específica de la aplicación), ya que, como bien decís, existen otros factores de mayor peso que deben ganar mayor atención que algunos simples Time.deltaTime, sería una tontería "optimizar" partiendo de esto, pero si se diera el caso que "estos tiempos"(dT) sean comparables con los "otros tiempos"(resto del código, monoB, graficos, audio, IA, etc), ya sea porque uno desea llamar 10 trillones de veces a un Time.deltaTime (vaya uno a saber porqué) la mejora general que implica la mejora del dT es, como bien decís, abismal. Claro, esta situación casi nunca se da y almacenar el dT se puede ignorar completamente.
   

Tienes razon en que si vas a utilizar 10 trillones de veces Time.deltaTime dentro del Update se notaria la diferencia en comparacion a guardar el valor una variable ... pero en ese supuesto caso, como decia (y sin necesidad de verlo), estaremos de acuerdo en que tendrias una mierda de codigo xDDD
 
Pero olvidemonos de utilizarlo 10 trillones de veces ... si eres capaz de pensar en un codigo factible para la funcion Update donde se utilice un minimo de 5 veces (una miseria !!!) el Time.deltaTime y no sea capaz de optimizarte el codigo sin necesidad de almacenar deltatime en una variable, para mi sinceramente estarias en un pedestal. (puedes tomarlo como un reto personal, que es buena manera de practicar)
 
Como ejemplo utilice un caso que contenia un bucle con un indeterminado numero de elementos (podian ser 1 o 10.000) y aun asi el deltatime, optimizando el codigo, solo se utiliza una sola vez. Por eso me refiero, a que si tienes un codigo donde utilizas el deltatime un gran numero de veces, es que no tienes un codigo muy optimizado ... y cuando se habla de optimizar, en lo primero que se deberia pensar es en el codigo en su conjunto.
 
P.D. para mi, el numero maximo necesario que aparece deltatime en una funcion Update (sabiendo para lo que se utiliza dicho valor) es dos veces ... Si aparece mas veces, señal de que algo esta fallando en el planteamiento del codigo.

Cita de: TheBullet date=1508134760Yo también lo encuentro pasarse, quizás para móviles es más útil... También dependerá del caso, si tienes un for o un while que utilizan una posición o el time.delta time a cada vuelta quizás será mejor guardarlo, pero para uso habitual lo veo excesivo.
   

Incluso aunque la funcion Update contenga un bucle for y que tuviera que recorrer 10.000 de objetos ... sin necesidad de ver el codigo, como habia dicho anteriormente, me atreveria a decir que el menor de los problemas es el uso de deltaTime.
 
Pongamos por ejemplo que nuestro personaje avance 1 unidad por cada enemigo que haya dentro de un rango de X unidades en un momento dado, es decir en el frame en cuestion. A continuacion pongo dos codigos que hacen exactamente lo mismo ...
 

EnemigoControlador [] enemigos;
float distancia_minima_reaccion;
private void Update () {
foreach (EnemigoControlador enemigo in this.enemigos) {
   if (personaje.posicion - enemigo.posicion < distancia_minima_reaccion) {
            personaje.posicion = personaje.posicion + distancia_recorrer * Time.deltaTime;
        }
}
}

EnemigoControlador [] enemigos;
float distancia_minima_reaccion;
private void Update () {
int enemigos_dentro_rango = 0;
foreach (EnemigoControlador enemigo in this.enemigos) {
   if (personaje.posicion - enemigo.posicion < distancia_minima_reaccion) {
            enemigos_dentro_rango += 1;
        }
}
    personaje.posicion = personaje.posicion + (distancia_recorrer * enemigos_dentro_rango) * Time.deltaTime;
}

 
Ambos codigos hacen exactamente lo mismo, aunque lo que hacen sea una chorrada ... la diferencia es que en el primero utilizas deltaTime un numero indeterminado de veces (hasta un maximo igual al numero de enemigos) y en el segundo caso solo utilizaras deltaTime en una unica ocasion, indistintamente al numero de enemigos.
 
Como decia, si se utiliza deltaTime 10 - 20 - 30 ... veces en una sola funcion Update, no hace falta ver el codigo para saber que el menor de los problemas es el deltaTime. Programar con la mentalidad de optimizar el codigo, junto con la de hacer un codigo facil de leer, es la mejor practica y lo mas sensato (y eso lo dira cualquier programador del mundo) ... pero para optimizar hay que saber lo que se hace y no solo ponerse a quitar cosas a punta pala.

@TheBullet es que para mi cachear con el objetivo de optimizar rendimiento, por lo menos en lo que se refiere a la funcion Update, solo tiene sentido si asignas el valor a la variable dentro de las funciones Start o Awake. Por ese motivo pensaba que era una broma ... porque no le encontraba ningun sentido puesto que el valor de deltaTime cambia en cada frame.
 
Incluso aunque me dijeran que guardando el valor de deltaTime iria un 75% mas rapido ... lo encontraria una tonteria: si a 1.000.000 le quitas el 75% la diferencia es abismal pero si a 0 le quitas el 75% te quedas igual. No comparemos los recursos que consume GetComponent, por ejemplo, con los que consume Time.deltaTime.
 
Para que tuviera un impacto notable el guardar deltaTime dentro de una variable se deberia de utilizar tal numero de veces dentro del Update que, aun sin saber como es el codigo (sin necesidad de verlo), me atreveria a asegurar que el menor de los problemas seria el uso de deltaTime.
 
Otra razon por las que un programador podria guardar cierto valor en una variable es para darle un nombre descriptivo, consiguiendo asi un codigo mas facil de leer ... por ejemplo, si tienes un circulo cuyo radio fuera de 5 unidades, en el caso de que tuvieras que trabajar con el area se crearia una variable llamada area_circulo = radio * 3.14; indistintamente de que lo fueras a utilizar 1 o 20 veces ... pero no por rendimiento, sino porque haras un codigo mas facil de leer. Pero tampoco es el caso de deltaTime porque cualquiera que lea esa palabra ya sabe lo que significa.
 
Ahora a nivel personal, a mi me causa sonrojo como poco el observar que se quiera optimizar en exceso incluso guardando el valor de deltaTime en una variable ... pero al mismo tiempo se vea continuamente fragmentos de codigo donde se utilizan GetComponent o Debug.Log como si los regalasen con las pipas

Cita de: juguefre date=1508112673Si me quieren atacar por lo que estan a punto de leer haganlo que no voy a tomar ofensa por que se lo pretencioso que esto va a sonar, hace unos 5 años se me ocurrio esta idea de videojuego.
   

No dire nada ofensivo sobre que tuvieras esa idea, pero si algo critico sobre la idea de juego en si ... a mi parecer, en lo que respecta a ese tipo de juegos, lo que menos te deberia preocupar es el tiempo necesario para realizarlo (que seguro tambien es mucho). Considero es un tipo de juego que necesitan una inversion de marketing brutal, fuera del alcance de los desarrolladores indies:
 
Cuando salio el Pokemon GO ya tenia el marketing hecho, solo diciendo la marca Pokemon te aseguras varios millones de descargas a nivel mundial. Ademas la idea de juego era muy original y animaba a salir en familia ... yo he visto padres con sus hijos salir a pasear con el movil en la mano a la caza de pokemons. Con todo eso, y teniendo en cuenta que no ha salido desde entoces ningun juego que fuera similar (que yo me haya enterado), lo logico es que hubiera Pokemon GO para tiempo en lugar de durar dos telediarios como duro.
 
Un juego que se excede de social, o tienes cientos de miles descargas en tu region (por ejemplo a nivel del territorio español, porque a nivel mundial seria ridiculo esa cifra) desde el primer momento y se mantienen ... o vas a tardar mas en hacerlo que la vida que tendra el producto.
 
Como yo veo las cosas los desarrolladores indies deberian centrarse en tipos de juegos que sean asequibles, con periodos cortos de produccion, mecanicas simples (rozando lo absurdo) pero adictivos, y sobretodo con mucho margen de beneficio.
 
Cuando alguien nombra titulos como tetris, la serpiente ... son juegos que podrias desarrollarlos en un breve periodo de tiempo, son juegos muy absurdos pero debido a su nivel de adiccion podrias tirarte horas jugando aunque todo el rato es lo mismo, y el margen de beneficio es infinito.
 
Ahora bien, si titulos como tetris, la serpiente, o mas recientes como es el caso de flappy birds son rapidos de programar con unos ridiculos costes de produccion, se sabe que provocan un alto grado de adiccion y tienen un margen de beneficio increible, que con suerte podrian provocar que te jubiles a antes de los 30 - 40 años ... porque no aparecen mas juegos como estos ? si existen en el mundo muchisimos mas programadores indies (incluidos los estudios indies) que no empresas desarrolladoras, porque da la sensacion que el 99.999% de titulos estan marcados por las empresas desarrolladoras (en cuestion de originalidad) ?
 
Por cada empresa desarrolladora de videojuegos en el mundo seguramente hayan miles de desarrolladores indies; lo mas normal seria que las empresas desarrolladoras sacaran ideas de nuestros productos, los mejoraran ganando una pasta y asi todos estariamos contentos ... en lugar de eso sucede todo lo contrario.
 
Que quieres que diga @juguefre, pero el unico motivo posible que encuentro es que no es tan facil tener una idea original ...

mmm Quiero entender que el guardar el valor de deltaTime en una variable para utilizarla es en plan ironico, medio en cachondeo ... pero como en los posts posteriores han continuado con la "broma" y en un tono serio, de hacer pruebas y tal, ya no se que pensar
 
en cualquier caso, siendo bien pensado y creyendo que era un chiste, mejor nos reiremos ... por lo menos que si alguien lee eso y no tiene muy claro lo que esta haciendo, no tenga el presentimiento de que esta correcto y se sienta tentado a hacerlo JAJAJAJA.

Hola @Igor, en realidad el titulo del tema esta equivocado ... ni el transform contiene el gameobject, ni el gameobject contiene el transform.
 
La clase GameObject puede referenciar al transform (que es el unico componente obligatorio) pero no es que lo tenga guardado; para que te hagas una idea, cuando haces gameobject.transform es como si fuera una manera simplificada de gameobject.GetComponent<Transform> y la prueba esta en que consume muchos mas recursos realizar gameobject.transform dentro del Update, por ejemplo para realizar un cambio de posicion, que no si guardas el transform en una variable y cambias la posicion mediante dicha variable.
 
Del mismo modo, el Transform tampoco contiene el GameObject ... lo que cualquier componente (Transform, Collider, o cualquier script realizado por ti) puede referenciar a su gameobject de manera similar a como sucede con la clase GameObject que puede acceder a su transform.
 
En resumen, que lo que tienen las clases GameObject y Transform son getters para referenciar a su transform o gameobject respectivamente, pero no los tienen almacenados de ningun modo.

Hola @SavitarDev,
 
primero advertirte que si te quieres dedicar al tema shaders, podras contar poquito con el foro (las cosas como son) ... aqui hay muchos programadores por lo que si tienes una duda personal en programacion podran aclararte, pero en tema shaders no hay ningun experto (no se puede decir que ni tan solo haya nadie que entienda mucho, aunque no sea al nivel de experto) por lo que la ayuda que podras recibir en el foro no ira mucho mas alla de ponerte algun video colgado en youtube o el link de alguna pagina de internet y la causa es que los shaders es un tema mucho mas especializado y concreto dentro de la programacion.
 
por contra, y la parte buena, si te especializas en shaders tendras mucha mas salida (o como minimo te encontraras con mucha menos competencia) que si te dedicas a la programacion en general.
 
Respecto a tus preguntas, que perfectamente podrian ser dudas tanto de shaders como de programacion C# porque son temas compartidos en este caso, sobre los vectores nada que añadir a lo que comenta el compañero @OldGuy, simplemente es un conjunto de valores que hacen referencia a una posicion o direccion.
 
Sobre los vectores normalizados no es mas que el resultado de convertir un vector cualquiera para que todos sus valores esten comprendidos entre -1 y 1, pero guardando la proporcion con el vector original. Por ejemplo, si tienes el vector [-5, 0, 1] al normalizarlo obtendrias [-1, 0, 0.2]. En realidad el proceso de normalizar es muy sencillo, y es mas el nombre que recibe que no la dificultad del proceso pues no es otra cosa que dividir todos sus valores entre el valor (absoluto) del valor mas grande:
 
[-10, 0, 2.5] -> [-10 / 10, 0 / 10, 2.5 / 10] -> [-1, 0, 0.25]
 
Nota importante : tener en cuenta que aunque un vector puede hacer referencia a una posicion o direccion, un vector normalizado SIEMPRE hara referencia a una direccion y nunca se normalizara un vector cuando se trate de posiciones. Los vectores [-10, 0, 2.5] y [-1, 0, 0.25] son identicos cuando se refiere a direccion pero no cuando se hacen referencia a posiciones.

@lightbug supaplex es reciclado ? La verdad es que no lo hubiera dicho nunca ... mas que nada porque tiene 30 años ese juego (es un decir, pero los 20 largos no se los quita nadie). Recuerdo que cabian un monton de copias de dicho juego en un disquete de 1.44 megas.
 
Dicho eso, si hoy en dia saliera un juego similar yo creo que lo volveria a jugar ... pero sin ser remasterizado, el juego tal cual porque lo bueno era la comida de olla para superar los niveles (aunque la mecanica tambien era super simple) y eso es lo dificil de conseguir con algo novedoso.

Hola @Yonkykong,
 
Lo complicado de esa propuesta no esta en la dificultad de realizar el juego, sino de tener la idea de juego ... cojo el ejemplo de uno de los juegos que has puesto, el flappy bird. Puedes hacer un flappy bird en una sola tarde si quieres, y ahora hay miles de tutoriales sobre como hacerlo en unas horas, es decir que puedes realizarlo en un dia incluso sin saber programar.
 
Pero serias capaz a hacer un flappy bird, aun con todo lo sencillo que es, si no existiera un flappy bird ya ? Incluso sabiendo programar y siendo un experto en Unity, me refiero a si se te ocurriria la idea de ese juego ... yo creo que incluso aunque la pensaras, la descartarias por ser una mecanica tan chorra.

Cita de: gZone date=1507716943lightbug, no se como será en tu país ... pero por aquí no pasarías ningún proceso de selección con esa ortografía, sobre todo porque saben perfectamente lo que implica (no estamos hablando de faltas sueltas -que todos podemos hacer y hacemos-)
   

Para mear y no echar gota ...
 
No se como sera en tu pais, pero aqui (y soy de españa) tiene guasa que creas tu pasarias algun proceso de seleccion ... quizas si el proceso de seleccion fuera para un puesto donde no existiera ningun tipo de interrelacion con otros compañeros, pongamos por ejemplo barrendero.
 
Pero aqui en españa, en un puesto donde dentro de los procesos de seleccion (ademas de la tipica entrevista) te hacen pruebas que tienen que ver con la psicologia y capacidad de los candidatos para relacionarse con los demas (mas cuando el puesto fuera para programador, que es un trabajo en equipo) ... realmente crees que tu pasarias algun proceso de seleccion, o pretendias hacer un chiste ?

Cita de: juguefre date=1507527296Posiblemente ya las vieron ambas pero igual las escribo:
   
   
      Shaolin soccer
   
   
      Kung fu hustle
   

Shaolin soccer no se si tiene que ver con los dibujos manga (tampoco se si hay unos dibujos manga llamados asi, lo supongo por el tema que se trata) ... pero yo he visto la pelicula que tiene el mismo nombre.
 
Si a alguien le gusta el cine independiente, y quedarse con la boca abierta de la perplejidad ... recomiendo ver tanto "Shaolin soccer" (la pelicula) como "La historia de ricky". No tienen calificativos posibles esas dos peliculas jajajajaja

No existe la figura de desarrollador de videojuegos como tal, lo mas normal es que haga referencia a un grupo de personas; en este grupo de se engloban programadores, diseñadores, artistas, etc. Dicho en otras palabras, el desarrollador no es una categoria laboral sino la compañia que desarrolla el videojuego.
 
Un juego puede ser realizado por una sola persona (la app store o este mismo foro estan repletos de ejemplos) pero aun asi, cuando se hable del desarrollador no se dira la persona que lo hizo sino el nombre que le puso a su "compañia" o estudio.
 
Programador de videojuegos tampoco existe ... existe la figura de programador, que despues puede darse el caso que se dedique o este especializado en videojuegos.

Cita de: Igor date=1507387896jajaja, estoy a poco de hacerlo... acabo de empezar(por fin me he decidido) a ver "dragon ball super" en japones, con subtitulos

Si te gusta el mundo dragon ball te lo recomiendo mucho ... a mi al principio me daba mucha pereza por ser en japones pero antes de terminar el primer capitulo ya te acostumbras a los subtitulos.
 
Lo bueno que tiene dragon ball super es que la accion pasa muy rapido, normalmente un combate por capitulo, por lo que cunden mucho ... no como en dragon ball o dragon ball Z donde muchas veces se tiraban un capitulo para un kamehame y poco mas.
 
Puedes empezar a verlo desde el capitulo que empieza el torneo de poder, casi en el capitulo 100 (llevan muy pocos capitulos del torneo), pero si quieres enterarte de toda la historia y que ha llevado a la situacion del torneo te recomiendo verlo desde el principio.
 
P.D. esta semana hay un especial de dos capitulos donde por fin se enfrentaran goku y jiren ! Que ganas tengo de que sea esta noche jajajaja