#59 deltaTime Description The completion time in seconds since the last frame.
Por qué debe deltaTime entregar fixedDeltaTime en todos los ticks si deltaTime se calcula a partir del anterior frame? en cada tick estás avanzando en el tiempo... del siguiente frame.
edit: para no fastidiar el hilo si quieres lo debatimos por privado xD
Note also that the Input flags are not reset until Update. It is suggested you make all the Input calls in the Update Loop.
#60 Es donde me pude documentar.
Vale, ya esta arreglada la cámara y he mejorado con las recomendaciones de @d-bug y @totespare, gracias a los dos.
Después de depurar el código, arreglar y entender lo que hago.
Tengo varios puntos. Si hago que el value input lo haga el joystick, la velocidad será dinamica. Puedo hacer que detecte el valor del joystick y darle una velocidad al personaje en concreto para no liar la marrana.
Que sugerís? Queda más natural el movimiento dinamico, pero con animaciones quedará...raro
Después de 9 días sin dar ninguna noticia es ser un poco desgraciado.
Realmente he estado trarbajando pero poniendo updates o cosas en Taberna. Entre hoy y mañana pondré en todo lo que he avanzado como costumbre pero de momento echarle un vistazo al Trello.
https://trello.com/b/QaIo4JWG/arpg
Ruinless venture <- Este el nombre que tenía pensado para el juego, si alguien sugiere otra cosa, por favor 
One man army.
La idea es hacerlo todo yo mismo.
Seguramente sea lo que más me haga invertir tiempo, porque la programación la tengo bastante más por la mano
#68 Cuando llegué a casa, puedo subir algo, pero creo que he hecho 3-4 sprites en mi vida. Soy un poco patán. Pero la idea es esforzarse
#70 
Lo otro son sprites muy sencillos de tilemap
Este era una idea del personaje principal, pero no me acaba de convencer que sea tan grande 
#71 Intenta asignar un tamaño de sprite fijo y cíñete a ese tamaño siempre. Lo mismo con la paleta de colores.
En mi juego uso sprites de 8x8, para el tuyo creo que 32x32 es más que suficiente, incluso probaría sprites de 16x16, pero eso ya va más a gusto personal.
#72 El problema que tengo a la hora de diseñar el sprite del personaje es que si hago 32x32, las animaciones de ataque pueden ser más irregulares que 32x32 y no se muy bien como afrontarlo. Alguna idea sobre el tema? Estos días he estado haciendo research sobre personajes 32x32 y 16x16. Y decidiendo el tipo de "estilo" que quiero tener en el juego. A ver si consigo unas horas para hacer las animaciones de andar.
Edit:
Sobre el tema de ataque, lo digo porque la arma será cambiante, entonces será un sprite adicional a la animación. Y por ejemplo tengo pensado 2 tipos de armas de momento, lanza y espada. La espada es un slash tipico en arco, pero en cambio la lanza en cambio son ataques muy rectos y alargados comparados, por ende el 32x32 se me va a la mierda. He estado pensando en hacer una gran paleta de 256x256 y hacer slots de 32x32 para tener las zonas calculadas pero teniendo en cuenta que hay cosas que podrían cambiar y así convertir el sprite en un playground para probar sin tener que hacer mierdas para el 32x32.
Pero si, el personaje será como mucho 32x32 y ya será mucho.
#73 Puedes plantearlo de la siguiente forma:
El arma y su animación podría ser un sprite adicional al del personaje, y ésta podría tener un tamaño diferente, mira este ejemplo:
#72 Eso da = , los mios son 32x32, pero luego el dibujo es 16x16, lo que hay que coger es un cuadrado, e intentar no salirte de ahi, y es mejor que sobre a que falte xD
Si vas a usar un sprite para el personaje y otro para el arma, podrías almacenar para cada frame del player la coordenada (offset) donde colocar el sprite del arma.
Con ese offset ya tienes alcance fuera de la base de 32x32 y como curro extra solo sería asignar la coordenada.
No se si me explico...
#77 dos sprites de 32x, el punto rojo es el offset... la imagen combinada supera los 32x
#78 Ah, creo que sería lo más importante, pero en el Animations tendría que hacer estas animaciones y posaciones a mano, si no me equivoco, no?
Por cada frame del player tendrías que asignar/almacenar manualmente la posición de la espada.
En cada frame de la espada asignar/almacenar su origen (el mango) y tocaría "manejarla" vía código.
#81 si se tratase de una animación a base de bones sería sencillo auto-anclarlo, el problema es que es pixel art (píxeles puros) toca hacerlo a mano.
edit: si no, pues rejilla de 256x256 y vía xD
@johnvoiden por eso te comenté hace unas semanas si lo querías pixel art "puro"...
Si te sirve pixel art "sin purismos" podrías trabajar con bones...
Te ahorraría mucho trabajo.
#79 Mira, un claro ejemplo de que comentaba debug:
https://twitter.com/KiwiSquaredDev/status/1169419049324826624
Se aprecia perfectamente los 2 sprites (el player y el arma), sencillamente tienes que indicar el punto de anclaje para el sprite del arma y rotarlo en la dirección del mouse o al atacar.
#86 Es que mi juego al ser zelda-like(en el sentido, la arma no vuela, si no que la tiene en la mano) y ser joystick movil, no tengo ese doble joystick. Pero si, al final será hacer 2 sprites separados con 2 animaciones diferentes, y juntarlos depsues en Unity.
