Como criar um sistema estilo Bomberman?

[Jorge_Maker]

Minha nossinhora, entre 2 e 4 fps? Isso é péssimo. uahuae'
Te enviei o arquivo com o novo método. Na teoria ele é mais leve, no entanto, como eu já disse, não vai fazer milagres. Testei ele com o mapa cheio e usando o anti lag do Victor/Atoa, a taxa de fps ficou oscilando entre 29 e 34 fps, oque não é tão bom, mas considerando que testei em um notebook completamente defasado, isso até que não é tão ruim também. hue'

[Geraldo de Rívia]

Opa, bom que conseguiram! Pela GIF e com as animações, ficou muito bacana.

Se não conseguirem resolver a questão da performance, posso dar uma olhada também pra tentar ajudar em algo. Na minha cabeça não era pra um sistema desse lagar. E acho que anti-lags não funcionarão também não, pois eles só funcionam em eventos fora do campo de visão da tela, aí, todos estão visíveis.

[Jorge_Maker]

Realmente, Gerar, depois que você disse fui testar aqui, e o script do Atoa não faz diferença alguma na performance. xD o do MOG que o Hammer estava usando deve fazer algo similar ao script do Victor, logo, não adiantou de muita coisa também.
É que eu lembro que no RPG Maker XP tinha um anti lag que era como RTP da engine, geral usava. Ele não só parava a atualização de eventos fora da tela, como também aumentava a prioridade do RPG Maker em relação a outros programas ativos. Em um projeto que o testei, a taxa média de fps subiu de 6~10 para 16~19. (20 é a taxa normal no XP)
Mas ainda, assim, se houvesse algo similar pro Ace, não tenho certeza se iria funcionar nesse caso em específico, sou completamente leigo nessa questão. uahueh'

[HammerStrike]

Eu testei colocar bastante eventos na demo e a taxa ficou boa com 57 a 60 fps, até aqui tudo nice, entretanto quando eu copio para o "main project" fica com 3 de fps. Fiz uns testes e descobri qual é o problema a principio, por algum motivo (não entendo nada) quando coloca mais script no projeto mais lento fica, fui adicionando scripts na demo aleatoriamente e a cada 2 script mais ou menos ele caia uns 5 fps, independente do script, mesmo os relacionado a batalhas e outras coisas. Será que tem como solucionar isso ou azedou?

Té mais.

[Geraldo de Rívia]

Com ou sem o sistema, o projeto principal fica com essa taxa de FPS baixa ou somente com o sistema? Porque, eu não sei pois não vi o sistema ainda, mas se há processos paralelos e os scripts que tu tá adicionando trabalham com os eventos, são mais coisa pro sistema verificar a cada processo paralelo lido.

[HammerStrike]

Com ou sem o sistema, o projeto principal fica com essa taxa de FPS baixa ou somente com o sistema? Porque, eu não sei pois não vi o sistema ainda, mas se há processos paralelos e os scripts que tu tá adicionando trabalham com os eventos, são mais coisa pro sistema verificar a cada processo paralelo lido.

Só quando adiciona o sistema e só no mapa que ele funciona.

[Geraldo de Rívia]

Olhei aqui a demonstração e realmente não tem como esse sistema não lagar. Todos os eventos destrutíveis checam em processo paralelo a cada frame se a bomba explodiu à distância especificada, mesmo se ela não tiver explodido, pois a condição que checa se ela explodiu está depois do método que checa a distância, e mesmo que estivesse antes não adiantaria muito, pois essa condição não está configurada.

Ajeitar essa condição e colocá-la antes de verificar se o destrutível está à distância da bomba ajudaria, pois os destrutíveis parariam de verificar se estão à distância de uma bomba que nem explodiu ainda. Porém, quando ela explodisse, o jogo teria que fazer um cálculo absurdo de uma hora pra outra, pois essa condição seria satisfeita em todos destrutíveis e todos verificariam se estão à distância. Nessa hora o FPS cairia.

Eu acho que não há necessidade de cada destrutível verificar isso. Muitos eventos no mapa por si sós já pesam um pouco, cada um deles tendo processo paralelo seria inviável. Processo paralelo não deve ser usado em massa.

Eu fiz algumas mudanças aqui aproveitando o que já fizeram, caso queira testá-las, seguem: o primeiro passo é remover o processo paralelo dos destrutíveis, fiz isso deixando-os com duas páginas, assim:

[hs width=200]https://i.imgur.com/l93PCks.png[/hs] [hs width=200]https://i.imgur.com/tc2RAYH.png[/hs]

Como agora eles não vão verificar as consequências da bomba, precisaremos fazer um meio para tal, e fiz isso editando o código. Agora, ao invés de um método que é chamado constantemente, teremos um que é chamado somente quando a bomba explodir, realizando todo o trabalho pesado na sequência.

module Bomba
  ID_DA_BOMBA = 2
  ID_DA_ANIMACAO = 2
  AOE = 1

  def self.kabum
    xO = $game_map.events[2].x
    yO = $game_map.events[2].y
    range = AOE
    p xO
    p yO
    
    xMin = xO - range
    xMax = xO + range
    yMin = yO - range
    yMax = yO + range
    
    while xMin <= xMax do
      eventId = $game_map.event_id_xy(xMin, yO)
      if eventId > 0 && eventId != ID_DA_BOMBA
        $game_self_switches[[$game_map.map_id, eventId, "A"]] = true
      end
      xMin += 1
    end
    
    while yMin <= yMax do
      eventId = $game_map.event_id_xy(xO, yMin)
      if eventId > 0 && eventId != ID_DA_BOMBA
        $game_self_switches[[$game_map.map_id, eventId, "A"]] = true
      end
      yMin += 1
    end
    
    pRange = ($game_player.x - xO).abs + ($game_player.y - yO).abs
    if pRange <= range
      $game_player.animation_id = ID_DA_ANIMACAO
    end
  end
end

ID_DA_BOMBA é o ID do evento da bomba no mapa, ID_DA_ANIMACAO é o ID da animação executada no jogador quando ele estiver no alcance da bomba e AOE é o alcance da bomba, em tiles.

E com o método criado, precisamos chamá-lo quando necessário. E fiz isso no próprio evento da bomba, assim que ela explode.



Após essas alterações, vê se o resultado melhora. Eu não verifiquei tudo, talvez consigamos enxugar mais algo caso seja necessário.

[HammerStrike]

Ficou muito bom Gerar:

Essa queda de fps no começo é por conta do programa de gravação dos gifs, no jogo mesmo está rodando liso.

Seria que teria como colocar a animação do bloco destruindo igual estava antes?
OBS: Jorge mandou beijos.

EDIT: Outra duvida é como que eu posso criar inimigos que ao morrer adicionem um valor de variável (porque eu quero colocar um sistema que quando todos os inimigos morrem um portal se abre).

[Geraldo de Rívia]

Então, se tu reparar no código, quando a bomba explode ela verifica se há eventos ao redor e, se há, ativa a Switch Local A deles. A segunda página dos destrutíveis é a que é ativada pela Switch Local A. Assim sendo, é só tu fazer a animação nessa página, e no fim da animação, ativar outra Switch Local que leva à página que vai ficar sem nada. Eu não lembro da animação, então não sei se há algum problema em fazê-la assim e é até bom tu testar assim pois seria um meio de tu fazer inimigos também, caso vá fazer.

[CleanWater]

EDIT: Outra duvida é como que eu posso criar inimigos que ao morrer adicionem um valor de variável (porque eu quero colocar um sistema que quando todos os inimigos morrem um portal se abre).

Isso é simples. Na parte do evento em que eles morrem, você adiciona uma variável que vai aumentar o valor em 1, até chegar ao valor necessário pra abrir a porta.

Se for por eventos no maker, acho que já sabe como fazer. Se for em código:

$gameVariable[id] += 1;

No evento da porta, você vai colocar como condição para o evento "aparecer" na tela, o valor da variável que criou no maker.

[Crixus]

Sobre LAG que pode ocorrer devido ao número de eventos no mesmo mapa.
No Rm2k/2k3 é possivel trocar um tile (Não Tileset) por outro.

Neste caso cada tileset precisaria ter varios tiles iguais e um que seja o chão padrão de baixo dos objetos destrutiveis.

Cada tile seria para um pedaço do mapa, eu não sei se no VX e ACE voltaram a ter essas opções, claro que teria de usar RGSS para acertar esses tiles como eventos.

Só uma idéia.

[edit]
Existe um Script para Rpg Maker XP que faz isso, é este:
https://forum.chaos-project.com/index.php?topic=11353.0

[HammerStrike]

Valeu pelas dicas ai galera, a solução do Gerar deu certo aqui. Parece que o sistema agora ta funcionando 100%, vlw pela ajuda.