#120 El color espero que sea un poco más vivo, quizás marrón o naranja de diferente tonalidad cuando este activo e inactivo
#124 Es subliminal, es para que te fijes en los colores, y por otro te persigo con el estilo que me mola xD
#120 Tal vez un overline blanco o que se ilumine de forma que dé a entender que es un item con el que puedes interactuar y que no es parte del entorno del mapa si más.
#126 Todo eso quedará explicado en el tutorial, con su correspondiente cartelito, para que el player conozca cada uno de los items y mecánicas del juego. Pero bueno, esos detalles artísticos los iré puliendo al final. Quizás ponga un icono de flecha igual que en los carteles, ya veré.
Gracias por las ideas
#128 https://godotengine.org/article/godot-31-will-get-many-improvements-kinematicbody
Apartado del final Sync to Physics
Básicamente cambiando la plataforma de static a kinematic y estableciendo a true esa propiedad.
He estado echando una partidica con el mando, está quedando muy bien. El control del pj con el mando va genial. Lo único que no me funciona es leer los carteles con el joystick, tengo que usar la cruceta.
Porfa pon unos putos checkpoint antes de los primeros pinchos, que me he muerto 2 veces y paso de pasarme el tutorial por tercera vez xD
#131 por eso la necesidad de los checkpoints xdddddd. Lo de leer carteles con el joystick lo tengo en "bugs", lo solucionaré en breves.
Los checkpoints no los tendré terminados hoy, me fallan unas cosillas.
#120 Yo opino igual que otra gente, deberías cambiarle el color cuando está activo, por ejemplo ponlo marrón/naranja y luego al pasar y cogerlo lo pones gris como está ahora para que el jugador sepa que ya lo ha cogido o activado.
"@AikonCWD no usa Rigids en su juego porque son un overkill para lo que él hace"
Vamos a dejar la información clara, porque ninguno queremos que nos tachen de ignorantes dando informaciones falsas 
Por favor, ni se os ocurra ensuciar el tema. Si vais a empezar una batalla sobre comentarios que son correctos o no, por privado o nuevo hilo, solo para hablar sobre cursed gem.
Si no usas físicas como haces para mover al pj y saltar? Cambiando directamente las posiciones del objeto en plan pos.x + 1 o que?
#142 si usa un controller, estará scripteado, no es ninguna locura, en Unity se hace mucho también. Es bastante común en plataformeros, según tengo entendido.
#142 No, no usas eso. En Godot para los kinematic tienes dos funciones para moverlos. Una que los mueve una distancia y si colisiona se para y te devuelve la colisión. Y otra que lo mueve y si colisiona lo desliza dependiendo del ángulo del objeto con el que colisiona.
Para hacer esto tienes que calcular tú las físicas, que no tiene mucha complicación. Es coger un vector director, una velocidad que quieres que lleve y un delta. A partir de ahí es añadir complejidad, como fuerzas externas (otros objetos o gravedad), rozamiento o inercia. Es bastante sencillo si tienes nociones básicas de matemáticas y bastante más ligero que usar rigid, ya que dista mucho de ser tan real. Pero para un plataformas en 2D, el resultado es casi que mejor que si fuera megarealista.
#142 Me expliqué mal.
En Godot, hay 3 objetos muy diferentes dentro de la familia "colliders": static, kinematic y rigid. El static está claro, un bloque que no se va a mover
El Kinematic es un cuerpo que lo mueves tú por código, por ejemplo cambiando las coordenadas de su vector X,Y,Z
El Rigid es un cuerpo que lo mueve el própio motor de físicas. Tiene propiedades como masa, gravedad, fricción, rebote, refracción y mil cosas más.
El Rigid es el objeto con mayor coste de rendimiento, en el momento que instancias un rigid, godot exportará todas las funciones necesarias para que funcione en tu juego, incrementando el peso del mismo y eso. Si en todo tu juego no usas rigids, esa parte del motor no se exporta en tu juego y terminas con un proyecto más pequeño y ligero.
Todo el juego está hecho con statics y kinematics. Por eso decía que veo un poco overkill meter un rigid para hacer una plataforma, ya que eso provocaría que mi proyecto crezca y consuma más.
No se si lo he explicado bien xd
#145 "va ha" mis hogos!!!!!
No es cosa de Godot, es cosa de muchos motores en 2D. En box2d tienes eso, y por ende tanto en libgdx como en pygame por ejemplo. En godot tienes una tercera escena, el area2D, que detecta colisiones pero no evita que los objetos pasen a través de esta.
En cuanto a lo de que por no usarlos no lo mete, no lo tengo claro. Que no haga las llamadas sí, pero no sé si el juego va a pesar menos por no usarlas, el código digo yo que seguirá ahí
#145 ok entonces es como te digo en el mismo comentario, que lo mueves tu por código a pelo xD Si en unity eso lo puedes hacer también, pero siempre entendí que mover objetos directamente cambiando en el update sus posiciones del transform x y era mala idea y es mejor usar las físicas del motor, pero ni idea la verdad de si en unity no usas ningún rigibody el proyecto pesará menos porque no usa las físicas.
#147 Ya no es solo por el peso final del juego, es por el consumo de rendimiento en CPU. Si tienes instanciados objetos rigid, el loop del update estará pendiente de las fuerzas que se aplican (o se dejan de aplicar) en cada rigid. Si no hay ningun rigid, todos esos checks se omiten en el loop y eso provoca mejor rendimiento.
Si me viese forzado a utilizar cientos de rigids y el consumo fuese algo importante... debería dormir los rigids que no se moverán para sacar esos checks en el loop y tal. En definitiva, más esfuerzo para mí. Por eso si puedo evitar usarlos, mejor. Intentaré exportar, solo por los loles, el juego en smartphone a ver que tal se mueve.
#148 vale es que lo que me pusiste en 144 yo había entendido lo mismo con un poco más de complejidad en la fórmula simplemente calculando tu el vector de dirección y velocidad, pero leyendo otra vez lo que me imagino que para los kinematic lo que tiene godot es que sin implementar todas las físicas de un rigid pero si una físicas básicas propias con funciones para mover y colisionar.
