Comunidad Game Maker

Otra idea es que pudiera haber algo como "el mejor juego del mes" y ponerle un ícono o avatar distintivo. Digamos que para votar por el mejor juego de este mes, la votación comenzaría el 28 de enero (por decir algo) y se anunciaría al mejor juego de enero el 2 o 3 de febrero

Si tú fungieras como encargado del foro, elvis, podrías incluso "entrevistar" al ganador del mes y subir la entrevista aquí mensualmente, para enterarnos un poco más de cómo y en qué se basó el makero para crear el juego, etc etc.

Bueno, es nada más una idea, como quiera, es muy buena la idea de darle un lugar destacado en el foro a los mejores juegos

Citarpero en cuanto a los "string" no lo creo. Un "string" es una cadena de caracteres, o sea un "array" de caracteres.

Cierto, me falto hacer énfasis. Al referirme a global y local, estaba hablando sólamente de variables numéricas, no de cadenas. Claro que un array o las estructuras de datos  en general pueden ocupar más RAM que una variable numérica sencilla, pero aun así, creo que aunque tu manera de programar sea la más desorganizada, no podrías "hacerle cosquillas" a la RAM en base a variables numéricas simples o incluso estructuras de datos (a menos que a propósito escribas código para generar datos basura con el único propósito de comerte toda la RAM). Otra cosa son los objetos, instancias, fondos, srpites, archivos de sonido, partículas, etc. Ahí sí hay que medirse.

Citar
todas las variables independientemente del numero que esté dentro de ellas ocupan el mismo numero de bytes aunque no se si sean 8 bytes por variable ¿de donde sacaste ese dato?.

http://www.maartenbaert.be/game-maker-dlls/http-dll-2/buffers/

"Game Maker uses doubles (float64) to store numbers,"

Type         Size (bytes)     Lowest value    Highest value    Resolution                        Other names
float64               8            -8.9885e307     8.9885e307      ~16 significant figures         double

perdón por meter mi cuchara, en esta charla de "adultos"  XD

En mi travesías por aprender GML, recuerdo una recomendación que se repite bastante, tanto que la tengo muy presente, y esta más o menos dice así: "procura usar variables locales siempre que puedas, evita usar variables globales". Luego se menciona que las variables globales no se destruyen al finalizar la ejecución del script y las locales sí.

A mi, la verdad, me parece una recomendación de poco valor, tomando en cuenta el hardware que se maneja hoy en día.

Citar¿Creen que para no tener que utilizar la partícula "with" sea mejor crear las variables globales? ¿Ocupan más espacio las globales que las locales?

Creo que no hay diferencia en cuanto al tamaño de local y global. Hasta donde sé, a diferencia de los lenguajes 'mayores', GML maneja únicamente dos tipos de datos, string y real. Ahora, lo que determina el tamaño de una variable, no es el valor que almacena, sino su tipo de datos. Como todas las variables (globalesy locales) son REAL en GM, todas ocuparán el mismo espacio en RAM.

Si no mal recuerdo, en este caso, todas las variables de GM, ocuparían 8bytes en memoria. Para utilizar un Kilobyte de memoria, necesitarías tener 128 variables (un sprite , el que sea, ocupa más que esto). Para ocupar 1 mísero Megabyte de RAM con variables, necesitarías un juego con 131072 variables. Reto a un valiente a que haga un juego con 130000 variables distintas

Después del cálculo anterior, no no le veo sentido a eso de usar variables locales y evitar las globales. Para mi, bienvenidas sean las variables globales. Quizás hace 20 años me hubiera preocupado por no gastarme un megabyte de ram, pero no ahora.  ;D

GM:S  != estabilidad

Creo que todavía queda rato para que le sigan sacando bugfixes al Studio. Como tengo poco usando GM, sólo conozco la versión 8.1. No tenía ni idea de los problemas que menciona Fenris en proyectos grandes, lo tendré en cuenta.

Mr. Dudas y Penumbra buscan aliado que quiera colaborar en el desarrollo de videojuego NO COMERCIAL en GM. Aun no tenemos definido el género y el estilo del juego, sólo estamos seguros que será en 2D. Esperamos que el nuevo integrante se sume al aporte de ideas. Como spriter, tendrás la responsabilidad de crear sprites y fondos para el juego, diseñar elementos de la interfaz, menús, etc.

¿Qué buscamos?
Seriedad.
Un mínimo de calidad.
Creatividad y trabajo en equipo.

Qué ofrecemos
Dada la naturaleza no comercial del proyecto, ofrecemos aparición en los créditos del juego. Todos los integrantes del grupo tendrán acceso a los recursos y código del proyecto.

Si estás interesado en unirte al proyecto, te pedimos que nos envíes un par de sprites de muestra por MP, ya sea al usuario Mr.Dudas o a mi Penumbra

Gracias.

Citartendriamos que definir cuantos tipos posibles de relaciones hay en game maker.(yo pienso que muchas ^^!)

Bueno, no me he puesto a pensar en ello, pero creo que más bien son pocas las relaciones entre objetos. En mi ejemplo mencioné 3, colisión y destrucción de instancias (rojo), entrada controlada por usuario (azul), colisión y cambio de variables (rosa). Seguro hay más, pero no creo que muchas más. Se me ocurre IA, para distinguir el control mediante teclado/mouse.

Una pregunta. Suponiendo que el estándar ya está definido como dios manda. Me imagino que en la creación de diagramas, documentos, etc., intervienen todos los miembros del equipo, ¿o esto lo hace el líder nada más?

No olviden las limitaciones de la versión gratuita de GM:Studio:

Rooms   5
Sprites   20
Sounds   10
Objects   15
Backgrounds   5
Timelines   5
Scripts   10
Fonts   5
Paths   10
Included files   5

Hay dos libros a los que podrías echarle un ojo. Más información en google. The game maker's apprentice y la continuación, The game maker's companion.

Esto sí como que está descuidado en GM. Ojalá para la versión 9 mejore el soporte en cuanto a sonido.

Yo aun no le meto sonido a mi proyecto, pero planeo usar OGG, pues para mi, ofrece mejor calidad de audio y además es de libre uso.

Aquí una librería para los que quieran usar OGG (No la he probado aun)

http://moacube.com/resources/caster-multi-platform-ogg-extension-for-gamemaker/.

Ah, y aquí traduzco algo que aparece en esa página, y que es importante tener en consideración al meter música, ya sea ogg o mp3:

"Debes entender que .ogg es un método para comprimir archivos EN EL DISCO DURO, pero éstos deben de descomprimirse cuando se cargan en la memoria, al ser usados. Por ejemplo: Si tienes un WAV de dos minutos de duración, y un OGG de dos minutos de duración, ambos archivos usarán la misma cantidad de RAM, aunque su tamaño sea totalmente distinto. En resumen: Debes prestar atención a la duración de los archivos de sonido, y no a cuántos megas ocupan en tu disco duro"

;D

Yo me voy de cabeza por el pixel art (apariencia pixelada). Los gráficos vectoriales nunca me han llamado la atención en los videojuegos. Además, game maker no tiene soporte para manejar gráficos vectoriales, no puedes  importar un archivo SVG, ni tratarlo como vector en GM, así que independientemente de si creas  sprites en corel, inkscape, freehand  o illustrator, terminarás convirtiendo a formatos raster (jpg, png, bmp, gif)

La ventaja de crear un gráfico en vectores, es que puedes trabajar a gran tamaño, y al final reducirlo al tamaño deseado sin sacrificar calidad. No creo que específicamente haya un libro como el que buscas, pero en Youtube encontrarás un montón de tutoriales o demostraciones que te pueden dar una idea de cómo crear sprites, más que nada, sprites estilo pixelado

http://www.youtube.com/watch?v=wwPLJtJk5XI

http://www.youtube.com/watch?v=yU1mF1ipAZA

http://www.youtube.com/watch?v=ya3Too-DBCY

http://www.youtube.com/watch?v=i-faR9_CKho

http://www.youtube.com/watch?v=eXJo5C01Jho

Uff man, qué buen juego te has mandado. Los gráficos se ven muy pro. Todo está muy detallado. Muy buena ilustración en la pantalla inicial. Los sprites de salto y de ataque me encantaron. La pinta del mundo me recordó un poco a earthworm jim. La jugabilidad es buena. no me tocó nigún glitch, siempre respondió bien el control. Los diseños de nivel están muy buenos, los enemigos bastante creativos. Este podría ser un gran título 2D.


Lo que puede mejorar:

A lo mejor me equivoco, pero me dió la impresión de que estás escalando la pantalla para que se vea más grande, y eso le da esa apariencia a los gráficos que a mi en lo personal no me gusta. Pero bueno, esto es opinión personal, he visto muchos juegos usando scalling así.

El tema musical es bueno, pero como es algo corto, se vuelve repetitivo, aunque en esencia no tiene nada de malo y le aporta su dosis de tensión al mundo.

Los enemigos son algo fáciles de derrotar, excepto la cosa grandota, que aguanta mucho. Creo que el rango del ataque del arma es muy grande. Alcanzé a golpear enemigos que creí estaban muy abajo o muy arriba. para hacerlo más difícil, yo haría un ataque 'normal' lento, y para el ataque rápido (el que haces presionando tres veces seguidas el botón de ataque) pondría una barra que se agotara al usarlo y se recargara poco a poco.

Quise ver los créditos presionando espacio, pero nunca apareció nada. ¿Tú te encargaste de todos los aspectos del juego? Espero que termines pronto este juego, pues promete bastante.

Wow  :o

Se ve que te tomaste en serio lo de implementar el marco de trabajo. Muy interesante tus propuestas de los diagramas de relación y de definición de objeto. Yo creo que ambos diagramas son complementarios y deberían usarse los dos; si se emplea uno solo, faltaría información que no se podría incorporar en el otro diagrama.

Si todo esto lo planeaste  con miras a hacer un proycto en GM, creo que se le podrían agregar detalles. Por ejemplo, en el diagrama de definición de objeto, agregar un área, recuadro o sección que indique si el objeto es padre o es hijo, si es persistente o no; si es sólido o no; si es visible o no. (Quizás esta información vaya codificada en etiquetas o íconos con determinados colores o iniciales).

Más sugerencia que crítica: A primera vista, cuesta descifrar el diagrama de relación. Creo que debería haber distintos tipos de líneas (colores, formas) para especificar el tipo de relación. Por ejemplo, de control a jugador, una línea azul para indicar entrada desde ratón o teclado. De jugador a proyectil, o visceversa, una línea roja para indicar colisión y posible destrucción de instancia. Imaginando un objeto plataforma y un objeto jugador, la línea que los une podría ser rosa, para indicar que hay cambio de variables (dirección, posición, gravedad, velocidad, etc)

Por último, te dejo este enlace para que le heches un vistazo
http://www.youtube.com/watch?v=yPTZh13OTLU

Es una herramienta que podría interesarte a la hora de realizar tus diagramas. Yo la utilicé para crear un diagrama que indicara las habilidades de mi personaje, las variables de las que dependen las habilidades y la forma en que aumentaría de nivel. Lo malo es que es de paga, pero está disponible en demo (probé varias de este tipo y me pareció la más versátil)

A ver qué más se les ocurre a otros  ;D

Citarcuando mi personaje salta y colisiona con la esquina pasan cosas raras...

En tu ejemplo, el código y = esquina.y+80; }no va a afectar a la "ye" del personaje, sino a la "ye" del objeto esquina. Además, el código que puse fue como sugerencia, no está totalmente adaptado a tu juego, pero creo que sería así.


trepo  = collision_circle(x, y, 80, objParentEsquina, false, true) //el objeto que pongas aquí debe ser PARENT
if (place_free(x,y+5))  && (trepo > 0) // Si estás en el aire y hay contacto con alguna esquina HIJA
{
move_contact_solid(direccion,20); //Mover al jugador

with (trepo)                              //Elegir la instancia esquina correcta, 'descartar' las otras que existen en el room
{
obj_Player1.y = y + 80;
obj_Player1.gravity = 0;
obj_Player1.vspeed=0;
obj_Player1.sprite_index = trepando;
}

}



Como mencioné antes, el objeto que usas en collision_circle o collision_rectangle debe ser PARENT, no HIJO. Dentro de los corchetes, te faltó poner el nombre de tu objeto jugador. Mientras estés dentro del with, y quieres modificar propiedades del objeto jugador, tienes que usar el formato

nombre_de_objeto_jugador.variable

Es decir, substituye obj_Player1. con el nombre del objeto de tu personaje.

Citar¿como puedo hacer para que mi personaje tome la altura de la esquina a la cual me estoy trepando actualmente y no a la de la primera instancia que coloque en el room?

Al usar with, estás "saliendo" del objeto jugador y estás "entrando al dominio" del objeto esquina. Esa entrada a la instancia especificada por trepo es lo que te permite elegir la esquina correcta, en lugar de que sea siempre la primera esquina que colocaste en el room.

Pero al entrar a la esquina correcta, ya no puedes llamar a las variables del jugador como lo hacías fuera del with. Es decir, la variable gravity AHORA es la gravedad de la esquina referenciada por trepo. Mientras estés dentro de WITH, la gravedad del jugador se llama así obj_jugador.gravity.

No sé si funcione, pero creo que debes hacer algo así

sujetar = collision_circle(x, y, 80, objParentEsquina, false, true)

cuando haya una colisión, la variable 'sujetar' va a contener la id de LA ESQUINA HIJA CORRECTA (con la que hiciste contacto). si no hay colisión con ninguna esquina,  sujetar = número negativo..

Cuando compruebes que hay colisión con una esquina y que está en el aire, usarías algo como

with(sujetar) {

}

y dentro de los corchetes, pones el código para posicionar correctamente al personaje. Más o menos algo parecido a


obj_mi_personaje.gravity = 0
obj_mi_personaje.y = y +/- valor

donde:
obj_mi_personaje.y = la posición vertical del jugador
y = la posición vertical de la esquina HIJA con la que hay contacto

EDITO: La vspeed y el sprite del personaje también lo debes cambiar dentro de los corchetes, refiriéndote a ellos externamente, como la gravedad y la posición vertical del ejemplo

Mmm bueno, esa es mi sugeerencia, a ver si me expliqué bien.  ;D

Nada de lo que escribí lo he usado, nunca he sido jefe de algún grupo de videojuego.  :-[

Una vez participé como grafista en un proyecto, que también sufrió de abandono y nunca se completó. Después de leer tu post y acordándome de mi experiencia, escribí las sugerencias que se me ocurrieron al momento, para tratar de evitar las fallas que nos pasaron, pero no sé si funcionen, no las he puesto a prueba.

En mi proyecto actual, se puede decir que soy el lider, pero nada más somos un músico y yo, por lo que se me hace exagerado aplicar mis sugerencias. Como no hay otro programador, no sé exactamente qué medidas tomar para maximizar la compatibilidad de código.

No me puse a pensar a detalle que información pedir en el reporte, jeje. Creo que el reporte sería más apto para los programadores, los grafistas o músicos tendrían que enviar una muestra de su progreso.

De nada, camarada.  :)