Comunidad Game Maker

BUeno, trataré de responder a la pregunta original, lo mejor posible que mi novatez lo permita.

El 90% de las veces, IA significa la manera en que se mueve el mono/nave/enemigo, etc

Esto quiere decir que desas programar el movimiento para que responda sin la intervención directa del usuario. O sea, que vas a manipular las variables 'x' y 'y' del objeto en cuestión.

en GML, el objeto se mueve cuando le sumas o le restas unidades a su posición, es decir, a sus variables 'x' / 'y'. Ahora, un script 100% a la medida, no creo que te llegue caído del cielo. ¿POr qué? Bueno, principalmente
porque no especificas cómo se comportará la nave, ni si harás un shooter horizontal o con vista cenital. Alguien pensará en hacer que la nave se mueva de lado a lado, otro más de arriba a abajo, otro más en zig zag, otro que persiga a la nave protagonista o que dispare de tal o cual forma.

Volviendo a la pregunta original, el objetivo principal es controlar las variables x y y de manera "inteligente". De entrada tienes que tener el objeto que representa tu nave y el objeto para la nave enemiga. La nave enemiga tiene que saber la distancia y la dirección donde está la nave protagonista. Para eso usarías funciones como

point_distance
point_direction


cuando sepas esos datos, querrás mover la nave de alguna manera (no especificada). Es decir, llega el momento de sumarle o restarle unidades a alguna o ambas variables x e y, de tal manera que la nave enemiga se vaya aproximando o alejando a la posición de la nave protagonista. point direction devuelve el valor del ángulo de la trayectoria recta, jugando con ese ángulo, puedes conseguir variaciones en la trayectoria de la nave. Después de mover la nave, debes saber si ya se alcanzó la posición deseada o si hay que seguir moviendose en la misma dirección o hay que cambiar la dirección, etc, etc.

Una IA falsa o tramposa pudiera hacerse guardando pares de valores para x e y en un arreglo, de tal manera que esos pares definan el movimiento de la nave, dando la impresión que se controla por sí sola. PAra que no se sienta tan mecanizada dicha trayectoria, puedes aleatorizar los valores de la tabla dentro de cierto rango, o modificar el giro de la nave, etc.

Esto sería un ejemplo muy rústico de IA.

Saludos.

Las D&D funcionan, pero no son tan flexibles como el código. D&D es como una sopa intantánea y GML es como una sopa casera. D&D es como una calculadora con las 4 funciones básicas y GML es una calculadora científica.

Los ejemplos que he puesto son muy burdos, pero se entiende el sentido, espero.

En muchos foros es común ver que los usuarios tienen problemas con el aterrizaje o posicionamiento de su personaje contra el suelo (como que el personaje queda "flotando" un piexel por encima del piso, por ejemplo); o que en ciertas paredes o esquinas se quedan atorados. Eso EN OCASIONES se debe a la manera en que las D&D (las encargadas de revisar colisiones) actúan. Usando GML hay muchas maneras de resolver o controlar  dichas colisiones, usando D&D hay una o dos y párale de contar (y no siempre es satisfactorio al 100% el resultado).

En pocas palabras y generalizando para efectos prácticos, D&D ofrece una solución genérica y GML ofrece soluciones personalizadas, el costo es un poquito más de complejidad

Me olvidé por completo de Flash (voy poco con los gráficos vectoriales). Posiblemente sí se pueda hacer el esqueleto en Flash.

Si has hecho php y html, sería cuestión de días o semanas para que comprendieras el GML. Puedes hacer totalmente tu juego en D&D, aunque veo que tienes la intención de en algún momento comercializar tus creaciones. De existir, creo que han de ser verdaderamente escasos los juegos comerciales realizados íntegramente con D&D.

Es cuestión de que comiences a jugar con el GM:S para que en algún punto caigas en la cuenta de que necesitas del códgo. GML es tu amigo  8)

4. Aquí puedes ver las limitaciones que tiene la versión libre de GMStudio
http://www.yoyogames.com/gamemaker/studio/free
Soy un novato en esto del GM, Yo no compraría ninguna versión de Studio, hasta que fuera un gurú de GM, si acaso compraría la Standard, para quitar las restricciones básicas. Mejor me espero a ver si el año que entra, CGM realiza un concurso donde se premie con licencias de GM:Studio  8) jojojojo
De momento me quedo con la versión libre de GM8.1 y espero a que salga la versión 9 el año que entra, posiblemente compre esa.

5. No lo sé, pero apostaría a que la única manera (sin usar ingeniería inversa) de eliminar esa pantalla de inicio y el logo de GM:S es pagar  :-[

6. Aparte de las incompatibilidades técnicas que describe Texic, esa flexibilidad cuesta 500 dlls para comprar la versión Máster, o individualmente comprar la(s) licencia(s) para exportar a Android (200 dlls), HTML5(100 dllls) e iOS (otros 200 dlls).

10. GM sólamente carga la habitación actual, pero al abandonarla y pasar a otra nueva, las instancias que usaste permanecen latentes, por lo que tienes que destruirlas si ya no las vas a usar, o a la larga experimentarás sobrecargas

12. No entiendo bien tu pregunta. Te refieres a controlar libremente un esqueleto interno para hacer poses, y cada pose guardarla en un frame o imagen? No creo que eso se pueda hacer en los editores 2D, solamente en un programa como Blender, Maya o Max, para lo que tendrías que armar el modelo 3D del esqueleto y crearle su respectivo 'rig' o armazón. También te iba a realizar la recomendación de Texic. Spriter es buen programa

las D&D es el sistema de arrastrar y soltar acciones, para programar tu juego sin tener que usar código en GML
Saludos

Una vez que tienes la versión de paga, eres libre de vender tus juegos como quieras. YoYo no pide comisión alguna alguna. Igual puedes vender un juego hecho con la versión gratuita, pero tus compradores verían el logo del GM:S siempre... no creo que quieras eso ;D

1. Tengo entendido que no se pueden usar esas comparaciones con operadores lógicos en la estructura CASE, únicamente puedes comparar contra un solo valor.

2. Si te fijas bien, el script no define qué pasa cuando el valor del score es exactamente igual a 50 o 100. Es probable que el score nunca tenga esos valores, dependiendo de tu juego, pero esto puede ocasionar sorpresas.

3. En la primera condición, cuando el score es menor a 50, qué pasa si cambias el color de blanco a azul?

Hasta entonces, me quedo frotando las manos como mosca  ;D

Quizás hay  que evitar usar el ciclo for, pues eso le quita dinamismo (tienes que saber el valor de "i" de antemano. )No sé si funcione, pero una idea es definir un arreglo parecido a

arreglote[1000, 1000] = 0

tengo entendido que en GM no tienes que especificar el contenido  celda por celda para poder crear el arreglo. El ejemplo anterior llena con ceros el millón de casillas (esto es una exageración, sólo para ejemplificar)

Ahora que ya tienes ceros, encárgate de llenar el arreglo a tu gusto, pero sin saltarte celdas ni columnas (sin dejar ceros entre datos, por así decirlo)

Puedes recorrer el array con un cilclo WHILE,  (así evitas tener que saber el límite de "i" y de "j") ir leyendo el valor de las celdas e incrementar una variable contador mientras no se encuentre con un cero, o con "" (cadena vacía). Tambien dentro del while harías la escritura al archivo txt. Al encontrar el cero o la cadena nula, se alcanza el final de los datos válidos en el arreglo y se termina el ciclo while.

Como dije, sólo es una ídea. No sé si pueda funcionar.

Edito: La variable contador no es necesaria, a menos que quieras saber el límite donde terminan los datos válidos en el arreglo, o si quieres hacer la escritura al archivo fuera del WHILE, usando un ciclo FOR

Secundo lo ya mencionado, tiene muy buena pinta el juego, y me pareció interesante ver a un tipo vestido con armadura antigua manejando armas de fuego modernas. Un pequeño comentario: cuando avanzas hacia arriba, la view queda un poco rezagada o hacia abajo, y no te deja ver bien lo que hay en la dirección en la que avanzas. 

Voy de salida, y no tuve mucho tiempo para trabajar en el código. Hice unas pequeñas modificaciones, aun falla, pero mejoró un poquito el comportamiento. No adjunto archivo porque sólo puedo guardar como gm81

xj = abs(obj_jugador.x - x)

yj = abs(obj_jugador.y-y)


validar = 1-( (2*g*yj) / (power(v,2)) ) - ( (power(g,2)*power(xj,2)) / (power(v,4)) )
if validar > 0
    direccion=arctan(   ((power(v,2))/(g*xj))*(1+sqrt(1-((2*g*yj)/(power(v,2)))-((power(g,2)*power(xj,2))/(power(v,4)))))  )


Con las pequeñas modificaciones, si el jugador no estáa muy alejado del cañón y tiene una "y" menor que la torreta (es decir que está algo más arriba) la bala si le alcanza a dar

Tambien se solucionó el error de raíz negativa si el jugador avanzaba más allá de x = 500 en la pantalla.

Como te dije, no tuve mucho tiempo de meterle mano, pero lo que te recomiendo es que apliques la ecuación tal cual, es decir, hay dos soluciones, una con + antes de la raíz y una con - antes de la raíz. En el código sólo tienes la solución con "+", pero puede que en ocasiones funcione con "-". Ese tipo de ecuación indica que matemáticamente hay dos soluciones, pero en el mundo real, solamente una es válida, a veces funciona una, y a veces otra. Prueba implementando "direccion2" =

Se me ocurre que para la fórmula con signo negativo, crees un segundo objeto tipo bala, y que dispares las dos balas siempre, cada una va a usar una fórmula, la primera bala, usa la fórmula que ya hiciste, la segunda usa la solución con signo "-". Esto para que veas la diferencia en las trayectorias

Espero haberme explicado. Nos vemos. Suerte

De nada. Suerte con el sistema de disparo

Tambien hay una función que devuelve enteros aunque le des parametros con decimales, creo (nunca la he usado, pero eso dice en el manual)

irandom_range(min, max)        //Notar la "i" al principio

En esta nueva version 0.8, lo primero que se nota es que responde mejor la nave al cambio de dirección, aunque para mi gusto aun se siente algo "dura". Lo que sí creo que debe cambiarse es que cuando pierdes una vida, y pasas a la siguiente, el control se inhabilita y no puedes mover la nave. Esto afecta la jugabilidad, por ejemplo justo cuando conseguí un escudo o municiones nuevas, me mataron, y al volver a aparecer la nave, no pude tomar el power-up, y me quedé como el chinito  XD

Me gustaría poder usar la típica recarga de poder, donde mantienes presionado el botón de disparo cierto tiempo, y al soltarlo, lanzas un ataque más potente

Qué fórmulas exactamente estás usando. Las fórmulas de caída libre y tiro vertical no te van a funcionar (si es que buscas realismo), porque este no es un tiro vertical ni hay caída libre, lo que tienes es un tiro parabólico, por lo que deberías usar la fórmula:

R(t) = (V0x*t + x0)i + (-0.5gt^2 +V0y*t + y0)j

Que es la fórmula para conocer la posición del proyectil, en un instant (t)

V0x = Es tu velocidad inicial en x. Tienes que especificar un valor de velocidad con la que sale disparado el proyectil del cañón

t = Es el instante de tiempo, para el cual quieres saber la posición del proyectil. Va a ser necesario que hagas un script que cuente el tiempo (en este caso, el número de pasos entre la velocidad de fps que manejas en tu juego). En el momento que la bala sale disparada, iniciar en el paso = cero, y a partir de ahí contar los pasos. Puedes manejar directamente el número de pasos, pero tienes que tener en cuenta que hay mucha diferencia entre t = 5 (pasos) o t = 5 (segundos)

x0 = Es la posición en x del cañón, con respecto al origen de la pantalla.

g = tu gravedad

V0y = Velocdad inicial en y

Y0 = Es la posición en y del cañón, con respecto al origen de la pantalla.

Recuerda que para conocer V0x o V0y tienes que usar algo similar a

Vx0 =lengthdir_x(v, angulo)     v = velocidad inicial a tu gusto   angulo = el ángulo de disparo del cañón

o en lugar del método anterior, usar las funciones seno y coseno según corresponda.
Vx0 = cos(angulo*pi/180)*v

No sé si los cañones pueden variar su ángulo o van a estar fijos. El objetivo final es calcular en qué momento disparar la bala para que le de al blanco (o se aproxime a la zona donde está localizado). Esto quiere decir que además de calcular distancias, tambien tendrías que calcular tiempos en base a la velocidad de tu personaje. Esto fue la primer idea que me vino a la cabeza, igual y hay un método más sencillo, pero no se me ocurre  ;D

Por último, puedes olvidarte de toda la teoría y probar hasta dar con alguna velocidad y ángulo de los cañones para que el jugador tenga que ser hábil y esquive los proyectiles, aunque así el juego sería menos dinámico sin duda.

Suerte.

Creo que es


if (n mod 2) == 0   
numero_par = true


a reserva que me equivoque :P

El programa para dibujar es secundario. El hábito no hace al monje. Hay muchas opciones disponibles en la red, y prácticamente, el 90% del tiempo sólo vas a usar dos herramientas: el lapiz y y el borrador o goma, otro 4% quiazás para la herramienta de selección y otro 4% el selector de color... prácticamente cualquier programa actual tiene esas herramientas, hasta el Miscrosoft paint. Lo que quiero decir es que no te preocupes por pasar horas o días buscando cuál es el programa más potente o completo, la calidad va a salir de tus manitas

Lo más importante: PACIENCIA. Es difícil que tu dibujo te salga a la primera y es mejor empezar por animaciones de pocos cuadros que aventarte a dibujar una superanimación donde no haya sincronía y los movimientos se vean falsos.

Dibuja tu personaje en una hoja de papel, y luego trata de dibujar lo mismo pero en un área de 16X16 o 32X32 pixeles en tu PC. No uses el pincel, eso es para dibujos grandes, usa el lápiz siempre

Quizás algo que sí debas buscar en el programa de dibujo, es la herramienta de varita mágica, que te permite elegir secciones del dibujo por color, eso acelera mucho las cosas en ocasiones.

Crea un muestrario de colores, por ejemplo, qué color vas a usar para el tono base de la piel, qué color para las zonas oscuras o sombreado, etc. No uses demasiados tonos, pues no es necesario en un dibujo tan pequeño. Si el estilo es manga, por lo general el sombreado es en 1 o dos tonos nada más.

Hay gente que hace una imagen grande en el programa, y después le reducen el tamaño que desean en el propio programa, y esto crea un efecto pixelado como el de los juegos de 8 bits antiguos, otros empiezan por dibujar algo muy pequeño y aumentarlo de tamaño, obteniendo un efecto similar. La opción que me gusta más es dibujar desde el principio al tamaño requerido, sin redimensionar nada, pero esto es cosa de gustos.

Hacer sprites es una tarea que consume muuucho tiempo, pero es muy gratificante ver cómo se mueven tus monitos al final. Suerte  :)