Comunidad Game Maker

¿Y sí se crea la instancia "obj_b" ? o sea, ¿Sí se cumple la condición a=10?
De otra manera, no debería haber motivo para que no se guarde el valor del id  :-\

Pues tengo esa duda existencial, tanto tiempo entregando trabajos "formales" en la escuela me han enseñado que la letra arial o New Times Roman es la que hay que elegir, pero en un vídeo-juego no se ve muy bien...
Intenté jugar con las fonts pero luego se ven borrosas, opacas o parece muy formal  :'(

Sólo les pregunto ¿Qué tipo de fuente recomiendan? ¿Cuál acostumbran usar para diálogos y mensajes al jugador? :P

A la hora de colisionar con el bloque checas la velocidad vertical del personaje, si es menor a 0 (o sea si va para arriba) vuelves el bloque no sólido. Si la velocidad de mayor o igual a 0 haces que sea sólido y que el personaje deje de caer. Debes tener cuidado por si el personaje detiene su salto mientras está cruzando con el bloque :P

En ese caso, más sencillo:

draw_text(98,132,string((global.ataque+1)*25)+" pt");

;)

Cita de: Iros en Febrero 08, 2013, 04:22:58 AM
Digamos que puede caber la posibilidad de que usen un programa de fuerza bruta o un simple editor para obtener algunos datos de tu juego, esos datos pueden ser los datos de la base de datos y CRASH!!!, chau base de datos. Ese es el único problema de vulnerabilidad. Y si mal no recuerdo existía un descompilador para el GM6 así que puede que hayan hecho alguno para el GM8 >.<

Ése problema existe en cualquier ámbito que uses un gestos de Base de Datos (programación Web con PHP, C#, Java, Python, etc); y como en todos debe ser trabajo del administrador de la BD y del programador validar tanto las entradas de las consultas como las salidas para evitar esas vulnerabilidades. Para empezar evitar las inyecciones MySQL. También, en el caso de los programas para PC, se puede llegar a leer las variables que están en memoria así que los datos como el usuario y contraseña de la BD no es bueno en ese caso tenerlas en variables... o bien tenerlos en una forma encriptada... todo ese royo de seguridad informática.
Mmm... no creo que deba ser un motivo de desanimo el que haya una vulnerabilidad. Todos los métodos son vulnerables (guardarlos en txt, .ini...) siempre se pueden leer, aunque estén encriptados se puede usar fuerza bruta, así que sigue con tu proyecto :P

A veces un interesante detalle cuando hay hordas de enemigos es dejar por un tiempo el sprite del enemigo muerto en el suelo y pasado ese tiempo empieza a parpadear y luego desaparece... digo porque a veces se ve bien ver tanto cadáver en el suelo para ver la "destrucción lograda" XD

Interesante juego, no lo he jugador bien pero el juego tiene buena presentación...
Yo también creí que tenía que ver con la canción XD

Wow, buen Tema y buena info.

Primero, el diseño (en el ámbito de desarrollo) es la base del producto, no lo más importante ya que ese papel se distribuye en partes iguales; es la base porque es lo primero que se debe hacer y por eso si se falla en ello, al tener el producto terminado se debe retroceder al principio. Si se falla programando sólo se debe corregir la programación, lo mismo con la parte gráfica y sonora, muy pocas cosas (o ninguna) dependen de las demás etapas siguientes al diseño.

Hay ciertos tipos de errores que no llegan a ser desastres pero que le quitan mérito al juego; otras, sin embargo, llegan a ser sólo curiosidades legendarias que bien pueden enmascararse como "huevos de pascua" o "secretos", aquí no hay mucho problema, son sólo cosas que dentro de 5 o 10 años serán datos curioso  ;)

¿Qué errores de diseño has tenido?

No usar clases padres (parent); es muy común el pensar el juego/programa de una manera ya determinada, cerrada. Sin la posibilidad de ampliar de manera flexible, por ejemplo aumentar los tipos de armas o las diversas formas de obtenerlas. Como la ídea del juego puede cambiar a futuro (o fallar en ciertos puntos del diseño) es normal ampliarlo o modificar detalles "básicos"; lo cual, si no se implementa un método flexible para hacer esos "pequeños" cambios pero que afecten de manera general al juego, se llega a perder mucho tiempo además de que aumenta muchísimo la posibilidad de Bugs. Por ejemplo, se tiene en un juego 25 llaves distintas, pero se quiere cambiar la forma de interactuar con las llaves o darle un extra (como guardarlas en un lugar específico), en un caso mal diseñado se tendría que hacer esa misma modificación a las 25 llaves, lo que puede inducir a olvidar de una llave o equivocarse debido a que de cierta forma las 25 llaves son distintas. Si se diseña correctamente la herencia de objeto, sólo es necesario modificar un objeto que le hace de padre sin alterar el funcionamiento específico de las demás llaves.

No pensar en todos los casos de validaciones posibles (dentro de lo humano :P). Más que nada me ha ocurrido en programación general (no de vídeo-juegos) pero estoy seguro que ésta anécdota les servirá en alguna ocasión:
Hice un programa que registraba usuarios a diferentes grupos, cada grupo con su capacidad limitada. Me limité a obtener los grupos que no estén llenos de capacidad para mostrarlos al usuario pensando en que así evitaba que se sobrellenara el grupo. Jamás pensé que, mientras el usuario elegía un grupo, éste ya se podía haber llenado entre el momento que se le mostró y el momento que lo eligió. El problema pudo haber sido catastrófico si no me hubiera percatado 5 minutos antes de ponerlo en marcha.

¿Que ejemplo de Diseño sigues?

No he conocido un modelo de diseño seguido por una empresa en específico, pero conozco 3 ejemplos de diseño:

Top to Down (De arriba hacia abajo)
Down to Top (De abajo hacia arriba)
4 + 1 vistas (Muy similar a la "Top to Down").

Yo uso la Down to Top (De abajo hacia arriba). La cual consiste en empezar con aquello que se encuentra más "abajo" de la programación... haciendo referencia al diseño de la base de datos, los datos que se van guardar/utilizar, las clases e instancias que lo contendrán así como las estructuras, y las funciones-métodos con los cuales trabajar con los datos.
Sigue con la parte de control (Controller o controlador). Consiste en diseñar las funciones y acciones que se realizarán, la "vida" del programa-juego; por ejemplo en cómo se ejecutarán las magias, cómo funcionará el correr de un personaje, etc, etc.
Finalmente la vista, que es precisamente la interfaz con el usuario.
Como cada "etapa" de éste diseño depende de la anterior, cada vez te vas fijando tu diseño con respecto a la etapa anterior, por ello prefiero empezar con la parte "baja" de programa-juego, porque empiezo con lo esencial de éste que son los valores que se manejan y terminar con la interfaz la cuál sólo debe contemplar que sea cómodo para el usuario.

No, no lo hay, por desgracia.
En muchos casos es suficiente que detengas la velocidad de desplazamiento y la animación del sprite y a la hora de volver a ponerlos en marcha le reasignas las velocidades.
Digo, en muchos casos.

En otros más específicos tienes que programar una serie de pasos tanto antes de pausarlos como antes de volver a ponerlos en marcha, como por ejemplo guardar algunos valores en variables "secundarias" :P
Es parte del trabajo de diseño y programación  ;)

Algo sencillo (en ocasiones) es agregar una variable que indica si están pausadas o no, el fin es que si esa variable indica que está pausa el juego todas las instancias se detienen; así podrás mostrar los objetos e imágenes del menú. Cuando destruyas el menú vuelves a poner la variable indicando que el juego no está pausado.

De nada, para eso estamos.

No creo que se pueda obtener la fecha de un archivo directamente con una función del Game Maker, tal vez te puedas ayudar si llevas un registro de los archivos .sav creados (enumerados o algo así) y sus respectivas fechas de guardado con las funciones de tiempo:
http://www.comunidadgm.org/manual_GM/Trabajando_con_el_tiempo_y_la_fecha.htm

Tal vez apoyándote con archivos .ini o externos o lo que se te ocurra; pero así directamente no :/

Haz que el room principal (el grande) sea persistente, así se conservarán los cambios, enemigos y todos... de cierta forma también te ayudaría a que cuando regreses del room de un edificios al principal el personaje se encuentre justo donde estaba (Aunque también podría darte problemas dependiendo de cómo te "teletransportas" al otro room).

Se siente un poco raro, pero está bien al acostumbrarse a las herramientas...
Lo raro es ¿Por qué no puedo seleccionar el color blanco?  :P
Los baldes también se sienten raros por que para cambiar todo el color de fondo primero tengo que ponerlo de blanco y luego seleccionar el color para después usar los baldes, no puedo cambiar el fondo elegir otro color y volver a cambiarlo directamente...

Me gustó el cambio de herramienta de clic-derecho para lápiz y clic izquierdo para borrador  :D

Aun que parezca raro nunca le entendí al juego... ¿Para qué puedo lanzar bolas de fuego si no le afectan a nada?  :-\
Y ¿Cómo mato algo?. A mi parecer la dificultad si está elevada  :-[