Su **** madre con el rigidbody, las fuerzas y la previsualización

**Anarchy** · 10/01/2016, 13:56

Esto es una mezcla entre duda y queja, por ver si alguien lo ha sufrido en sus carnes.

Estoy haciendo un enemigo que tiene rigidbody y que persigue al jugador añadiéndole una ConstantForce en el eje X. Vamos, que el enemigo corre de forma continuada hacia la derecha.
La velocidad del jugador también es constante a la derecha.

Pues bien, dependiendo de cada ejecución que hago, el enemigo tarda más o menos tiempo en alcanzar al prota dependiendo de factores tan tontos como añadir un nuevo elemento en el GUI, o modificar ligeramente una animación en el personaje. NO LO ENTIENDO. No es un problema de rendimiento, el juego va a los FPS que debe durante la preview.
Si hago una preview en el Unity, el enemigo alcanza al personaje cuando no debería hacerlo (debe quedarse casi a su par, pero sin llegar a alzancarlo). Esto sucede casi el 100% de las veces.
Si toco algo y hago otra preview, el resultado puede ser completamente diferente.
Si lo compilo, el enemigo no llega a alcanzar al personaje. Así que he ajustado el ConstantForce del enemigo teniendo en cuenta el resultado que consigo en la versión compilada. Pero NO COMPRENDO PORQUÉ COJONES ME PASA ESTO. Y más si el juego no tiene caída de FPS durante la preview.
¿Alguna posible explicación?

Acabo de probar a marcarle una velocity.x fija en lugar de añadir una ConstantForce, pero no me ha funcionado (tengo que ver porqué)

Un saludo
Anarchy

**HexDump** · 10/01/2016, 14:39

Ahora mismo solo te diré algo, un motor de físicas no es determinista. No se si lo que te ocurre es por esto o algo que se debe a tu código, pero esperar que tras 2 ejecuciones distintas se obtenga el mismo resultado usando físicas va a ser un FAIL total.

Sacado de la FAQ de physx:

"The first problem here is that the PhysX SDK is not deterministic.Especially when running different hardware setups, bus latencies can vary between runs, or on different machines. Even without hardware in the machine, we do not guarantee any type of determinism."

Un saludo.

**Anarchy** · 10/01/2016, 14:48

Pero *****, si ambos objetos usan el mismo motor y ambos tienen una fuerza constante estable... ¿Porqué uno de ellos cambia tan drásticamente su comportamiento respecto al otro? ¿No debería afectarles de una forma más o menos similar a ambos?
Qué rabia, *****!

-----Actualizado-----

Y claro, teniendo en cuenta que uno de los personajes tiene que usar físicas por narices (por la forma en la que lo he programado), si un move sobre el otro usando Time.Deltatime para determinar el tiempo que tardará de un extremo al otro, el resultado también variará dependiendo de la máquina...

**HexDump** · 10/01/2016, 14:51

Que no sea determinista no significa que todo vaya a ser un caos xD. Cuentaos un poco más tu setup, por que usas un rigid body? Es solo por obtener callbacks de colisión? Podrías hacer kinemático y controlar tú el movimeinto mediante el transform?

Yo te doy un consejo si me lo permites: Tomate las cosas con calma, una persona que llega a unity lo ve todo de color de rosa por que tiene muchas cosas pero cuando empieza a meterse a fondo se da cuenta de que todo no es tan rosa xD. La gente que viene de sus propios engines o ha hecho mucho bajo nivel llega a quererlo como es porque sabe el trabajo que le ha quitado de encima. Los usuarios que quieren hacer juegos sin más cuando se encuentran movidas, y ya te digo que las físicas son un caldo de cultivo de cosas raras, se exasperan y acaban muy quemados.

Tú piensa que estás para aprender (como todos) y si algo no va pues hay que mirarlo y ya está. Esto te lo digo porque te veo crispado

.

Un saludo.

**Anarchy** · 10/01/2016, 15:02

Si me lo tomo con calma, pero llevo tiempo programando con diversos lenguajes y no he tardado en ver que se le pueden sacar algunas pegas a Unity. Y a nivel de rendimiento no entro ni a discutir, porque es evidente que necesita muchas mejoras.

Eso sí, es súper cómodo y te permite desarrollar cosas en pocas horas. Jamás habría podido tener en 6 días tenía un sistema de juego completo desarrollado y funcionando como lo tengo si no fuera por Unity.

Estoy cambiando el sistema para mover el enemigo mediante transforms y simplificarlo un poco.

-----Actualizado-----

Hecho. Funcionando perfectamente en 1 minuto. No se ni para qué cojones me complico la vida.

En un nivél anterior ya había hecho una especie de persecución usando el transform.position, pero parece que me gusta meterme en líos. xD Quería hacerlo más "bonito" y que fuera destruyendo el entorno (por eso el uso de un rigidbody), pero pasando de líos.

**HexDump** · 10/01/2016, 15:08

Con un kinematic puedes hacer que vaya destruyendo el entorno pero a la vez seguir controlando tú mismo al personaje. Por eso te preguntaba.

Si es eso lo que querías usa un kinematic. Ser kinematic es como super man, tú afectas físicamente a todos pero a tí no te afecta ná!. Eres un macho super hombre

.

Por cierto, yo quiero ver que leche estás haciendo por que parece que estás montando un buen percal no?

Un saludo.

**Anarchy** · 10/01/2016, 15:12

Qué va! Es un juego sencillito 2D en el que sólo controlas el salto del personaje (pensado principalmente para móviles), pero con un nivel de dificultad muy alto.
Lo que pasa es que me gusta añadir chorraditas para darle "toques" y me acabo liando demasiado la manta a la cabeza. xD
Luego si puedo subo un vídeo.

**HexDump** · 10/01/2016, 15:14

Mola! Un video siempre está chulo para robar ideas

.

Un saludo.

**Anarchy** · 10/01/2016, 15:32

Sigo teniendo un problemilla, y es que el personaje sigue usando el sistema de físicas, así que aunque el enemigo tiene el comportamiento esperado en tiempos, el resultado final acaba variando.
voy a hacer una simple fórmula para calcular las posiciones y situar al enemigo dependiendo de la posición del personaje. Esto es trampear el resultado (se supone que la distancia con el enemigo depende de tu habilidad esquivando obstáculos), pero me solucionará todos los problemas.

**Anarchy** · 10/01/2016, 17:31

Media tarde perdida con esta chorrada!

No te lo pedonaré jamás, Manuela Carmena, jamás.

**notbad** · 10/01/2016, 17:42

Media tarde perdida no está mal si piensas que nunca perderás media tarde por ese problema

. Ha salido muy a cuenta....

Un saludo.

**Drumpi** · 10/01/2016, 19:52

Tranquilo, Anarchy, que el sistema de físicas es una constante fuente de quebraderos de cabeza.

Para empezar ¿Dónde estás aplicando la fuerza? Todo el tema de físicas debe ir en el FixedUpdate y no en el Update (el segundo se ejecuta cada frame, el primero más veces, y se actualiza a la vez que las físicas).
Segundo: NO USES TRANSLATE. Si le metes físicas a tu personaje, es lo peor que puedes hacer porque transform.translate teletransporta tu game object ignorando las físicas. En su lugar te recomiendo que uses (en el FixedUpdate) el comando Rigidbody.MovePosition, y no se si deberías usar el Time.FixedDeltaTime.
Otra opción es que trabajes directamente con Rigidbody.velocity. No se recomienda porque generalmente los novatos la modifican sin pensar en las consecuencias.
Recomiendo leer tutoriales de este tipo:
http://gamedevelopment.tutsplus.com/...ame--cms-21418
Y mírate a ver si el CharacterController (no confundir con thirdPersonController o FirstPersonController) te puede ayudar con tu juego. Ha habido veces que he pensado en mandar todo el código a la porra y empezarlo de cero con él, porque (supuestamente) da muchas facilidades

Yo he tenido que lidiar con un personaje que entraba en modo "caida" cada vez que había un cambio de rasante hacia abajo, plataformas que se movían sin trasladar al personaje, temblequeo del protagonista al chocar con una pared por usar translate en lugar del movePosition... y así un montón de cosas.
Así que paciencia, experimenta, busca mucho por internet (porque hay más de lo que te he contado) e intenta que todo funcione. Ya me dirás.

**notbad** · 10/01/2016, 20:15

Yo del Character Controller solo puede echar pestes, y muchas. Es la cosa más mala que he visto :P. Y si el juego es en 2D es una ñapa buena usarlo. Primero de todo el tio es una capsula, preparate a tener q gestionar de forma creativa los extremos de las plataformas para que no parezca que el tio se hunda. Después solo recibe colisión por los lados (si no recuerdo mal) si el bicho se mueve, si no se mueve nada de nada (Añade un trigger o una collider para gestionarlo tú) y así unas cuantas cosas más.

Una de las ventajas que tiene es que te gestiona él el estado de "grounded" y la respuesta contra una colisión para que no traspases paredes ni tengas el efecto de "pegado" cuando tienes una colisión contra una pared vertical y sigues andando hacia ella en el aire.

Yo para hacer cualquier tipo de player que requiera cierto control del jugador siempre uso un kinematic y las físicas del player se las aplico yo. El engine se encarga de todo los demás.

Un saludo.

**ElRana** · 11/01/2016, 19:49

Se me hace raro escribir una intervención no troll... pero bueno, para todo hay una primera vez.
El problema que tienes con las físicas y que SIEMPRE SIEMPRE SIEMPRE estará ahí se llama 8087.
Sí, las MMX heredaron parte de la circuitería del 8087, las SSE se basan en la misma circuitería (ampliada y con apaños, pero la misma) y CUDA se basa en los mismos principios y técnicas que SSE, es decir, mas 8087.
Si quieres algo aproximadamente determinista NORMALIZA, ponlo en el rango de [-1,1] (intervalos cerrados, sí) y sólo una de cada mil ejecuciones (ya serán mas, pero bueno) tendrás problemas.
La otra opción es seguir mis pasos y formular una cosa que no se si existirá ya, pero que yo he bautizado como coherencia geométrica, que básicamente consiste en ver "cuanto se la ha ido la yoya al 8087", en términos coloquiales.
Pero vamos, que si normalizas no necesitarás "trampas" de ningún tipo, emplees FPU, CUDA o lo que sea.
Esto es algo que se da en programación y forma parte de las bases mas elementales, es algo que se lo repetía incesantemente a mis alumnos (cuando los tenía) que las matemáticas idílicas y superchupiguais tradicionales hay que adaptarlas porque no son iguales que las duras y re-j0didas matemáticas que se necesitan en nuestra profesión.

Suerte y ánimo.

**Drumpi** · 12/01/2016, 04:38

Notbad: hay formas de arreglar lo de las colisiones y... es añadir más colisiones ¿Has probado a poner un círculo 2D en la base de la cápsula? Se pueden generar colliders compuestos... No me preguntes cómo, porque a veces me funciona símplemente añadiendo los colliders como componentes junto a la cápsula, y otras sólo funcionan cuando están en un hijo sin rigidbody propio.
Porque sí, para que te detecte una colisión, todas las partes implicadas deben tener sí o sí rigidbody, aunque sea una piedra que no se mueve en absoluto (hay que ponerla en kinemática y sin gravedad, sin rigidbody sólo detecta OnCollisionEnter/OnTriggerEnter la primera vez).
Además, que el CharacterController hace más que lo que mencionas: permite seleccionar el alto de los escalones que puede subir de forma automática, permite definir el ángulo que diferencia un cambio de rasante con la colisión con una pared, ayuda a facilitar el movimiento del game object... ¿Que se puede emular por código? Sí, yo lo hice, le dediqué como tres meses a ello (aunque reconozco que no tenía ni idea de lo que hacía), y aun hay cosas que no funcionan como debieran.