Jump to content
UnitySpain

FNP

Registrados
  • Content Count

    249
  • Joined

  • Last visited

  • Days Won

    6

FNP last won the day on December 27 2018

FNP had the most liked content!

Community Reputation

62 Excellent

About FNP

  • Rank
    Asiduo

Profile Information

  • Especialidad
    Artista

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Función no hay, pero si no se soluciona con los materiales físicos siempre puedes intentar hacer un truco: lanza un raycast antes de que el cuadrado pegue a la bola, quítales las físicas y cuando colisiones, como el raycast te da información de donde, con que fuerza y demás, usa eso para aplicar un AddForce en la dirección indicada. Se me está ocurriendo sobre la marcha, pero igual te sirve. Yo he hice un pimball hace algún tiempo y aún recuerdo lo que sufrí con las físicas, no es de lo mejot que tiene Unity y cuidado con las escala que con cosas muy grandes se llevan fatal
  2. La idea es muy buena, promete ser muy movido, lo de que te encuentres los iconos de transformación y mogollón de figuras distintas detrás y te toque elegir rápidamente en cual convertirte sin meterte en una encerrona promete. Cuando decidas meter mas calidad gráfica siempre puedes hacer un arte basado en la geometría, no es muy difícil aplicar animaciones, incluso podrías modelarlas en 3D mediante primitivas y animarlas con rotaciones y generar los fotogramas, le daría mucha vistosidad con muy poco esfuerzo.
  3. Creo que lo he entendido, pero ¿es mas un simón o un guitar hero? si es como un simón, te vienen bien las soluciones descritas por Juanma, si es de la otra forma, repetir la seguencia mientras se reproduce, entonces tienes que controlar el tiempo y cambiar el botón cuando cambie la secuencia, por ejemplo indicando en una variable cual es el botón que toca ser pulsado cuando pulses uno este comprueba la variable y si es el está bien y si no da un fallo. En realidad el problema es el mismo, solo que en este caso no controlas la secuencia completa sino un botón determinado en un espacio de tiempo.
  4. Mola mucho, es un pique constante. A mi ve va perfecto. Ya he dejado la puntuación y el comentario adecuado. A ver si se descarga mucho.
  5. ¿Como vas a disparar? que te estoy viendo venir. Ni se te ocurra apuntar el proyectil a la dirección y hacer un AddForce o algo parecido, que os conozco. Mira el Raycast.
  6. Mi consejo es que te olvides de Unity, NO ES EL MOTOR PARA ESO. Está a años luz de poder hacer cosas decentes sin morir en el intento y el Adventure Creator es un asset no pensado para programadores que lo poco que te da por un lado, te lo quita por otro, haciendo las cosas mucho mas engorrosas. Para mí, el mejor motor, ha sido siempre y lo será Wintermute, pero me temo que ya está en el limbo de los justos, así que creo que lo mejor que encontrarás será Visionaire. Al César lo que es del César y a Dios lo que es de Dios y con Unity, por poder puedes hacer de todo, pero el curro y la complicación en inmensa, además de innecesaria.
  7. La API de Vuforia no tiene contemplada las capturas del stream de video. Tambien tienes que tener en cuenta que la versión de pago es cara, hay otras soluciones de RA, lo digo porque la versión que no es de pago, te planta la marca de agua y si guardas una captura de pantalla, la marca de agua se va a quedar y pagar una licencia básica, que anda por los 500 € solo para usar la cámara, pues no se si es rentable, pero desde luego es caro. Igual con el Unity AR Foundation que te soporta por debajo ARCore y ARKit haces lo mismo, aunque no vale para dispositivos mas antiguos. Mira el estado de ARToolkit, hace mas de un año que no lo uso, era gratuito y funcionaba muy bien. Y mira tambien Wikitude Te pongo soluciones AR porque parece que la cámara AR es lo que te soluciona el problema, pero igualmente, estas aplicaciones te van a cargar mucho la app, tanto en peso, como en rendimiento, esto funciona con una tecnología llamada VIO, (Odometría Visual con Inercia), que analiza la imagen que graba la cámara, cuanto mas fotogramas mejor, captura puntos de referencia, esta nube de puntos, la asocia a los datos del giroscopio y en su caso, del GPS y todo esto lo compara con lo mismo en el siguiente fotograma y así posiciona los objetos en su sitio y te los muestren distinta posición según te mueves. Por eso, cuanto mas potente es la máquina, mejor es el sensor CMOS de la cámara y mejores son las condiciones de luz, mejor funciona el sistema. Por lo que dices no vas a usar nada de esto, pero la app lo va a hacer igualmente en el momento que pones una camara AR y visualizas un objeto con esa cámara, así que imagina el consumo y la bajada de rendimiento que va a tener esa app, aunque también es cierto que no es lo mismo intentar escanear un marcador que mantener objetos 3D en pantalla (aunque esto ultimo lo pongo pensando exclusivamente en Vuforia). Tenlo en cuenta si además tiene que hacer otras cosas, porque puede empezar a ir a paso de tortuga antes de lo que imaginas.
  8. Esta claro, los libros del sr, Ceballos suelen incorporar ejemplos muy practicos, recuerdo uno, no sé cuál en el que se desarrollaba una pequeña aplicación para Windows con la que gestionar una biblioteca. Ahora, un libro de metodología, algorítmica, diagramación, lo que te va a incluir como ejemplo es ordenar una tabla por sustitución, o una matriz en burbuja, o acceder rápidamente a un elemento n-dimensional, que es de lo que trata, aunque puedas tener ejemplos más entendibles en la parte que trate de descomposición funcional y cosas así, Son buenos libros con un profesor al lado, pero yo nunca estudié informática y me los comí solo y te puedo asegurar que no te mueres, también he tenido buenos textos que los ha jodido un mal profesor.
  9. Lo primero es coger las bases de programación, que las puedes coger a la vez, pero que al menos te tiene que preocupar de aprenderlas a la vez que un lenguaje. Siendo asi, yo empezaría por un lenguaje no orientado a objetos y luego ya pasaría a C#. Yo para estas cosas soy muy de libro, por el tema de que cuando quieres consultar igual el tutorial aquel tan bueno ya no está y un libro bueno con la referencia del lenguaje (el que sea) creo que siempre tendría que estar en la biblioteca (aunque sea electrónica). Para aprender la base de la programación te recomiendo "Metodología de la programación" de Eduardo Alcalde Lancharro, profesor de la Universidad de Comillas, es un libro antiguo, ya está descatalogado, pero es facil de encontrar porque hace unos meses compre un ejemplar para regalárselo a un amigo y lo encontré en varios sitios, no es dificil y es un buen libro. Hay un profesor de Universidad de Alcalá, Francisco Javier Ceballos, que en este tema es una máquina, tiene como 4 ó 5 libros de varios niveles, desde uno de iniciación muy básico de 15 eurillos, hasta una "biblia" de 60, para todos los gustos y a mi parecer muy didácticos. Que conste, que el que este hombre escriba para la misma editorial que yo (RA-MA) no tiene nada que ver con mi recomendación, yo le sigo desde hace años y el primer libro que compré suyo fue de Visual Basic en 1994.
  10. La verdad es que dándole más y más vueltas solo es necesario avisar al Player de los enemigos cercanos en los niveles anterior y posterior, y realmente importa poco los que estén en tu mismo nivel siempre que se haga un buen diseño para esquivarlos. En este punto, tu idea de hacerlos semitransparentes o incluso marcar un aviso en la puerta lo simplifica todo, no solamente la interfaz, sino la gestión del mapa porque como encajan los distintos planos, me vale poner un transform como si fuesen los enemigos de los planos anteriores y posteriores y hacer un simple Distance() Habria que ver cómo tratar las habitaciones sin salida y los teletransportes, pero eso puede ser parte de la dificultad, al fin y al cabo el Player puede defenderse y si entra a una habitación o zona sin salida y le siguen pues que pelee y lo de los teletransportes se puede integrar como parte de la lógica que mientras el Player está reapareciendo no sea detestable o que el enemigo no se acerque a X distancia del teletransportador. Habrá que verlo, ni siquiera lo tengo claro, por la propia temática, en un inicio eran puertas mágicas que el Player podía abrir un determinado número de veces, pero al final veremos.
  11. Creo que lo mejor será la tercera opción, como en realidad es un único escenario que estará diseñado de tal forma que cuando pases de un plano a otro, en el lugar que ocupen las puertas no haya nada que pueda matar al Player, no sería necesario hacer ningún reseteo y como no será pantalla a pantalla como los juegos que me has puesto de ejemplo, sino algo continuo, tipo Gost'n Goblins, Little Big Planet o Donkey Kong Country, tanto en longitud como en altura, tampoco tengo que considerar nada especial en la IA de los enemigos si mantengo al Player en el centro de la pantalla y adecuo los tamaños lo suficiente como para tener espacio para verlos venir. Lógicamente hay una idea de IA, no porque haya pensado en el algoritmo, sino porque es un pathfinding típico por celdas en una matriz tridimensional, parece de cajón que será así, con lo que se debería adaptar según la proximidad del player para que el enemigo se mantenga en una celda sin moverse cuando proceda en vez de continuar con el algoritmo de búsqueda de camino, que casi seguro será un A* Hay que tener en cuenta que la UI tiene muchas cosas, hay un indicador de la tarea a realizar que es una barra de progreso, el objetivo de cada nivel es que el Player llegue a un punto y se mantenga en un sitio durante un periodo de tiempo concreto, realizando una tarea que será automática, con ponerse en el sitio ya la realiza solo, y mientras se le pedirán objetos que tiene que buscar por el mapa, por lo que tiene que interrumpir la tarea para ir a buscarlos, así que en la UI hay que poner, las vidas y/o energía, el % de la tarea, ¿puntuacion?, objetos recogidos y el que se tiene que recoger, munición, cada vez salen mas cosas y si vamos a dispositivos moviles la parte de abajo no se puede usar por el tema de controles, por lo que el espacio se reduce, además de que me gustan los UI muy limpios, así que quitar el mapa de enmedio cada vez me parece mejor solución.
  12. Me has hecho recordar los juegos de 8 bits de los 80, cuando pasabas de una pantalla a otra saltando o cayendo y te mataban y al iniciar de nuevo volvías a caer y te volvían a matar y así hasta que todas las vidas se acababan delante de tus narices por un fallo, perdiendo todo el avance. Esto además pasaba en una época en la que si no hacías un juego más difícil que el que había hecho el vecino se dudaba seriamente de tu hombría y claro, esto te hacía un hombre, pero reconoce que con muchos traumas, al menos en mi caso. Ahora soy una persona con tendencias psicópatas, trastornos afectivos y muy poco sociable gracias a aquellos programadores . Eso me hizo abandonar muuuchos juegos, por eso adoro tanto los checkpoints. Sobre lo que tu planteas la primera opción es perfectamente viable, se me había ocurrido, pero no me gusta,, porque la idea es que sea un juego en el que no puedas parar demasiado, con mucho ritmo y que los enemigos que te persiguen no te den mucho respiro, cada vez menos, de hecho y me parece fea. La segunda no la veo, si tengo un mapa como en el de la segunda o la tercera imagen no lo necesito porque se donde está el player y los enemigos, y podría representar una parte del mapa y mostrar la posición con marcadores de distinto color sin necesidad de cambiar tamaños, incluso sería facil marcar distintos tipos de enemigos, spawners, teletransportadores, pero no es para dar pistas, sino para evitar encontronazos injustos. Nadie dice que haya solo tres planos, ni que haya solo dos pisos, imagina que entro en un edificio de 10 plantas que lo cruzan dos pasillos y que hay habitaciones a ambos lados y en el centro, ahi ya tengo 5 planos (habitaciones, pasillo, habitaciones, pasillo, habitaciones) y 10 alturas, ese mapa puede ser muy grande. Quizá se pueda sacar una perspectiva cómoda para visualizar de forma clara la ubicación actual del player con un rango cómodo como para ver los peligros inmediatos y que quede visualmente claro y a la vez bonito, pero no se como encajar esas dos cosas. La tercera opción no es mala, me afectaría a la hora de diseñar la IA de los enemigos, tendría que prever o detectar la cercanía del player a una puerta y que el enemigo no la cruzase hasta que el player no se hubiese alejado, lo mismo con las subidas de nivel aunque si tengo un scroll esto no es necesario porque al desplazar la pantalla lo vería venir. habría que considerar las encerronas como el ejemplo de la habitación sin salida del plano C y en este caso, casi ni consideraría ya poner el mapa en la esquina, porque me aseguro que nunca se va a dar el caso, como la IA aún no la tengo definida, lo puedo considerar como parte de la misma, así no haría falta reacomodar enemigos ni nada, simplemente los enemigos evitarían que el player tropezase con ellos y el jugador ni se daría cuenta, solo cuando entrase a otro plano, tendría algún enemigo muy cerca, pero con margen suficiente para huir, atacar o lo que sea. Lo del prototipo me parece bien, pero el prototipo necesita tanto la IA, como la gestión del mapa programada y va a ser complicada, asi que no es cosas de tirar, los cambios deberían ser menores, así que tendría que ir a prototipo con la idea clara. De todas formas, tras esta última pensada, casi que me iría a por la opción 3 ¿Cómo lo veis?
  13. El de la switch es este, hay 200 videos, pero casi todos hablan de los mismos:
  14. A ver si soy capaz de expresarme de una forma mas o menos clara. Resulta que estoy diseñando un juego, este juego tiene una mezcla de estilos, por una parte es un plataformas clásico, con sus distintos niveles de altura en cada escena con sus enemigos, sus objetos de puntos y sus bonus fijos, pero por otro tiene también escenario en profundidad, es decir, no solo puedo subir al piso de arriba o bajar al de abajo, sino que puedo entrar por una puerta o abertura e ir detrás del escenario o delante del mismo y además, posiblemente haya transportadores de un sitio a otro del mapa y una cosa importante es que habrá spawners de enemigos para que cuando se maten la cantidad se mantenga constante. Además y aquí está la raíz del problema, el juego utiliza también un estilo de persecución de enemigos mas o menos inteligentes al Player, como si fuese el Pacman que además le persiguen entrando y saliendo por las puertas. Esto pues bueno, tiene mas o menos trabajo de pensar y de montar la gestión del mapa y la IA de los enemigos, pero el problema que tengo es en la UI, y me explico, pero primero voy a poner un mapa de ejemplo, para que quede claro (o lo más claro posible) lo que he explicado. Imaginaos que el mapa tiene tres niveles de profundidad, algo asi: Esto seria algo asi como si el personaje fuese por el escenario A y por una puerta pasase al B y de ahi al C y asi, esto lo hacen muchos juegos, recuerdo algunos antiguos como el Gift from the gods o el Tir Na Nog, pero siempre en escenarios de un solo piso. Yo lo quiero hacer con varios, como en este ejemplo: Si estudiamos el ejemplo, si el jugador está en el escenario A puede subir por las escaleras e ir por la pasarela 1 o ir por el camino 3 y entonces pasaría al escenario B, si ha ido por la pasarela 1 podría entrar por la puerta 2 y vlver al escenario A o pillar el teletransportador 6 e ir al escenario C y asi, con esto lo que tenemos son dos pisos que abarcan tres escenarios: Que tridimensionalmente se verían así: Bueno, espero haberme explicado bien con el mapa, ahora viene lo que no se me ocurre como hacer y es un tema de interfaz. Como he comentado antes por una parte cada escenario A, B o C tiene sus enemigos y objetos como un plataformas cualquiera, pero hay otra serie de enemigos que persiguen al Player a traves del nivel (los tres escenarios entrando y saliendo de ellos y moviendose por los pisos. Todavía no he entrado en programación ni de lejos, estoy en diseño del juego, ya veremos como hago la gestión del mapa y la IA de los enemigos, pero el principal problema es que necesito mostrar un mapa en pequeño para que el jugador vea al menos, la posición de los enemigos cercanos. Esto sería muy fácil si fuese un nivel plano tipo PACMAN, es decir, si no tuviese pisos ya que se crea una estructura equivalente a los escenarios, similar a la de la ultima imagen y se coloca en una esquina de la pantalla con una cámara independiente y sobre esa estructura se posiciona el jugador y los enemigos y todo lo que quieras e incluso puedes hacer cosas como ir activando las habitaciones abiertas y cosas de esas. El problema son los pisos, el Player puede subir unas escaleras y que cuando aparezca se encuentre con que un enemigo que le está persiguiendo las vaya a bajar y se dé con el de morros sin ninguna posibilidad, o que coja un teletransporte y se encuentre en una encerrona o que entre en una habitación sin salida como en el escenario C piso 0 y entre un enemigo detrás de el y no pueda salir porque, por ejemplo, no tenga munición y no pueda usar el arma. En estos casos el Player se quedaría jodido y sin ninguna posibilidad y creo que afectaría mucho a la jugabilidad, porque además pasará seguro ya que una de las gracias del juego es que según subes de nivel, la rapidez y la IA de los enemigos será mayor por eso creo que necesitaría ver de alguna forma los peligros que tiene cerca pero la verdad es que no se me ocurre como hacerlo. A ver si alguien tiene alguna brillante idea. El juego es todo en 2D, que es otro "problema" porque se podría hacer algo en 3D como la imagen anterior, pero aparte de que si es muy enrevesado no creo que se viese bien, creo que iba a quedar fatal. Gracias por leeros el tocho, Fernando.
  15. Tiene buena pinta, la mejora en rendimiento es importante y la definición de los mapas de normales parece muy buena. Habrá que probarlo en la realidad a ver cómo es. Dos cosas que nunca me han parecido buenas han sido los pinceles, que dicen que los han mejorado y el billboard que parece que no lo han tocado de momento. Veremos cómo acaba porque se avecinan cambios.
×
×
  • Create New...