Espera, ¿estas detectando al objetivo usando un raycast o simplemente mueves el proyectil con un collider?, porque por lo que cuentas tiene toda la pinta de que va tan rápido que atraviesa el objetivo sin llegar a colisionar.

Lo que yo haría seria crear un gameobject padre donde están todos los colliders y redimensionarlo con un script en función de la escala final de la pantalla en tiempo de ejecución.


No obstante, si lo he entendido bien yo personalmente lo haría de otra forma:


Crearía capas independientes en función de las piezas del dibujo. Puedes crearlas a mano o puedes crear un algoritmo que genere esas capas de forma procedural a raiz de una imagen en blanco y negro. Sea como sea, al crear estas capas independientes tienes control de ellas a través de EventSystem. Si te fijas bien, cuando creas un elemento de interfaz, se crea un objeto llamado EventSystem que tiene un script con este mismo nombre. Esta clase, EventSystem, se encarga de convertir los elementos de un cambas en objetos interactivos. Ademas esta clase te provee información sobre el evento en cuestión. Creo que con eso tienes información de sobra para lo que quieres hacer. 


Investigarlo (porque aun no he entendido del todo que quieres hacer) y si te es útil pues adelante. 


Espero que te haya sido de ayuda, mucha suerte con lo tuyo.


 

Antes de responder a tu duda, ¿me podrías decir para que estas usando el collider en un canvas?.

Cita de: iRobb date=1472152219Definamos dos tipos de personas por hambre de conocimiento. Una se rige por los resultados sin autocrítica (1) y otra se rige por la autoexigencia (2). Acordemos que la mejora en la calidad de un producto está directamente vinculada al conocimiento de sus participantes, aunque haya más variables, de cara a la reflexión no son pertinentes.
   
   
      Las valoraciones sobrevaloradas harán creer al primer tipo de persona que su nivel está por encima de la media y se relajará. En el caso del segundo tipo de persona continuará esforzándose debido a su persistencia ya obtenga un 1 o un 5.
   
   
      Por tanto, si eres una persona del tipo 1, buscas la aprobación de la gente de cara a tu ego y tu constancia es más bien escasa, no se debería sobrevalorar la puntuación. Si es del segundo tipo, le servirá aunque posiblemente se dará cuenta de que lo han sobrevalorado por los motivos que fueren.
   
   
      Conclusión: Sobrevalorar es correcto cuando se está en una etapa temprana de la vida siempre y cuando esa valoración provenga de alguien cercano. Cualquier otra te hará entrar en el autoengaño. Cuántas veces hemos oído a aquel que, a pesar de las críticas ha continuado esforzándose (tipo 2) y al final ha conseguido su meta. El resto del tipo 1 habrán desaparecido sin pena ni gloria. El objetivo sería transformarse, si es posible, del tipo 1 al tipo 2 con el tiempo.
   
   
       
   

Pues ale, acabó el debate


Preferiblemente creo que todo desarrollador debería tener esa actitud de buscar una crítica honesta por parte del usuario. Los ánimos los tienes que recibir en otro momento y con otro formato. Cuando necesitas que tu producto sea juzgado con otro punto de vista diferente al tuyo flaco favor te hace el que puntúa otra cosa que no sea su valoración del juego.
 
Otra cosa diferente es que tengas la necesidad de que tu producto tenga una buena valoración para que el algoritmo de búsqueda de la store te tenga en cuenta como primera opción, además de que genere en los posibles usuarios cierta expectativa. Pero eso obedece mas a movimientos de marketing que a que tipo de desarrollador seas. Independientemente de qué busques de una crítica, necesitas que tu producto tenga una buena sensación inicial.

Bueno, tienes los datos en la clase Bounds. Independientemente de cada tipo de collider, todos los tipos de collider2D descienden de la clase collider2D y esta contiene una variable de tipo Bounds. Esta variable almacena datos acerca del tamaño y posición del collider.
 
Te muestro un ejemplo en C# para obtener las esquinas de un BoxCollider2D:

 
 

Collider2D collider = gameObject.GetComponent<Collider2D>();
Vector3 vAux = Quaternion.Euler(,,90) * collider.bounds.extents;
Vector3 corner1 = collider.bounds.max;
Vector3 corner2 = collider.bounds.min;
Vector3 corner3 = collider.bounds.center + vAux;
Vector3 corner4 = collider.bounds.center - vAux;

 


PD: no recuerdo bien si Bounds.center te da la posición global o relativa al transform. Si es lo segundo solo tendrias que sumar el vector transform.position a cada punto.

¿Te refieres a conseguir su posición en el espacio?

Cita de: Braltor date=1471902599ya pude probarlo... tiene un nivel de dificultad un poco alto, tendrias que balancearlo mejor en los primeros niveles para q vaya progresando y uno no se desanime pronto, talvez rellenar con unos niveles faciles entre cada 1 de los q ya tienes... graficos sencillos y agradables aunque un poco monocromatico y aburrido, podrias tener una paleta de colores suaves e irla variando entre niveles cambiando el material... la musica esta de acuerdo con el tema del juego
   
   
      tienes +5 estrellas, comment y share!
   
   
      otra cosa mas: deberias poner un contador de movimientos y un "mejor marcador" x nivel para animarse a mejorar
   

Gracias por el +5 y por compartirlo, ayuda mucho .


Respecto a la dificultad es posible que la curva pueda ser demasiado... exponencial. No descarto hacer en un futuro precisamente lo que has comentado, añadir más niveles para escalar de forma mas suave la dificultad. Pero no es nada fácil diseñarlos, no me gustaría simplemente añadir un nivel solo para que el jugador termine moviendo las piezas hasta que terminen encajando. Si has avanzado lo suficiente verás que llega un momento en el que al jugador se le exige algo más que mover tontamente piezas sin saber que estás haciendo, y ahí reside el atractivo del juego realmente. Los primeros niveles son una presentación de las mecánicas mas básicas del juego, el movimiento de las piezas.


Respecto al tema visual, la decisión de usar ese estilo y esa paleta fija es, primero, porque no se me da bien el diseño gráfico, no sería capaz de crear texturas atractivas visualmente, y segundo, porque a pesar de su sencillez encaja perfectamente con su función informativa. Cada color, cada forma, cada sonido son indicaciones, pistas, información de como funcionan las cosas. Inicialmente yo no te explico nada del juego, ni siquiera te cuento que hay que hacer en cada nivel, pero intuitivamente te das cuenta que tal vez ocurra algo si mueves la ficha de forma que encajen las muescas del mismo color. No obstante si podría hacer algo respecto con el fondo, aunque en un principio estaba en ese tono para no tener una sensación de demasiado brillo y asi ahorrar batería, pero probaré tu idea en futuras versiones.


Sip, tengo en mente implementar algo parecido a un sistema de puntuaciones. Digo parecido porque en un principio este tipo de juegos de ritmo pausado no tienen muchas variables para medir una puntuación que no sea nº de movimientos y tiempo empleado, pero cada nivel siempre tendrá un número mínimo de movimientos que no se podrá mejorar y el tiempo empleado como variable tampoco es muy fiable si alguien se ha mirado la solución por cualquier sitio. Pero coincidio contigo completamente en el que algo de competitividad le sentaría bien, algo en plan: podium de los primeros jugadores que lograron pasárselo primero.


Agradezco mucho todos estos comentarios, no esperaba menos de la gente de este foro. Muchas gracias a todos.

Cita de: hammer date=1471728928Que mala leche tienes xD no he pasado de la tercera pantalla  , la que te salen dos fichas,hay poco espacio para moverlas xD.
   
   
      Esta muy bien, pero creo que tendrias que  ajustar un poco la curva de dificultad y ponerlo un poco mas facil las primeras pantallas,piensa en los que no somos muy listos xD.
   
   
       
   

Mejor te quedas después cuando lo resuelves . No obstante no tienes que hacer ese nivel forzosamente, siempre hay 3 niveles a elegir, por si te atascas en uno puedas avanzar por otro lado.

Bueno, ahí esta un poco el chiste. El juego no te dice nada, pero tanto los objetivos como la forma de resolverlo lo descubres jugando. 

Quiero presentaros el proyecto en el que he estado trabajando desde hace ya un tiempo. Por fin he podido terminarlo (aunque la idea es ir actualizándolo cada X tiempo con mas contenido).
 
Se trata de Bricks, un juego de puzles gratuito que ya podéis encontrar en Google Play Store: https://play.google.com/store/apps/details?id=com.ClockTowerStudio.Bricks


Mi idea al presentarlo aquí no es básicamente de hacer promo de mi juego. La verdad es que me gustaría conocer vuestra opinión como profesionales en el sector, o como gente que entiende de videojuegos, les apasiona, gente que se quiere incorporar al medio... ect ect. Busco perspectiva, y sobre todo en un lugar como este voy a tener muy en cuenta las opiniones que se generen.
 
Así que sin mas os lo presento y lo pongo a vuestra disposición para que lo juzgueis. Agradezco cualquier opinión, cualquier observación, y por supuesto espero que lo disfrutéis.
 
PD: Si os gusta no me vendría nada mal que lo recomendaseis y le dieseis una valoración en la Play Store... ahí dejo el dato .

Bueno, si te sirve de algo, lo que estas pidiendo es sencillo, no requiere conocimientos avanzados de programación. Pero si te recomiendo igualmente que, si te quieres dedicar a esto, sepas lo que es un script y algo básico de su funcionamiento.
 
Un script es básicamente decirle a tu juego que es lo que tiene que hacer cuando ocurran ciertas cosas.


Te recomiendo los tutoriales de unity3d, son muy buenos para principiantes y si el inglés te supone un problema están subtitulados:

https://unity3d.com/es/learn/tutorials/modules/beginner/scripting/scripts-as-behaviour-components?playlist=17117

Cita de: gonzilla date=1471441487Pues soy programador empirico y pues y hice un script para desaparecer un objeto pero no encuentro como hacer lo contrario (que aparezca on trigger). cual seria la palabra exacta para lograrlo?
   
   
       
   

¿Has probado con abracadabra?, ¡OJO! no lo confundas con avada kedabra que la lías parda.
 
Creo que Baltor ha respondido a tu pregunta, mas o menos, pero si el collider que dispara el OnTrigger se encuentra en el mismo objeto que quieres ocultar/mostrar entonces nos uses gameObject.SetActive(true/false) porque esto haría que se desactivase el collider. Lo que tienes que hacer es desactivar su renderer para que deje de mostrarse pero los demás elementos del objeto sigan funcionando (si es el mismo objeto el que tiene el collider seguirá detectando colisiones y si tiene algún otro script este seguirá funcionando).


Para ello, según los teóricos del modelo binario de com***ción (nada de teoria de cuerdas de la com***ción, esos están muy mal de la cabeza) bastaría con conseguir la componente Renderer con GetComponent<Renderer>() y poner su variable enabled a false.
 
Saludos.

Y... ¿cuál es la pregunta?


Suponiendo que lo que me estas diciendo es que no tienes ni idea de por donde empezar:


Esta claro que necesitas una variable para almacenar el número de vidas que tienes. Si se puede ganar o perder vidas entonces necesitas además una variable que diga cual es el número máximo de vidas que puedes llegar a acumular. Y finalmente necesitas métodos que al llamarlos realicen todas las tareas de control sobre tu vida que estas pidiendo (que pierdas vida cuando ocurre tal, que ganes cuando ocurre el otro tal....).


Se un poco más concreto sobre el problema ¿exactamente en qué te has atascado?.

Si te es posible acompaña de alguna imagen o incluso clip que muestre el error, porque a priori es precipitado decir que el error está en el código.


Como bien dice hammer 
 

Cita de: hammer date=1471004119Lo de que se levante unos centimetros cuando le das al play puede ser muchas cosas, podrias mirar en Animation Import Settings, tiene unas opciones para Root Position (Y),eso si es por la animacion,puedes mirar tambien de rehacer el avatar si es por el rigging,tambien revisaria las posiciones de todo,malla,esqueleto,collider.....
   

Puede ser muchas cosas, pero por como has descrito el problema yo tiraría por mirar si la animación esta bien pivotada y las opciones de root en el impor settings.


De todas formas si no consigues dar con el problema con lo que ha dicho, manda imágenes del antes del Play y el después junto con el inspector, seguro que de ahí sale alguna pista más.

Básicamente atente a la definición de Singleton, si tienes una serie de datos y necesitas de un elemento gestor único que los mueva o trabaje con ellos, eso esta pidiendo a gritos un Singleton. Lo suyo es tener tantos Singletons como "tareas de gestión independientes" haya. Si tienes diferentes datos o tareas para un gestor global de sonido, persistencia de datos etc etc, lo lógico es crear Singletons con responsabilidades bien definidas, no un MACROSINGLETONDELCOPON con 100000 lineas de código ilegibles.


En definitiva, no hay una respuesta clara de cuantos Singletons esta bien o esta mal, ni pocos ni muchos, los justos y necesarios según tu diseño (suponiendo que es un buen diseño).


Saludos.