Comunidad Game Maker

Yo soy novato y apenas estoy con mi primer proyecto, todavía no llego a esa parte, pero necesitaré algo parecido a lo que tu quieres, para el sistema de inventario.

Tendrías que usar arreglos o listas. Nunca he usado listas, así que yo lo haría con arreglos. Cada fila del arreglo equivaldría a una carta. Una columna del arreglo indicaría el ataque, otra el nombre, otra el tipo, etc.

Habría que crear un script que fuera capaz de ordenar alfabéticamente dos palabras, comparando letra por letra, para saber qué nombre va primero y cuál después. También habría que comparar por nivel de ataque, pero eso es sencillo, con '>', '==', '<', etc. Posiblemente "recorrerías" las columnas del arreglo con ciclos for.

Seguro alquien con más conocimiento da una solución detallada, y nos aclara el panorama XD

Mmm... no es por eso.

Esas calaveras (a veces tortugas) aparecen cuando GMS detecta que tienes una copia crackeada (archivo ejecutable modificado). Eso pasó cuando actualizaste el programa, el servidor de Yoyo te agregó a su "lista negra" y 'la marca fatídica' son esas calaveras o tortugas.

O bien, si tu GM:S no es una versión crackeada, aun así puede suceder lo mismo. Este error se ha reportado en YoYo, por parte de usuarios con copia legal, al parecer ciertos antivirus podrían modificar el ejecutable.

Como posible solución, tienes que desinstalar GM:S, después ir a tu carpeta de usuario c:\Users\Tu_nombre_de_usuario\

En esa carpeta, hay dos subdirectorios, el appdata y localappdata, dentro de ambas carpetas, hay otra llamada GameMaker-Studio, tienes que borrar esa carpeta (en ambas locaciones)

Después, abrir el editor del registro, buscar la clave 'GameMaker-Studio' y borrarla (puede haber más de una clave, el chiste es que no queden rastros del Studio en el registro, dale matarile a todas). Por último, reinstalar el programa.

Si no funciona lo anterior, apunta tu licencia y contacta al equipo de soporte de GM:S para que te reactiven tu copia.

Suerte  8)

Eso quiere decir que tu PC no tiene instalado el códec adecuado para reproducir archivos xvid.  Pudes instalar o el códec individual

http://www.digital-digest.com/software/download.php?sid=1052&ssid=0&did=1

o el famoso paquete K-Lite con los códecs más populares y usados

http://codecguide.com/download_kl.htm

Tienes que poner alguna condición antes de revisar la tecla de salto, por ejemplo, si hay colisión contra el suelo, o si gravity = 0, o tal vez si la subimagen es menor a 1 o 2

Hay más de una solución

Creo que es así

if keyboard_check(ord('X'))


Esta es la manera en que yo lo hago, obviamente hay más formas de conseguirlo.


//Código para el evento END_STEP:
if keyboard_check(vk_down) and (taire < 1)
{
    activa_sprite(inclina, 0.55)
    if image_index >= 15  image_index = 15
}

//Reproducir la segunda parte de la animación cuando el jugador suelta la tecla flecha hacia abajo
if keyboard_check_released(vk_down) and ttierra > 0
{
    image_index = 16
    activa_sprite(inclina, 0.5)


Explicación: Mi sprite con la animación del personaje agachado tiene alrededor de 30 subimágenes, las primeras 15 son para el movimiento de agacharse. La imagen 14 (el índice comienza en 0) es la imagen del personaje agachado, que es la imagen que se despliega mientras el usuario esté presionando la tecla de agacharse. Al soltar la tecla, se usa el mismo sprite, pero a partir de la imagen 16 >17>18, etc, para mostrar la animación de cómo se pone de pie, después de estar agachado.

taire y ttierra
son variables que indican el número de pasos (tiempo)que el jugador está en el aire o en tierra. CUando una de las variables es mayor o igual la uno, la otra obviamente es cero. Las uso para muchas cosas, en este caso  para evitar que la animación de agacharse se active si se presiona la tecla de flecha hacia abajo mientras el personaje está en el aire

activa sprite (nombre del sprite, velocidad de animación)
es un sencillo script para llamar al sprite que quieres desplegar, lo hice para no tener que estar escribiendo "sprite_index" e "image_speed" tan seguido. El script se ve así:

image_speed = argument1
sprite_index = argument0


Seguramente vas a tener que usar una velocidad de animación distinta a la que uso, para tus sprites; es cosa de que juegues con los valores. A ver si de algo te sirve el ejemplo.

Aplaudo tu iniciativa y el ánimo sincero, en serio, pero le veo poco futuro a tu idea. Lo underground  es underground precísamente mientras no llegue a  todos o la mayoría de los hogares. En el caso de que pudieras crear un prototipo de esa consola (lo cual lo veo prácticamente imposible por más de una razón), el costo sería muy elevado, no se podría comercializar. He realizado uno que otro proyecto de electrónica, y casi siempre te encuentras con la noticia de que los chinos ya producen lo mismo (EN MASA), y que comprarlo te sale en la mitad de lo que invertiste en los materiales

Aun así, pensemos que ya están las consolas empaquetadas y listas para venderse. Cuántos compradores en potencia ya tendrían en su casa una PC o Laptop? Yo pienso que la mayoría. Eso nos lleva a la pregunta "Si ya tengo una PC para jugar juegos de GM, para qué quiero gastar en una consola que hace lo mismo?

Una consola actual, que no ofrezca gráficos de última generación en 3D, se me hace impensable. Sería casi un objeto decorativo. Imagínate al típico chaval de 10 años, al que le pones enfrente una Playstation y la Fenris78, ¿cuál eligiría jugar? Seamos sinceros, la potencia 3D de GM no es competencia ni para el Nintendo 64

Texic tiene razón. NO hay mercado para el 2D en consolas (no hablo de ipods, ni iphones, etc).  Yo no compraría una consola para jugar juegos en Flash. Aun en el caso de tener una consola "potente", tienes que acompañarla de un número elevado de juegos, y no solamente juegos BUENOS, sino LARGOS. ¿Cuánto tiempo en promedio, se necesita para terminar un juego de GM? Al mes de comprar la Fenris 78, el jugador promedio ya se habría terminado todos los juegos decentes que hay para GM.

Yo creo que las incompatibilidades que quieres evitar, seguirán siendo el pan nuestro de cada día. El control sobre las actualizaciones y apariciones de más plataformas y Sistemas operativos, está fuera del alcance de los programadores indies. Incluso, las grandes casas de videojuegos, desarrollan para distintas consolas a la vez. A mi manera de ver, es mejor preocuparse por hacer un juego bueno, para una sola plataforma (PC, en mi caso) que querer abarcar todas las plataformas.

Los videojugadores somos una especie difícil de educar. La mayoría se deja llevar por las tendencias actuales. Todos defienden a capa y espada sus preferencias; lo que le gusta a uno, el otro lo odia. La verdad es que posiblemente, "allá afuera", la gran mayoría piensa que el 2D está muerto  XD

El detalle es que usas GM Studio, y creo que la mayoría de los usuarios del foro aun somos fieles a GM8.1. La mayoría, o muchos,  no podemos abrir tu proyecto. Como ya han mencionado otros miembros, GM Studio es relativamente nuevo y aun no está depurado al 100%, además la versión gratuita está bastante limitada.

Sí, algo así como la idea de 3dgeminis. Para ciertos juegos, lo antinatural es que no se pueda cambiar de dirección en el aire. Es más, me vienen a la mente más juegos que permiten cambio de dirección en el aire, que juegos que no lo permiten.

Yo todavía no me meto a asuntos de resoluciones. En algún lado (creo que en YoYo) leí de casos donde los usuarios tenían problemas de 'blur' o interpolación de pixeles cuando escalaban a 2x, y esos mismos usuarios reportaban mejora o solución total cuando escalaban su pantalla en factores de 1.5x o 3x

Tambien recuerdo haber leído que nos e recomienda usar la función fullscreen que viene el las opciones globales del juego, sino manualmente desarrollar tu propia función de escalado a pantalla completa.

Más sencillo que un timer o agregar una variable extra, es usar el evento "Animation end", que se encuentra dentro de la categoría "otros". Ahí pondrías algo como

if sprite_index == animación_de_salto
{
    image_index = 0                                           //Esto para asegurarse que la animación nueva comience desde el principio
    sprite_index = animacion_de_aterrizaje
}


Obviamente, tu juego debe estar bien sincronizado para que la animación de salto termine justo al tocar el suelo. Yo tambien manejo una animación de aterrizaje en mi proyecto, aunque no uso animation end, pero el resultado es similar.

En mi juego. en ciertos cambios de animación, la nueva animación empieza en el mismo número de subimagen donde se quedó la animación anterior, lo cual no es lo que quiero,  por eso el uso de image_index = 0

Ya veo lo que te pasa.

Desconozco si hay una función en GM que automáticamente devuleva la dirección dependiendo de las teclas que pulses (y su duración), si no existe, tienes que crear una para definir el ángulo con el que dispara el jugador. Tal vez ya tengas ese script, no lo sé, pero que la vista sea top-down ayuda a simplificar las cosas.

Me parece que lo más fácil es usar "tramposamente" la gravedad, para hacer que el balon avance poco a poco al punto de destino. Supongamos que tenemos la variable "angulo" (ángul ode disparo) y "límite" (límite de velocidad para el balón)


other.graviy = 3                                                 //Defines un valor adecuado para la velocidad del disparo
other.gravity_direction = angulo                       //La dirección del disparo según las teclas presionadas
if (vspeed > limite) or (hspeed > limite)             //Evitar que...
{
vspeed = limite                                                  //el balón adquiera velocidades...
hspeed = limite                                                 //exageradas como en "Los supercampeones"xD
}


Creo que también se pueden usar estas funciones si no deseas usar la gravedad para mover el balón (yo nuca las he usado hasta ahora)

motion_set(dir,speed) Sets the motion with the given speed in direction dir.
motion_add(dir,speed) Adds the motion to the current motion (as a vector addition).


Hay que frenar el movimiento del balón poco a poco, para simular un tiro real

if (vspeed > 0) or (hspeed > 0)
{
         vspeed -= friccion                       //Ajusta friccion a un valor conveniente, según tus necesidades
         hspeed -= friccion
}


¿Funciona? Quién sabe  ;D

No sé si esto es lo que deseas hacer:

Suponiendo que tienes un objeto llamado "pelota" y quieres que el objeto "jugador" modifique el movimiento del objeto "pelota". En el evento STEP de "jugador" escribes

pelota.x += valor_deseado1
pelota.y +=  valor_deseado2

Obviamente, eso debe ocurrir sólamente cuando el jugador golpea a la pelota, es decir, cuando hay una colisión de la pierna del jugador con el objeto pelota.

No tengo mucha experiencia, a ver si alguien más ducho nos aclara esto, pero hasta donde sé, una vez que pones código en el evento Draw del objeto "A", GM te obliga a que todas las rutinas o funciones que tengan que ver con dibujo en pantalla, las manejes en draw (es decir, que las saques de STEP). Por eso tienes que usar draw_sprite_ext para dibujar en DRAW

Aquí es donde es útil usar un objeto controlador para el juego, digamos objeto "B", el cual no tiene asociado ningun sprite. Este nuevo objeto se encargará de desplegar ese marcador (piensa que el marcador es algo más global o general para tu juego, y no debe ser manejado por "A"). Así que el controlador dibuja (en DRAW) el score, y te permite seguir usando funciones de dibujo 'más locales' en el evento STEP de "A". Obviamente el objeto controlador puede encargarse de otras tareas relacionadas con otros objetos que tengas en tu juego. No sé si me expliqué bien o si estoy en lo correcto, pero de momento eso me ha funcionado a mi

OK, estás usando el libro de game maker apprentice, entonces puedes revisar esta página. Son videotutoriales cortos muy bien explicados.

http://wizirdi.com/en/gml-beginner-tutorials/