Jump to content
UnitySpain

zorranco

Fosiles
  • Content Count

    15
  • Joined

  • Last visited

Community Reputation

1 Neutral

About zorranco

  • Rank
    Iniciado

Recent Profile Visitors

439 profile views
  1. Bueno hombre, pues gracias por los ánimos. Estáis haciendo una serie de suposiciones sin saber el trasfondo, las motivaciones y objetivos que tengo en mente. Estoy asociado con un programador que ahora mismo no puede dedicarle tiempo pero en unos meses podrá, yo simplemente allano el terreno todo lo que puedo con playmaker para que él tenga que hacer lo mínimo posible y dedicarse sólo a lo importante. Perseverancia, experiencia...que me vas a contar que llevo 2 años dedicándome en exclusiva a unity de lunes a domingo...
  2. Hasta dentro de 2 meses que no salga el asset de playmaker para Unity networking no podré empezar con el LAN
  3. La cosa va tomando forma...guerra en la oficina xD. A ver como hago para meter los espejos para que reboten los laser...podrían ser algunas de las ventanas, pero no sé si poner también paredes en la parte de abajo (quizá con su transparencia). Si abajo no hay paredes sólo se podria rebotar en la parte de arriba y la jugabilidad quedaría algo coja. Como dije algunas armas serán psicodélicas, como un bombardeo a cargo de estas simpáticas señoritas Esto es como el club de la menopausia: la única regla es que no hay reglas.
  4. ...y si no, que sepas que a un rigidbody le puedes añadir contraints a uno o más ejes!
  5. Pathfinding en tiempo de ejecución no existe, hay que hacer un bake navmesh sí o sí en authoring time. Si tu mapeado se va generando en runtime no podrás usarlo. A no ser que uses herramientas de terceros...
  6. Puedes poner un punto de anclaje donde sepas que el objeto cogido queda "bien", emparentas el objeto y haces un reset de su transform. El punto de pivote del objeto cogido se moverá al punto de anclaje. Método simple para coger objetos (digo simple porque luego lo puedes complicar todo lo que quieras si hay animaciones o los objetos a coger son de tamaño distinto etc).
  7. Lanzar animaciones desde código si el objeto a animar es muy simple puede valer, pero para casos más complejos, si por ejemplo necesitas que siempre haya un estado activo o que las animaciones retornen a idle con x condición lo que tienes que hacer es usar mecanim.
  8. A falta de una idea mejor, de momento sigo con el tema. Quizá cuando pregunté al principio parece que ya pensara en monetizarlo, pero no, es el primer proyecto serio y es más un ejercicio de programación que otra cosa...veremos hasta donde llega. La perspectiva finalmente será isométrica, coberturas que no tapan al jugador (así no se requieren transparencias). El control, doble stick (he comprobado que hay varios juegos con este esquema). Programado subfusil, RPG y recortada....barriles que explotan con daño AoE y hacen volar a los jugadores. Animaciones, muerte del jugador Campo de fuerza, ultimo recurso para devolver un cohete o similar en caso de muerte inminente También se puede esquivar pero al igual que el campo de fuerza sólo una vez por ronda (teniendo en cuenta que una ronda difícilmente pasará de 1 min de duración). También cristales (se ven en azul) que ofrecerán cobertura la primera vez, luego una vez rotos ya no. El multiplayer he estado unas semanas mirando photon...y aunque funciona bien al ser un arcade rápido con cambios bruscos de dirección, habría que compensar el lag y hacer movimiento autorizativo...total que como no tengo la capacidad de programación suficiente para ello, y como mi socio programador ahora por ahora no puede ponerse con el tema, seguramente lo haré simplemente con LAN. A ver hasta donde llega playmaker...intento mantener todos los scripts agrupados en plantillas para centralizar las cosas, todo ordenadísimo, pero a medida que vas añadiendo funcionalidades cada vez se hace más caótico seguir el flujo de ejecución xD. Lo siguiente, rifles laser que rebotarán en espejos...un caos xD
  9. Wenas, refloto el hilo que aunque es antiguo, sigue siendo válido. Me gustaría saber así a grosso modo, que estrategia se podría seguir para compensar el lag de un juego tipo Duck Game, arcade rápido con cambios bruscos de orientación etc... Todo el movimiento es muy bonito y suave con su lerpeado y animaciones hasta que corres 2 instancias en red una al lado de la otra y ves como las acciones se ven con un ligero lag (como es obvio, por otro lado)...a partir de aquí los propios devs de Photon ya te dicen en su foro que para arcades rápidos su opción no es la mejor (o al menos, no cuenta con herramientas de serie para corregirlo, ni tampoco tutoriales). Lo que sí he visto es que Photon Bolt sí trae algunas herramientas de movimiento autorizativo con predicción en el cliente y compensación del lag, aunque no sé como de buenas son. Algunos de los métodos que he leído son introducción de lag en local para compensar el lag en red (no me acaba de convencer pero tampoco hay muchas opciones) y movimiento autorizativo (que entiendo podría correr en el jugador "master", vamos no hace falta un servidor dedicado para ello, ¿no?) enviando los clientes su posición, devolviendo el master su ok y actualizando de nuevo con la posición los clientes (de manera que el master siempre tenga el estado actualizado de todos los objetos, a la vez que todos los clientes ven el mismo estado). A priori el prototipado lo estaba haciendo en single player con pooling, spawneando todos los proyectiles con rigidbodies...luego más tarde he visto que no hay ninguna solución de pooling en red, por lo que para el multi quizá habría que abandonar esa idea de instance/destroy y rehacer los proyectiles todos con raycast. Pues eso, perdón por el tochano y bienvenidos sean los consejos.
  10. Gracias pioj, muy informativo. Algunas de las premisas ya las tenía en mente, por ejemplo: que sea rápido, que se distinga por humor/gore etc, que mezcle géneros (a falta de originalidad pura)... Otros, son factores que no había tenido en cuenta. De nuevo gracias por las orientaciones, me son de gran ayuda. Un saludo!
  11. Ante todo gracias por el comentario.... Lo que dices del doble stick me da que pensar y creo que tienes razón...me viene a la cabeza por ejemplo el Lara Croft and the temple of light, que se controla de este mismo modo, pero claro, tampoco es un shooter frenético... Yo juego a todo con teclado y ratón, todo...y esto es algo que quizá he pasado por alto. Como comentas con doble stick el control sería algo difícil, pero no me preocupa tanto eso si no que la posición de los dedos no es la óptima, especialmente de la mano izquierda para pulsar el LT y LB, y cansa al poco de jugar (lo he estado probando ahora). Ya sabía yo que tenía que preguntarlo, varias mentes piensan más que una xD PD: siento si esta no es la sección correcta, que lo mueva el admin si es necesario.
  12. Wenas, hace ya un año y medio que programo con playmaker. Dado que el modelador con el que trabajaría es más de 3D que de sprites, le estoy dando vueltas a la cabeza al siguiente proyecto: Sería una especie de Duck Game (link abajo), para 4 players en local, con armas convencionales y otras que sean de paranoia, pero en vez de 2D con sprites sería en 3D con una perspectiva tipo top-down tal que así: Para aprovechar al máximo el espacio de la pantalla, he programado una cámara inteligente, que sigue la acción por la pantalla, y cuando los 4 players se apelotonen en un punto, hace zoom automático, una maravilla xD. Los aspectos que me dan que pensar son básicamente 2: -La cámara, al ser top-down, tendrá que hacer transparentes las coberturas (muros, paredes, etc) para que se vea el jugador detrás. Eso en principio es sencillo de hacer, pero algo me dice que de cara a la jugabilidad no quedará del todo bien 4 jugadores detrás de sendas paredes transparentes...no sé...La idea es que las coberturas sean lo más bajas posibles para que ofrezcan el parapeto justo pero no tan altas como para que entorpezcan la visión. Cuando la entorpezcan, pos transparencia al canto...La cámara está rotada 55º, o sea que es una perspectiva bastante vertical, que también ayuda...no debería haber problema pero hay una vocecilla que me dice que hay algo ahí raro xD... -El quid de la cuestión: el control con pad sería, stick izquierdo desplazamiento y stick derecho rotación del PJ, el problema es que los niveles deberán ser principalmente PLANOS, ya que 2 PJs a diferentes alturas no pueden dispararse entre sí. Por tanto no hay escaleras ni rampas ni pasarelas elevadas etc. La idea es hacer los niveles lo más dinámicos posible, con compuertas que se abren y cierran, cristales que se rompan, power ups a recoger, bidones explosivos y otros elementos que hagan daño al jugador (podrán empujarse entre sí) pero todo es para despistar del verdadero asunto, y es que el el nivel es completamente plano xD. La duda que tengo es si el juego acabaría siendo demasiado obvio por ser principalmente los niveles planos. De paso aprovecho para preguntar si conocéis algún juego con perspectiva parecida y que sea de ésta temática, para ver como solucionan los diferentes aspectos. Un saludo!
  13. En el animator puedes poner varias condiciones para que se ejecute una animación, y tienen que satisfacerse todas. Así por ejemplo, para que no camine en el aire, puedes poner como condiciones que se pulse la tecla correspondiente y que además esté en isGrounded.
  14. Wenas, el esquema de control es el que véis en el video de abajo. Como véis el robot simplemente se orienta hacia el puntero del ratón, pero esta rotación es independiente del movimiento. Ahora quiero substituir el robot por una animación bipedestrada , que necesito que muestre la animación de andar hacia adelante o hacia atrás dependiendo de la orientación y el movimiento. Vamos, que si el cursor está a la derecha y pulsamos "D", camine hacia adelante pero si el cursor está a la izquierda y pulsamos la misma tecla, entonces la animación que ejecutará será la de caminar hacia atrás. Programo con playmaker, o sea que con el pseudocódigo es suficiente...yo había pensado en calcular el ángulo entre el vector de la rotación en world space del personaje, y el vector de movimiento. Si es 0º (no exactamente, si no dentro de un rango) caminará hacia adelante...si es 90 o -90 hará un strafe, y si es 180 será hacia atrás...(creo que Vector.Angle sólo devuelve valores entre 0 y 180 positivos o negativos). Me hago un lío con los vectores y la madre que los parió xD, no sé qué manera es más facil de calcularlo, si quaterniones o angulos de euler UU' En fin, de programación poco, pero cuando entramos en temas de geometría, menos xD Pero no se porqué, creo que algo se me escapa y que seguramente haya alguna manera más fácil de hacerlo...¿tenéis alguna idea?
×
×
  • Create New...