[Tutorial] Otimizando seus jogos de Game Maker

Navegando pela internet, reencontrei um artigo muito útil para os membros, que é exatamente como melhorar o desempenho dos seus jogos Game Maker. O artigo original é de autoria de Derek, e a fonte você encontra no fim do tópico. Seria ótimo se os membros também deixassem aqui suas dicas pra melhorar os jogos, aumente o conteúdo do tópico. Isso seria de extrema utilidade visto que o conteúdo é do ano de 2008 e muita coisa mudou de lá pra cá. Podem ter surgido novas formas de otimizar um jogo então é importante a participação dos membros em geral.

1. Desativar/Destruir Instâncias Não-Utilizadas

Instâncias retardam BASTANTE o Game Maker. Ouvi dizer que 50 instâncias é o máximo que você deve ter ativo de uma vez. E quanto mais trabalho um objeto está executando a cada Step, mais lento o mesmo será, então certifique-se de que não existam objetos ativos, caso não estejam sendo utilizados.

Para fazer isso, instance_destroy() e instance_deactivate() são seus amigos. Tente desativar qualquer coisa que está fora de vista do jogador, e destruir tudo o que está fora da sala.

Por exemplo, ponha isso no Step de um objeto invisível em uma room:

Código:

instance_deactivate_all(true);
instance_activate_region(view_xview[0], view_yview[0], view_wview[0], view_hview[0], true);

Certifique-se de que isso não desativará objetos importantes (como o objeto que executou o código!). Se você definir o argumento notme como true, o objeto irá ignorar a si próprio na desativação

2. Use Tiles Ao Invés de Objetos

Tiles são muito, mas muito mais rápidos que objetos, então você deve usá-los no lugar dos objetos sempre que puder. Você pode, na verdade, fazer um monte de coisas com os tiles, como criá-los e destruí-los, definir seu depth, achar sua posição, etc. Eles não são completamente estáticos.

Detalhes do fundo que você não interage são o materiais perfeitos para tiles.

3. Faça Menos Checagens de Colisão

Objetos com eventos de colisão são muito mais lentos do que os que não tem. Então coloque esses eventos nos objetos que terão menos instâncias. Um bom exemplo é um jogador contra 100 balas. Você óbviamente terá que fazer uma checagem de colisão entre eles... certifique-se de que o evento vá para o jogador ao invés da bala.

Funções de colisão (e cálculos de trigonometria) são, geralmente, muito pesadas, então é uma boa ideia ter, em menor quantidade possível. Certifique-se de que você não está fazendo a mesma checagem de colisão mais de uma vez num único frame/Step. Se você precisar você precisar saber o valor retornado de uma função lenta mais de uma vez, considere colocar o valor da colisão em uma variável e checar a variável.

Sempre que possível, desative o "Precise collision checking" das sprites, que é uma método de colisão por píxel.

4. Otimize O Uso Do Seu Evento Step

Eventos Step são executados a cada frame... então quanto mais você fizer no Step, mais lento o jogo será. Sempre que possível, reduza o tamanho dos seus eventos Step, e também a quantidade deles. Se você não precisa executar algo a cada Step, então não faça isso!

Uma alternativa é o uso de Alarms.

5. Desenhe Menos

Quanto menos usar o Draw, melhor.

Se você tem um background numa room, desative o background color

Tome cuidado com o uso de muitas views. Pra cada view, a room é redesenhada.

6. Reduza A Qualidade De Seus Sons/Músicas

Sons podem usar muito de sua memória e espaço, especialmente wavs e mp3s, então diminua sua qualidade se puder. Pergunte a si mesmo se a alta taxa de bits ou canal de aúdio duplo valem a pena.

Tenha em mente que o Game Maker não suporta mods e oggs, e mal suporta mp3s...

7. Use "Crop"/Corte suas sprites

Primeiro de tudo, olha cuidadosamente pras suas sprites e backgrounds. Sprites animadas tomam muito da memória e desenhar muitas sprites de uma vez então... Faça suas sprites o menor possível. Remova qualquer área inivsível em volta dela (Comando "crop" faz isso automaticamente). O mesmo se aplica à backgrounds.

8. Desative a sincronização

Em "Global Game Settings -> resolution" tem uma opção chamada "Use synchronization to avoid tearing"... certifique-se de que está desativada! Além de ajudar muito pouco nos problemas de tearing, isso pode reduzir e muito a velocidade do seu jogo.

9. Use Tiles Maiores, ao invés de mais Tiles

Enquanto tiles são mais leves que objetos, ter um monte deles ainda vai causar lentidão. Se você puder usar tiles grandes ao invés de pequenos, faça isso.

10. Desenhe os primitivos para a surface primeiro

Para funções como draw_circle, draw_rectangle, ou draw_line: Primeiro desenhe o primitivo a uma surface, e depois desenhe a surface na tela. É muito mais rápido assim.

11. Não use execute_string()

É muito lento.

---------------------------------

Essa é uma tradução livre. Fonte: http://forums.tigsource.com/index...topic=3747.0

---------------------------------

11. Use with's, switch's e else if's sempre que possível

Quando quiser se referir a um objeto por outro, use sempre with's, que são mais rápidos que objeto.variavel. Por exemplo, ao invés de:

Código:

bala = instance_create(x,y,obj_bala)
bala.speed = 10
bala.direction = 90
bala.dano = 8

Use:

Código:

bala = instance_create(x,y,obj_bala)
with(bala)
{
    speed = 10
    direction = 90
    dano = 8
}

O switch é muito mais rápido que o if, e pode substituí-lo em alguns casos. Exemplo, isso:

Código:

if laranjas = 1 {...}
if laranjas = 2 {...}
if laranjas = 3 {...}
if laranjas = 4 {...}
if laranjas = 5 {...}
if laranjas = 6 {...}

Pode ser substituído por isso:

Código:

switch(laranjas)
{
case 1: ...; break;
case 2: ...; break;
case 3: ...; break;
case 4: ...; break;
case 5: ...; break;
case 6: ...; break;
}

Nesse caso, o switch vai se encerrar caso uma das condições seja verdadeira por causa do break (economizando memória e "trabalho" do jogo).

O else if funciona como um break, mas no caso de if's. Por exemplo, nessas condições:

Código:

if laranjas = 0 {...}
if laranjas = 1 {...}
if laranjas = 2 {...}

O programa leria todas elas, mas agora nesse caso:

Código:

if laranjas = 0 {...}
else if laranjas = 1 {...}
else if laranjas = 2 {...}

O programa vai lendo de cima pra baixo e, se uma condição for verdadeira, ele dá o break e para de ler as condições (nesses casos é mais apropriado organizar as condições por ordem de probabilidade).

---------------------------------

Espero que seja útil pra alguém.

Até mais!

.Cara essa parte acho que esta errado

instance_deactivate_region(view_xview[0], view_wview[0], view_hview[0], false, true);
instance_activate_region(view_xview[0], view_yview[0], view_wview[0], view_hview[0], true);

.Ele vai desativar o que esta sendo visto e depois ativa-los de novo

.O certo é desatival a room toda,e depois ativar o que esta sendo visto.

instance_deactivate_region(0, 0, room_width,room_heigth, false, true);
instance_activate_region(view_xview[0], view_yview[0], view_wview[0], view_hview[0], true);

.Muito boa sua iniciativa

Fiz um tutorial bem parecido. Na verdade, também se baseia em parte no tutorial do Derek.

Veja: https://gmbr.forumeiros.com/t19480-melhorando-o-desempenho-dos-jogos

@Thyago:

Verdade, rs. Nem percebi (mas o erro foi do cara hein, haha)... Botei no exemplo o instance_deactivate_all(true).

@PedroX:

Eu nunca tinha visto esse seu tópico (e infelizmente muitos outros também, rs), mas acho que a gente pode aqui juntar todas as nossas artimanhas pra melhorar os jogos ainda mais nesse ponto.

Até!

cara, gostei de seu incentivo, e graças à ele, meu jogo ficou um pouquinho mais rápido (desativando o draw background das rooms que já tem background!)

Gonçalves escreveu:instance_deactivate_all(true);
instance_activate_region(view_xview[0], view_yview[0], view_wview[0], view_hview[0], true);

Você inverteu a situação! Era para estar assim:

PHProductions escreveu:instance_activate_all();//primeiro ativar tudo o que ta na area da view
instance_deactivate_region(view_xview,view_yview,view_wview,view_hview,false,true);//desativar tudo o que esta fora da view depois

Mas você foi um gênio ter feito esse tutorial, e ele também me ajudou com meu jogo!
Parabéns!

PHPproductions
.errado cara primeiro desativa tudo depois ativa o que esta na view

Você ativou tudo e depois desativou o que esta dentro da view>
Não vai ver nada
O jeito que o gonçalves fez esta certo

@PHProductions:

Obrigado!

Mas o que está lá está certo. Analisemos:

instance_deactivate_all(true) desativa tudo que tem na room, exceto o objeto que usou a função (por causa do true). Depois, instance_activate_region(view_xview[0], view_yview[0], view_wview[0], view_hview[0], true) ativa tudo que está à sua vista.

O seu código também está certo, o que diferencia é que no meu o argumento inside está ativado, o que faz com que as instâncias dentro da área citada sejam ativadas. No seu, está como false, que faz com que a ação ocorra com instâncias fora da área.

Os códigos farão a mesma coisa, só que de forma contrária: No seu ele ativa tudo e desativa o que está fora, e no meu ele desativa tudo e ativa o que está dentro.

@Thyago:

O dele funcionaria também, rs.

Valeu! Até mais!

EDIT: Adicionei uma dica minha ali. Me corrijam se tiver algo errado.

ficou bom seu tuto,alias tutos desse tipo sao muito importante,pois no gamemaker é facil para um jogo ficar lento...

ficou muito interessante,e tinha coisas que eu nao sabia ai.
eu tinha visto algo tambem em algum site,para melhorar algumas coisas de desempenho,mas ja faz muito tempo,e nao me recordo muito aonde era,mas se eu achar eu posto o link para ter mais sugestoes

flws ai \o

Bom, vamos lá, eu uso o Game Maker a bastante tempo e aprendi na prática várias coisas..

9. Use resoluções de Tela Menores

Isso está errado, o que influencia na velocidade do jogo é o tamanho da ROOM e não a sua exibição para o jogador. Claro que um jogo executando 640x480 vai ser mais rápido que 1024x768, mas a diferença é insignificante, agora compara um jogo rodando a 640x480, mas a room é 5000x8000.

5. Desenhe Menos

Isso também não tem muita relação com velocidade, fazer 1 objeto desenhando 10 coisas na tela (exemplo) é MUITO mais rápido que 10 objetos responsáveis um por cada elemento!

6. Reduza A Qualidade De Seus Sons/Músicas

Isso está extremamente incorreto, a quantidade de sons e músicas influencia no TEMPO DE CARREGAMENTO do jogo e não na VELOCIDADE (taxa de execução, fps), a solução para isso seria colocar os sons externos e carregar dentro do jogo (após o início), por meio do sound_replace ou sound_add, dependendo do tamanho do arquivo de áudio demora um tempo para carregar, ai entra uma barrinha de loading ou algum feedback visual para mostrar ao jogador que alguma coisa está carregando. Se existir 1 música por exemplo, para cada cenário, o interessante é descartar (sound_delete) e carregar o novo.

O tutorial é bom, mas se aplica ao Game Maker 6 e 7..

640x480 is fine for most games. I kind of regret making [Immortal Defense] 1024x768 -- it looks nice, but just the fill rate makes it much slower. Use dedicated resolutions, they work faster than windowed and much, much faster than stretched.

Esse é o conteúdo do nº9, fiquei meio cabreiro de postar porquê achei meio confuso. Ali diz que, uma resolução "decidada" é muito melhor que esticada, até mesmo que em janela. Creio que isso se aplique à fullscreen, acho que o que ele quis dizer é que, o Fixed Scale funciona melhor que o Full Scale e o próprio modo janela. Confere?

Isso não interfere em nada, o que acontece é que as sprites ficam com um aspecto um pouco estranho, por exemplo se você fizer o jogo na proporção (aspect ratio) 4:3 (padrão antigo) e esticar o jogo para mostrar em 16:9 (widescreen), vai causar um achatamento da imagem, mas com relação a velocidade, é outra mentira.

Inclusive, se você faz um jogo rodar em 2x, ele acaba ficando mais rápido do que se ele for feito na proporção 2x (nas sprites e tamanho da room), por exemplo.

Bom, removi essa parte do tutorial. Qualquer outro apontamento a fazer, faça-o.

Sobre o "Desenhe Menos", ele não chega a se referir Draw exatamente, mas as views e backgrounds. (Acho que ele escolheu o título dessa parte equivocadamente, o que pode confundir os leitores)

E reduzir a qualidade dos sons pode diminuir e muito o tamanho do projeto, mas quanto à velocidade, já não sei dizer.

Valeu!

O que interfere no desempenho é o "Interpolate colors between pixels", quanto maior a room (com ele ativado), mais lento fica.. Mas dependendo do caso é imperceptível.

Porém é válido ressaltar, que o post é de 5 anos atrás, o desempenho dos equipamentos era menor (até para jogos comerciais), hoje eu acho desnecessário ficar restringindo a qualidade do jogo por questões de 1 ou 2 fps, obviamente que não é pra fazer um jogo 2D e as especificações mínimas de um jogo comercial, enfim essas limitações ERAM um problema, hoje em dia não são tão preocupantes..

Gente! Isso tá se tornando uma discussão! Calma! O cara quis apenas compartilhar sua experiência conosco! Não há tantos motivos assim para tal discussão! Tá certo que algumas coisas que o gonçalves postou não afetam o desempenho em quase nada, mas poxa, o cara está tentando nos ajudar e ajudar os iniciantes a serem cautelosos ao criar jogos grandes.
Eu sei que vão reclamar desse meu post, mas em algo eu devo ter alguma razão! Gonçalves quis ajudar e não gerar discussão.

O objetivo de um fórum é justamente POSSIBILITAR discussões, eu não acho que isso seja algo ruim, muito pelo contrário, ele postou o tutorial, eu corrigi o que estava incorreto e todo mundo sai ganhando. Compreende onde eu quero chegar? Se não fosse pra discutir isso, aqui seria um BLOG e não fórum!

Mestre escreveu:O objetivo de um fórum é justamente POSSIBILITAR discussões, eu não acho que isso seja algo ruim, muito pelo contrário, ele postou o tutorial, eu corrigi o que estava incorreto e todo mundo sai ganhando. Compreende onde eu quero chegar? Se não fosse pra discutir isso, aqui seria um BLOG e não fórum!

Concordo Plenamente. Se você compartilha de algo não deve esperar somente elogios ou agradecimentos, porque nem tudo é perfeito. Porem também confesso que esse tutorial é bem útil para optimização de um jogo. Uma dica que eu acho que seria muito boa e utilizar nomes de variáveis menores e fazer um mapeamento, porque nomes-curinga menores gastam menos memória. E claro que essa técnica visa melhorar o desempenho em jogos gigantescos com programações e sistemas impressionantes no GM, mas é sempre bom dar uma ressalva não é mesmo ? Outra dica também é ter organização, porque alem de ajudar a si mesmo, optimiza o código. Faça sempre uma releitura e veja o que pode melhorar, porque assim o jogo funciona melhor, evita bugs e etc. Ainda também apoio usar o AntiDec.exe com a opção remove errors code e compress runner, para melhorar o desempenho e diminuir o tamanho do executável principal.

Ótimo tutorial,há jogos aqui no fórum que são tão pesados que é desanimador baixar, não concordo com TRFN, a organização ajuda em alguns casos, porém na maioria das vezes guardar tudo em pastas ou nomear tudo certo não ajuda no desempenho do jogo, ajuda o criador do jogo mas não melhora nada, mas estou falando no sentido de sprites e objetos, óbvio que vai ficar mais rápido tirando espaços vazios de sprites ou tirando codes que são insignificantes por exemplo

Se vocês tiverem alguma dica pra acrescentar ao tópico, manda aí! Eu postei uma lá já, rs.

Obrigado!

The Wizard escreveu:não concordo com TRFN, a organização ajuda em alguns casoso

Não me referia a pastas, mas sim aos códigos. O tempo de execução é mais rápido. Em momento algum falei de recursos.

yooo... desculpe TRFN pensava que estava se referindo a recursos, imaginei que estava falando de codes, por isso disse

mas estou falando de sprites e objetos, é obvio que irá melhorar se retirar codes insignifcantes por exemplo

eu sei que não se referia as pastas, falei isso pois faz parte da organização