Comunidad Game Maker

Ah, no había visto el video. Pensé que los bloques caían a más velocidad, y en línea recta. Más bien casi van flotando y se mueven en diagonal. No sé cómo muevas los bloques, pero yo probaría que cuando haya una colisión contra lo que sea (se puede usar un objeto padre para englobar todos los cuerpos con los que chocar), cambiar la dirección de movimiento (ángulo, o vspeed + hspeed, o +x y +y) dependiendo de la posición de un bloque respecto a otro.

Bueno, no sé de qué va tu juego, pero esto suena como un trabajo para el sistema de físicas Box2D de GM:S. Deberías hecharle un vistazo al tutorial de shooter que incluye el GM:S, aunque tendrías que reescribir todo desde cero, pues ahí no se pueden usar eventos de colisión, ni vspeed, ni gravity, etc etc.

Muchas gracias, luckylandia. Se hace lo que se puede, nada del otro mundo  :)

Para saber si el rectángulo de colisión este bien definido es necesario saber cómo tienes configurado el origen del sprite. Tal como está, se supone que el origen del sprite está ubicado en la esquina superior izquierda del objeto bloque.

Makero Marth, el proyecto que subiste está vacío, ya me parecía raro que sólo pesara 1.82 Kb. No contiene ni sprites, ni rooms, ni objetos. Me da curiosidad ver qué hiciste con este mario clasificación C

Creo que ese es efectivamente el código del manual, y está mal, yo me saqué de onda cuando lo vi, de hecho, no es el primer ni el segundo error que me encuentro en el manual de GM:S.

Mdiante la función collision_rectangle creas una "ventana" (zona) en la habitación basada en las coordenadas de la instancia desde donde se usa. Si al menos un pixel de la máscara del objeto que especificas en la función entra dentro de esa ventana, la función devuelve el id de esa instancia. SI no hay colisión con instancia del objeto especificado, devuelve un número negativo.

Probablemente funcione ya que es la que más se adecua a la forma de un bloque.

Yo he buscado una dll o extensión que cargue las páginas, pero no he tenido suerte. Veo difícil que esta característica se incluya en GM:S. Ni siquiera los juegos AAA tienen algo así, si alguno da información web, se abre una ventana del navegador aparte, que es como funciona ahoram y que debe ser la opción más sencilla pensando que GM:S es multiplataforma.

Qué tal, comunidad.

Pongo a disposición de los interesados (si los hubiera) mis servicios como spriter. Me enfoco sobre todo en pixel art, pero si requieren otro estilo, también se puede pedir. Lo ideal es que para comenzar a trabajar se me facilite un boceto o una idea inicial que me permita tener una referencia de lo que quieres. En caso de no contar con un boceto, por favor dame detalles y precisiones de qué buscas en el diseño.

Una muestra de mis últimos sprites. Hubiera preferido no poner marca de agua en los tres primeros sprites, pero están siendo usados en un juego y el programador me ha pedido que fueran exclusivos.








http://romanticpixels.deviantart.com/gallery/

Costo: La verdad, es que el precio puede variar bastante, depende del tamaño del sprite, el número de subimágenes, el tema del sprite y el nivel de detalle deseado. Tratándose de sprites animados, el precio varía de 6 - 20 dólares. Para sprites estáticos, el precio varía de 3 - 5 dólares. Si necesitas un pack de sprites (4 o más) podemos acordar el precio (animados o estáticos o una mezcla)

Pago: El método de pago es por Paypal, con un anticipo del 50% al solicitar el trabajo y el otro 50% antes de la entrega del mismo (envío los sprites a tu cuenta de correo)

Sé responsable y serio al solicitar algo, yo ofrezco lo mismo.

Yo no tengo el módulo android, así que no puedo hacer pruebas, pero ¿por qué no usar posiciones relativas en lugar de absolutas?

Suponiendo que la posición de uin boton sea (200, 180), y la resolución 1024X768 y que quieres mantener una posición proporcional en cualquier dispositivo.

200/1024 = 0.195, redondeado sería un 20%
180/768 = 0.234, redondeado sería 24%

Entonces, en lugar de especificar una posición fija para el botón (lo que que no permite adecuarla al dispositivo), se usaría algo así (no sé si sean las funciones correctas, pero la idea se entiende)

xx = display_get_width() * 0.20   
yy = display_get_height()* 0.24

o

xx = 0.20 * display_get_gui_width();
yy = 0.24* display_get_gui_height();

Y estas serían las coordenadas que se usarían para posicionar el botón según la resolución que maneje el dispositivo. Repito, no puedo probar esto, pero creo que debería funcionar así, o con ligeras modificaciones.

Es que no es 1.2 Studio. Es Studio 1.2. Studio vino después que GM 8.1

Si ya pagaste por Studio, tu licencia se mantiene y obviamente tienes derecho a actualizar. Claro, esto mientras YoYo no saque algo distinto a Studio y quiera volver a cobrar por algo "más nuevo".  :D

Cita de: LowHertzs en Abril 27, 2014, 03:12:09 AM
Que podría ser? saludos~

Por sí solo, el código no tiene nada e malo (es una simple resta). Hablas de que al tocar a un enemigo, a la variable se le resta uno. Suponiendo que el código esté en un evento de colisión, cuando éste contacto ocurre, GM resta 1, tal como indica el código, pero al siguiente paso (ocurren muchos pasos en una fracción de segundo) lo más probable es que todavía el enemigo esté haciendo contacto, por lo que se vuelve a ejecutar el código, y al siguiente paso, probablemente haya colision, y así...

Seguro habrás notado que en michos juegos, una vez que tocan al jugador, hay un momento corto en el que el jugador queda en estado invencible, en el cual no lo afectan otros contactos. Obvio esto es temporal y dura 1, 2 o 3 segundos y luego el jugador vuelve a admitir daño. Puedes usar una variable y una alarma, la primera para saber si se permite restar vida (dañar) al jugador, la segunda para controlar el tiempo que el jugador dura en modo invencible y luego restablecer la variable que permite hacer daño

Ojalá te escuche el staff. Yo pedí lo mismo hace mucho y no pasó nada  :)

Cita de: Killer en Abril 26, 2014, 12:24:24 AM
view_surface_id[n] desactiva el dibujado de la view elegida, por eso si lo usas con la view 0, que es la view usada por defecto para dibujar la pantalla y tratas de dibujarlo en un evento draw normal solo aparece un cuadro negro, mientras que Draw GUI no depende de views para dibujarse.

¡¡Cierto!! Y ahora que veo, el mismo manual lo dice, esa vista no se dibuja en pantalla, y tienes dos opciones, usar draw gui o usar exclusivamente otra vista para dibujar la surface (Se cachetea a si mismo)XD

Gracias, Killer. Todos los días se aprende algo nuevo

es bastante sencillo. Debes usar vistas, suponiendo que usas la vista 0

Creas una superficie en CREATE del obj controlador
mi_superficie = surface_create(view_wport[0], view_hview[0])

En DRAW ocurre la magia, la función que dibuja la vista en la siperficie.
view_surface_id[0] = mi_superficie;

en el evento [Draw GUI]
if surface_exists(mi_superficie)
   {
   draw_surface(mi_surf, 0, 0);
   }

Lo que no sé y no entiendo es por qué la superficie se debe dibujar precísamente en elvento DRAW GUI. Si se dibuja en otro evento DRAW no aparece (se ve todo negro). Pero de que funciona, funciona.