ADVERTENCIA: Estos juegos son proyectos sin fines de lucro,NO SE LUCRA Y NO ESTA A LA VENTA ninguno de estos proyectos de Komiteka. Son completamente GRATIS.

Notas de avances: Arreglando mecanicas (Pt.1)

 

Los errores y fallos me pasan muy seguido.
Tanto que ya no me afecta.

Bueno, Creo que empezare a mencionar los avances para mantener vivo al Blog, y porque no, encontrar errores o simplemente, mencionar alguna de estas y las mas destacables a mi parecer (Si fuera ese el caso, publicaria a cada hora) , asi que vamos alla:

  • Comando de cambio de personajes, no se eliminaba el objeto responsable del comando y al multiplicarse el objeto, causaba ralentización (Ademas que era persistente, o sea, que estaba en todo momento) 

  • Cambio en el orden del escenario de la Etapa Población, es cierto, debo admitirlo, aun no estoy conforme con esta etapa, siento que algo le falta, no lo se... como mas emocion, mas accion, mas sangre, mas de todo. 

  • Eliminacion de frames a los coches incendiados del prologo, aquí les contare algo para que vean que todos somos imbeciles: "Me di la molestia de crear una animacion al coche (copiando y pegando todo el rato y pixelar el fuego en cada frame con cada animacion independiente en cada lugar, 56 frames y despues reducidos solo a 12)  y se me OLVIDO POR COMPLETO que tenia un objeto que creaba flamas ALEATORIAS sobre un objeto.

    Si... peguenme, soy estupido XD

  • Cambio de Nombre de escenarios: Esteticamente hermoso, pero me obligo a cambiar algunos comandos de accion (Lo menciono porque gracias a esto, pude hacer los primeros dos puntos XD)

Notas de avances: Cambios Musicales

Imagen para llamar la atencion
(GIF hecho por Deathknight)


Referente al titulo de la entrada.

Después de mucho tiempo, eso creo, me he puesto con el compositor del proyecto y debo anunciarles lo siguiente:

La música de resurrección, colocada en la revision 2 del prologo del proyecto, sera cambiada, debido a lo siguiente:

Lo acordado con el compositor es la implementación total del soundtrack del videojuego, no aceptará que sea colaborado y/o puesto un OST que no sea ajeno a su mano, esto debido a que a palabras de el es lo siguiente: "Quiero que cuando pregunten quien creo el Soundtrack de este proyecto, llamado Gunshot Adventure, tenga YO la total seguridad, de decir que soy yo su compositor y no otra persona si fuera el caso de preguntar por un tema que no sea hecho por mi".

Referente al punto anterior, yo concuerdo en lo mismo, ya que "El mismo se ofrecio voluntariamente a ayudarme, y creo que es correcto acoger su palabra." -- Debo aclarar que el fue el primero en crearme un Theme propio y cuando dijo que iba a realizar el OST de mi proyecto, no solo quede asombrado, sino, entusiasmado. Mi moral andaba por los suelos y ahora tenia un motivo.

Aunque esto no quiere decir que el tema musical anterior quede como un "Unused" del proyecto, fue claro en decir "en este proyecto", eso quiere decir que podría ser utilizado a futuro en algún otro proyecto.

Esperemos que proximamente, en la revision 3 y final, pueda mostrarle un avance con sus temas actualizados.

Saludos.-


Notas de avances: El error tipico de todos mis proyectos de GM al fin esta solucionado.

Si bien es cierto que hay gente que podria decirme "Pero es es facil de corregir" "En los nuevos GMK ya no pasa eso" o tambien "Debes hacer una deteccion de movimiento y se soluciona" para mi no es el caso...

Les pondre en contexto:

El error ocurre cuando dejas presionada una tecla cualquiera
y dejas de presionar los botones izquierda o derecha
la animacion de correr continua y no se detiene.

Lo llamo, el efecto LOOPWALK


Este error impide que yo realice otras funciones adicionales al proyecto, como el de cargar la gunshot o mantener presionado para hacer un ataque poderoso, ademas de la estetica de hacer el paso moonwalk.

Dicho error es debido a que en el proyecto "no se ocupa el comando hspeed" sino mas bien, un place_free() para detectar el terreno y x+=velocidad, dicho de ese modo, no lo esta moviendo por la velocidad, sino por el cambio de posicion en el terreno, haciendo que cuando añadamos un codigo de advertencia de chequeo de movimiento, este lo pase por alto, ya que "aun se presiona una tecla"

Se ha intentado de todo: "no key" "if not (aka !)" "distance_to_object()" "not hspeed, speed, etc." y ninguno da resultado.

Recién en mi proyecto Castlevania: The Adventure DX he logrado dar un avance en la programación DETENIENDO POR COMPLETO el movimiento del personaje y evitar su ciclo de LOOPWALK, aunque cuando intente implementar la misma formula al proyecto Gunshot Adventure, este no resulto.

La solucion consistia en que si se chequeaban que una tecla estaba presionada y el personaje estaba con la animacion LOOPWALK sin moverse, este llamara al sprite de quieto para parcharlo. Solucion simple!

Aunque aun existe el segundo problema que es cuando presionas una tecla random (si dejo presionado la tecla ENTER) que provoca el mismo efecto de LOOPWALK, ahora habia otro cuando PRESIONABA LAS TECLAS IZQUIERDA Y DERECHA A LA VEZ, lo cual no solo había encontrado que la solución anterior no estaba resultado, sino que ahora, me he topado con otro error.

Fue entonces cuando se me ocurrió la idea, si no puedo realizar ningún comando de acción ¿Podría realizar un evento con una colisión? asi que, experimente con un objeto que persiguiera al otro persistentemente "Solo cuando este exista" y destruyendose en caso contrario.

Entre numerosos fracasos y fracasos, habia logrado con un codigo.

Inventando en el Create Event los codigos funcion_A y funcion_B,
estos le darian indicaciones al evento de colision.


Este objeto perseguiria a mi personaje y cuando "Yo realice los bugs ya mencionados" este activara las funciones A y B respectivamente (El A es para solucionar en caso de que se presionen dos teclas simultaneamente, y el B es por si dejas presionado una tecla cualquiera)

En el evento colision desde el objeto del personaje, colisionando
con el objeto que lo sigue, este reconoce los dos comandos funcion cuando
esten activos y realiza las acciones parchadas.


El resultado (Despues de mas de 10 años ignorando el problema) es una cancelacion de animacion en su totalidad, lo sorprendente de todo esto es que "estoy seguro que existe un problema aun ajeno a este, lo cual no les sorprenderia con una funcion_C parchando dicho error a futuro en una de las publicaciones.

Pero de momento, disfrutare de mi avance mostrandoles
como se ha logrado combinar una cosa tras otra.

Si bien en proyectos anteriores, siempre fue un problema, la idea del Game Maker es aprender mas y mas al momento de desarrollar videojuegos, cancelados, demos o alphas, nunca dejes de crear, ya que quizas, algun dia, puedas solucionar un problema que te impedia "Potenciar tus sueños"

Notas de Avances: Cambios en el Prologo (Revision #2)

 


Seguimos con las actualizaciones para el prologo de la historia narrada en Gunshot Adventure, en esta ocasion, se mostrará la animacion de resurreccion (unico momento y solo cuando batallas contra Mister T), ademas de mostrar una previa del escape. 


Aun faltan detalles por pulir e implementar, asi que de momento, pueden ver como va quedando.
Los detalles del video son los siguientes:

Saludos.-

PS:

* Las músicas del Minuto 0:00 y 1:30 es cortesía de ESMEDU.
* La música colocada en el minuto 3:02 es cortesía de MIKA MUSIC.
* La música reproducida en el minuto 4:44 NO CORRESPONDE AL PROYECTO Y SE REMOVERA CUANDO ESTE LA PISTA DE SU OST PARA IMPLEMENTAR.

Notas de Avances: Cambios en el Prologo (Revision #1)

 

Imagen final del evento prologo del proyecto en avance
"Gunshot Adventure"

La acogida del video Prologo (click en la imagen de arriba para verlo), fue muy bien recibido y con anotaciones y detalles que estoy trabajando, segun las sugerencias que el publico fiel me ha dado, ( Obviamente, aceptando a solo aquellos que me han seguido desde el progreso, para que aceptar sugerencias de newbies que despues se van a ir :v )

debo de añadir que me alegra que les este gustando el nuevo OST que tendra el proyecto, sinceramente, como lo dije en los comentarios, "Esto no es nada, lo que viene es filete de calidad" y yo soy un critico de la musica OST de los videojuegos y obviamente, lo que me laguea mucho siempre son los ritmos de percusion repetitivos y entre otros tonos irritables ( Cada uno con sus gustos, ¿vale? ) con el compositor de este proyecto, hemos estado creando los temas via zoom y entre conformidad e inconformidad, se crean los temas.

Y bueno... la razón por la cual publico esta nota, es para mostrarles una pequeña animación (Cortesia de un GIF hecho por Magia Lista tiempo atrás) para la secuencia de escape, que fue, una sugerencia despues de haber mostrado el video, espero que les guste.

Saludos y sean pacientes :)



Notas de avances: Importancia en el orden de los codes del drawing

 


Estuve implementando una mecánica de secuencia de conteo regresivo "SIN DEPENDER DE NINGUNA CLASE DE SPRITE" y descubrí cosas interesantes de lo que puedes hacer con los códigos draw_rectangle y draw_text, entre otros codes de personalización de texto y dibujo de formas.

Si bien esta mecánica para mi es UNA MECANICA BASTANTE VIEJA nunca lo implemente debido a que cuando usaba un texto personalizable en algunos objetos, estos cambiaban de forma y de color durante el gameplay, arruinando la estetica configurada del proyecto. (En ocasiones, estos efectos eran permanentes)

Para darles una solucion para mi en su momento fue "NO COLOCAR AMBOS OBJETOS JUNTOS" o sea, que debian de actuar en cuartos independientes o de que no debian estar juntos.

Un ejemplo se puede apreciar en el video publicado en youtube: PROLOGO.

En la primera imagen (Minuto 7:12), despues de la conversacion con Lita,
se ve que el texto de Puntos es blanco por un instante...

... pero cuando abandona el objeto dialogo del room (como el objeto no existe)
este retoma su configuracion original.


Si bien esto ocurre en 1 frame de segundo, aun es estetico, y es notorio para el ojo detallista, sin embargo, experimentando con el code de nuevos menus y de emergencias, la solucion parecia ser mas de ORDEN que de PROGRAMACION.

Normalmente uno escribe el texto primero (draw_text) y despues coloca la configuracion de colores (font_color, font_name, etc) -- Lo cual es completamente erroneo, en primer lugar, antes de escribir un texto o de dibujar una figura, "EL COLOR VA PRIMERO" y despues "EL TEXTO Y/O DIBUJO" -- asi como el orden de los sprites para ver que Depth va por encima del otro en un Draw Event, es de la misma forma con estos textos y formas.

Es bueno saber de los detalles como estos, ya que muchas mecánicas pasaron  a ser Sprite u otros métodos de evasión de objetos por este simple error, ahora que lo he anotado, no necesitaría eliminarlos como tal...

Ahora la pereza de todo esto es "REVISAR UNO A UNO CADA TEXTO Y VER QUE ESTA EN EL ORDEN CORRECTO" [ Que flojera :( ]




Las Entradas populares

Komiteka Code

▼-▲------- Z-X-ENTER