Hola buenas, tengo ganas de volver a programar un poquito y quisiera saber que forma es mejor de hacer algo y porque. Bueno mis dudas son respecto al rendimiento del juego, si afectan o no y cual es la mejor forma de hacerlo.

1. MISMA ROOM - Muchos objetos con poco codigo o Pocos objetos con mucho codigo.
2. Muchos sprites con pocas subimagenes o Pocos sprites con muchas subimagenes.
3. Mismo codigo en step o mismo codigo en otra evento.

Bueno, por ahora ya  :-[

Un saludo y gracias :3

Por lo que llevo programando, ésto es lo que te puedo contestar:

1) Pocos objetos con mucho código, acá te conviene usar lo que se llama reutilización de recursos, es decir, en vez de destruir un objeto lo volves a usar.
2) Esto como que es un poco lo mismo, todo depende de la función que cumpla el sprite, por ejemplo, si son solo imágenes de objetos o cosas así por ahí te conviene usar sub imágenes, en código también se vería más corto.
3) Yo te diría que en el evento Step trates de poner únicamente el código que vas a utilizar y poner condicionales para evitar que se ejecute todo el código constantemente ya que el evento Step se ejecuta a cada paso al igual que el evento Draw. Si podes te recomiendo utilizar funciones (Scripts en GM) ya que es mejor la reutilización de código por este método.

Concuerdo completamente con Iros. :D

#3 Marzo 02, 2015, 09:15:12 PM Ultima modificación: Marzo 02, 2015, 09:18:36 PM por matiascarpello
Haber, hay varias cosas que no aclaras, por ejemplo, para que dispositivo será el juego, eso influye. No es lo mismo un juego para PC que para Android, el rendimiento varía. y mucho.
Tampoco aclaras a que velocidad vas a desarrollar tu juego. 30 o 60 es lo más utilizado, aunque 30 ya casi no se utiliza, sobre todo en juegos con mucho movimiento, porque al estar a 60 fps se ve todo mucho más fluido.

Trataré de responder.
1)No se que es mucho para ti, pero es una comparación irrelevante.
Ya sea muchos objetos con pocos códigos o pocos objetos con mucos códigos siempre dependera de la optimización por como lo hayas programado. Si abusas mucho del step no va a importar si hay muchos o pocos objetos, el rendimiento se verá afectado. Ten en cuenta que el step se ejecuna en cada paso. Aveces se ahorra mucho utilizando alarmas en vez de step. Por ejemplo, que una alarma de repita cada 2,3,4,5 seg, etc.

2) Esto si que es inecesario. Lo único que importa con los sprite es la cantidad de ellos y como optimizas tu página de textura.
Cuando vas agregando sprites o background a tu juego, estos se van guardando en una página de textura. Por defecto, gamemaker guarda los sprite y los acomoda en una página de 2048px X 2048px. Mientras más paginas de texturas tengas, más se demorara gamemaker en cargar los sprite y background. Ahí es donde entra en juego el texture group para acudir al rescate.

3) Esto depende de como sea tu juego. El evento step es cuando necesitamos agregar un código que queremos que lea constantemente y a cada paso.

Por lo que solo tendrías que utilizarlo en esos casos. Pero como comente arriba, aveces es posible utilizar alarmas y se se repitan constantemente cada cierto tiempo y eso ahorra rendimiento.
Por ejemplo, Tienes un juego de plataformas, en donde al agarra una llave se habre una puerta. Resulta que la puerta al final de la room, mientras que la llave al inicio. Entonces la puerta tendría que tener un código para que cuando coliciones con la llave, la puerta cambie de sprite y se habra.

Lo lógico sería que coloques el código que habre la puerta en un evento step, pero en este caso no es ncesario porque recuerda que cuando hagarras la llave la puerta no se ve, esta al final de la room, por lo tanto como utilizaste alarma, no vas a notar el retardo de la puerta cambiando de sprite por una puerta habierta. ¿Me explico?

También hace falta tomar en cuenta el lado técnico, definitivamente matiascarpello tiene razón a la hora de decir a qué plataforma correrá la aplicación, así como los FPS, resolución de las imágenes, uso de sonidos, procesos en segundo plano y demás. Pero basándose en la arquitectura de una computadora (Que es la base de todo dispositivo como SmartPhone, ipad, tablet, etc) opino lo mismo que Iros:

1) Considerando que en sumatoria son las mismas líneas de código (o más o menos las mismas líneas), conviene usar pocos objetos con mucho código que muchos objetos con poco código. ¿Por qué? En primera, cada objeto se pasa a memoria cuando se está ejecutando; si tiene 50 objetos es menos espacio que 200 objetos. Además, Game Maker procesa los eventos de un objeto a la vez. O sea, que en cada STEP procesa un objeto y cambia a otro, así hasta terminar con todos los objetos. Hacer ese "cambio" de un objeto para procesar 200 es más la carga que hacer sólo 50 "cambios".

2) Pues... considera que el renderizado es el proceso más costoso de una computadora; ya que éste se hace en la tarjeta de vídeo y no se encuentra conectada tan "cercanamente" al procesador como es el caso de la memoria RAM, así que entre menos objetos tenga que renderizar le será mucho mejor para tu juego; estarías sacrificando costo en el procesador pero ahorrando renderizado. El costo de la memoria es "casi" la misma, ya que las imágenes que se están usando se cargan a memoria (cada subimágen).

3) Recuerda que los eventos STEPS, COLLISION y DRAW se ejecutan en cada Frame (cuadro) del juego. Así que entre menos uso hagas de éstos será mejor. Usa el STEP sólo en aquellas condiciones que se tengan que revisar cada cuadro; si la puedes reemplazar con cualquier otro (Evento de teclado, ratón, alarma, etc) te estarás ahorrando procesador. (Sé que muchos odian usar los eventos del teclado por lo inexactos).

Y ya que hablamos de tiempos, usa lo menos posibles las funciones de leer archivos de disco duro; es muy tardado abrir un archivo y pasarlo a la memoria y esto se puede ver reflejado por parte del usuario, ya que comúnmente la aplicación se "pausa" hasta haber leído todo el archivo. Claro, posiblemente este proceso dure 1/4 de segundo o menos, pero nada más te informo.