Na implementação de games complexos, algo que percebi na literatura do gênero é a adoção de scenes. Mas o que é uma scene?

Posso dizer que é um bloco de código independente que armazena dados e realiza um conjunto de funções pertinentes apenas àquela parte do jogo atual.

Mas para quê isso?

Com o uso de scenes, você pode separar cada pedaço do jogo em blocos, sendo que apenas um bloco é carregado e executado por vez.

Imagina ter que escrever toda a lógica de update de um game inteiro dentro do método Update()? Ou mesmo carregar todas as texturas do jogo inteiro no LoadContent()? Para um Asteroids, tudo bem. Mas imagina um de tamanho razoável como Braid sendo inteiramente escrito dentro de um único arquivo (Game1)?

Certamente ficaria extenso e confuso demais.

É aí que o conceito de Scene é utilizado, pois assim consegue-se separar o código e agrupar toda a lógica de cada tela/fase/cena do jogo em um único lugar, de modo que fique independente do resto e que sejam intercomunicáveis.

Por exemplo, a tela de menu tem toda uma lógica e grupo de gráficos próprios, que o resto do jogo não aproveitará. Aqui podemos agrupar tudo numa Scene. E quando o fluxo principal do jogo vai rodar pela primeira vez, a Scene é invocada e ela passa a comandar o jogo. Já no menu, ao selecionarmos o modo Arcade, a cena de menu chama a cena de jogo (ou da fase 1, dependendo do nível de agrupamento), e o menu "sai de cena".

É um conceito parecido com o teatro ou filme. Cada cena possui um grupo de falas, atuações, objetos, decoração figurantes e atc, que estão independentes do resto de tal maneira que não importa a ordem em que as cenas sejam filmadas. Depois basta rodar cada uma em ordem.

Dentro do desenvolvimento de games, uma scene geralmente é uma classe. Algumas engines já possuem uma implementação padrão para isso. Como o XNA é cru, temos que implementar nosso próprio conceito de scene.

Uma idéia que vi na literatura é criar uma classe que herda de GameComponent, pois esta classe possui todos aqueles métodos da classe Game, como Update(), LoadContent() e Draw().

A idéia com isso é que cada scene teria o poder de carregar sprites e renderizá-los sem a intervenção de Game1.

Mas quando eu fui tentar implementar isso, não consegui fazer com que o framework utilizasse os métodos corretamente. Por algum motivo, o comando Content.Load<>() usado para carregar textura e áudio não era acessível nestas classes extendidas. Ou seja, ainda não consigo carregar conteúdo fora da classe Game1.

Então eu decidi criar minha própria implementação de Scene, que considero ser menos poderosa, mas muito mais simples e fácil de onganizar, pois não depende de usar métodos obscuros do framework e de certa forma faz com que todo o processamento fique dentro de Game1, mas a implementação, fora.

Veja abaixo como funciona atualmente o fluxo das scenes no XNA Lander:

Clique para ampliar

Bem, a idéia geral é que toda a lógica do jogo seja de alguma forma executada a partir do Game1, e assim tudo vai funcionar bem.

O que eu fiz foi criar uma classe Scene contendo o seguinte:

- lista de Sprites;

- lista de Fontes;

- método LoadContent();

- método Update().

Para cada scene usada no jogo, eu crio uma nova classe e herdo de Scene. Aí eu declaro todos os sprites que serão utilizados na classe e adiciono na lista. Faço o mesmo com as fontes. Mas só declaro, e não as carrego, pois fora de Game1 eu não consegui. No método LoadContent() eu carrego ou inicializo qualquer outra coisa necessária para aquela scene funcionar (por exemplo, recarregar o combustível nave para uma nova fase caso seja a Scene de jogo).

No método Update() eu escrevo toda a lógica de fluxo de jogo para a Scene. Caso seja a Scene de menu, o Update() ficará lendo as teclas para mover o cursor pelo menu, além de verificar se o jogador pressionou Enter para selecionar a opção desejada.

Com isso, eu carrego a Scene desejada num objeto de visibilidade global (usando public static) chamada de CurrentScene, de modo que Game1 possa acessá-la. Aí, no método Game1.LoadContent(), eu chamo o CurrentScene.LoadContent(), e depois eu percorro a lista de sprites e carrego as texturas. No método Game1.Update(), invoco o CurrentScene.Update(). E no método Game1.Draw(), eu percorro a lista de sprites da CurrentScene e renderizo em ordem uma a uma. Isso tudo sem o jogo saber qual scene está sendo usada no momento, pois independente de qual seja, ela estará no objeto CurrentScene. O Game1 executa os mesmos passos para qualquer scene carregada. E isso é possível porque todas elas herdam de Scene e se comportam de maneira similar. Só seus conteúdos mudam.

Com isso, toda a lógica e sprites/fontes ficam contidos em cada scene, mas seu carregamento e execução ainda ficam  atrelados a Game1.

Após colocar isso em prática, basta codificar uma vez o Game1 e todo o resto do game passa a ser codificado através das Scenes.

Veja o void Initialize() do Game1:

Este código acima só rodará uma vez durante a execução de todo o game. Nada impede que você chame depois o método, entretanto. Então eu aproveito para carregar a primeira scene do jogo, que é a SceneTitle(), da tela de título e menu principal.

Vamos para o LoadContent():

Aqui no LoadContent() eu chamo o CurrentScene.LoadScene(), que pode ter qualquer carregamento que não seja gráfico.

Para carregar os sprites eu percorro a lista de sprites que carrego na Scene. Como não sei quais são os sprites a serem carregados, basta jogar todos eles na lista. Assim eu percorro ela carregando um por um. Faço o mesmo com as fontes também.

Vejamos o void Update():

Veja que aqui eu chamo o Update() que está no scene. Outra coisa que faço é verificar se devo chamar novamente o Game1.LoadContent(). Mas quando isso acontece? Simples, devo chamar sempre um LoadContent() quando carrego uma nova Scene. Assim que carrego qualquer scene, mudo um boolean Globals.MustLoadContent para true e o update volta novamente para o processo anterior, de carregamento dos sprites, para carregar os novos sprites da scene recém-carregada.

No Draw(), continua tudo tranquilo:

Veja que eu não renderizo o sprite ou font quando o Visible está como false. O resto é só renderizar cada sprite na lista da Scene carregada.

Aqui eu mostrei mais como o jogo invoca e usa as scenes, mas não expliquei a implementação de cada Scene internamente. No próximo post eu falo mais sobre isso, inclusive com exemplos de código.

Parte 3 - Codificação Básica
Parte 5 - Mais Scenes

Mas o que interessa ao post é o editor de músicas. Mesmo com toda limitação e simplicidade do editor, bastante gente brinca montando músicas de jogos e, apesar da simplicidade, o resultado é muito bom e fica muito divertido ouvir. Outro dia eu estava brincando com um amigo no msn com essas músicas, ligava o som, colocava o microfone na caixa e ele tinha que descobrir. Só acertou uma ou outra.

Existe até uma versão para windows do editor. Caso vocês queiram tentar o desafio de montar alguma música no editor.

Terra theme - FF VI

Clique em continuar lendo para conferir mais músicas criadas (principalmente pelo usuário TomBobBlender) no Mario Paint.

Zelda

Sonic - GreenHill Zone

Tetris

Chrono Trigger - Robo's theme

ps: achei esse post nos "escrombos" dos rascunhos aqui da CubaGames. A fonte do Mario Composer foi esse post do Alexei Barros do blog hadouken.

Se você quer programar de verdade em actionscript, use o FlashDevelop, simples, leve (3,5mb) e rápido para instalar. Você pode criar projetos dentro dele e abrir uma nova classe que já vem tudo prontinho e certinho para programar. Se você precisar importar algum pacote e esqueceu de dar o "maldito" import no topo do arquivo, não se preocupe, no momento que você instancia algum objeto de uma classe que ainda não foi importada, ele faz sozinho para você. Sem falar no maravilhoso "auto-complete" (o Ctrl + espaço) para terminar o que você tem preguiça de escrever ou que não lembra.

Seja decente e fuja do F9 do Flash. Baixe o FlashDevelop 3 Beta 7 clicando aqui ou na imagem abaixo.

Impressionante é a palavra para esta engine! A movimentação do personagem no exemplo é muito boa, melhor ainda é a sombra que se cria em contraste com a luz. Lendo rapidamente os "como começar" a desenvolver algum jogo utilizando a FFilmation vi que realmente é fácil fazer qualquer coisa ali dentro. Os desenvolvedores pensaram também nos designers que não precisam mais se preocupar com a engine de renderização do jogo.

Veja algumas das facilidades prometidas pelos desenvolvedores:

- Inferface de programação entre a engine e o seu jogo (ou aplicação) simples e fácil de aprender;
- Uma mega performance de renderização;
- Os designers poderão "ver em tempo real" como ficará dentro do jogo o que estão criando;
- Capaz de criar cenas isométricas de diferentes complexidades;
- Criar cenas através de arquivos xml padronizados, chamado de "human readable xml";
- Imagens podem estar em arquivos externos e podem ser carregados a qualquer momento;
- Todos os componentes dos cenários são editados como se fossem 2D, a engine faz o trabalho de projetá-las de maneira isométrica (muito bom isso);
- Iluminação dinâmica com sombras em tempo real;
- Detecção de colisão integrada;

Exemplo do site oficial

Veja os exemplos no site oficial e fique de queixo caído como eu aqui. Em próximos artigos, vou testar essa engine para ver se ela é tudo isso mesmo! Quem sabe ela vem a ser muito útil para a CubaGames , aguardem.

No finalzinho de fevereiro a Adobe anunciou uma licença free do Adobe Flex Pro 3 para estudantes e professores de universidades. Para adquirir a sua licença basta comprovar que é estudante e você receberá um serial.

É realmente simples, acesse: www.flexregistration.com

Aquele abraço.

RPG Maker no resto do mundo

O RPG Maker acabou aparecendo no ocidente quando um russo chamado Don Miguel traduziu e distribuiu em seu site o RPG Maker 2000. Don Miguel fez uma tradução não tão boa, mas ele acabou lançando o programa ao mundo ocidental, que, em pouco tempo, virou febre. Muitas pessoas começaram a baixar o programa e criar jogos nele. Quase que instantaneamente, comunidades de “makers” (como começaram a ser chamados aqueles que criam jogos no RPG Maker) surgiram no mundo todo. Nessas comunidades, os makers discutiam sobre o programa, trocavam resources (recursos gráficos, sons e músicas para jogos) , criavam tutoriais, etc.

Assim como em outros países, o RPG Maker estourou aqui no Brasil também. Várias comunidades surgiram, entre elas: A Castelo RPG, a Universo RPG Maker, a Wolfpac e a CBRPG. Os makers brazucas tiveram muito destaque aqui e no exterior, tanto pela qualidade dos jogos, como pela técnica da maioria.

Atualmente

O RPG Maker teve duas versões lançadas nos últimos anos (2004 e final de 2007) que mudaram bastante o padrão que vinha sendo seguido pelo programa. Primeiro foi lançado o RPG Maker XP, em 2004, que apresentou muitas mudanças em relação aos programas anteriores, o RPG Maker 2000 e 2003. A versão XP trazia uma engine mais poderosa, com suporte à imagens 32-bit e músicas em formato MP3 e OGG. Além disso, o tamanho da tela dos jogos era de 640x480, o dobro das versões anteriores. Contudo, a mudança mais importante foi a inclusão de um sistema de scripts, baseado na linguagem de programação Ruby, muito popular no Japão e que ganhava espaço no ocidente. Toda a engine do RPG Maker XP foi montada em cima desse sistema de scripts, conhecido como RGSS (Ruby Game Scripting System). No final de 2007, foi lançado o RPG Maker VX, uma “continuação” ao RPG Maker XP, embora hajam várias diferenças entre os programas. O VX apresentou uma facilidade maior ao se criar jogos, e também tornou a criação mais rápida. Um novo visual também deu as caras, e também uma versão atualizada e mais organizada do Ruby Game Scripting System.

Criando jogos

O RPG Maker permite que uma pessoa comum, que nunca teve experiência com programação ou criação de jogos em geral, possa criar seu próprio jogo de RPG. Para criar o seu jogo, basta uma idéia na cabeça, um pouco de paciência e muita dedicação. Os jogos criados seguem o estilo clássico dos RPG’s para Super Nintendo, como Final Fantasy, Dragon Quest e Breath of Fire. É muito fácil, e principalmente, divertido criar um jogo no programa. Você cria falas para personagens, cria batalhas e mudar várias opções comuns em um jogo de RPG. A criação de mapas não pode ser mais fácil, você praticamente desenha no mapa com os itens que quer colocar (grama, água, castelos, casas).

Editor de Mapas do RPG Maker XV, clique na imagem para vê-la maior.

Uma ferramenta essencial no RPG Maker é o banco de dados. O banco de dados guarda quase todas as informações do seu jogo, como os personagens, itens, armas, armaduras, monstros, etc. No banco de dados você pode criar, editar e gerenciar esses dados importantes do seu jogo. O RPG Maker já vem com um banco de dados completo para você usar em seus jogos, então, cabe a você dar uma customizada no banco de dados para dar mais cara ao seu jogo.

Alterando seu banco de dados, clique na imagem para vê-la maior.

O que realmente faz a mágica acontecer e torna a criação de jogos no RPG Maker tão fácil, são os eventos e seus comandos. Quando um personagem conversa com você, um monstro o ataca, você entra numa loja para comprar coisas, etc. Tudo isso são eventos, e os acontecimentos são comandados por comandos de eventos. O RPG Maker possui dois modos de edição: a edição de mapas e a edição de eventos. Depois de desenhar seu mapa (uma ilha, um vilarejo ou uma caverna por exemplo) você passa para a etapa de edição de eventos, onde você criará o que acontecerá ali. Pessoas caminhando com quem o jogador poderá conversar, monstros que irão atacar o jogador, etc. Os comandos de evento são o "roteiro técnico" de seu jogo.

Editor de eventos do RPG Maker XV, clique na imagem para vê-la maior.

No RPG Maker você também encontra várias outras ferramentas que você utilizará durante a criação do jogo, como o "Resource Manager", onde você pode importar gráficos, sons e músicas para seu jogo, o teste de som, onde você pode ouvir as músicas e sons de seu jogo, e o editor de scripts, que é onde toda a ação relacionada a programação acontece. Você pode criar um jogo sem sequer abrir o editor de scripts, mas, para usuários avançados (ou curiosos), ele é uma ferramenta muito útil.

Editor de Scripts do RPG Maker XV, clique na imagem para vê-la maior.

Requerimentos Mínimos

Microsoft Windows 2000 / XP / Vista
Intel Pentium III 1.0GHz ou superior
Memória RAM de 256 MB ou superior
Suporte à resolução 1024x768 High Color (24 Bit) ou superior
Suporte à DirectSound e DirectX 8 ou superior instalado
100MB de espaço livre em disco

Configuração Recomendada

Microsoft Windows XP ou Vista
Intel Pentium 4 2.0GHz ou superior
Memória RAM de 512 MB ou superior

Saiba Mais

Para saber mais sobre essa incrível ferramenta, acesse o site RPG Maker Brasil, lá você encontra tutoriais, forum de discussão e jogos feitos com a ferramenta.

ps: Guilherme da Silva (a.k.a Falco) é administrador do site RPG Maker Brasil e mandou este texto via formulário de contato da CubaGames. Gostou? Quer mais textos dele sobre RPG Maker? Comente!

Os mods são feitos pelos usuários por editores fornecidos pelas próprias empresas junto com o pacote do jogo. Um bom exemplo são os vários mods feitos a partir do jogo Half-Life. A chamada Source SDK (programa para fazer mods do jogo Half-Life 2) é aberta para download através do Steam não a achei no Steam, um programa proprietário para comprar os jogos da Valve. Vários jogos vem junto com seus editores para serem feitos os mods, geralmente empresas grandes, com um bom tempo de mercado oferecem estas possibilidades por terem uma equipe bem estruturada e, principalmente, por terem um investimento maior.

Imagem de Counter Strike Source.

Mas por que empresas como a Valve, Bioware e Blizzard fazem isso? Para você jogar um mod, necessariamente o jogador precisa do jogo original, certo? Quantos mais mods de sucesso, mais $$$ para estas empresas.

Existem dois tipos de Mod:

Conversão parcial: neste modo, apenas muda-se partes que não influenciem no estilo de jogo. Como por exemplo, mudar as roupas dos jogadores, criar uma arma nova dentro do novo jogo ou transformar um jogo de deathmatch em capture the flag. Mas lembrem-se "não mudam" o estilo de jogo.

Conversão total: são modificações que "mudam" todo o estilo do jogo. É como criar um MMORPG a partir de uma modificação de um FPS. Segundo a wikipédia, o jogo Counter Strike é um jogo considerado como "conversão total" e eu pergunto, seria mesmo?

Vantagens e Desvantagens de um Mod:

Se você está realmente começando a desenvolver um jogo, estudar uma engine, brincar com um editor para fazer mods ou um jogo com o código aberto é uma boa saída para saber como "as coisas" (digo as coisas no sentido mais padrão, coisas que todos os jogos têm) funcionam. Dizer que conhece de jogos é uma coisa. Saber fazer é bem diferente! Mesmo que você seja um expert em qualquer linguagem de programação. Fazer sistemas é uma coisa, trabalhar com jogos é bem diferente.

A grande desvantagem de fazer um mod é se a sua idéia é muito genial e não se encaixa em nenhum "molde" feito pelas empresas que oferecem suas ferramentas para o uso. Às vezes, seu jogo precisa ser online e a ferramenta não te dá essa possibilidade.

Dota Allstars - Um famoso mapa para Warcraft 3

Empresas que oferecem mods:

A Valve, já citada acima. Fornece a Source SDK para desenvolvimento de mods para o Half-Life 2. Ela é free, você pode baixá-la através do Steam. É só baixar o Steam, criar um usuário e ir na aba "tools". Upgrade: eu baixei o Steam e tentei achá-la mas só vi para baixar servidores de Team Fortress 2 e de outros jogos.

A Bioware também oferece uma ferramenta para criar mods para o jogo Neverwinter Nights, que vem junto com o jogo, como ele você pode criar outras fases, personagens, etc.

Outra empresa que oferece uma gama de modificações é a Blizzard, o grande exemplo é o jogo Warcraft 3. Nele você pode fazer o seu mapa com a sua missão, e pode ter um objetivo totalmente diferente do jogo normal, destruir o exército inimigo. Eu li que têm tower defense, jogo de futebol e também o famoso Dota Allstars.

Outra empresa que libera (epa!) o código é a Id Software, conhece? Não. Mas Quake e Doom eu garanto que você conhece né? Então se quiser dar uma estudada ou fazer um mod, você pode baixar uma SDK para fazer mods do Quake 4 e do Doom 3 através deste link.

Imagem da primeira versão do Team Fortress.

Fazer um mod vale muito a pena para o quesito estudo. Quer ver como funciona? Quer fazer seu próprio mapa? Ou seu próprio personagem? Baixa uma SDK ou compra algum jogo que ofereça uma ferramenta de mod e sua a camisa que o jogo vai ficar legal! Caso você tenha o sonho de fazer um jogo no estilo dos que oferecem ferramentas para mod, aproveite-se disso porque facilita um monte, eu disse UM MONTE! Entendeu? Então, boa "moddagem".

Depois de muito tempo sem postar volto com uma novidade para quem gosta de jogos no celular. A Nokia colocou um acelerômetro (o artigo em inglês é muito mais completo), dispositivo que permite a identificação dos movimentos de um objeto, no seu N95 e as aplicações que utilizam isso já estão começando a "povoar" as listas de aplicações para celular.Obviamente os jogos não podem ficar fora dessa. O video abaixo mostra um cara jogando Space Invaders no N95.

link para o feed

O blog do cara que desenvolveu o jogo é esse. E quem tiver oNokia N95 pode baixar o jogo aqui.
No Symbian Blog, dá para encontrar também outros jogos para o N95, inclusive um em 3D.

O Luiz Valente, o desenvolvedor do Space Invaders N95, usou o OpenGL ES, um OpenGL mais simples para sistemas embarcados.

E aproveitando a deixa, um post muito bom sobre 3D com Java ME. Vale a pena ler para quem se interessa por jogos no celular.

Faça seu próprio jogo - parte 1 - 3D GameStudio;

Faça seu próprio jogo - parte 2 - Blender;

Faça seu próprio jogo - parte 3 - Game Editor;

Faça seu próprio jogo - parte 4 - RPG Toolkit;

Faça seu próprio jogo - parte 5 - The Games Factory;

Faça seu próprio jogo - parte 6 - RPG Maker;

Estou apenas revitalizando-os por causa de sua qualidade. Espero que o Tiago faça mais posts nesta linha.

A idéia de criar engines para "partes parecidas" de um jogo, como menus, sistemas de lutas, sistema gráfico e outros trouxe bastante velocidade no desenvolvimento de jogos pois com apenas uma engine, vários games podem ser feitos. É o exemplo da SCUMM, criado pela LucasArts para desenvolver o jogo Maniac Mansion, daí o nome (Script Creation Utility for Maniac Mansion), depois de Maniac Mansion vieram muitos outros jogos no mesmo gênero que utilizavam a mesma engine.

Atualmente existem muitas engines de diversos tipos e variadas finalidades, desde engines para sistemas gráficos 2d e 3d a engines que simulam as leis da física dentro de jogos. No site da DevMaster existe uma lista enorme de engines (comerciais e grátis) para pesquisa e (se possível) download, vale a pena dar uma checada.