Olá, pessoal! Tudo bem?

Dessa vez vamos ver como o mouse pode ser utilizado para controlar a direção de deslocamento do personagem e o ângulo de visão da câmera, em um jogo feito no 3D GameStudio. Só não vale usar um mouse capenga e colocar a culpa no programa hein!

Então… para o alto… e avante!

A implementação é bem simples, e para facilitar ainda mais, vou utilizar como referência um post que deixei aqui, falando sobre “câmera seguindo personagem”. Este:

http://jogosdigitais.wordpress.com/2009/12/01/camera-no-3d-gamestudio-seguindo-o-personagem

Pois bem, as modificações devem ocorrer em 2 pontos:

1. Primeiro nas linhas 28 e 29, em que o pan do personagem era modificado de acordo com as teclas pressionadas, teremos agora o seguinte código, utilizando como referência o movimento do mouse.  Dessa forma o movimento do mouse irá interferir apenas na rotação do personagem para os lados.

2. Depois, na linha 66, em que o pan da câmera era igualado ao pan do personagem, passaremos a utilizar o movimento do mouse. Com isso teremos a câmera girando para cima, para baixo e para os lados.

Prontinho!

Sim! É só isso mesmo! Pode testar! Ah, vale lembrar que a utilização dos eixos  (x, y ou z) sempre depende da forma como os modelos foram criados. Assim, caso a utilização desses 3 valores gere resultados estranhos, substitua-o por outro, até encontrar aquele mais adequado ao seu projeto. Coisa de 2 minutos e vocês conseguem ajustar isso.

Abraço a todos.

.

.

É possível criar e editar alguns elementos no próprio WED, como formas primitivas, luz e outros. Mas, na maioria dos casos, modelos (.mdl) e terrenos (.hmp) são criados a partir softwares de modelagem, como o editor de modelos do 3D GameStudio (MED), ou outros que exportem nos formatos citados.

Considerando que todos os modelos já estão prontos e à disposição, as orientações a seguir nos permitirão organizar o conteúdo em um mesmo espaço e gerar o arquivo que será carregado pelo script.

Então… muita atenção!

1. Deixe todos os arquivos salvos na mesma pasta. Somente assim o WED irá encontrá-los.

2. Abra o WED e crie um novo level (File -> New), salvando-o em seguida na pasta do projeto (com os demais arquivos, modelos etc.). A extensão WMP é o arquivo fonte, utilizado para edição, mas que ainda não pode ser utilizado no jogo.

3. Ao clicar com o botão direito em qualquer das 4 janelas de visualização, a opção Add mostra as possibilides de inserção de elementos. Vamos nos concentrar na opção Add Model, que irá exibir os modelos existentes na mesma pasta. Para cada modelo que quisermos inserir no cenário, basta selecioná-lo e repetir o processo.

4. No topo, há 3 botões que ativam os modos de posicionamento, rotação e escala, bastante úteis para que consigamos organizar todos os elementos. São os três que possuem setinhas verdes.

5. Inseridos todos os itens, devemos gerar um arquivo WMD, este sim pronto para ser utilizado no jogo, acessado via script. Para isso devemos clicar no botão Build, ou no menu File -> Build Map.

…..5.1. Caso algum objeto esteja sem textura, o sistema perguntará se pode ser utilizada a textura padrão, o que pode ser confirmado.

…..5.2. Em seguida abrirá a janela Map Compiler, com algumas possibilidades de configurações. Vamos simplesmente clicar em OK.

…..5.3. Nesse momento outra janela abre-se, mostrando a evolução da compilação. Se não houver mensagem de erro, sua fase está pronta para ser utilizada.

……….5.3.1. Verifiquei, algumas vezes, que o sistema dá erro em um arquivo pallete.pcx. Caso isso aconteça, vá no menu File -> Map properties, e no campo pallete escolha um arquivo com extensão RAW (com o mesmo nome da fase), que é gerado pelo WED. Daí é só confirmar e repetir o passo 5 desde o início que provavelmente funcionará.

.

Por último deixo uma dica bastante importante: muitas vezes, ao testarmos o cenário no jogo, deparamo-nos com o fato de o personagem não colidir com os elementos, inclusive o terreno. Específicamente estes que fazem parte do ambiente, como pontes, ruas, chão etc. devem ser inseridos de outra forma no WED, através do menu File -> Import -> Import From MDL Files.

Então é isso! Boa sorte a todos! E quem quiser postar um link com um print do trabalho para vermos será ótimo!

.

.

A câmera em um jogo 3D representa o tipo de visão que o jogador terá de tudo o que acontece. Longe ou perto, em primeira ou terceira pessoa, inclinada, superior e por aí vai…

Nesse post iremos aprender a configurar a câmera do 3D GameStudio para seguir o personagem,  em situações que variam desde o FPS clássico (só com os braços do personagem aparecendo) até visões de terceira pessoa com seres humanizados ou veículos. Pra quem já gosta de matemática, mamão com açúcar! Para quem não gosta… só posso dizer que está passando da hora de parar com a cara feia e comer logo desse brócolis! Brincadeiras a parte… vamos nessa!

Aí você pode pensar: tá bom… eu configuro a câmera com o mesmo posicionamento e rotação do personagem e está pronto. Sim… e não! O problema está no fato de que na maioria das vezes afastamos um pouco a câmera do personagem, para podermos mostrar um pouco dele. É nessa hora, ao girar, que a câmera (até então com posicionamento fixo) começará a focalizar áreas em que o personagem não está, conforme grafico abaixo, que representa a questão vista de cima.

.

.

Para corrigirmos isso, precisaremos sempre reposicionar a câmera, de forma que o personagem continue centralizado na visão apresentada. Para isso vamos usar o Teorema de Pitágoras (Professora de matemática da quinta série! Bem que a senhora falou que um dia eu precisar ia disso!). Vejamos abaixo o que fazer, antes de implementar o script.

.

.

Considerando a distância sempre fixa entre a câmera e o personagem, e que ela poderá girar por todos os ângulos, teremos que esse valor corresponde ao raio da circunferência para o movimento obtido.

Para acharmos as coordenadas correspondentes trataremos esse tal raio de hipotenusa (H). A distância vertical entre o personagem e a câmera será tratada como cateto adjacente (CA), pois ajuda a formar o ângulo (que está na cor branca). A distância horizontal é o cateto oposto (CO). Pronto! Já temos nosso triângulo retângulo esperando!

Considerando que CA = H * seno(angulo) e CO = H * cosseno(angulo), teremos calculados os valores horizontal e vertical. Com isso em mãos, basta subtraí-los dos valores atuais do personagem. Abaixo deixo um exemplo disso aplicado a um protótipo que desenvolvi.

.

.

Espero que todos tenham conseguido! Um abraço… e até a próxima!

Ahhh… e participem do blog, postando comentários, críticas, sugestões etc.

Fui.

.

.

Tudo bem… quando se faz um jogo pretende-se que o jogador fique nele o maior tempo possível, e não que ele clique logo no botão “SAIR” e acabe com a brincadeira. Mas nem por isso podemos esquecer de dar essa opção a ele. Afinal, fechar o jogo através do gerenciador de tarefas ou algo assim seria algo extremamente desagradável e sinal de um trabalho nada profissional.

Então vejamos…

No 3D GameStudio isso é bem tranquilo de implementar. Resumindo: basta programar o botão e/ou a tecla desejados para que executem a função sys_exit(). Abaixo deixo um exemplo disso.

No meio do ano deixei aqui um tutorial sobre a criação de um jogo de tiros em Flash, só que utilizando a versão 2.0 do actionScript. Esse aqui: http://jogosdigitais.wordpress.com/2009/06/05/jogo-de-tiros.

Dessa vez trago uma nova versão, em actionScript 3.0. Repetindo a explicação que coloquei naquela época: “Funciona assim: diversos alvos (do modelo BOM ou do modelo RUIM) caem pela tela. Se você acertar um alvo ruim, perde o jogo. Para vencer deve acertar todos os bons.”

Vejamos o que nos espera!

Pra começo de conversar, vamos combinar o trabalho a ser feito:

1. Programar a classe responsável pelo funcionamento da mira.

2. Programar a classe responsável pelo funcionamento de cada alvo.

3. Programar a classe responsável pelo funcionamento do jogo como um todo.

4. Criar os elementos visuais e inserir referências às classes em um arquivo FLA.

.

1. Classe da mira

Vamos chamá-la de Mira.as. Resumindo, fará com que o ponteiro do mouse seja ocultado e no lugar dele apareça um movieClip, com o desenho de uma mira da nossa preferência. Eis o código:

.

2. Classe do alvo

Esse classe cuidará de todo o funcionamento de cada alvo: desde o movimento até a verificação se abateu-se um alvo bom ou ruim. Além dos comentários existentes no código, deixo algumas linhas para prestarmos atenção:

1.  O método constructor está vazio porque, como veremos adiante, ao ser linkado a um movieClip não conseguiríamos passar parâmetros, que seriam necessários para a configuração dos alvos. Por isso, criou-se o método configura com esse objetivo. Assim, logo após  criarmos cada alvo, executaremos  referido método para passar a ele os valores necessários ao seu bom funcionamento.

2. No método acerta, é feita referência a uma propriedade de JogoAcertaAlvos. Veremos mais adiante que trata-se de uma propriedade estática que, por essa qualidade, deve ser acessada diretamente na classe, e não nos possíveis objetos. Essa classe JogoAcertaAlvos será a terceira a última desse projeto, criada no próximo tópico.

Então vejamos a programação da classe Alvo.as.

.

3. Classe do jogo

Essa classe cuidará da criação dos alvos, cujas quantidades dos tipos bom e ruim serão devidamente controladas. É nela que definimos o intervalo de tempo entre a criação de um alvo e outro.

Então vamos ao que interessa: o código da classe JogoAcertaAlvos.as.

.

4. Configuração do FLA

Para finalizar o jogo, vamos criar o arquivo FLA que conterá o desenho dos alvos e da mira, algumas configurações de movieClips e a criação de um objeto baseado na classe principal. O nome do FLA não faz diferença, mas já salve-o de uma vez na pasta em que estão os demais arquivos.

Para criar os objetos:

1. Alvo: Crie um movieClip (chamado Alvo) com 2 frames: no primeiro faça o desenho do alvo bom e no segundo o do alvo ruim. Insira também um stop() no primeiro frame (de preferência em outra camada), para que a linha de tempo não fique animada.

2. Mira: Também será um movieClip (com nome Mira). Deve conter o desenho que será a referência do jogador para clicar sobre os alvos. Importante: a parte central, onde está localizado o ponto de registro, deve ser sem preenchimento, caso contrário não conseguiremos detectar que um alvo abaixo da mira foi clicado.

Agora vamos configurar esses 2 objetos. O processo é o mesmo, então basta repetir para a mira o que vou explicar aqui sobre o alvo. Antes de mais nada, podemos remover os movieClips do palco (se ainda estiverem lá), pois os mesmo serão inseridos via código.

1. Na biblioteca, após clicarmos com o botão direito sobre o movieClip Alvo, vamos acessar a opção propriedades. Basta clicar a opção Export for ActionScript e confirmar, mantendo todas as configurações que lá estiverem. Como o nome do MovieClip e o nome da classe são idênticos (Alvo!) o campo class já estará configurado corretamente, linkado os dois elementos.

2. Prontinho! Não se esqueça de repetir o processo com a mira.

Por último vamos inserir um código na linha principal do FLA, que servirá para criar um objeto a partir da classe principal e colocar tudo em funcionamento.

.

E então!? Que tal um Control + Enter? (Finalmente!)

Abraço! E boa diversão!

.

.

Quem está começando a trabalhar com o 3D GameStudio deve estar se deparando com uma questão um tanto desagradável: a limitação do seu editor de modelos (MED – Model Editor). Para essa turma, uma boa opção é utilizar softwares de modelagem mais avançados (e mais conhecidos), cujas referências podem ser encontradas com mais fartura na web. Mas, para que isso funcione, é necessário conseguir migrar os modelos produzidos, de forma que a engine do 3D GameStudio compreenda-os.

Este tutorial irá mostrar como utilizar modelos desenvolvidos no Blender para jogos no 3D GameStudio. Abordaremos animações e texturas com alpha. Procurei bastante por referências desse tipo, mas não achei muitas (e todas fragmentadas e em inglês). Achei uma boa postar isso aqui.

Então… bom estudo! E bom trabalho!

.

1. Preparação das texturas.

.

Primeiro vamos salvar 2 imagens que servirão como textura, uma com as cores normais do objeto e outra apenas em preto-e-branco, sendo que o preto será tratado como transparência.

Você pode utilizar o editor de imagens de sua preferência. Só lembre salvá-las com extensão TGA (cor.tga e alpha.tga) e dimensões com potência de 2, como os 256 x 256 pixels que usei para testar.

De preferência, exporte a imagem colorida com 32 bits, pois é assim que precisaremos dela mais adiante, quando estivermos configurando a transparência no editor de modelos do 3D GameStudio. Mas atenção: a imagem em preto-e-branco deve estar em 24 bits!

Abaixo, exemplos em miniatura.

(cor.tga)

(alpha.tga)

2. Criação do modelo e mapeamento UV no Blender

.

Agora no Blender, criar um arquivo novo e remover o cubo padrão. Salve o arquivo na mesma pasta em que estão as texturas.

Para aplicar mapeamento UV:

1. Inserir um plano.

2. Alternar para o modo de edição.

3. Selecionar tudo o conteúdo.

4. Apertar U e selecionar UNWRAP no menu.

5. Dividir o espaço em 2 janelas, alterando uma delas para UV/Image Editor.

6. Na janela de mapeamento, clicar em Image -> Open, e selecionar a imagem colorida normal (cor.tga).

Até aqui já seria suficiente para termos um modelo texturizado sendo exibido no 3D GameStudio, apesar da textura não aparecer quando renderizamos no Blender (F12).

.

3. Configuração da transparência no Blender

.

Nos passos seguintes faremos a aplicação da transparência, configurando um material com duas texturas.

Para configurar a textura com alpha:

1. Ativar o painel de material.

…..1.1. Adicionar um novo material (será apenas 1 mesmo!).

…..1.2. Ativar o botão ZTransp e setar o alpha para O (zero), para reconhecer a transparência.

2. Ativar o painel de texturas.

…..2.1. Adicionar uma nova textura, do tipo Imagem, carregando para ela a imagem colorida normal (cor.tga). É mesma que foi utilizada no mapeamento UV.

…..2.2. Adicionar uma nova textura, também do tipo Imagem, carregando para ela a imagem em preto-e-branco (alpha.tga). Para essa textura, no bloco Map Image, Desmarcar a opção UseAlpha.

3. De volta ao painel de material, em Map To, desative a opção Col e ative a opção Alpha, apenas para a segunda textura.

.

4. Script para exportação do modelo do Blender para .mdl

.

O Blender não tem a extensão mdl (utilizada no 3d GameStudio) como padrão para exportação. Por isso vamos recorrer a um script feito em Python (a linguagem utilizada pelo Blender). Eu não sou especialista nisso, mas encontrei um script na web bastante eficiente, que vou compartilhar com vocês.

Atenção, renomeei o arquivo para .doc, pois não conseguia postar com a extensão correta. Portanto, não tentem abri-lo. Apenas renomeem para export_3dgs_mdl7.py.

Depois de não conseguir utilizá-lo diversas vezes precisei fazer um ajuste, devido a um nome de variável que passou a ser proibido nas versões mais novas, pois passou a ser palavra reservada.

export_3dgs_mdl7

Bom, baixado o script, basta copiá-lo para a pasta scripts, dentro da pasta de instalação do Blender. A explicação a seguir é praticamente uma tradução do que encontramos em http://www.coniserver.net/wiki/index.php/Blender, principal referência para esse estudo. Se alguma coisa não funcionar corretamente, desculpem-me os poucos testes que realizei antes de criar esse post, mas quis compartilhar logo a informação com vocês. Dúvidas, críticas e sugestões são bem-vindas!

Como usar o script no Blender:

.

1. Dividir a área em pelo menos 2 janelas: uma para a visão 3D (que precisa estar visível para que as animações sejam exportadas) e outra para os scripts. Nessa última, acessar Scripts -> Export -> 3dgamestudio mdl7 (.mdl). Se não estiver aparecendo essa opção, tente Scripts -> Update Menus.

2. Selecionar as malhas que serão exportadas.

3. Defina a escala para exportação do modelo (no Blender cada unidade é próxima a um metro, enquanto que no 3dGameStudio é mais parecida com uma polegada).

4. Ative a opção internal textures.

5. Ative o tipo de coordenada world space.

6. Pressione export.

7. Configure o caminho e o nome do arquivo e pressione export mdl7 para iniciar a exportação.

8. Aguarde até que o popup “export done!” apareça. .

.

5. Exportação das animações
.

Caso o modelo seja animado, antes de exportar (passo 6 do tópico anterior), deve-se configurar os ciclos de animação, da seguinte forma:

1. Pressione export animation para ativar a configuração da animação a ser exportada. No caso de modelos estáticos pode deixar esse item desabilitado.

2. Cada ciclo de animação deve ser definido por um nome e uma lista com os números do frames correspondentes, separados por espaço. Ative a opção v para exportar uma animação do tipo vertex, ou a opção b, para exportação uma animação com bones.

…..2.1. Pressione add ou remove para gerenciar os ciclos de animação.

…..2.2. Comentários quanto à exportação de animações com bones:

………2.2.1. Cada vértice deve sofrer a influência de apenas 1 bone. Caso contrário  será considerado o mais forte, ou de forma randômica, se tiverem o mesmo peso.

………2.2.2. Bones cujos nomes comecem com “ik” não serão exportados.

………2.2.3. Apenas o esqueleto do objeto ativo será exportado.

………2.2.4. O esqueleto deve ter o mesmo ponto de origem e transformação que o objeto a ele vinculado.

.

6. Configuração da textura com alpha no editor de modelos (MED)

.

Com tudo pronto no Blender, inclusive a exportação do modelo em formato .mdl, nosso último passo será configurar as texturas no Model Editor (MED),  editor de modelos do 3D GameStudio.

É bem simples! Com o MED aberto, devemos seguir os seguintes passos:

1. Abrir o modelo exportado do Blender.

2. Acessar Edit -> Manage skins e clicar no botão Skin Settings. Uma janela abrirá para a configuração das texturas.

3. No campo Texture File, selecione o arquivo cor.tga, nosso conhecido das etapas no Blender.

4. Em Texture format, set a opção 32 bits, que ativará o canal alpha. Lembre de confirmar clicando em OK logo abaixo. (Atenção: esse passo não será necessário se a imagem cor.tga já tiver sido exportada com 32 bits pelo editor de imagens).

5. O campo Alpha Texture File ficará disponível para seleção. Mesmo que haja qualquer conteúdo inserido (mesmo que seja o que imaginamos ser o certo!) devemos clicar e selecionar o arquivo alpha.tga. Aquele mesmo, preto-e-branco.

6. Pronto! Salve o modelo!

.

Agora já podemos testar nosso projeto no 3D GameStudio e ver que o modelo aparece com a textura correta, inclusive com transparência.

.

7. Mais alguns comentários importantes.

.

1. Os nomes não devem ter mais de 20 caracteres para os bones, 16 para as texturas (fora a extensão) e 16 para os objetos/malhas.

2. Exportar texturas internas pode ser mais demorado devido à geração de mipmap.

3. Com os botões save options e load options, as configurações de exportação podem ser gravadas e carregadas.

.

Quem quiser ver a referência que utilizei para criar esse passo-a-passo, principalmente na parte sobre textura com transparência, aqui está o link:

http://blendertotal.wordpress.com/tutorial-como-usar-alpha-maps

Entendeu direitinho? Então agora é aplicar no seu modelo 3D!

.

.

.

Olá, pessoal! Tudo bem?

Hoje vamos de tutorial para criar um jogo de labirinto. Todos prontos?

Primeiro vamos criar os elementos visuais em um arquivo FLA e depois programar todo o funcionamento do jogo em apenas uma classe.

Lembrem que utilizo o Flash CS4. Caso haja alguma opção diferente ou alguma incompatibilidade com o CS3, favor comentarem aqui suas dúvidas e soluções, ok?!

Um… dois… três… valendo!

.

1) Preparativos e considerações gerais..

Primeiramente, vamos criar um FLA novo. Pode ter qualquer nome e qualquer tamanho, ao gosto do freguês.

Agora, antes de criar os personagens, recordemos uma questão importante a respeito de colisão de objetos: colisão entre movieClips versus colisão entre um movieClip e uma coordenada.

Se verificamos a colisão entre 2 movieClips, como no caso do jogo do quebra-cabeça, o Flash considera a área retangular dos objetos, e não apenas seu desenho. Naquele jogo tudo bem pois os objetos são separados e não contêm um ao outro. (Se quiser saber mais sobre quebra-cabeça, tem um tutorial aqui no site que explica como montar um).

Já no caso do labirinto, os personagens ficam o tempo todo dentro dele. Dessa forma, se fizessemos o mesmo tipo de teste, a colisão seria detectada a todo instante. Sendo assim, para não termos que criar um movieClip para cada parede e fazer um monte de teste, trabalharemos com a colisão entre um movieClip (o cenário) e uma coordenada (um ponto no personagem). Na verdade vamos calcular quatro pontos nas extremidades do personagem, que, de preferência, devem ter formato retangular (melhor ainda se for quadrado). Dessa forma, se tratarmos a colisão com cada extremidade dessa, teremos cuidado de todo o personagem.

Outra consideração importante diz respeito à necessidade de manter essas coordenadas representando as mesmas extremidades, mesmo que o personagem gire para fazer o movimento em outra direção. Caso contrário teríamos que multiplicar por 4 a quantidade de código, uma vez para cada direção que o personagem apontasse. Isso será resolvido com o uso de 2 movieClips: 1 interno, que apenas gira, e um externo, que contém o primeiro, que apenas desloca.

.

2) Criação do cenário.

Essa é parte mais fácil! O cenário é um simples movieClip com as paredes desenhadas. Olhem o meu como ficou.

Há três restrições:

- Onde não tiver parede tem que ser vazado! Não pode só colorir de branco ou outra cor.

- As paredes têm que ser verticais ou horizontais (nunca inclinadas);

- As paredes tem que ser mais largas do que os personagens, devido aos cálculos de colisão que faremos adiante.

Assim que terminar o desenho, lembre colocar nome de instância no movieClip: cenário.

3) Criação do personagem jogável.

Vamos desenhar nosso personagem (esse magnífico quadrado!) com uma marca que identifique a frente dele. Nesse caso eu usei uma cor diferente. Utilize a parte de cima para isso, ou então terá que ajustar a rotação, quando tratarmos da programação.

Devemos convertê-lo em movieClip, cujo nome de símbolo não fará diferença. O ponto de registro, entretanto, deve ser no centro, para que o personagem gire sobre o próprio eixo. O nome de instância deve ser interno. Ah, e não precisa ser desse tamanho! Lembre que o personagem deve ser mais estreito do que as paredes do labirinto.

Em seguida, vamos apenas selecionar o movieClip interno e convertê-lo novamente em movieClip, dessa vez com o ponto de registro no canto superior esquerdo, para atender aos nossos cálculos das extremidades. O nome do símbolo mais uma vez não faz diferença, mas o de instância deve ser externo.

Dessa forma teremos no palco o movieClip externo, com o interno dentro dele.

Lembre de posicionar o personagem nos corredores, fora das paredes.

.

4) Criação dos personagens não-jogáveis (NPCs).

Os NPCs devem ter a mesma estrutura do personagem jogável, composta por dois símbolos. O movieClip de dentro deve ter o mesmo nome dado no caso do personagem jogável: interno.

O movieClip de fora deve possuir um nome diferente. Para fazer esse teste eu criei dois NPCs: inimigo e inimigo2. (Segredo: eu até usei o mesmo símbolo e só apliquei um pouco daquele efeito Tint, que muda a cor dos objetos. Viva a criatividade e o reaproveitamento de movieClips. Tá bom… nem ficou tão legal… então trate de fazer um desenho novo e bem bacana!)

5) Como vencer o jogo…

Devemos criar um movieClip que representará o objetivo do jogo. Pode conter um desenho qualquer (e até ser transparent). Apenas seu nome de instância deve ser definido como final.

6) Configuração do FLA para “conectar-se” à classe.

No menu, em File >> Publish Settings, indicaremos que o arquivo FLA ficará vinculado à classe que criaremos já já, em um arquivo AS. Para isso, basta acessar, na aba Flash, o botão Settings e configurar o nome da classe (Labirinto) e desmarcar a opção de declaração automática de instâncias.

Depois é só dar OK em todas as telas e partir para a programação.

7) Programação da classe.

A classe Labirinto será criada em um arquivo AS. Para criá-lo vamos em File >> New >> ActionScript File >> OK. Pronto, nosso arquivo de texto está pronto para ser alimentado com o código que dará vida ao jogo. Não esqueça de salvá-lo como Labirinto.as.

A programação está abaixo, toda comentada. Parece muito? Que nada… metade são linhas vermelhas de comentário.

Prontinho! Esperam que todos tenham achado a saída!

Um abraço e até a próxima!

.

.

.

Olá, pessoal! Nosso desafio de hoje é montar um quebra-cabeça utilizando o actionScript 3.0 do Flash. Todos prontos?

Basicamente, criaremos uma classe que cuidará do funcionamento das peças e da verificação de final de jogo. Portanto, teremos 2 arquivos: 1 FLA e 1 AS.

Então… mãos à obra!

.

1) Criação das peças

Cada peça de deverá ser um movieClip, com o formato que você quiser. Para facilitar a identificação, vamos utilizar um padrão de nomes. Para um jogo padrão de com 9 peças, com as mesmas distribuídas em 3 linhas e 3 colunas, teremos os seguintes nomes:

peca_0_0, peca_0_1, peca_0_2,
peca_1_0, peca_1_1, peca_1_2,
peca_2_0, peca_2_1, peca_2_2.

O primeiro número corresponde à linha e o segundo à coluna. Começamos a contar a partir de 0 para acostumarmos que isso acontece muitas vezes de forma obrigatória quando se trata de programação.

Importante mesmo é que todas as peças sejam inseridas no palco com estes nomes de instância, pois os mesmos serão importantes quando chegarmos na parte da programação. Se o nome do símbolo na biblioteca for o mesmo, ótimo! Mas isso não interfere no resultado final.

.

2) Criação das peças-solução

Para criarmos a solução do quebra-cabeça, devemos duplicar as peças que estão no palco, atribuindo a elas novos nomes de instância, variando apenas uma parte, mas mantendo a numeração.

solucao_0_0, solucao_0_1, solucao_0_2,
solucao_1_0, solucao_1_1, solucao_1_2,
solucao_2_0, solucao_2_1, solucao_2_2.

Atenção para duplicarem apenas as instâncias e não os símbolos da biblioteca, uma vez que o lugar de encaixe de cada peça deverá ser igual à própria.

Esses movieClips, denominados “solução”, devem ser posicionados de forma a criarem o resultado final do quebra-cabeça selecionado, para servirem de referência na hora de verificar os acertos. Por outro lado, as peças jogáveis devem estar espalhadas pela tela.

As peças de solução não serão móveis e a príncipio podemos deixá-las um pouco transparentes para diferenciá-las daquelas controladas pelo jogador. Ao final, poderão ficar 100% transparentes, apenas com uma borda em volta para identificar a área de jogo.

.

3) Configuração da área de contato

Para verificar se cada peça foi colocada sobre a solução correspondente, faremos os chamados testes de colisão. Entretanto, eles apresentam uma limitação no Flash, que é o fato de verificarem a área retangular que envolve os movieClips, e não apenas seus conteúdos. Dessa forma, alguns casos poderíam ser dados como colisão, mesmo que esta não acontecesse.

Mesmo que esse problema não existisse, permitir que o jogador acerte a jogada mesmo que esbarre apenas um pedaço da peça na solução correta seria deixar o jogo muito fácil e impreciso.

Para resolver as duas questões, utilizaremos um recurso bastante simples e eficiente, como veremos a seguir.

Dentro de uma das peças criaremos um novo movieclip (que pode ser o desenho de uma bolinha ou quadradinho) que chamaremos de miolo (lembrem de colocar esse nome de instância nele). É importante que o desenho ocupe apenas uma parte da peça, na área central. Automaticamente, a solução correspondente a essa peça também apresentará o tal miolo, já que são instâncias do mesmo símbolo. Pois bem, na programação não iremos simplesmente comparar uma peça e sua solução, mas o miolo da peça com o miolo da solução.

Agora é copiar o tal movieClip e inserí-lo também nas demais peças (conferir se o nome de instância é o mesmo “miolo” em todos os casos).

Dica: para mudar o nível de dificuldade do jogo, basta entrar no símbolo miolo e alterar suas dimensões. E ao final, basta mudar a cor do desenho para transparente (tudo isso dentro do símbolo), que todas as peças estarão prontas!

.

4) Criação da classe Peca

Toda a programação será feita na classe que nomearemos Peca. Portanto, criemos um arquivo actionScript com o nome Peca.as. O código está abaixo, todo comentado!

.

5) Vinculação das peças à classe

Estamos quase lá…

Pra finalizar, falta apenas configurar os movieClips das peças para que seu funcionamento seja baseado na classe que acabamos de criar. Para isso, devemos clicar com o botão direito sobre o nome do objeto (na biblioteca) e acessar o painel “Properties”. Nele devemos ativar a exportação para actionScript e definir o nome da classe base, que é justamente a classe Peca que criamos. Veja na imagem:

Demais itens que aparecem clicados ou escritos automaticamente devem deixados como estão.

O processo deve ser feito individualmente para cada peça.

.

.

Agora é só testar o projeto! Se foi tudo configurado e digitado direitinho, teremos um jogo quebra-cabeça saindo do forno! Aproveitem e deixem seus comentários, dúvidas, sugestões etc.

Abraço!

.

.

Bom, se você não acessou a primeira parte desse tutorial, aqui está o link:

http://jogosdigitais.wordpress.com/2009/09/15/cenarios-tile-based-com-xml-1-2

Para quem já concluiu a montagem e leitura do XML, vamos ao que interessa: a montagem dos blocos na tela.

Continuando do arquivo jogo.fla que trabalhamos na primeira parte, vamos agora criar o conteúdo visual dos blocos e em seguida fazer com eles apareçam na tela de acordo com a configuração do XML.

.

1. Criação do movieClip para os blocos

Teremos apenas 1 movieClip contendo o desenho de todos os blocos. Algumas recomendações:

- É importante que os blocos sejam separados por quadro (1 bloco em cada quadro);

- Todos os blocos devem ter o mesmo tamanho e serem posicionados no canto superior esquerdo.

- O primeiro bloco será transparente, mas não vazio. Isso permitirá que haja uma imagem de fundo no cenário, como o céu, montanhas, etc, que apareçam atrás dos blocos.

- O primeiro quadro (frame) deve conter uma ação stop(); para que os quadros não apareçam em loop, um após o outro.

Abaixo está uma animação do que chamaremos de bloco_mc. Os blocos que criei são bastante simples, apenas para ilustração. Cada um deve criar a quantidade de blocos (com desenhos mais interessantes do que os que eu fiz, eu espero!) necessária para produzir cenários atraentes.

.

Quadro 1:

.

Quadro 2:

.

Quadro 3:

.

Quadro 4:

.

2. Configuração do movieClip para acesso através da programação

Criado o conteúdo visual, vamos agora configurar o movieClip para que possam ser criados vários blocos na tela, de acordo com o cadastro feito no arquivo XML.

O processo é simples.

Primeiro localize o objeto na biblioteca e clique com o botão direito. No menu que aparecerá, acesse Properties.

No painel de propriedades que abrirá, marque apenas a opção Export for ActionScript e altere o nome da classe para Bloco (com B maiúsculo para manter o padrão de nomenclatura das classes). Esse é o nome que utilizaremos na programação para criar objetos baseados nesse movieClip.

As demais opções que forem preenchidas ou marcadas automaticamente devem permanecer como estão.

Pronto. Podem confirmar e avançar para a programação.

.

3. Montagem dos blocos na tela.

Agora vamos alterar o código produzido post anterior desse tema, fazendo com que, ao invés de apenas listar as linhas e colunas, sejam criados os blocos correspondentes, devidamente posicionados.

(Inserir apenas a parte destacada em amarelo,
pois o restante já está feito)

.

Agora é deixar a criativade fluir e criar blocos bem legais para o seu projeto! Para acrescentar, remover ou alterar os blocos, utilizaremos 2 arquivos: o FLA para definir o conteúdo visual e o XML para definir quantidade e posicionamento. Só para vocês terem uma idéia do resultado, abaixo uma imagem do meu cenário.

.

Então é isso! Até o próximo post!

.

.

Neste post iniciaremos os estudos para a construção de cenários do tipo tile-based, aquelas baseados em blocos que se encaixam para formar o ambiente do jogo. Na verdade, o jogador não precisa perceber que há vários blocos distribuídos pela tela, devendo o ilustrador cuidar da criação de blocos sem costura, ou seja, com encaixes suaves, imperceptíveis.

A vantagem desse tipo de cenário é que não será necessário criar imagens extensas à medida que o cenário aumenta. Além disso, a atualização também é mais simples, pois ao alterar um bloco, sua atualização é automática em todos os pontos do cenário em que for aplicada. Por fim, possivelmente teremos arquivos menores do que se utilizássemos grandes imagens com o cenário completo.

Então vamos direto à implementação, que é nosso objetivo no momento. Podemos discutir questões conceituas sobre tile-based em outro momento.

.

1. Criação do arquivo XML

É no arquivo XML que definiremos a quantidade de linhas e colunas do nosso cenário. Nesse tutorial nomeei o arquivo como arquivo.xml. O conteúdo está indicado abaixo.

Observações importantes:

- Todas as linhas devem ter a mesma quantidade de colunas;

- O valor do atributo bloco indica o quadro (frame) do bloco a ser exibido na composição do cenário. Esse conteúdo visual deve ser criado no arquivo FLA, como abordaremos no segundo post dessa série.

.

2. Leitura do XML

A leitura do arquivo XML pode ser feita em um arquivo FLA ou AS, dependendo da forma como estivermos implementando o projeto. Nesse exemplo, vamos criar um arquivo FLA (ActionScript 3.0) e inserir o código abaixo no primeiro quadro (frame). O nome do FLA não importa, mas fica jogo.fla como sugestão.

.

Acompanhem com atenção os comentários junto ao código e guardem o arquivo como referência. Para qualquer outra aplicação utilizando XML vocês poderão aplicar o mesmo modelo.

Bom, terminaram de criar os arquivos? Então agora é só executar o FLA e visualizar as informações sobre linhas, colunas e blocos listadas na janela de saída.

.

Espero que tenham entendido e conseguido implementar! Até o próximo post, quando cuidaremos da criação, posicionamento e exibição dos blocos!

.