Mostrar Mensajes

Esta sección te permite ver todos los mensajes escritos por este usuario. Ten en cuenta que sólo puedes ver los mensajes escritos en zonas a las que tienes acceso en este momento.

Mensajes - fasst007

31
Preguntas y respuestas / Re:GM:S Android Export Module
Octubre 01, 2015, 06:18:03 PM
Ahí va... lento pero va... tarda más que llegar a marte pero bueno, ya se lanzó el cohete XD.

32
Preguntas y respuestas / Re:¿Pausar animación Sprite?
Octubre 01, 2015, 04:34:04 PM
Te hago unas preguntas:

1) El obj_player ¿siempre avanza de izquierda a derecha? porque si no es así, este código no funcionaría bien cuando se acerca al objeto desde la derecha avanzando hacia la izquierda.

2) A qué te refieres con: "sería más trabajo a largo plazo según cada objeto que le llame la atención."
Porque si te refieres a que hay otros objetos además de "obj_dooralter1" que le llamen la atención entonces creo que la solución (no lo he probado) sería crear un objeto vacío padre llamado "capta_atencion" y definir los múltiples objetos de interés como hijos de este. Luego en el código cambiar  "obj_dooralter1" por "capta_atencion" y listo.

3) Habría que definir un "else" en ese if que inicialice el contador a 0 (cero).
33
Preguntas y respuestas / Re:GM:S Android Export Module
Septiembre 30, 2015, 05:03:47 AM
Tenés razón Penumbra, cuando el manager del SDK quiera conectarse le va a dar error.

Amigo, el SDK de android me ocupa 17 GB en mi máquina y comprimido ocupa 4 GB. Esos 4GB me tardan 14 hs en subirlo con mi conexión de internet. Pero de alguna forma lo voy a subir en estos días asi directamente lo descomprimes en una carpeta. El ndk y el instalador del jdk son chicos asi que lo voy a subir rápido. 
34
Preguntas y respuestas / Re:GM:S Android Export Module
Septiembre 30, 2015, 02:36:54 AM
Haz una prueba... no se si servirá pero inténtalo. Usa el Chrome con la extensión ZenMate que es como un proxy que te da distintas direcciones. Instalas la extensión, simplemente haz clic sobre el icono y en algun lugar hay una especie de switch o perilla (on-off), ya sabes, lo dejas en on y queda activado con direccion IP de Estados Unidos. No se si esto funcionará pero haz la prueba
35
Teniendo en cuenta el problema original de tener un sprite distinto por cada estado, hice un proyecto a las apuradas de forma muy simplificada. Al ejecutar el proyecto aparecen en el room 4 instancias gusano y 2 rectángulos con nombres: "aplastar" y "matar". Estos rectángulos hay que arrastrarlos con el mouse y hacerlos colisionar con las instancias de gusano, al hacer esto el sprite del gusano cambiará con el sprite correspondiente.

La mayoría del código es usado para manejar el arrastrado de esos dos rectángulos y la ubicación de los elementos en el escenario con su inicializaciones correspondientes. Pero el código que cambia los sprites está en el evento colisión del objeto: accion y es una sola línea de código. Esto es un ejemplo para captar la idea.

También hay código en el "Creation Code" del room.
36
y no... porque la idea era evitar los switches porque si por ejemplo tenes 20 elementos tenés que usar 20 cases para el switch para cambiar a un modo, otro switch con otros 20 cases para pasar al otro modo. Y además si agregas elementos al juego tenés que modificar todos los switch. En cambio de esta forma se haría todo con una sola linea de código y no habría que modificarla aún cuando se agregaran elementos lo que sería más fácil, más corto y más genérico que los switch.

La cantidad de sugerencias era para que tenga varias alternativas para enfocar el problema, es mejor dar varias opciones que una sola opción, porque por más que le demos la mejor opción a nuestro criterio quizás para él sea mejor otra. Bueno entonces uno brinda varias ideas, para dar un abanico mayor de posibilidades y que elija, y de paso también le puede servir  a muchas otras personas que entran a leer estos comentarios .
37
Bueno los ejemplos que te pasé tuvieron como fin proporcionarte ideas para que puedas mostrar el sprite de aplastado o muerto correspondiente al gusano sin ni siquiera tener necesidad de saber de que tipo de gusano se trata pudiendo lograr un código genérico que funcione para todos los casos.

Pero si necesitas saber que tipo de sprite tiene asignado el objeto para darle un comportamiento distinto según sea el caso, esto es muy sencillo.

sprite_index guarda el número identificador del sprite que tiene almacenado.

Entonces... hacemos un switch ( o if )preguntando si el número del sprite_index corresponde al spr_gusano01, en ese caso hacemos las acciones que querramos correspondientes a ese tipo de gusano, luego preguntamos por el caso de que si el sprite_index corresponde al spr_gusano02, etc.

¿Cómo sabemos cuál es el número de sprite de spr_gusano01 y de cada sprite? No hace falta saberlo, Game Maker nos la hace fácil, definiendo como una especie de "variable" (para que se entienda) con el mismo nombre que el sprite cuyo valor almacena ese número. Entonces podemos hacer:

if (sprite_index == spr_gusano01)
{
   //realizar las acciones correspondientes
}

el if compara la igualdad con spr_gusano01 sin comillas porque no es una cadena de texto sino esa especie de variable creada por Game Maker con el mismo nombre del sprite que tiene el valor numérico del id de sprite correspondiente.
38
Amplié aún más mi comentario anterior agregando nuevas alternativas (le puse modificar comentario y le agregué cosas) te aviso por si ya leíste mi comentario para que vuelvas a fijarte. Si te funcionó o tienes alguna duda avisame. Saludos!
39
En realidad ni siquiera hace falta que sepas que gusano es para cambiarle el sprite.
Simplemente haz esto:

1) acomoda los nombres de los sprites de forma conveniente.

spr_gusano1, spr_gusano2, spr_gusano3, ..., spr_gusano10
spr_gusano1_muerto, spr_gusano2_muerto, spr_gusano3_muerto, ..., spr_gusano10_muerto
spr_gusano1_aplastado, spr_gusano2_aplastado, spr_gusano3_aplastado, ..., spr_gusano10_aplastado

2) cuando tengas que mostrar el sprite muerto, solo pon esta línea de código:
sprite_index = asset_get_index(sprite_get_name (sprite_index) + "_muerto");

Debería funcionar, no lo probé. La idea es que el nombre del sprite del gusano muerto sea el mismo nombre del sprite que ya tiene pero con el sufijo "_muerto".
Entonces habría que hallar primero el nombre del sprite en texto del objeto gusano para agregarle el sufijo "_muerto", esto se logra con sprite_get_name (sprite_index) siendo sprite_index el número identificador del sprite, al pasárselo a esta función devuelve su nombre en texto. Luego de esto le agregamos el sufijo. Con esto tenemos el nombre en texto del sprite que debería tener el gusano, ahora falta hacer la operación inversa, es decir, obtener el número identificador del sprite que corresponda a ese nombre en texto que generamos. Esto se logra con la función asset_get_index() y por último almacenamos ese numero en el sprite_index y ¡listo!

De esta forma podés agregar la cantidad de gusanos que quieras y no tendrías que alterar el código porque funcionaría igual, siempre y cuando respetes la convención de nombres de los sprites, que el sprite correspondiente a la muerte sea el mismo nombre pero con el sufijo "_muerto" (o el que quieras porsupuesto)

3) cuando tengas que mostrar el sprite aplastado, haz lo mismo pero con el sufijo correspondiente:
sprite_index = asset_get_index(sprite_get_name (sprite_index) + "_aplastado");


Nota:
No se las transiciones que hay entre los estados del gusano. Porque si primero es aplastado y después muerto, vas a tener que hacer unas modificaciones en el código o en los nombres de los sprites. Porque primero va genial de spr_gusano5 a spr_gusano5_aplastado pero si luego muere va a quedar el nombre como spr_gusano5_aplastado_muerto en lugar de spr_gusano5_muerto. Podrías pensar en poner los nombres de los sprites de muerte con el sufijo: _aplastado_muerto para que cuando sea aplastado le agregue "_aplastado" y cuando esté muerto le agregue "_muerto" quedando perfecto pero el problema es ¿que pasa si el gusano muere directamente con un disparo de llama del mario bros sin ser aplastado antes? pasaría del estado normal a muerto directamente y no funcionaría el código.
Aclaro esto porque hay que tener en cuenta todo, y este código que te pasé es solo para transmitir la idea pero hay que hacerle modificaciones para que ande en tu juego. Conceptualmente lo correcto sería dejar los nombres de los sprites con un solo sufijo, es decir, el nombre del sprite mas el guión bajo seguido del nombre del estado, como esto:

spr_gusano01_normal, spr_gusano02_normal, spr_gusano99_normal
spr_gusano01_muerto, spr_gusano02_muerto, spr_gusano99_muerto
spr_gusano01_aplastado, spr_gusano02_aplastado, spr_gusano99_aplastado


hice la modificación de rellenar con un cero los gusanos de una sola cifra, es decir, gusano01 en lugar de gusano1 para que todos estos nombres antes del sufijo tengan el mismo tamaño de caracteres. Entonces a la hora de cambiarle el sufijo habria que copiar los primeros 13 caracteres de la cadena (con alguna función de manejo de cadena de texto) y agregarle el sufijo que queramos después y por último convertir esto a índice.

quedando así para el caso de muerte:

sprite_index = asset_get_index(string_copy(sprite_get_name(sprite_index),1,13) + "muerto");

y así cuando es aplastado:

sprite_index = asset_get_index(string_copy(sprite_get_name(sprite_index),1,13) + "aplastado");

y de esta forma si muere directo, o si es aplastado antes no importa, porque cambia el sufijo en lugar de agregarlo funcionando para todos los casos.


Todo lo anterior es para evitar un gran switch de este tipo:

switch(sprite_index)
{
case gusano01:
  //acciones para cambiar al sprite correspondiente
  break;
case gusano02:
  //acciones para cambiar al sprite correspondiente
  break;
case gusano03:
  //acciones para cambiar al sprite correspondiente
  break;
case gusano04:
  //acciones para cambiar al sprite correspondiente
  break;
case gusano05:
  //acciones para cambiar al sprite correspondiente
  break;
case gusano06:
  //acciones para cambiar al sprite correspondiente
  break;
case gusano07:
  //acciones para cambiar al sprite correspondiente
  break;
case gusano08:
  //acciones para cambiar al sprite correspondiente
  break;
case gusano09:
  //acciones para cambiar al sprite correspondiente
  break;
case gusano10:
  //acciones para cambiar al sprite correspondiente
  break;
}

y un switch así para la muerte y otro para cuando es aplastado, es muy ineficiente y poco elegante. Encima habría que modificarlo cada vez que se agregue un nuevo tipo de gusano. Por eso doy la idea de poner los nombres de los sprites de forma conveniente para que con una línea de código tengas la solución genérica que te servirá para la cantidad de tipos de gusanos que quieras.

Por último:
Si los sprites de los gusanos son estáticos y no hay ningún sprite animado la cosa es aún más simple. En la posición cero del sprite ponés la imagen del gusano en su estado normal, en la posición 1 la imagen del gusano aplastado y en la posición 2 la imagen del gusano muerto. En el objeto pones: "image_speed = 0". Y luego cuando el gusano es aplastado simplemente poner: image_index = 1 y cuando muere: image_index = 2.

Con la lógica anterior podrías hacerlo con sprites animados pero haciendo unas modificaciones.Supongamos que en el modo normal todos los gusanos muestren su correspondiente sprite de animación de 5 sub-imágenes (pero aunque las imágenes son distintas todos con la misma cantidad de cuadros de animación). El sprite aplastado y muerto sean sprite simples de una sola imagen. Entonces haz esto:

1) usa un solo sprite para cada tipo de gusano que reúna todas las fases de su vida (normal, aplastado y muerto).
1) De la posición "0" a la posición "4" pon la secuencia de animación del modo normal
2) En la posición 5 pon cualquier imagen, si quieres transparente, porque esta subimagen no se va a mostrar nunca simplemente va a servir como bandera para decir que ya terminó la animación y hay que volver a la subimagen cero, por
lo tanto jamás se dibujará esta subimagen.
3) en la posición 6 pon la imagen del gusano aplastado
4) en la posición 7 pon la imagen del gusano muerto

en el evento "step" del objeto gusano pon:

if (image_index == 5)
     image_index = 0;


esto hará que se muestre la animación cíclica de las subimágenes 0,1,2,3 y 4.

cuando es aplastado:
image_speed = 0; //para que muestre una imagen fija
image_index = 6; //que es la imagen del gusano aplastado


cuando muere:
image_speed = 0; //para que muestre una imagen fija
image_index = 7; //que es la imagen del gusano muerto










40
Preguntas y respuestas / Re:Girar view
Septiembre 19, 2015, 03:57:54 PM
Es que es con view_angle la forma en que lo debes hacer, si no te funciona quizás hay algo mal en el código.
Mira te hice un proyecto de ejemplo donde giro un view con las teclas <-  y  -> (izquierda y derecha)
41
Preguntas y respuestas / Re:Problema con este script
Septiembre 19, 2015, 05:55:48 AM
El código está bien. Lo que debes hacer es poner en el evento "create" del objeto perseguidor:

//variables
enemyspeed = 4;
aggrorange = 100;


y en el evento "step" del mismo objeto (perseguidor)

var dis = point_distance(x,y,object26.x,object26.y)

if (dis <= aggrorange){
    mp_potential_step(object26.x,object26.y,enemyspeed,true);
}


yo te hice un archivo fuente con el ejemplo que funciona lo único que cambié los nombres de los objetos, uno se llama "perseguidor" y el otro "perseguido", cambié la distancia necesaria para que empiece a seguir: "300 pixel".
En este ejemplo deberás mover el objeto perseguido cerca del perseguidor para corroborar si efectivamente empieza a seguirlo. El objeto perseguido se mueve moviendo el puntero del mouse ya que se ajusta a la posición del puntero, y acércalo al otro objeto y verás que lo sigue
42
Creo que te convendría poner en el evento "create" del obj_enemigo esta línea de código:
salud = 100;

Entonces cada instancia del objeto enemigo maneja su propia salud. Un enemigo puede haber recibido daño y tener su salud en 40 otro que no recibió daños en 100 y otro en 15, etc.

Cuando su salud llega a 0 que se destruya esa instancia con: instance_destroy(); y luego de ello verifique si quedó alguna instancia más en el room ,en caso de que no haya más que pase de nivel. Esto se verifica con if (instance_number(obj_enemigo) == 0)


Pero respondiendo a tu pregunta, deberías poner en el inicio del room: global.salud = 0; y luego en el evento create de obj_enemigo pon: global.vida += 100;


43
Si sos muy principiante en la creación de juegos quizás debas probar con un programa para crear juegos RPG que te deja todo mucho más fácil. El programa se llama RPG Maker, podés buscarlo, hay miles de videos en internet y materiales.
44
Preguntas y respuestas / Re:Moverse por camino
Agosto 13, 2015, 05:50:25 AM
Amigo, estuve buscando una solución a tu planteo y he dado gratamente con funciones incorporadas de Game Maker que facilitan enormemente esta labor. Asi que a usar el traductor de google  XD para entender la ayuda de esas funciones pude hacerte un ejemplo que funciona el cual lo adjunto en este mismo mensaje.

Te digo cual es la idea del asunto. Si te fijas bien esa imagen está compuesta por circulos que están a la misma distancia tanto vertical como horizontal, como si esto estuviera alineado con respecto a una cuadrícula que en Game Maker suelen llamar "Grid".

Entonces lo que debes hacer es abrir la ventana de diseño del room y definir una cuadrícula (entra al room del ejemplo que te adjunto y mira). Los círculos donde el personaje puede detenerse deben estar dentro de un cuadrito de dicha cuadrícula. Debes definir un sprite que ocupe un cuadrito entero que se llame "pared", con ese objeto delimita el camino como te puedes fijar en el archivo que te pase.

Cree un objeto origen que es el objeto que deberá caminar (hice un simple cuadrito para simplificar) y otro objeto destino que es invisible y es el lugar donde debe ir nuestro personaje.

Ojo: El objeto real que va a ser el que camina por esos caminos no va a ser un simple cuadrito sino un personaje más grande, entonces debes hacerle la máscara de colisión igual que el cuadrito, porque sino estaría atravesando la pared delimitadora y calculo que no funcionaria.

Dentro del objeto origen tenés todo el código para que el objeto se dirija a donde quieres que vaya y busque el camino por sí mismo.

este es el código:

globalvar cuadricula;

tam = 43;
cuadricula = mp_grid_create(0, 0, floor(room_width/tam), floor(room_height/tam), tam, tam);
mp_grid_add_instances (cuadricula, pared, false);

camino = path_add();

if mp_grid_path(cuadricula, camino, x, y, destino.x, destino.y, 0)
    path_start(camino, 5, 0, 0);


Si bien en el diseño del room definimos una cuadrícula para alinear los objetos, esa cuadrícula era solo para ayudar al diseño del room y sin existencia real en el juego. Ahora deberemos crear un recurso de game maker que es equivalente a la cuadrícula del diseño del room pero en memoria, para hacer cálculos.

la creación del mismo se hace con mp_grid_create(), en este caso definí que esa cuadrícula comience desde la posición 0,0 del room, es decir sin desplazamiento, desde el inicio.
el tercer y cuarto campo indica que tamaño tiene esa cuadrícula en cantidad de cuadritos horizontales y verticales respectivamente. Yo puse lo que entre en el room, por eso dividí el room por el tamaño de un cuadrito y al resultado de la división le trunqué los decimales porque necesito un número entero. Los últimos dos campos indican el tamaño en ancho y alto de cada cuadrito de esa cuadrícula.

Esta otra línea de código:
mp_grid_add_instances (cuadricula, pared, false);

lo que significa es que busque todos los objetos "pared" que hay en este room, se fije en que cuadrito estaría y que defina ese cuadrito como límite infranqueable, como lo es la pared.

luego se crea un path nuevo y vacío que va a ser usado por una función que usaremos después que le cargará los datos del camino a recorrer.

esta es la función de la que hablaba:
mp_grid_path(cuadricula, camino, x, y, destino.x, destino.y, 0)

esto quiere decir: buscá un camino usando la cuadrícula (la cual ya definimos los límites u obstáculos que son los objetos pared), el itinerario encontrado guardalo en el path llamado camino, y el camino a buscar es el que se origina en x,y de esta instancia que ejecuta esté código y el que termina en las coordenadas x,y del objeto llamado destino, y el campo cero del último quiere decir: no usés caminos diagonales (es decir, usá movimientos horizontales o verticales solamente)

Esta función esta siendo usada en un if porque si encuentra el camino devuelve true y si no lo encuentra devuelve false. Entonces si encuentra el camino entra a esta otra línea:

path_start(camino, 5, 0, 0);

que quiere decir: empezá a recorrer el camino encontrado a una velocidad de 5 pixel por step, cuando termines el recorrido detente (valor 0 del tercer argumento) y usa el path relativo a mi propia posición.

Acá está la ayuda de las funciones que usé:

http://docs.yoyogames.com/source/dadiospice/002_reference/movement%20and%20collisions/motion%20planning/mp_grid_create.html

http://docs.yoyogames.com/source/dadiospice/002_reference/movement%20and%20collisions/motion%20planning/mp_grid_path.html

http://docs.yoyogames.com/source/dadiospice/002_reference/paths/path_start.html

cualquier duda consultame. Saludos!
45
Preguntas y respuestas / Re:Problema con redondeo
Agosto 11, 2015, 02:50:04 PM
Buen dato! entonces mucho mejor, porque el uso de abs() te simplifica mucho las cosas y te ahorrarías de hacer código casero. Claro yo estoy acostumbrado a un lenguaje compilado donde en ese caso sería mucho más rápido dos o tres if que un llamado a función y en game maker solo tengo un mes de experiencia XD y olvidaba que es interpretado.