Lehanius RPG Maker

Mais Três Scripts e Novas Atualizações

2012-01-25T00:38:00.003-02:00

Fiquei algum tempo sem atualizar adequadamente o blog, a medida em que fui lançando novos scripts e atualizações. Tanto o Time & Sun quanto o Event Vision foram atualizados; o primeiro, apenas para uma pequena correção e o segundo para acrescentar novas funções e arrumar o modo de teste.

Além disso, lancei três novos scripts:
Dynamic Troops
Eventer Tools
Pathfinder

Os três são para o RM VX Ace, já que só desenvolvo para o Ace agora. Ao longo da próxima semana pretendo detalhar cada um dos três scripts, para manter o blog devidamente atualizado.

RPG Maker VX Ace e Processos Paralelos

2012-01-18T09:40:00.002-02:00

Enquanto fazia um pequeno script para meu projeto, me deparei com um problema no RPG Maker VX Ace. A condição de script Input.trigger?(:C) apresentava algumas falhas quando colocada em um evento em processo paralelo.

Felizmente, isso me remeteu a um problema que tive em 2008 e que pude resolver com a ajuda do maniaconfloor. Enquanto o RPG Maker XP espera 1/2 frame a cada ciclo de processo paralelo e o RPG Maker VX espera 1 frame, o Ace espera 2 frames. (Me pergunto se no próximo RM esse tempo será de 4 frames.)

O teste foi similar ao feito em 2008. O problema desses 2 frames de espera é que o Input.update é feito a cada frame, então o processo paralelo corre 1 frame a mais, sem o update, gerando buracos na verificação do pressionamento da tecla.

A solução? Iniciar Ciclo, com comando de esperar por 1 frame dentro dele.

Time & Sun vxa.1.0

2012-01-04T22:57:00.002-02:00

Como fan de sistemas realistas, não resisti e fiz um novo script. É como um sistema de dia e noite, mas a mudança de tonalidade é contínua durante todo o dia. As tonalidades são facilmente ajustáveis para qualquer período do dia e as mudanças de tom podem ocorrer devagar o suficiente para que o jogador só perceba a mudança de tom a longo prazo. Também incluí a possibilidade de se mesclar um tom ambiente com a iluminação solar, para que cada mapa possa ter sua própria individualidade de tom.

Confira seu tópico oficial na Santuário:

Time & Sun VXA

Event Vision vxa.1.2.1

2011-12-31T14:45:00.002-02:00

RPG Maker VXAce tá aí! E aqui vai meu sistema de visão para eventos também para o Ace, na versão 1.2.1. Ele também conta com a possibilidade de se usar terrain tags para fazer com que tiles sejam transparentes - para que os eventos vejam através deles - ideal para usar em água e buracos.

Como de costume, o sistema está no meu 4shared e o seu tópico oficial postado na Santuário:

Event Vision VXA

Event Vision xp.1.1.0

2011-01-22T12:16:00.003-02:00

A versão desse sistema para o RM XP finalmente saiu. Resolvi nomeá-lo já como versão 1.1.0, por ser semelhante em funcionalidades ao script do VX. No entanto, esse script para XP oferece a possibilidade de se usar terrain tags como indicadores de transparência de tile, tornando essa tarefa mais simples.

Ele está disponível na Santuário:
Event Vision XP

Event Vision vx.1.1.0

2011-01-20T03:50:00.004-02:00

Em outubro de 2010, lancei a versão vx.1.0.0 deste sistema, na Santuário. Em janeiro de 2011, atualizei o tópico na Santuário e postei a versão já atualizada na ReinoRPG. Ele pode ser baixado na versão vx.1.1.0 nesses dois sites ou diretamente da minha pasta no 4shared.

Esse é um sistema de visão para eventos, que encontra-se devidamente detalhado nos respectivos tópicos nos sites supracitados.

Event Vision System VX na Santuário

The Undead RPG Maker Blog

2011-01-20T03:16:00.002-02:00

Olá!

Este blog, que há muito estava morto, acaba de ser desenterrado das profundezas abissais e retornará de uma forma bastante diferente. Provavelmente agora ele será utilizado apenas para apresentar e atualizar informação sobre eventuais sistemas que eu tenha desenvolvido ou venha a desenvolver. E esses sistemas não estarão na forma como estão acostumados a ver (por eventos), pois pretendo aproximá-los o máximo da forma plug-and-play, o que nos leva aos scripts.

Scripts, sim. Uma provável surpresa pra quem se acostumou a meus mirabolantes sistemas por eventos. Devo antecipar que ainda não tenho muito estudo de RGSS e que a forma dos meus scripts pode não estar muito elegante, mas minha principal preocupação neste momento é a funcionalidade dos sistemas. Também devo avisar que minha produtividade será lenta, pois outras prioridades tomam maior parte do meu tempo.

Resolvi voltar com o blog para que meus sistemas tenham uma referência principal, onde é certo que todos eles estarão atualizados. Percebi a necessidade de haver essa referência a partir do momento em que meus sistemas se difundiram para outros sites, em que pode não haver a preocupação de atualizá-los. Por hora, o único site em que garanto conteúdo sempre atualizado é este: http://www.santuariorpgmaker.com/

Este blog também pode ser um meio mais definitivo de contato, onde os sistemas poderão ser livremente discutidos, caso surjam sugestões ou bugs.

Bom...

Frames e alguns detalhes na engine do RM

2008-11-18T15:59:00.002-02:00

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?"

2008-11-07T19:36:00.005-02:00

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

2008-11-03T15:26:00.004-02:00

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):

Apresentação

2008-10-31T08:39:00.000-02:00

Olá, visitante.

Resolvi criar este blog a fim de reunir meus trabalhos e minhas idéias sobre RPG Maker.

Pra quem não conhece, o RPG Maker é um software de desenvolvimento de jogos amadores, voltado para o RPG (Role Playing Game - Jogo de Representação de Papel). O RPG Maker é baseado no padrão dos RPGs eletrônicos clássicos como Final Fantasy (até o FF6) e Chrono Trigger. No entanto, ele permite que se fuja desses padrões (mesmo não sendo fácil), apesar de que eles são bem recebidos por quem conheceu alguns desses clássicos.

A maioria dos jogos feitos no RPG Maker segue esse padrão clássico e possui gráficos com qualidade muito aquém daquela vista nos jogos mais modernos. O que, então, atrai pessoas para esse tipo de jogo, já que não possui gráficos maravilhosos? Se você está se perguntando isso, provavelmente nunca jogou Chrono Trigger ou mesmo alguns dos mais conhecidos jogos nesse estilo. Ora, o que interessa, aqui, é a história e a jogabilidade.

Veja, por exemplo, o RPG de mesa: ele não necessita de recurso gráfico algum. Basta um enredo envolvente, situações inusitadas, desafios, uma boa gama de possibilidades e um sistema de jogo interessante para que se faça uma aventura excelente. Se, até hoje, existem muitos fãs do RPG de mesa, como eu, é só tentar levar características dele para o RPG eletrônico para se produzir um ótimo jogo, independentemente de sua qualidade gráfica.

Atualmente, estou aprimorando minhas habilidades para garantir uma boa jogabilidade, desenvolvendo sistemas interessantes que deverão prender a atenção e promover o entusiasmo do jogador. Esses sistemas são, às vezes, chamados de "extras", mas são, ao contrário do que o nome sugere, essenciais para um bom jogo.

Meu foco principal no RPG Maker é, atualmente, a programação de eventos. Da próxima vez falarei mais sobre eles e sobre meus trabalhos.

Até mais.