Element Conquest! (juega desde el navegador)

[TRaFuGa]

Al final los AAA o tienen su propio motor o tiran de Unreal (que es el más grande), como desarrollador independiente, unity es LA herramienta, con una curva de aprendizaje muy bien llevada y un acabado final de muy buena calidad, al final volvemos al inicio, matar moscas a cañonazos, que va a depender de lo que realmente busques o necesites en ese momento.
Intenté utilizar GODOT, pero no me llegó a convencer...
¿Qué motor utilizan para juegos tipo Candy Crash? (no tengo ni idea de quién ni de cómo lo han realizado), si no recuerdo mal, Gameloft utiliza unity...
Yo creo que cada uno debe de buscar la herramienta que más le convenga y a la que le pueda sacar el mejor rendimiento.
@Drumpi todos tienen sus cajas de colisión, el personaje al acercarse al muelle desde arriba es cuando hace el efecto, es un material específico que actua como rebotador (físicas incluidas en unity), una de las cosas que tengo que controlar es los fps, ya que en el preview funciona a un ritmo y en el navegador a otro (lógico), por lo que debo de limitarlo para que se ejecute siempre a unos mismos fps, de esa forma evitaría muchos problemas de colisiones porque todo se ejecutaría a un ritmo más lento y que es el que quiero conseguir: el del preview del editor... (al menos eso es lo que puedo entender con los problemas que he visto, ya que en el editor no se reproducen la mayoria).

[josepzin]

Los juegos hechos por estudios pequeños me imagino que están hechos con Unity, al menos los casos que yo conozco lo usan y supongo que saber usarlo es una carta para publicar cosas en todo tipo de sistemas facilmente o conseguir trabajo en alguna de estas empresas o como freelance.

[Drumpi]

¿Qué motor utilizan para juegos tipo Candy Crash? (no tengo ni idea de quién ni de cómo lo han realizado), si no recuerdo mal, Gameloft utiliza unity...

En su mayoría creo que tiran por Unity, sí. Por ejemplo, en la antigua Genera Games, los del Frozen Freefall, usan Unity en casi todos sus proyectos (y eso os lo puedo decir casi de primera mano, porque lo he visto).
Y tiene su lógica: es muy sencillo desarrollar, te da casi todas las herramientas, y casi todos los que entran han terminado por usarlo de una forma u otra.

También os digo una cosa: usar Fenix y BennuGD me ha ayudado mucho a entender la filosofía de objetos de Unity, y gracias a ello he ayudado a más de un "experto" a solucionar problemas de sincronización de objetos. Es que es casi lo mismo: los procesos son objetos, las variables locals son las propiedades del objeto, el orden de ejecución es "aleatorio". Lo que cambia es que hay un sistema de comunicación con señales, y que tienes más eventos (en BennuGD tienes el apartado de "OnExit" para cuando matas a un proceso).

@Drumpi todos tienen sus cajas de colisión, el personaje al acercarse al muelle desde arriba es cuando hace el efecto, es un material específico que actua como rebotador (físicas incluidas en unity), una de las cosas que tengo que controlar es los fps, ya que en el preview funciona a un ritmo y en el navegador a otro (lógico), por lo que debo de limitarlo para que se ejecute siempre a unos mismos fps, de esa forma evitaría muchos problemas de colisiones porque todo se ejecutaría a un ritmo más lento y que es el que quiero conseguir: el del preview del editor... (al menos eso es lo que puedo entender con los problemas que he visto, ya que en el editor no se reproducen la mayoria).

Pero puedes añadir otra caja de colisión encima, de tipo trigger o como se llame, para que cuando choque algo con él hacer "algo". Cuando hice el PaperTale, coloqué una pequeña caja de colisión en la pare inferior del prota para poder saber cuándo este tocaba el suelo o no para poder activar el salto (idea de un tutorial).

[TRaFuGa]

Drumpi lo de debajo del personaje lo controlo de otra forma, así también me vale para la máquina de estados que gestiona las animaciones.
Revisaré los muelles, tengo que ajustar la propiedad de rebote en cada uno y ver si el problema de que se te queda enganchado en el tilemap es cosa de los fps y colisiones (que va más rápido de lo que debe y no las detecta bien)

[Drumpi]

No, si lo de la caja de colisión debajo del prota es un ejemplo de uso de una caja de colisión secundaria. Lo que te digo es que a lo mejor te conviene usarla para detectar que el prota choca contra la superficie superior del muelle.

Además, acabo de recordar que al final lo cambié por un rayo hacia abajo, que detecta la distancia con el objeto más cercano, que seguramente será el sistema diferente que dices que usas tú.

[zhorro]

Dos errorcillos me he encontrado, en la primera pantalla despues de que me matara el bicho de la derecha (porque no habia leido lo de la z para atacar ), el bicho se quedo estatico justo a la entrada del pasillo.

Y en la segunda salte de la escalera y se fue a otra pantalla y se ha quedado el personaje incrustado en la pared donde esta el circulo amarillo.

[blindrulo]

Yo lo hacía con las cintas del Amstrad. Mi padre tenía unos cuantos juegos sin instrucciones y... bueno, te encontrabas sorpresas. Descubrí que apretando todas las teclas del teclado, a dos manos, podías pasar de pantalla en el Plaga Galáctica (seguramente fueran dos o tres botones, pero nunca descubrí la combinación)

En realidad no hacia falta ninguna combinación, bastaba con darle una o dos veces no recuerdo bien hacia la izquierda o derecha y punto, dejabas el disparo pulsado y te podías pasar el juego sin más ya que ningún disparo de las naves enemigas te tocaba. xDDD

Un saludo.

Ayer subí mi "nuevo" juego a itch.io y no os avisé xD
Se trata de Element Conquest, juego estilo NES en el que pude poner en prácticas lo aprendido durante un cursillo (que me hacía falta conocer sobre todo el entorno Unity). Hay un bug detectado que espero corregir estos días (o el finde...)
OS dejo el enlace (solo PC desde el navegador!)

https://adanoliva.itch.io/element-conquest

He jugado en MAC con Firefox y va bien, sólo un problema...soy malísimo. XDD No he pasado de la segunda pantalla.

Un saludo.

[TRaFuGa]

Dos errorcillos me he encontrado, en la primera pantalla despues de que me matara el bicho de la derecha (porque no habia leido lo de la z para atacar ), el bicho se quedo estatico justo a la entrada del pasillo.

Y en la segunda salte de la escalera y se fue a otra pantalla y se ha quedado el personaje incrustado en la pared donde esta el circulo amarillo.

No he conseguido replicar esos fallos
Voy a ver si añado unas mejoras y proceso a revisar las colisiones y muelles, que les hace falta jejeje

[chipan]

Yo me salí del camino y me quedé dentro de las paredes... por culpa de un muelle. La parte buena es que pude explorar una buena parte del mapeado sin peligro.

[TRaFuGa]

Yo me salí del camino y me quedé dentro de las paredes... por culpa de un muelle. La parte buena es que pude explorar una buena parte del mapeado sin peligro.

Cuando pasa eso, la tecla O te hace respawn en la pantalla en la que te encuentres xD
Este finde no he podido tocar casi nada, a ver si saco algo de tiempo entre semana (que lo dudo con las fechas que son) y me pongo a revisar, voy a dejar el juego a 60FPS, lo probé a 30 y parece que va a tirones.

[TRaFuGa]

Estoy tratando de exportarlo para android (pronto subiré una versión web corregida, al final he eliminado los muelles...) pero la resolución me marca mayor pantalla de la que necesito mostrar, a ver si alguien sabe decirme cómo hacer para que ajuste a lo que yo necesito (creo que era 800x600)

Ya que estoy mostrando los botones para la versión Android, quiero saber vuestra opinión (el d-pad lo pondré más grande, hay veces que no lo pulso bien), quiero ponerlos en un sitio que no moleste tanto, aunque parte de visibilidad se va a perder con los dedos...

[futu-block]

a mi gusto, haría el juego 4:3 y pondría los botones a los laterales negros pero decorados con un becel guapo simulando botones y cruceta

[Drumpi]

Por eso no me gustan los controles táctiles, te tapan la acción.
Cuando hice el Screen Break Time me quedé con las ganas de experimentar con unos controles fuera de la zona de juego. Sin embargo, el control usando toda la pantalla como cruceta, en el nivel de plataformas, resultó bastante cómodo, incluso con los dedos. Especialmente porque para desplazarte podías usar, de los laterales, la parte media y la baja de la pantalla, por lo que siempre tenías una alternativa para no cubrir parte del escenario.

Pero sí, habría querido probar a poner los botones de desplazamiento fuera de los márgenes laterales, usar las esquinas superiores para los saltos laterales, y repartir los botones de acción en los huecos sobrantes.
Y si no, cambiar el diseño de juego de plataformas por algo en el que se use la pantalla táctil, y no un control tradicional, como en el nivel del shooter lateral.

[TRaFuGa]

Gracias @futu-block voy a probar a ver si consigo hacer el juego 4:3.
He subido una nueva versión web del juego (https://adanoliva.itch.io/element-conquest) en el que he eliminado todos los muelles y remapeado algunas pantallas para hacerlo más jugable, también añadí un menú de pausa al juego. Seguramente haga un remapeo de una pantalla en concreto que no me termina de cuadrar, y dudo que toque algo más, a parte de hacer la versión para Android...
Estos días, a pesar de estar de vacaciones, estoy algo liado cambiando habitaciones (y aún tengo que pintar xD) que para poder tenr el estudio ayer me partí el lomo montando y desmontando camas (literalmente, tengo la espalda jodida xD), voy a ver si preparo el escritorio para poder trabajar, quiero pillarme un teclado externo y un soporte para el portátil y voy a esperar a ver si me dan una segunda pantalla, y sino, miro una grande que la de 15" de ahora es muy pequeña.