Comunidad Game Maker

Que guardadito se lo tenían los del Staff. Felicidades, se ve más profesional y limpio el diseño. Lo único que extraño es una mezcla de colores oscura, como mencionaron otros usuarios, pero bueno, eso es ya una cuestión de gustos.

Yo lo leí hace unos meses, pero nunca lo he probado. Creo que se puede hacer algo parecido sin tanto enredo. En mi juego, por ejemplo, hay íconos que representan 7 acciones (una para cada botón: salto, ataque, retroceso, etc)

Hay lo que se llama "capas de tiles" digamos que tienes tres tiles y a los tres le das una profundidad de -10, entonces, esos tres tiles están en una capa. El GM trae funciones para mostrar u ocultar capas de tiles. Eso uso para mostrar un tile activo (cuando el jugador elige una acción determinada) y los demás tiles (no elegidos) muestran el estado inactivo, que está en otra capa. O sea, funciona parecido a un mouse hover basado en tiles

Aunque a lo mejor esto es ineficiente si se hace con un fondo que ocupe toda la ventana.

Ahora, no sé si funcione, se me acaba de ocurrir , pero nunca lo he probado. Dices que pusiste el depth al máximo y no te funciono. No sé si GM respete el alpha en los fondos. Si así fuera, podrías hacer una zona totalmente transparente en un fondo, y justo en esa zona empalmar otro fondo u otro objeto y a lo mejor ese objeto se vería a través de la transparencia del fondo. Igual y esto es una tontería y no es posible

Es que lo instalé la semana pasada y no le había movido. Se ve que los efectos son muy buenos, pero tenía la idea que se podía importar manteniendo los parámetros entre el particle illusion y GM. Aunque tiene la ventaja que una animación se puede usar en cualquier computadora y no te demanda tanto procesamiento.

gracias

Prueba con este
http://host-a.net/u/Pixelated_Pope/Animated_Tiles_Examples.zip

a que una vez importado en game maker, hay cero partículas, es un strip en PNG. es decir, no se usa el sistema de partículas nativo de GM que las genera en tiempo real, con variaciones en la velocidad, tiempo de vida, gravedad, dirección, etc.

Aquí hay un ejemplo de tiles animados, pero requiere la versión estándar o registrada
http://gmc.yoyogames.com/index.php?showtopic=585083

mmm pero entonces el efecto no se genera en tiempo real, siempre se va a ver igual, no?

cómo exportas de particle illusion a game maker?

http://alertgames.net/index.php?page=s/pd2

El mismo GM:S incluye un tutorial de partículas, con eso te armas.

Cita de: Jangse en Enero 20, 2014, 08:54:10 PM
Por que si no, sería interesante hacer una lista de que poner y no poner en Step.

No. Sería declarar una nueva inquisición

Cita de: Jangse en Enero 20, 2014, 08:54:10 PM
Y más para los que aprendemos y pensamos que no hacemos algo correcto.

Si quieres aprender, date la oportunidad de fallar y equivocarte. Arriésgate y experimenta por ti mismo qué te funciona y qué no. Parece que estás demasiado pendiente de no salirte del camino seguro. Fíjate que un simple loop while con una condición equivocada ya te va a echar a perder la ejecución de tu juego, sin haber sobrecargado nada. Todo puede ir en STEP o incluso en DRAW.

Cita de: Jangse en Enero 20, 2014, 08:54:10 PM
Si no, queda todo muy ambiguo.

Jústamente, ahí es donde comienza la experimentación y nacen las diferencias entre una manera de hacer las cosas y otra menera de hacerlas.

Bueno, a ver si te puedo ayudar, aunque no estoy muy seguro

Para que se vea en una view específica, le indicas en qué view dibujar, por ejemplo draw_sprite,subimg, view_xview[1] + margen_x, view_yview[1] + margen_y.

Que el objeto tenga un sprite distinto en dos views distintas, no sé cómo se haga de manera directa. yo me imagino que no se puede directamente porque sprite_index es una propiedad del objeto independiente de la vista. Aunque en una vista se puede dibujar el objeto de manera normal y en otra(s) dibujar un sprite distinto mediante surfaces. O crear un objeto réplica para una de las vistas.

Lo de apuntar con el mouse, yo lo haría revisando sobre qué vista está el mouse. Por ejemplo, suponiendo que la vista 2 está en la zona derecha de la ventana y no ocupa todo el alto de la ventana, algo así



pos_xvista2 = view_xview[2]
pos_yvista2 = view_yview[2]
vista2_ancho = view_wview[2]
vista2_alto = view_hview[2]

if ( mouse_x >= pos_xvista2 ) and (mouse_x < pos_xvista2 + vista_ancho)
      dentro_de_vista2x = 1
else
      dentro_de_vista2x = 0

if (mouse_y >= pos_yvista2) and (mouse_y < pos_yvista2  + vista2_alto)
     dentro_de_vista2y = 1
else
      dentro_de_vista2x = 0

if (dentro_de_vista2x == false) and (dentro_de_vista2y == false)
      //código que le permite al jugador apuntar hacia el mouse


Para controlar la visibilidad del mouse, revisa la función window_set_cursor(curs) en el manual

uh, hace como un mes que terminó esa promoción.  :-[

¿horizontal hacia abajo?  :o



En las casillas puedes poner decimales, o eso creo.

Yo tengo una duda, agradecería si Strod la puede resolver.

Después de ejecutar el código, ¿qué valores (id) tiene el arreglo global.arreglo[]? En el debug se puede revisar

Cita de: Jangse en Enero 16, 2014, 09:09:33 PM
Se puede poner event colisión en el enemigo contra nosotros. O bien, poner el event colisión en nuestro personaje pero que colisiona contra el enemigo. A la postre, es lo mismo ¿Pero cual es la forma correcta?

Si a la postre es lo mismo, ¿por qué una forma sería incorrecta y la otra no? Por ahí he leído que "Antes claridad que eficiencia", "La eficiencia prematura es una maldición".  No sé qué tan ciertas sean, pero imagina que en tu juego hay 100 enemigos diferentes. Aunque fuera menos eficiente, yo preferiría poner un evento de colisión en cada enemigo (vs el jugador) que cien eventos de colisión en el objeto jugador. Me parece que se aconseja poner el evento de colisión en el objeto del que haya menos instancias en la habitación, pero me imagino que la diferencia entre hacerlo de una u otra manera no se notaría en el 95% de computadoras que ejecutaran el juego. Ya sería cuestión de hacer pruebas.

Cita de: Jangse en Enero 16, 2014, 09:09:33 PM
Otra duda, es, donde poner el control de vidas, puntos, energía ¿En el objeto personaje? ¿O crear otro objeto controlador? Por que hay gente que pone este control en el personaje. Pero luego tiene un lío de narices cuando cambia de room y tal (Como le paso a un servidor). Por eso, me gustaría saber si hay un patrón donde es mejor ubicar estas cosas.

Si dices que tuviste problemas con variables al cambiar de habitación, el mero hecho de pasar el código del objeto jugador al objeto controlador (que es un objeto más) no resuelve el problema. La solución (bien sencilla) en este caso es que el objeto jugador sea persistente. De hecho un controlador que no sea persistente no le veo mucha utilidad.

Y sí hay un patrón de dónde ubicar las cosas, de hecho, hay dos patrones: Sentido común y preferencias personales. Nada está escrito en piedra sobre qué poner en un objeto controlador. Si consideras que una variable es más global que "privada", la pones en el controlador (si quieres). Sería muy feo que el manual te exigiera dónde poner tal variable.

Cita de: Jangse en Enero 16, 2014, 09:09:33 PM
Por que según lee uno, mucha gente pone el código en un step, otros en un draw o en un create. Y uno no sabe donde poner el suyo.

¿A qué código te refieres? Digo, hay mucho código, cada uno hace cosas distintas. Un código de colisiones no tiene mucha lógica meterlo en DRAW, aunque se puede. ¿Como qué código es el que no tienes claro dónde poner?