Frames e alguns detalhes na engine do RM

Há pouco mais de uma semana, me pediram pra desenvolver um certo minigame. Comecei a desenvolvê-lo pelo RM VX e percebi que havia algo estranho com os frames, eles pareciam ter tamanhos diferentes, dependendo da situação. Depois, fui transferir o minigame para o RM XP. Aí é que as coisas se complicaram, mesmo, os frames pareciam estar totalmente loucos. Discuti o problema com um pessoal do chat e, algum tempo depois, o maniaconfloor veio com a solução, que me tirou das trevas da ignorância. Resolvi, então, publicar um texto discorrendo sobre frames e apresentando alguns detalhes sobre eles.

"O que são frames?" Frames são unidades de tempo. Você talvez já tenha visto em algum Maker que 60 frames são iguais a um segundo, por exemplo. Nesse caso, o frame seria uma unidade de tempo 60 vezes menor que o segundo. No entanto, o tamanho do frame varia de um Maker para outro e, além disso, ainda pode ser alterado por script. Eles também podem sofrer algumas alterações de acordo com o seu computador. Para ver a quantos frames por segundo seu jogo está rodando, aperte F2.

Depois de ter alguns problemas com frames, no RM VX, resolvi fazer um teste: fiz dois timers (relógios). Um deles aumentaria o valor de uma certa variável em 60, em processo paralelo, após 60 frames. O outro aumentaria outra variável mas, dessa vez, com 1 frame de espera. Eu esperava que, a cada 60 frames, ambas variáveis possuíssem o mesmo valor. Mas o que ocorreu foi que a primeira variável ficou com o dobro do valor da segunda. Para o RM XP, repeti a mesma experiência mas, dessa vez, a primeira variável ficava 1,5 vezes o valor da segunda. Como se não bastasse estar diferente em um único Maker, ainda divergia entre Makers diferentes!

Aí que o maniac veio com uma outra experiência: ele programou para que, durante 60 frames, dois relógios funcionassem: um funcionaria em processo paralelo, sem tempo de espera; o outro funcionaria em processo paralelo, com 1 frame de espera. Repetiu a experiência para o VX e para o XP, obtendo os seguintes resultados: no VX, após esperar 60 frames, o primeiro relógio deu um resultado de 60 e o segundo deu um resultado de 30; no XP, após esperar 60 frames, o primeiro relógio deu um resultado de 120 e o segundo deu um resultado de 40. Aí ele propôs a seguinte solução: para evitar "crash" (excesso de processamento, que faz o jogo travar), a engine do RPG Maker adiciona um tempo de espera ao final de processos paralelos. No entanto, o VX adiciona 1 frame, enquanto o XP adiciona meio frame.

Então, o que ocorre nos relógios do VX é o seguinte: o primeiro espera 1 frame, aumenta a variável, repetindo isso 60 vezes, até que marque 60; o segundo espera 2 frames e aumenta a variável, repetindo isso 30 vezes (60 frames), marcando o valor 30. Já no XP, o primeiro aumenta a variável a cada meio frame e, já que isso se repete durante 60 frames, marca o valor 120; o segundo relógio espera esse meio frame e mais 1, totalizando 1 frame e meio de espera entre cada incremento de variável, durante 60 frames, marcando o valor de 40 na variável (60/1,5 = 40).

Pronto, está resolvido, agora, já sabemos por que ocorre essa divergência. Mas algo nisso me incomodou: o RM XP parte os frames ao meio! Isso significa que você pode ter muitos problemas se precisar trabalhar com medidas precisas de tempo e que repetem um processo paralelo por muito tempo. Como você não pode mandar um evento esperar meio frame, isso te impõe algumas limitações.

No entanto, pra resolver isso, basta que, em vez de deixar o evento ocorrer em processo paralelo, crie um ciclo para contar o tempo. Mas lembre-se de que, no ciclo, precisa haver um tempo de espera, exatamente para evitar o "crash". Então, mande o ciclo esperar 1 frame, ao seu final, e os frames não serão mais partidos, ficando com o funcionamento semelhante ao do VX.

Mais uma coisa que percebi, nesse estudo de frames, foi que o VX era 3 vezes mais rápido que o XP, por padrão. Ou seja, enquanto o VX rodava a 60 fps (frames por segundo), o XP rodava a 20 fps. Isso, no entanto, pode ser alterado por script. Para o RM XP, basta colocar isto no Main, logo abaixo do "begin": Graphics.frame_rate = (VALOR), substituindo pelo valor desejado.

Nas próximas semanas, ainda continuarei atualizando o blog com baixa freqüência, mas pretendo aumentá-la em dezembro.

Até a próxima.

"Lehanius, como você aprendeu a fazer isso?"

Olá, pessoal! Ultimamente tenho ouvido essa pergunta com alguma freqüência, então vou falar um pouco da minha tragetória (até então) como programador de eventos e contar uns "segredinhos" de como aprender a programar desde eventos simples até sistemas mais complexos.

Eu conheci o Maker quando a versão 2000 ainda era novidade. Eu mapeei coisa ou outra, mexi um pouco no database e logo parei de usá-lo. Alguns anos depois (há uns 2 anos), eu conheci o RM XP, em que comecei a mapear bastante e a fazer uns poucos eventos bem simples, apenas com uso de switches locais e switches globais, mas logo parei de usá-lo, também. Em agosto deste ano, baixei o RM VX e conheci o fórum da RPG Maker Brasil, que chamou muito minha atenção. Empolgado em ver que a comunidade Maker tinha um tamanho respeitável, comecei meu primeiro projeto no VX, determinado.

Montei a base da história, fiz uns montes de mapas, editei o database, mas aí vi que estava faltando algo no meu jogo. Eu queria passar uma sensação de mistério em um dos meus mapas, com algum recurso visual. Foi então que me envolvi em meu primeiro sistema: fazer com que as tochas de um corredor se acendessem conforme o personagem fosse avançando por ele e que elas se apagassem à medida que ele voltasse. Adivinhem pra quem eu pedi que fizesse esse sistema pra mim? Pra ninguém, é claro. Afinal, se eu mesmo podia fazer aquilo, por que pediria a alguém?

Comecei fazendo a tocha se acender quando eu passasse, algo bem simples, só precisaria de uma switch. Certo, já estava começando a funcionar, mas eu ainda tinha que fazer mais tochas e elas deveriam se apagar quando eu voltasse, e somente quando eu voltasse. Isso, sim, me deu um grande trabalho, fiquei por muito tempo pensando, programando, testando, errando, corrigindo. No final, acabei usando uma variável e algumas linhas de programa e, mesmo que o sistema parecesse simples pra tanto esforço e tempo, me sentia recompensado: afinal, eu tive o sistema que queria e, melhor ainda, EU o havia feito! A satisfação foi um prêmio muito grande, mas prêmio maior que aquele foi o conhecimento que eu adquiri, o meu aprendizado!

Ah, eu deveria ter dito algo antes de começar, uma advertência: programar vicia! Assim que eu terminei meu primeiro pequeno desafio, abastecido pela satisfação e motivado pela consciência de que eu estava aprendendo, parti para um desafio um tanto mais ousado: o puzzle da Torre de Hanói (disponível pra download). Como um dos meus puzzles favoritos, resolvi encaixá-lo, de uma forma discreta, em meu jogo. Desde o começo da programação, eu sabia que não seria fácil mas, poxa... não achei que seria tão complicado! Passei algumas horas tentando entender algumas funções do Maker e pensando em formas de programá-lo. Comecei a fazê-lo de uma forma mas, depois de várias tentativas e vários erros, resolvi montar o programa de forma diferente, comecei tudo denovo. Passei mais algumas horas queimando a cabeça e errando muito, mas consegui o meu puzzle! E sozinho! A recompensa? Satisfação e conhecimento.

Já me sentindo com um conhecimento razoável na programação de eventos, resolvi, então, ver o que os outros Makers faziam e tinham pra mostrar. Visitei vários tópicos sobre sistemas por eventos. Alguns eu só lia e já pensava: "esse eu sei fazer" ou, então "caramba, como ele fez isso?". Mas, em qualquer dos casos, eu analisava como o sistema havia sido feito. Mesmo os sistemas simples, às vezes, eram feitos de maneira muito interessante e inteligente. Um, entre os sistemas que me marcaram, foi o sistema de teleporte do Leandro_Frodox. Eu, até então, não havia mexido com variáveis que armazenavam posições no mapa. Haviam, também, alguns outros na RMB, como o Mobyduck, que me motivavam a continuar crescendo como programador de eventos e com cujos sistemas eu aprendia vários novos conceitos.

Com algumas idéias novas, resolvi criar um jogo bem inovador pro jogo de um amigo, o Vida de Slime, do Leandro306. Daí que nasceu o Digletball! Dessa vez, além da satisfação própria e do conhecimento adquirido, tive, também, algum reconhecimento pelo meu trabalho, o que me motivou a fazer coisas ainda mais ousadas. E não pense que, dessa vez, foi fácil fazer! Apesar de que eu já tinha a idéia pronta, na cabeça, me deparei com vários problemas e erros, que, evidentemente, tive que entender e corrigir.

Mas não é só de grandes desafios que absorvemos conhecimento e, até, reconhecimento. Sempre havia alguém no fórum pedindo algum sistema que eu poderia fazer, facilmente, por eventos. Eu contribuía com idéias para os mais simples e até me propunha a fazer os mais complicados. De vez em quando, eu até me surpreendia, quando percebia que aquele sistema, aparentemente simples, era, na verdade, muito complicado! Um exemplo são os binóculos que fiz para o txmaster, pro RM XP. Aliás, sem a idéia inicial do Neto RPG, eu provavelmente não teria conseguido nem começar o sistema. Depois que comecei, mais 6 horas pra terminá-lo... 6 horas corrigindo problemas imprevistos, até eu sentir que eu já havia feito o melhor possível.

É importante trocar idéias com outros programadores, principalmente pelo fato de que o RM tem muitos recursos. Eu, que já fiz muitos sistemas e minigames, ainda não devo ter usado nem 40% dos recursos que a programação de eventos oferece, e muitos desses recursos eu descobri vendo sistemas de outras pessoas. Além disso, mostre seus trabalhos pra outros, mas sem medo de críticas. Afinal, é por meio delas que percebemos alguns defeitos que podem ser melhorados. Permita que te ajudem e ajude os outros.

Espero ter sido claro em mostrar pra vocês o meu posicionamento quanto à programação de eventos, pois acho que é devido a essa postura que eu estou aprendendo tanto. Mas vamos recapitular: não tenha medo de desafios, encare os problemas; erros e problemas vão aparecer, e cabe a você corrigí-los, mesmo que você tenha que dar algumas pausas pra arejar a cabeça; ajude sempre que puder, pois ensinar é uma das melhores formas de consolidar o conhecimento; peça opiniões e aceite críticas a seus programas; estude os sistemas de outras pessoas. E vai uma dica a mais, se você quiser fazer coisas realmente boas: estude matemática! Além disso, obviamente, você não pode se esquecer do seu lema: "desistir? Jamais!".

É isso aí, pessoal... dessa vez o texto ficou um tanto grande, mas acho que vale à pena ler, se você tem interesse em programação. Além do mais, a RMB (e toda a comunidade brasileira de RM) está carente de gente que entenda razoavelmente de eventos. Que tal a gente começar a mostrar mais serviço? Eu adoraria ver ótimos sistemas por eventos na RMB toda semana, em vez de uma vez a cada 2 meses. Se você realmente se interessa nisso, terá o meu apoio, mas eu quero ver esforço, pois sem esforço não há evolução.

Finalmente, eu gostaria de agradecer a todos que me apoiaram na minha então tragetória no RM e àqueles que continuam me apoiando. O Leandro306 e o TAXD me incentivaram bastante, no início, e continuam incentivando. Todo o pessoal do chat da RMB tem sido bastante receptivo aos meus trabalhos e isso também me motiva bastante. Muito obrigado. Cabe um agradecimento especial pro maniacofp... quer dizer, maniaconfloor, por me aturar mandando sistemas todos os dias (várias vezes por dia) pra ele e ainda por comentar cada um deles, sempre dando boas sugestões de como eu poderia melhorá-los... exceto quando estão perfeitos! (Huahuahua)

Brincadeiras à parte, espero que tenham gostado das dicas e que a leitura não tenha sido muito chata. Vou colocar um link no blog pros downloads de alguns sistemas que criei. Aos que permanecem na luta, vamos mostrar praqueles japoneses que os brasileiros não somos pamonhas no RPG Maker!

Abraço!

Programação de Eventos

Como prometido, falarei um pouco sobre as possibilidades na programação de eventos e a sua importância em um jogo. Muitas pessoas não valorizam a programação de eventos, com a ilusão de que dezenas de scripts farão tudo que o seu jogo precisa. Não estou aqui pra condenar o uso de scripts, de forma alguma, mas cabe lembrar que a programação de eventos não é substituível por eles.

Então, o que essa tal programação de eventos tem de interessante? Ora, é possível fazer de quase tudo com ela! Além de que o RPG Maker faz com que a programação possa ser feita de maneira bastante intuitiva e sem qualquer conhecimento de linguagens de programação. Com ela, é possível fazer desde um sistema de depósito de itens (um banco) até complicados sistemas de interação com o ambiente e com NPCs com inteligência artificial. Se você nunca viu nada de interessante feito por eventos, tenho certeza de que você mudará de idéia, se continuar acompanhando este blog, pois pretendo colocar links de tudo aquilo que eu achar interessante sobre isso.

Agora que você já se animou pra saber mais a respeito disso, vou falar um pouco dos meus trabalhos como programador de eventos. Se você participa do fórum da RPG Maker Brasil, é possível que já conheça um pouco dos meus trabalhos. Eu, geralmente, costumo fazer alguns sistemas que o pessoal pede, na RPG Maker Brasil (RMB), ou dar sugestões para esse tipo de sistemas. Além disso, gosto de criar sistemas mais desafiadores que possam servir de puzzles, minigames ou mesmo como meras ilustrações, mas que tornem o jogo mais atraente.

Também gosto de compartilhar meu conhecimento, principalmente sobre eventos, com os outros makers. Um dos trabalhos que levei mais tempo pra concluir e que demandou bastante esforço foi um tutorial sobre o uso de variáveis na programação de eventos, em 6 aulas, publicado na RMB. Na verdade, ainda falta digitar a 6ª aula, mas a demo do tutorial já está pronta. Agradeço, inclusive, ao pessoal que me apoiou pra terminar essa demo. Possivelmente, irei publicar esse tutorial aqui, no blog, também.

Agora que você já percebeu a importância de se saber como programar eventos e já conhece um pouco de mim, vou deixar o vídeo de um dos minigames que criei, para o projeto Vida de Slime, do Leandro Marinho. Pode até parecer muito complicado, mas é possível aprender a fazer algo assim em pouco tempo. Por hoje está bom... da próxima vez darei umas dicas de como aprender a mexer bem com eventos. Fique, agora, com o famoso Digletball (hehe):