Ver la versión completa : Unity Empezar con Unity
Y esoty hablando de lo poco que he visto de Unity 4.6. Aun no he rascado ni la superficie.
Patada en los coj... ya mismo!!! :lol2:
Empieza por irte a unity5 que tiene cantidad de mejoras y abraza el lado oscuro xD
Si no, siempre puedes usar "viejos trucos", como tener siempre los mismos 5 enemigos en el nivel, que se "teletransportan" en donde se supone que tiene que estar el siguiente enemigo, y se ocultan "tras el escenario" cuando mueren (nunca se descargan). O de usar los "pasillos de interconexión" entre zonas (no se ven los niveles, y puedes aprovechar que el jugador está entretenido yendo de una a la otra para cargar recursos).
Esto no soluciona el problema del que hablamos drumpi. Unity es "tan ortogonal" que no sigue ni su propio patrón. Es decir, primero de todo el problema no es ir creando los enemigos cuando salen (que podría ser un problema si tienes varios saliendo a la vez, no voy a meterme con pooling ni nada ahora) si no que cuando se crea el primer enemigo del tipo X sus dependencias se cargan. El coste de creación de la instancia de un enemigo que ya tiene todas sus dependencias cargadas es infinitamente menor que el de la resolución de sus dependencias. Y ya no solo por tener que irte a un medio externo a traerte texturas, etc... si no porque tras esto hay que subir esas texturas a otra memoria externa como es la de la GPU. Por otro lado, y ahí es donde hablo de ortogonalidad, unity no descarga los recursos cuando no existe ningún enemigo de ese tipo en pantalla, tienes que hacerlo de forma manual y te aseguro que no es fácil por sus shared references.
Vaya, que hace las cosas cuando le da la gana y no siempre sigue una misma lógica. Esta claro que no me gustaría tampoco que descargara recursos por el mismo pero era para mostrar sus tejemanejes.
Un saludo.
IronArthur
12/01/2016, 10:16
A ver voy ha explicar lo del preload (que se llama asi en Unity5).
Todos los objetos que formen parte de una scene en unity5 se referencian en una tabla en el fichero scene(muy toca huevos para mi) en la que se referencia todos los objetos que se tienen que precargar en dicha escena. Si no estan ahi es porque por ejemplo se cargan dinamicamente desde el codigo Unity que no tiene forma de saber que tiene que precargarlos y tienes que cargarlo en memoria de la forma tradiciional.
Todas las dependencias de estos objetos/prefabs/loquesea estan en los resource.assets o sharedassets**.asset. Pero luego hay una carpeta sin compactar donde los ficheros se pueden dejar sin integrar en asset que es la de streamingassets, evidentemente hay que tratarlos de forma diferente en loading de tu pantalla etc...
Si teneis alguna duda mas de estas cosas igual cacharrear tanto los ficheros de unity me sirve para algo.
Y ya que estoy por si a alguien le interesa cotillear, el source de un prototipo de juego de supervivencia en plan basico. http://gamejolt.com/games/survival-prototope-alpha-source-code/84876
Salu2
Patada en los coj... ya mismo!!! :lol2:
Empieza por irte a unity5 que tiene cantidad de mejoras y abraza el lado oscuro xD
No podía, el proyecto formaba parte del TFM, y durante el Máster estábamos obligados a usar todos la misma versión (con decirte que aun uso la 4.6.2f en lugar de la 4.6.8 ¿o era .9 ya?).
De todas formas, comentan que Unity5 aun tiene muchísimos bugs, y ya bastante tengo con aprender los entresijos de Unity como para andar peleándome con errores del sistema.
Esto no soluciona el problema del que hablamos drumpi. Unity es "tan ortogonal" que no sigue ni su propio patrón. Es decir, primero de todo el problema no es ir creando los enemigos cuando salen (que podría ser un problema si tienes varios saliendo a la vez, no voy a meterme con pooling ni nada ahora) si no que cuando se crea el primer enemigo del tipo X sus dependencias se cargan. El coste de creación de la instancia de un enemigo que ya tiene todas sus dependencias cargadas es infinitamente menor que el de la resolución de sus dependencias. Y ya no solo por tener que irte a un medio externo a traerte texturas, etc... si no porque tras esto hay que subir esas texturas a otra memoria externa como es la de la GPU. Por otro lado, y ahí es donde hablo de ortogonalidad, unity no descarga los recursos cuando no existe ningún enemigo de ese tipo en pantalla, tienes que hacerlo de forma manual y te aseguro que no es fácil por sus shared references.
Vaya, que hace las cosas cuando le da la gana y no siempre sigue una misma lógica. Esta claro que no me gustaría tampoco que descargara recursos por el mismo pero era para mostrar sus tejemanejes.
Un saludo.
Ese es el precio que hay que pagar por facilitar el trabajo a los usuarios. Siempre he dicho que un sistema que te quite el control de algo va a dar problemas, y uno de los mayores quebraderos de cabeza de los programadores es la carga/descargas de recursos, y algo que los novatos o los no-programadores no saben manejar adecuadamente.
De todas formas, por eso digo que lo ideal es que cargue todo lo que se referencia en la escena, y luego se desactive para que consuma los mínimos recursos posibles... Aunque deberían existir (si no existen ya) una serie de funciones para "expertos" que permitan a los programadores decidir qué y cuando se cargan/descargan las cosas, pero no me he puesto a investigarlo.
Bueno, lo de cargar y descargar recursos es un problema habitual uses el sistema que uses. Si hay algún programador de JAVA en Android que haya desarrollado en nativo, sabrá de lo que hablo. Es una pelea constante.
Yo he desarrollado en nativo en muchos lenguajes y lo que pasa en unity no me ha pasado en ninguno. Y me refiero a no poder forzar la carga de todos los recursos de los que depende un objeto. Es de risa.
Hombre, Anarchy, yo he programado en C y en Fenix/BennuGD y siempre he sido el responsable de cargar y descargar los recursos que he ido necesitando.
Otra cosa es que te pongas con Java (y creo que C#), que tienen su "recolector de basura", que creo que es el peor invento que he visto en la escritura de código, porque encima ni se te ocurra invocarlo manualmente, porque te puedes cargar la "armonía" del sistema.
Entiendo que en un entorno como Unity te cargue todos los recursos de una escena, porque es para lo que es, para gente que quiere programar poco o nada, pero siempre he dicho que "todo sistema automático debe tener un sistema manual", en este caso, unas funciones de carga y descarga de recursos, y si no, mal vamos.
> "con Java (y creo que C#), que tienen su "recolector de basura", que creo que es el peor invento que he visto en la escritura de código"
Es una buena idea, pero no tanto para el desarrollo de videojuegos.
A menudo vemos quejas por culpa de las pausas en la ejecución, que si la GC no es determinista y sus caidas en el framerate, etc,etc... pero mucha gente ignora su mayor inconveniente:
un programa con GC requiere 2 o 3 veces más de memoria que uno sin él.
Esto hace 15 años no era un problema porque la RAM siempre ha sido muy barata, sin embargo en las CPUs actuales, para un buen rendimiento es crucial un buen uso de la caché.
A más memoria ocupe tu programa en memoria, más refrescos de la caché tendrá y más lento el programa irá.
A ver quién suelta la parida más gorda.
Sois todos unos noobs joer. Si enlazas unity con el sdk de la ps3 para dirigir los misiles, y usas el condensador de fluzo para linkar el proyecto todo va de pm y unity es la reostia. :lol2:
Yo creo que con untarle un poco de tocino ya gana en velocidad...
Enviado desde mi SM-N910F mediante Tapatalk
La app de facebook para Android está hecha en Unity.
> "con Java (y creo que C#), que tienen su "recolector de basura", que creo que es el peor invento que he visto en la escritura de código"
Es una buena idea, pero no tanto para el desarrollo de videojuegos.
A menudo vemos quejas por culpa de las pausas en la ejecución, que si la GC no es determinista y sus caidas en el framerate, etc,etc... pero mucha gente ignora su mayor inconveniente:
un programa con GC requiere 2 o 3 veces más de memoria que uno sin él.
Esto hace 15 años no era un problema porque la RAM siempre ha sido muy barata, sin embargo en las CPUs actuales, para un buen rendimiento es crucial un buen uso de la caché.
A más memoria ocupe tu programa en memoria, más refrescos de la caché tendrá y más lento el programa irá.
Calla, calla, que aun tengo escoceduras del sistema de reserva de memoria de las listas de Java. O de usar Hashmaps en el último proyecto, que sí, que son muy cómodas y facilitan el trasbase de todos los datos entre clases, pero en cuanto pienso en el algoritmo que hay que generar a bajo nivel para que eso funcione (y aun dividiendo por 3 el tiempo de cualquier código que yo pudiera generar)... [Ahhh]
Sois todos unos noobs joer. Si enlazas unity con el sdk de la ps3 para dirigir los misiles, y usas el condensador de fluzo para linkar el proyecto todo va de pm y unity es la reostia. :lol2:
¿No te has enterado? Los de Unity han contratado al equipo del proyecto SETI para crear una versión capaz de hacer funcionar un juego similar al GTA VI en un PentiumIII :awesome:
Volvinedo al tema del hilo, voy a empezar mi "proyecto" dsde 0, ¿cómo gestionais un proyecto desde el inicio? empezais directamente a crear la jugabilidad y luego vais creando niveles y menú o al contrario, primero el menú y luego vais a jugabilidad??
Yo normalmente empiezo creando algo jugable y luego voy creando los menús para gestionarlo todo, pero lo mismo no es la mejor forma de empezar un proyecto jejeje
Para empezar un proyecto nuevo yo recomiendo:
1) Estimar cuanto tiempo te gustaría que durara el desarrollo.
2) Multiplica el tiempo por 2
3) Concentrarse en una nueva mecánica importante del juego y reproducela lo más fiablemente posible sin gráficos ni nada. Solo la mecánica.
4) Si la mecánica mola: mantenla
5) Si la mecánica no mola: desestimala
--> Muestra lo que tengas a compañeros
6) Si disponemos de más tiempo para esta primera parte de prototipado y pensamos que con las mecánicas que poseemos aún no tenemos lo que nos gustaría en cuanto a jugabilidad, refinar la mecánica o volver 3
7) Cuando ya tenemos la jugabiliad donde queríamos empezar a realizar nuestro primer nivel e introducir algún enemigo si los hay.
--> Muestra lo que tengas a compañeros
8) Cuando nuestro primer nivel este creado y ya tengamos al 100% claro que nuestro juego mola mil empezar a producir niveles como si no hubiera un mañana según lo grande que queramos el jeugo.
-> Muestra lo que tengas a compañeros
9) Crear menus, compensar el juego, etc...
-> Muestra lo que tengas a compañeors
10) Empaquetar y a forrarnos :D
Y recuerda la máxima.... cuanto antes lo vea la gente antes empezaras a recibir feedback super mega valioso que te hará volver a iterar tus fases de creación 1 y 1000 veces. Por si no lo había dicho antes... muestra! muestra! muestra! muestra! tu juego lo antes posible y durante el proceso.
Un saludo.
Un saludo.
Desarrolla ese punto 11 y hacemos un libro y nos forramos. GOTO 11. xD
Anarchy si te refieres al de monstrar el trabajo, es que es una máxima.
Los desarrolladores somos super protectores con nuestro trabajo. Solo queremos enseñarlo cuando para nosotros esté perfecto y es una gran equivocación. Deja que lo vea hasta tu abuela. Nadie imagina la calidad del feedback que se recibe de gente ne´fita en tu campo. Yo, esto lo he aprendido a base de ostias como panes.
Un saludo.
Anarchy si te refieres al de monstrar el trabajo, es que es una máxima.
Los desarrolladores somos super protectores con nuestro trabajo. Solo queremos enseñarlo cuando para nosotros esté perfecto y es una gran equivocación. Deja que lo vea hasta tu abuela. Nadie imagina la calidad del feedback que se recibe de gente ne´fita en tu campo. Yo, esto lo he aprendido a base de ostias como panes.
Un saludo.
Por una vez NO estoy deacuerdo contigo, asi que te espero a la salida para partirnos la cara ehhhhh!!! xDD
Coñas aparte, a mi NO me gusta enseñar nada porque siempre recibo el mismo feedback de mier...
-oye q graficos mas feos
-no tiene sonidos
-¿esta caja de aqui que es? (tipico box que usas en vez del player para testear)
-el juego se ha colgado al apretar este boton
etc, etc
Es decir que en MI caso particular solo he encontrado gente que no sabe ver mas allá, y que su feedback cambia totalmente de ver el proyecto "terminado" a verlo en testing...
^MiSaTo^
18/01/2016, 13:19
Por una vez NO estoy deacuerdo contigo, asi que te espero a la salida para partirnos la cara ehhhhh!!! xDD
Coñas aparte, a mi NO me gusta enseñar nada porque siempre recibo el mismo feedback de mier...
-oye q graficos mas feos
-no tiene sonidos
-¿esta caja de aqui que es? (tipico box que usas en vez del player para testear)
-el juego se ha colgado al apretar este boton
etc, etc
Es decir que en MI caso particular solo he encontrado gente que no sabe ver mas allá, y que su feedback cambia totalmente de ver el proyecto "terminado" a verlo en testing...
Cada vez que cuentas algo de tu experiencia me da la impresión de que NO te mueves en los círculos adecuados. No se tío en reddit hay mucha getne mostrando sus mierdas a la que se le da feedback desde el principio. He estado en meetups aqui que lo mismo. Sin ir a sitios físicamente, hay muchos sitios de internet en donde promocionar tus cosas y recibir feedback. Precisamente yo siempre hablo de mis cosas (no de juegos ojo, de cuando he montado empresa o proyectos así más grandes) y siempre he recibido feedback desde muy temprano lo cual he valorado un montón.
No se si es porque tú te mueves por sitios que no son adecuados o no "procesas" bien el feedback. Es evidente que tu abuela no te va a decir: la mecánica de este juego no es tan clara como en X. Hay tb que entender lo que te cuentan como feedback sobre todo si son no programadores
El problema que yo tengo es que la gente veo que no sabe valorar el tipico juego con "cubitos" porque aun no tienes graficos, y su feedback solo es "que feo ¿no?", vamos que me importa una mier... tus mecanicas o el juego.
Y lo "frustrante" de esto es cuando eso te pasa en meetups con gente que esta en esta industria.... asi que probablemente sera que tengo la china y me tocan todos los tontos a mi xDDD
Por ejemplo sabotage es un juego normalito, cuando lo enseñe con unos graficos feotes y sin luces, etc, todos me dijeron "vaya mier.. pero oye que si quieres publicarlo adelante, pero no mola", esta misma "gente" prueba el juego ahora "terminado" y me dicen, "oye que bien te ha quedado, esto mola"... ahhh vale el juego que ayer era un asco ahora que tiene graficos finales ya mola.... xDDD
Lo que dices tu, sera q tengo mala suerte porque casi nadie se centra en el gameplay y me da algun feedback interesante que sea para considerar. Todo son chorradas visuales xD
^MiSaTo^
18/01/2016, 13:45
Pero aparte de tus círculos cercanos por qué no miras las distintas comunidades de internet que hay? En serio, me sorprende mucho lo que dices en gente más o menos seria/madura
Mas me sorprende a mi..... q trabajando de esto seas tan lerdo como para no saber imaginar el juego y centrarte en la mecanica/idea o lo que sea...
Para Sabotage si voy a ir poniendo cositas en reddit poco a poco, a ver si tengo tiempo para liquidar el proyecto e ir posteando cosas :) a ver que me encuentro por alli
Yo siempre digo que a los testers hay que "edudarlos". Tras contarles unas cuantas veces lo que quieres y decirles, sí, los gráficos son una mierda pero... ¿Te parece que el salto flota mucha?, ¿Te es difícil saltar allí?, ¿Piensas qeu hay otro juego que hace esto mejor? acaban diciendote lo que quieres oir. Muchas veces hay que sacarles las palabras de la boca pero vaya, prefiero mil veces que me digan los gráficos son una mierda que me digan "Cómo mola" y al final no saquemos nada :D. Yo siempre tengo en much más consideración a los que se quejan que a los que lo dan todo por bueno. Y eso, que tocan muchas veces las bolas demasiado pero hay que aguantar como un jabato y pensar que tú siempre no tienes la razón :).
Un saludo.
^MiSaTo^
18/01/2016, 17:45
Yo siempre digo que a los testers hay que "edudarlos". Tras contarles unas cuantas veces lo que quieres y decirles, sí, los gráficos son una mierda pero... ¿Te parece que el salto flota mucha?, ¿Te es difícil saltar allí?, ¿Piensas qeu hay otro juego que hace esto mejor? acaban diciendote lo que quieres oir. Muchas veces hay que sacarles las palabras de la boca pero vaya, prefiero mil veces que me digan los gráficos son una mierda que me digan "Cómo mola" y al final no saquemos nada :D. Yo siempre tengo en much más consideración a los que se quejan que a los que lo dan todo por bueno. Y eso, que tocan muchas veces las bolas demasiado pero hay que aguantar como un jabato y pensar que tú siempre no tienes la razón :).
Un saludo.
A eso me refería también a saber "recibir" el feedback. Hay tb que entender por qué se están quejando y lo que tú dices, preguntarles de cierta manera. Y sobre todo tener paciencia y no ir pensando que "vaya mierda" o "para esto no habria preguntado".
Tú tb tienes que hacer un poco tu parte para entenderlo bien.
Yo no tengo paciencia y suerte la mia que nunca pido feedback, mas que nada porque no hago juegos xDD
A mi si hago una pregunta como decis y no me contestan paso del tema, no tengo tiempo ni ganas de estar detras de alguien que no sabe responder a una pregunta sencilla como las vuestras:
- ¿que tal el salto, es bastante alto o salta muy poco?, no se tio los graficos no me molan, la animacion de caminar X, etc, etc
directamente desconecto mi cerebro cuando me dicen eso porque no me estan ayudando con lo que quiero y su feedback me es irrelevante porque aun no estoy en la fase de cambiar graficos, asi que ese feedback no me ayuda nada y esa persona me parece gilip0shas, asi tal cual xDDD
^MiSaTo^
18/01/2016, 19:02
Yo no tengo paciencia y suerte la mia que nunca pido feedback, mas que nada porque no hago juegos xDD
A mi si hago una pregunta como decis y no me contestan paso del tema, no tengo tiempo ni ganas de estar detras de alguien que no sabe responder a una pregunta sencilla como las vuestras:
- ¿que tal el salto, es bastante alto o salta muy poco?, no se tio los graficos no me molan, la animacion de caminar X, etc, etc
directamente desconecto mi cerebro cuando me dicen eso porque no me estan ayudando con lo que quiero y su feedback me es irrelevante porque aun no estoy en la fase de cambiar graficos, asi que ese feedback no me ayuda nada y esa persona me parece gilip0shas, asi tal cual xDDD
Pues ese es el problema entonces, el que no tengas paciencia. Esto no funciona así tío, lo mismo sí te quieren ayudar pero tu cerebro ya ha desconectado.
Y bueno la gente no es gilip0llas por darte un feedback que no te gusta. Ese tipo de pensamiento es bastante dañino a la larga para ti. Ahora me cuadran todos los rants de twitter xD
Las cosas no van a ser exactamente como tú quieras, a los usuarios/clientes hay que educarlos tb.
Lo que hay que hacer es intentar obviar las partes de "qué gráficos más feos" y todo ese rollo, porque ya sabes que a la gente le atraen unos buenos gráficos (candy Crush es prácticamente pr0n visual con tantos efectos :D).
Si te dicen que la cosa pinta bien, es que realmente pinta MUY bien, porque si alguien ajeno al mundo del desarrollo se divierte viendo botar a una cápsula, es que has dado en el clavo con la jugabilidad.
Pero también eso juega en tu contra: al añadir los gráficos finales y las animaciones, aunque el movimiento sea igual que antes, se APRECIA de forma diferente. Una mala animación puede hacerle perder fuerza al salto y da la impresión de que salta menos. El simple efecto de una nube de humo que se disipa al acabar con un enemigo, le dió mucha perosnalidad a cierto juego de plataformas que publiqué hace tiempo.
Por eso es importante tener a gente que sepa de qué va la cosa, y si no la tienes, guiarla hacia lo que quieres que se fije.
Y es importante tener feedback, incluso de tu propio equipo ¡y ya te digo que no es fácil conseguirlo! Es el tipo de cosas para la que necesitas a alguien encargado de ello... de pedir feedback del equipo, de que se cumplan los tiempos, de comprobar que se van creando los elementos necesarios para el juego... esa persona no tiene tiempo para aburrirse, no (ni para programar).
Pues ese es el problema entonces, el que no tengas paciencia. Esto no funciona así tío, lo mismo sí te quieren ayudar pero tu cerebro ya ha desconectado.
Y bueno la gente no es gilip0llas por darte un feedback que no te gusta. Ese tipo de pensamiento es bastante dañino a la larga para ti. Ahora me cuadran todos los rants de twitter xD
Las cosas no van a ser exactamente como tú quieras, a los usuarios/clientes hay que educarlos tb.
No es una cuestion de que su feedback no me guste o que las cosas no sean como quieres. Si hago preguntas sencillas y se van por los cerros de ubeda pues considero que o son gilip0llas o se lo hacen. ¿Que no lo son?, pues probablemente no lo sean, pero yo me quedo con esa sensacion sobre todo porque es gente de la industria. [Ahhh]
Si te pregunto si te gusta el programa de la tele y me dices que el presentador no va bien peinado pues considero que eres gilip0llas, mi pregunta ha sido clara, "el programa", no si el presentador va bien vestido o no... de eso si quieres debatimos luego y me encanta hablar con la gente y escuchar sus opiniones, pero ahora mismo mi pregunta ha sido clara.... y tu no la has respondido...
No es una cuestion de que su feedback no me guste o que las cosas no sean como quieres. Si hago preguntas sencillas y se van por los cerros de ubeda pues considero que o son gilip0llas o se lo hacen. ¿Que no lo son?, pues probablemente no lo sean, pero yo me quedo con esa sensacion sobre todo porque es gente de la industria. [Ahhh]
Si te pregunto si te gusta el programa de la tele y me dices que el presentador no va bien peinado pues considero que eres gilip0llas, mi pregunta ha sido clara, "el programa", no si el presentador va bien vestido o no... de eso si quieres debatimos luego y me encanta hablar con la gente y escuchar sus opiniones, pero ahora mismo mi pregunta ha sido clara.... y tu no la has respondido...
Ni que te hubiesen respondido "Pa k kieres saber eso jaja Saludos"
Tienes que tener en cuenta que, si no hablas con desarrolladores, las respuestas que te van a dar son las que ellos estiman oportunas, que son las partes visibles. Si hablas con gente del mundillo se fijarán en la parte técnica... con suerte. Si hablas con programadores lo mismo sí que obtienes las respuestas que esperas, pero ellos no son los jugadores a los que va dirigido.
Por eso necesitas mucha mano izquierda, saber dirigir el interés sutilmente a tu terreno, y filtrar lo que te dicen porque sólo el 10% de lo que te van a decir (siendo generosos) es lo que esperas oir.
En mi último proyecto, alabaron el acabado del juego los que lo probaron, pero eran colegas de mis compañeros, por lo que no me parecía nada objetivo, sabiendo que hay decenas de juegos similares al nuestro.
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions Inc. All rights reserved.