Comunidad Game Maker

Cita de: _-Caleb-_ en Marzo 05, 2014, 10:54:03 AM
Si me permitís, para este tipo de cosa; ¿Por qué no montáis un dokuwiki?

Eso estaría muy bien, pero está más allá del propósito inicial del proyecto. Ya la traducción significa una cantidad enorme de trabajo, son cientos de temas y funciones que hay que traducir "a mano", también se debe revisar que quede bien escrito, que sea comprensible, que no sea un trabajo descuidado. Las traducciones van avanzando, pero así como una semana se puede avanzar mucho, habrán otras que no se avance, esto porque los miembros aportan desinteresadamente su ayuda, pero tienen sus deberes familiares, escolares, de trabajo, etc.

De momento estaremos trabajando "en lo oscurito", cuando tengamos material suficiente para decir que tenemos un remedo de manual, entonces subiremos alguna alfa o beta de la traducción.

131072. Ciento treinta y un mil setenta y dos.

Ese es el número de variables de GM que necesitarías crear para ocupar un Megabyte de memoria RAM en tu PC. Dudo que haya un juego en GM que siquiera se acerque a esa cifra.

Teniendo en cuenta que para "gastar" un Megabyte de memoria necesitas más de cien mil variables, francamente una, cien, mil o diez mil variables "inútiles" no significan nada. Hubo una época en que 100 o 1000 variables inútiles sí hacían diferencia, pero esa época quedó en el pasado y no volverá.

No pasa nada si nunca usas "var" en tu juego. El manual no te obliga a usar tal o cual tipo de variable es específico. Pero en muchas ocasiones sí resulta cómodo usar var, porque no tienes que andar entrando a un CREATE y a otro y a otro para declarar variables, símplemente las declaras en el momento que las necesitas. Yo lo veo más como una manera de hacer el código más flexible que como una manera de economizar recursos.

 ¿Agregaste el sprite(s) a la lista de included files? Esto es necesario en GM:S para cualquier archivo externo.

No es muy recomendable cargar imágenes externamente en GM:S, sobre todo es muy ineficiente en ios / android. En PC no tanto, pero aun así YoYo no lo recomienda.

A mi se me ocurriió algo parecido a lo que menciona el makero LowHertzs: "Plantar" en la pista objetos que especifiquen "el curso correcto". Por ejemplo, en la imagen que subiste, hay partes de la pista donde al bajar en Y se considera que el coche avanza, pero hay partes donde al bajar en Y se debería considerar que el coche retrocede. Lo mismo pasa en X, a veces al ir a la izquierda, avanzarías, pero otras veces retrocederías (irías al contrario del curso de la carrera, por lo que deberías manejar al lado contrario: la derecha)

Los coches tendrían variables algo así
dist_valida_x
dist_valida_y

Que serían una especie de contador de cuántos "kilómetros" (en realidad pixeles) has avanzado de manera correcta. Si vas en el sentido correcto, las variables aumentan (x, y o ambas si avanzas en diagonal). Si vas en el sentido contrario, las variables disminuyen, indicando que te queda más tramo por recorrer, o que vas retrocediendo en lugar de avanzar. Si avanzas bien, una variable OK = 1, si avanzas mal OK = 0.

Volviendo a los objetos "curso", éstos objetos al ser colisionados por el carro indicarían eso: "A partir de este punto, si te mueves a la izquierda, vas bien (se amenta X). Para explicarlo mejor:



El coche inicia SABIENDO que hacia la izquierda se avanza y hacia abajo se AVANZA. Al contactar con C1, se le indica que ahora izquierda significa RETROCEDER y derecha significa AVANZAR, en este punto, abajo todavía significa AVANZAR.

Al llegar a C2, izquierda es avanzar.

Al llegar a C3, arriba es avanzar. Y así con todos los demás objetos curso. Ahora, se debe llevar un contro lde las colisiones, por ejemplo, si después de pasar el objeto C2, giras en sentido contrarioy te regresas a la meta, ya no debería contar la colisión contra C1, porque vas en sentido equivocado (OK = 0).

Ahora, para saber cuál va primero, necesitas llevar un control de cuántas vueltas lleva cada coche, eso se haría al contactar con un objeto meta posicionado en la meta. Cada que se colisione contra este objeto, se suma 1 a una variable "vueltas". Probablemente al sumar una vuelta, quieras reiniciar el contador de kilometraje. El coche que tenga mayor vueltas, va en primero. Si dos o má scoches tienen el mismo número de vueltas, va en primero el que tenga más kilometraje

Esto es lo que se me ocurrió, posiblemente sea muy enredado y no lo más óptimo. Además, sólo expuse una idea básica, se necesitaría desarrollar más para que funcionara. Por ejemplo, detectar si la punta del coche colisiona primero con la parte delantera que con la trasera de un objeto c1, y así saber si se va en dirección correcta o no.

Quizás con paths sea más fácil de lograr, pero por eso quise poner un método enredado  :D

Hay muchas maneras de hacer menús.

Tienes que pensar todo en términos de localización (coordenadas x e y) por ejemplo, el botón 1 ocupa un área definida por (x1, y1, x2, y2) que son los límites del botón. Lo mismo para el boton dos.

Si el menú se maneja con las teclas o el gamepad, no es necesario, pero ayudaría tener un objeto adicional además del objeto menú. Este objeto adicional sería un objeto cursor que te indique VISUALMENTE qué opción del menú tienes elegida (botón 1 o botón 2). Entonces, el objeto cursor tiene dos posibles posiciones, la posición que "marca" al botón 1 (pos = 0) y la posición que "marca" al botón 2. (pos = 1)


Si (pos == 0)
{
   x = 10; y = 50
}

Si (pos == 1)
{
   x = 10; y = 90
}

El código se arriba sería algo similar a lo que usarías para posicionar el cursor según se haya elegido el botón 1 o botón 2. Para esto tendrias que hacer tu código para desplazarte por el menú, por ejemplo. Se empieza en la posición cero (botón 1) al entrar al menú, si se presiona la tecla de abajo, la posición pasa a 1 (botón 2), etc etc.

Si el menú se maneja por ratón, es algo más fácil, ya que sólo tienes que saber si en la posición actual del puntero hay "debajo" un botón.

Esta pregunta es más para el área de soporte de YoYo. Seguro que ellos conocen mejor que nadie cada código de error del GM:S

CitarAccess violation at address 016DB135 in module '5piceIDE.exe'. Read of address 00000000.

Ahora, este error a mi me ha saltado, y lo que yo he notado es que siempre que aparece es porque GM:S no tiene acceso a internet, pero de todas maneras siempre me deja abrir el GM:S. QUIZÁS  tienes algún firewall que está bloqueando el GM:S.

También me ha pasado que de vez en cuando el GM:S se olvida que está licenciado y pone una ventana para introducir una licencia DESDE ARCHIVO. En este caso, lo que hago es cerrar esa ventana y volver a abrir el GM:S, en esta ocasión, ya no aparece la ventana de abrir licencia DESDE ARCHIVO, sino que aparece una ventana donde puedo introducir la licencia de manera normal (escribiéndola o pegándola), después de lo cual ya abre GM:S de manera normal

Cita de: jose en Marzo 04, 2014, 08:05:30 PM
¿Como lo soluciono? ¿Que hago? ¿He perdido la licencia? SOCORRO

Si tomaste la precaución de guardar la licencia, entonces no pasa nada.  En algun lugar de tu PC está la carpeta de proyectos donde se van guardando todos los proyectos de GM:S, no está de más respaldar esa carpeta de cuando en cuando, para evitar problemas (creo que en la mía estaba en "mis documentos" pero yo cambié la ubicación a otra unidad, así que no recuerdo dónde está originalmente). El GM:S se puede desinstalar sin pánico y luego volver a meterle la licencia.

EDICIÓN: Proble a quitar el internet y me aparece exactamente el mismo error cuando intento abrir el GM:S. Pero ahora no me deja abrirlo y luego me pide la licencia. exactamente igual que en tu caso. Le tuve que volver a meter la licencia y activar de nuevo el internet

Cita de: Jangse en Marzo 03, 2014, 09:44:22 PM
¿Hay algo que no sepas hacer con GM penumbra? jajaja...

:-X Mucho. Hace poco que empecé a moverle al GM. Hay cosas a las que no les he metido mano jamás, por ejemplo, al 3D. Tampoco sé de android-ios, no soy partidiario de los gadgets. Esta fue una de las razones por las que emprendí el proyecto de traducción del manual del GM:S, me sirve para conocer cosas que desconozco. Mi nivel de GM es si acaso intermedio  :)

EDIT: No no, crack para nada. Cracks los usuarios que tienen muchos años por acá en el foro, yo soy de los novatos aun. Tan novato que sigo trabajando en mi primer juego.  :D

Se ve que tiene una jugabilidad bárbara. El nivel del video más reciente me recuerda mucho a uno de los últimos niveles del prince of persia. Ojala lo lances pronto.

En el mundillo GM se les conoce más por subimágenes que por frames.


if (image_index == 1)
{
     with (id_segunda_instancia)        //identificador del "mismo objeto" que quieres crear al lado derecho
     {
           image_index = choose(1, 2, 8)
     }
}

Modifiqué el código y ya funciona. Se crean cinco objetos aleatorios sin tocar paredes ni a si mismos. Me faltó lo de colocarlos alineados a una rejilla, eso lo puedes completar

El problema era que estabas generando posiciones aleatorias desde el objeto controlador, pero la función place_free y similares necesitan máscaras de colisión para trabajar, y el objeto controlador no tenía sprite, así que la función no podía evaluar colisiones de manera correcta. También tenías el origen del objeto pelota en 0,0, en estos casos es mejor centrar el sprite.

Hasta donde recuerdo, creo que ajustar la profundidad de un objeto no da resultados en las partículas.

part_system_depth
With this function you can set the draw depth for the particle system, much the same as you can set the depth of different instances within the room, where a low draw depth means that it will appear on top of all things drawn with a higher depth, and a high draw depth placing it below everything with a lower draw depth.

Si el juego va a ser comercial, mejor ve planteándote que los tienes que hacer tu mismo o conseguir un artista.

En la web hay muchas cosas, pero muchas son rips de juegos comerciales, por lo que tienen copyright..

Hay cosas de calidad que son gratis o tienen licencia de uso libre, pero al ser libres, están a disposición de cualquiera. Puedes encontrar gráficos alucinantes o música buenísima, pero si son recursos de uso libre, cualquier otra persona los puede usar, y al menos a mi no me gustaría ver eso en un juego comercial.

La programación no es sencilla, pero siempre he pensado que crear gráficos originales y de calidad es mucho má sdemandante.

Pues la mayoría de las plataformas son planas, ¿no?

Esa "plataforma" es un objeto que se mueve en la coordenada Y hacia arriba o abajo. Sólo hay que hacer que cuando el jugador colisione con él, el jugador se mueva a la par:

en el evento de colisión de la plataforma, usas algo como
other.y = y

También puedes usar la función point_distance(x1,y1,x2,y2) para saber cuanta distancia hay del jugador al centro de la plataforma, esto para hacer que si el jugador cae lejos del centro de la plataforma (en las orillas) no llegue a aterrizar, sino que se caiga.

[CREATE]
poder_disparar = 1

[STEP]
if  (keyboard_check_released(ord('S') )
     poder_disparar = 1

if (autofire == 1)
{
     if keyboard_check(ord('S')) and (poder_disparar == 1)
     {
             instance_create (xx, yy, objeto_bala)
             poder_disparar = 0
             alarm[0] = 4
     }
}
else
{
     if  keyboard_check(ord('S')) and (poder_disparar == 1)
     {
          instance_create (xx, yy, objeto_bala)
          poder_disparar = 0
     }
}

[ALARM 0]
poder_disparar = 1

La alarma sirve controlar la ráfaga del autofire. Sin la alarma, se generarían demasiadas balas al mantener presiionada la tecla de disparo.

Cita de: rapsi en Febrero 28, 2014, 02:45:47 AM
La bajé de ese mismo link de hecho, pero viene con archivos GPL, LESSER GPL, LICENSE y Version, (declaraciones de licencia y derechos de autor) no veo nada que sea útil.

Pues yo la bajé del mismo link y ahí viene una carpeta de nombre gm con ejemplos