Jogos · Game Developer

Minha participação no Ludum Dare #58

Fri, 10 Oct 2025 00:00:00 +0000

Apesar de participar da game jam Ludum Dare há mais de uma década, ainda continuo aprendendo como finalizar um projeto em um tempo tão curto.

Lembro da primeira vez que participei de uma game jam, lá em 2015. Na época eu já trabalhava na indústria de jogos há cerca de cinco anos, com nomes como Glu e Electronic Arts no currículo, mas as game jams sempre me ensinaram algo novo sobre desenvolvimento de jogos.

Como mencionei no meu artigo anterior, decidi participar da última edição da game jam Ludum Dare. Desta vez, o tema escolhido pelos participantes foi Collector.

Conceito do jogo
#

Assim que o tema foi revelado, começou a contagem regressiva de 48 horas. Collector foi o tema mais votado de uma lista que os participantes geram e votam durante a semana anterior à game jam. Como essa lista é divulgada antes, costumo me preparar pensando no que poderia fazer com base nas 16 possibilidades.

Minha ideia original era criar um jogo roguelike em que o jogador coletaria cartas deixadas pelos inimigos e as usaria para melhorar seus poderes e habilidades. Antes de cada novo nível, o jogador escolheria algumas das cartas coletadas e usaria as habilidades dessas cartas para avançar e conquistar mais cartas ao final.

Como dá pra ver na imagem abaixo, rascunhei a ideia no papel, listando tudo o que veio à cabeça, sem pensar muito na viabilidade naquele momento. Esse processo ajuda bastante a tirar as ideias da cabeça e colocá-las no papel, deixando tudo mais claro e fácil de visualizar.

Do papel ao Unity
#

Assim que a ideia ficou um pouco mais concreta, comecei a desenvolver na minha game engine de escolha: Unity. Uso o Unity desde 2009, quando a versão 3.0 foi lançada, então é sempre minha escolha segura.

Meu conselho pra quem quer participar de uma game jam, seja iniciante ou profissional, é: use uma engine que você já conheça e tenha alguma experiência. Fazer um jogo em tão pouco tempo, com um tema que você só descobre na hora, já é difícil o bastante — então é importante eliminar qualquer complicação desnecessária do processo.

Costumo preferir fazer jogos 2D nas game jams, porque é mais fácil pra eu desenhar algo simples e colocar no jogo (até porque não tenho nenhuma habilidade artística). Porém, dessa vez decidi fazer um jogo 3D. Sabendo das minhas limitações, optei por usar apenas objetos geométricos básicos do Unity e criar materials diferentes pra mudar as cores. Também adicionei alguns spotlights nos objetos pra dar mais destaque.

Comecei criando uma cena de testes — algo que sempre faço pra experimentar ideias. Na imagem abaixo dá pra ver a cena: basicamente um plane servindo de chão e quatro cubos esticados formando as paredes. O jogador é um cilindro amarelo e os inimigos são cubos vermelhos e azuis — tudo bem simples, pra eu conseguir focar na jogabilidade.

Conforme comecei a programar, também fui ajustando a ideia e reduzindo bastante o escopo, pra garantir que conseguiria terminar algo dentro do prazo.

A jogabilidade mudou pra algo mais simples: inimigos surgem na cena e perseguem o jogador. Quando colidem, ambos causam dano ao longo do tempo até que um deles morra ou o jogador se afaste.

Mantive o conceito de coletar cartas, mas na nova versão do jogo os inimigos deixam cair cartas das suas respectivas cores (que chamei de cartas de Fogo e Gelo). Quando o jogador coleta uma carta, sua vida é restaurada para 5 pontos.

Esse é o core loop do jogo: o jogador precisa atacar os inimigos, mas também fugir quando mais de um começa a persegui-lo. Os inimigos vermelhos e azuis têm valores diferentes de ataque, vida e velocidade — assim como o jogador.

A imagem acima mostra a versão final que fiz upload no site do Ludum Dare dentro das 48 horas. Não tive muito tempo pra balancear o jogo, então as partidas acabaram ficando mais curtas do que eu esperava se acumular muitos inimigos na tela.

Apesar de o resultado final ser bem mais simples do que o conceito inicial, consegui desenvolver um jogo durante o fim de semana. Por causa dos inimigos e cartas vermelhas e azuis, o nome que escolhi foi Fire & Ice.

Lições de uma game jam
#

Depois de mais uma game jam, acho que meus conselhos e aprendizados continuam praticamente os mesmos das participações anteriores. Aqui vão algumas coisas que fiz e que funcionaram bem:

Pense em ideias de jogos com base na lista de possíveis temas antes da game jam começar.
Use uma game engine que você já conheça e tenha experiência.
Faça rascunhos da sua ideia pra ter uma visão mais clara do que vai criar.
É normal mudar o conceito do jogo depois que começar, mas tente fechar o core loop o quanto antes pra poder melhorar o jogo a partir daí.
Exporte o jogo para web (se possível), assim outras pessoas conseguem jogar sem precisar fazer download.

E aqui vão as coisas que fiz errado e quero evitar da próxima vez:

Ter que criar tudo do zero em 48 horas já é difícil o bastante, então fazer um jogo 3D não ajuda. Na próxima, vou ficar no 2D — é mais fácil deixar visualmente agradável e com menos problemas de colisão.
Falando em colisão, tive vários problemas que só percebi depois de enviar o jogo. Usando 2D, boa parte disso nem teria acontecido.

Como sempre, participar da game jam foi uma ótima experiência. Sou um grande fã do Ludum Dare e fico feliz de ter algo completo o suficiente pra compartilhar. Ainda estou aprendendo a fazer melhor a cada edição, e tenho certeza de que na próxima vai sair ainda melhor.

Você pode jogar Fire & Ice aqui. O código-fonte está disponível no meu GitHub (um dos requisitos do modo Compo).

Se você perdeu esta edição do Ludum Dare, recomendo ficar de olho na próxima, que vai acontecer em abril de 2026.

Minha participação no Ludum Dare #44

Sat, 04 May 2019 00:00:00 +0000

Depois de não participar das últimas 3 edições do Ludum Dare, decidi tentar fazer um jogo em 48 horas na edição 44. Demorei um pouco pra pensar em uma ideia, e depois de executá-la achei que não ficou bom e decidi não terminar e publicar o jogo na página do evento.

Até tive tempo para me dedicar no jogo, e não demorei muito para achar algo que combinava com o tema Your life is currency (sua vida é moeda, em tradução livre). Meu problema foi acreditar que minha primeira ideia já seria interessante e comecei a desenvolver sem pensar muito. É exatamente pra isso que serve protótipos: validar uma ideia antes de desenvolver, porém não havia muito tempo para validar uma ideia antes de fazer um jogo em 48 horas.

Game Design

Minha ideia era faz um um jogo onde o jogador estava sempre atacando os inimigos, e vice-versa. Com dois botões, aumentar ataque e aumentar defesa, o jogador poderia causar mais dano ou resistir mais aos ataques do inimigo. Porém, esses upgrates lhe custariam vida, e seria necessário balançar o quanto de vida poderia ser usada para upgrades uma vez que os inimigos iriam atacar sem parar. Minha ideia era fazer algo no formato de waves, onde após derrotar alguns inimigos a vida do jogador seria restaurada para uma próxima wave - sempre com inimgos cada vez mais fortes.

Depois de fazer uma primeira batalha do jogador contra um inimigo achei que ficou bem chato e confuso para saber em qual momento o upgrade valeria a pena - sem falar na dificuldade absurda que seria balancear isso e não deixar o jogador apenas gastar tudo em defesa e esperar sentado as coisas acontecerem.

Programação

Decidi usar a boa e velha Unity para realmente não perder tempo relembrando ou pesquisando coisas relacionadas a uma engine ou framework durante a game jam. Apesar de não ter muitos desafios técnicos, gostei da maneira que organizei os atributos padrões do jogador e do inimigo, já pensando em variações que poderiam ser facilmente configuradas através do ScriptableObject que criei. Isso também ajudou bastante para testar o balanceamento do jogador, já que seus atraibutos base estavam em um arquivo.

Outro destaque foi a fórmula para calcular o dano considerando a defesa. Eu pesquisei na internet mas perdi o link da fonte, porém deve ser uma fórmula bem comum para jogos de RPG: ataqueRecebido * ataqueRecebido / (ataqueRecebido + defesa). Como podem ver o no gif acima, o dano é reduzido/aumentado de acordo com os upgrades feitos no jogador. O código do projeto está disponível no meu GitHub.

Arte

Não cheguei tão longe para pensar na arte do jogo, mas minha ideia era fazer a base do jogo em 2D e depois mudar para 3D com cubos se atacando e usar algumas coisas como Camera Shake e partículas para o feedback dos ataques dados e recebidos. Como não sou artista seria algo bem básico, e também seria meu primeiro jogo 3D em um ludum dare.

Conclusão

Apesar de não ter enviado o jogo para a game jam não fiquei frustrado. Pelo contrário, ao perceber que o jogo ficaria ruim e parar de trabalhar nele me poupei da frustação. Talvez desse pra pensar em outro jogo e fazer algo bem simples, mas também não queria ter esse desgaste no meu fim de semana. As vezes as coisas não dão certo, e mesmo falhar é uma grande lição para próximas vezes. Com certeza estarei mais preprado para a próxima vez, e mesmo depois de 10 participações ainda tenho muito para aprender em game jams.

Minha não participação no Ludum Dare #41

Thu, 17 May 2018 00:00:00 +0000

Depois de 9 edições do Ludum Dare, 6 em que participei e 3 em que falhei, decidi não participar desta que seria minha décima vez. Mesmo não participando quis escrever este post sobre algumas coisas que queria compartilhar.

O tema desta edição foi Combine 2 Incompatible Genres (Combine 2 gêneros incompatíveis), e pelos jogos que foram desenvolvidos durante o Ludum Dare #41 percebi que mesmo pensando em temas diferentes os participantes conseguiram criar jogos interessantes. Eu pessoalmente não acho que existam gêneros que são incompatíveis, tudo depende da ideia e da execução.

Nas últimas edições do Ludum Dare reparei que alguns temas as vezes se repetem durante as fases finais onde votamos em todas as sugestões, inclusive temas escolhidos em edições anteriores aparecem com a chance de se repetir em uma nova edição. Na minha opinião, temas que já foram usados deveriam ficar de fora das votações.

Acho que depois de tantas edições os participantes acabam sempre colocando as mesmas sugestões, então pra quem participou de algumas delas acaba percebendo que os temas repetem. Não sei se isso é algo ruim, mas acaba um pouco com a criatividade para novos temas. Sei que não combina com o formato do Ludum Dare, mas hoje eu acho que seria mais divertido se o organizado da game jam escolhesse o tema, sem votação. Acho que assim seria algo realmente diferente.

Faz quase 1 mês que terminou o Ludum Dare #41, mas comecei a escrever este post naquela semana e só agora voltei e terminei. Tomara que eu consiga participar da edição #42 daqui alguns meses, e que desta vez eu termine o jogo.

Minha participação no Ludum Dare #40

Thu, 07 Dec 2017 00:00:00 +0000

Semana passada foi a edição de número 40 do Ludum Dare, e minha nona participação nesta game jam. Repetindo meu desempenho da edição anterior, eu falhei em terminar meu jogo.

Desta vez o tema foi The more you have, the worse it is (Quanto mais você tem, pior é) e como mencionei no post anterior decidi utilizar a Unity, o que teve suas vantagens e desvantagens. Neste link você pode ver detalhes sobre o meu jogo incompleto, o King's Duty. Seu código fonte no GitHub.

Game Design

Minha ideia era fazer um jogo de gerenciamento de recursos onde o jogador tinha que controlar os recursos do seu reino para que não tivesse muito de um único tipo, o que fazia ele ter pouco dos demais e levaria seu reino ao declínio (considerando que eu tivesse acertado o balanceamento para ter esse resultado). Os recursos que defini foram Água, Comida e Ouro, sendo que esta era minha ideia inicial para a produção deles baseada na alocação de trabalhadores:

Produzir 1 unidade de água = consumia 1 unidade de comida e 1 unidade de ouro;
Produzir 1 unidade de comida = consumia 1 unidade de água e 1 unidade de ouro;
Produzir 1 unidade de água = ouro 1 unidade de água e 1 unidade de comida;

O jogador seleciona uma célula do tabuleiro que representa o seu reino e adicionar trabalhadores para gerar o recurso que ele deseja e também para proteger seu reino dos ataques de inimigos que podem sugir ao redor do reino e tentarão destruir os recursos e as células que contem os trabalhadores. Não cheguei a pensar muito no combate, mas provavelmente faria algo simples como um inimigo seria destruído por um trabalhador, mas levaria ele junto. Se tivessem mais inimigos do que trabalhadores em uma célula, aquele local seria tomado pelo inimigo e o jogador não poderia mais colocar trabalhardores lá.

Não cheguei a testar se o balanceamento estava correto, mas estes eram os valores iniciais de produção. Para ajudar nisso utilizei um recurso bem legal da Unity chamado Remote Settings, que fica localizado no serviço Unity Analytics. Este recurso permite criar variáveis do tipo string, int, float ou bolean e definir um valor para os tipos de build Development e Release. Quando o jogo é iniciado, é possível buscar estes valores de acordo com o tipo da build, facilitando bastante ajustar detalhes do jogo sem ter que gerar uma nova build.

A versão gratuita da Unity já te dá acesso a isso, basta criar um projeto e habilitar o recurso de Analytics. Para este jogo decidi criar variáveis para cada recurso de valor inicial, produção por segundo e valor máximo (9 variáveis ao todo). Também criei um define para ignorar o remote settings e poder testar com valores locais, sem precisar ficar alterando os valores no site e fazer sync para aplicar. Nem preciso dizer que me empolguei tanto em brincar com isso que percebi que era algo overkill para uma game jam só depois de já gastar algum tempo nisso, mas é bem útil para jogos.

Programação

Esta foi outra parte que me fez perder tempo por que não consegui me desapegar e fazer código de qualquer jeito, então acabei pensando um pouco demais em cada linha que escrevi. Claro que não é o melhor código do mundo, mas com certeza não deveria ter perdido tempo pensando em deixar ele tão flexível. Em uma game jam de apenas 48 horas, e participando sozinho, o ideal seria pensar em fazer um código de protótipo: descartável e direto ao ponto. O código que fiz está reutilizável para eu continuar este jogo, inclusive a estrutura do projeto e dos prefabs usam algumas das melhores práticas que aprendi na Aquiris e que pretendo compartilhar por aqui em posts sobre Unity, com este aqui.

Arte

Este foi o primeiro jogo 3D que fiz para uma game jam, o que pelo menos planejei fazer. A arte é bem simples, basicamente um tabuleiro quadrado com cubos para cada célula e cubos menores para indicar ocupações do jogador e dos inimigos. Assim como na minha participação anterior, busquei um padrão de cores para deixar o jogo com um visual legal, apesar de simples. Esta foi a paleta de cores que utilizei, e buscar uma um padrão de cores tem sido uma boa prática para fazer algo simples e visualmente agradável. Não cheguei a trabalhar muito na interface, foi apenas uma área com informações e botões para adicionar trabalhadores em uma célula.

Conclusão

Pelo tamanho da descrição do game design da pra ver que tentei fazer algo maior do que fiz em minhas participações anteriores e, apesar de ter perdido tempo com o remote settings e escrevendo código flexível, eu acho que teria conseguido terminar pelo menos algo jogável se estivesse mais motivado. Ainda preciso resolver isso para poder participar do próximo Ludum Dare, e até avançar em meus projetos pessoais.

Minha participação no Ludum Dare #39

Tue, 01 Aug 2017 00:00:00 +0000

E chegou ao fim mais um Ludum Dare, e minha oitava participação nesta game jam teve uma novidade: eu falhei.

O tema desta edição foi Running out of Power e, das opções que poderiam ter ganhado a votação para o tema, foi uma das que eu achei mais sem graça. Porém, isso não foi desculpa para eu ter falhado, e até que pensei em algo legal para fazer (se tivesse conseguido terminar).

Neste link você pode baixar o meu jogo incompleto para Android e MacOS, e também ver seu código fonte no GitHub.

Game Design

A ideia do jogo foi baseada na primeira parte da raid "Crota's End" do Destiny, chamada "The Abyss" (vídeo abaixo). Minha ideia era ter uma caminho de cristais que escureciam a tela quando sua energia era drenada pelo jogador ficando próximo dela. Quando metade do cristal tivesse apagado, uma seta nele iria indica o caminho para o próximo cristal, até a saída da fase. Porém, uma vez que a a tela ficasse escura, ela só iria voltar a ficar clara quando o jogador chegasse no próximo crista. Isso tudo com monstros aparecendo de todos os lados. O nome do jogo, Weight of Darkness, é o nome do debuff que o jogador recebe e fica mais lento na raid do Destiny.

A mecânica era bem simples, o jogador tocaria na tela para movimentar o personagem (e a câmera acompanharia o seu movimento), e o tiro da arma seria automático. Os monstros morreriam com poucos tiros, mas viriam de todos os lados e o jogador teria apenas uma vida. Não era uma ideia totalmente original, mas foi algo dentro do tema que teria sido possível fazer.

Na página do jogo classifiquei ele como "não terminado", e a versão que está lá tem apenas o motimento do personagem e o tiro automático. Também tem um monstro parado ao lado do jogador, que não faz nada mas é "empurrado" pelos tiros.

Programação

Escolhi utilizar Corona SDK e a linguagem de programação Lua, que não é algo novo pra mim, mas não usava esse framework para fazer jogos há uns 4 anos. Minha participação no Ludum Dare 35 foi o jogo com o maior conteúdo que fiz em game jams, e por ter utilizado Lua e Defold dei uma chance para o Corona SDK.

Escolher o Corona SDK não foi uma decisão ruim, e provavelmente vou querer dar outra chance para este framework em alguma outra game jam, mas desta vez não consegui produzir algo com ele. Isto também não foi o motivo de eu ter falhado.

Arte

Acredite ou não, eu demorei mais pra desenhar os o personagem, o monstro e o cristal do que programar essa pequena parte do jogo incompleto. Uma das coisas que fiz quando comecei a arte foi pesquisar uma paleta de cores escuras, e a imagem abaixo foi uma boa escolha para o padrão de cores que eu tinha em mente para o jogo. Já fiz isso em outras participações, e ajuda bastante pessoas que não tem noção de arte (como eu) a combinar cores.

Conclusão

Eu até comecei bem pensando em uma ideia simples o suficiente para fazer sozinho em um fim de semana, e até a arte estava aceitável para colocar no jogo. Tinha até planejado gravar uma pequena trilha sonora com minha guitarra, algo que faz tempo que não faço em uma game jam, mas nada disso foi suficiente pra me motivar a fazer este jogo. Até tinha pensando em desistir de submeter o jogo para a modalidade de 48 horas, e deixar pra terminar na segunda-feira a noite e colocar na modalidade de 72 horas, mas não consegui e deixei o jogo marcado como "não terminado".

Daqui a 4 meses será o Ludum Dare 40 e, como sempre, vou tentar participar e fazer algo legal. Minhas últimas participações não foram tão boas como as minhas primeiras, na minha opinião. Eu sempre estou aprendendo uma lição nova a cada participação, e desta vez foi que não importa game design, arte e programação se você não esta motivado a dar o seu melhor.

Final Frontier: Refactoring e GitHub

Fri, 14 Jul 2017 00:00:00 +0000

Desde o último post sobre o andamento do Final Frontier, há quase 4 meses atrás, comecei a descartar código e assets que eram temporários para o protótipo, e assim começar a desenvolver o projeto como um jogo. Naquele post falei sobre o início do GDD do projeto, que foi o primeiro passo para organizar as ideias que tenho para o jogo e comparar com o que eu testei através do protótipo.

Após aquele post comecei um branch novo do projeto para limpar tudo que era temporário, e até acabei adicionando um novo modelo de nave e refazendo o controle dela. Todo o resto, interface do menu e asteroides, foram removidos por que não tinham sido desenvolvidos pensando em fazer parte do jogo final.

Refactoring preguiçoso

Como mencionei acima, a ideia do refactoring era primeiramente limpar o projeto de assets e código que eu não iria utilizar. Consegui remover quase tudo, deixei apenas algumas coisas para serem usadas como referência daqui pra frente. A estrutura do projeto foi reorganizada e escrevi um código novo para o controle da nave, que está melhor mas não com o feel que eu quero.

Uma das mudanças visuais foi remover o modelo de nave que estava usando por um novo, que é modular e vai permitir que eu mude as partes da nave de acordo com cada upgrade que o jogador selecionar no inventário. O novo asset pack, Modular Spaceship 1: StarSparrow, também é gratuito e permite mudar partes e cores das naves. A mesma empresa que fez esse asset pack gratuito tem um outro bem maior e com mais conteúdo que é pago, o Modular Spaceships Collection. Como o projeto fica em um repositótio público, não posso colocar assets pagos, mas quem sabe um dia eu não faço um repositório privado para poder colocar essas naves e lançar o jogo.

Outra mudança é que o jogo agora tem 4 scenes, sendo duas antes do jogo e duas para o jogo em si. Hoje elas são apenas uma estrutura, mas que no futuro será expandida.

scene_init: Possui scripts de sistemas que precisam ser iniciados com o jogo (ainda não está em uso)
scene_loading: Scene para carregamento dos assets (hoje ta com um timer fake de 3 segundos)
scene_ui: UI do jogo onde vão ficar elementos de interface e menu (hoje tem só o contador de FPS)
scene_game: Scene principal do jogo carregada junto com a UI usando LoadSceneMode.Additive

Por fim, implementei um contador de frames por segundo que vi neste tutorial. Achei algumas coisas bem legais nesse tutorial, como ter a separação de valor máximo, médio e mínimo da contagem de frames por segundo, e o uso de um array de strings para não fazer conversão de o valor do FPS para string em cada frame. Recomendo dar uma lida no artigo e até implementar eu um projeto, é bem útil e simples ter um contador de FPS desde o início.

Features do GitHub

Outra novidade, que vai deixar o desenvolvimento do jogo mais organizado e fácil de acompanhar é o uso de duas features do GitHub: Pull Request (PR) e Issues. Ante seu estava trabalhando direto no branch principal do projeto, mas agora vou criar um branch separado para cada feature nova. Antes de criar o branch, vou criar um Issue no projeto, que vai servir para listar o que eu quero fazer naquela feature. Quando terminar a feature, eu abro um PR mencionando a Issue, e no PR é possível ver todos os commits e arquivos que foram modificados no branch que será/foi mergeado no branch principal. Além disso, o status da Issue pode ser acompanhado no board do projeto no GitHub também.

Se tudo o que eu disse no parágrafo acima não faz sentido, recomendo dar uma lida no livro Introdução ao GitHub: um guia que não é técnico e conhecer as features que o GitHub oferece para os desenvolvedores. O GitHub é muito mais do que apenas um lugar para manter o repositório dos seus projetos, ele também possui ótimas features para ajudar na organização e desenvolvimento. O BitBucket, outro serviço para manter repositórios git, também possui algumas features similares.

Próximo passo

Atualmente estou trabalhando na próxima feature, que é implementar controle da nave através de touch e testar o jogo em um Android. É uma feature simples que não deve tomar muito tempo, e a ideia daqui pra frente é justamente esta: manter tudo simples para o que projeto não fique muito tempo parado por ter uma feature longa em desenvolvimento. Diferente dos posts anteriores, onde eu adicionei o link do último commit do projeto até a data da publicação do post, a partir de agora vou sempre adicionar o link da Issue que eu criei, e nela é possível ver seu status e se já foi integrada ao branch principal. A Issue atual é Touch controls and Android test.

O andamento do projeto pode ser conferido no repositório do GitHub e no board do projeto. Todos os posts desta série sobre meu projeto podem ser vistos na tag Final Frontier, e como sempre qualquer sugestão ou opinião é bem vinda!

Minha participação no Ludum Dare #38

Mon, 24 Apr 2017 00:00:00 +0000

No fim de semana passo aconteceu a edição número 38 da game jam Ludum Dare, comemorando seus 15 anos de existência. Desta vez o tema foi "A Small World" (um mundo pequeno), e eu tentei fazer algo não muito óbvio.

Tive mais ou menos 4 horas para trabalhar nesse jogo, então decidi usar a Unity para não perder tempo e focar em fazer algo dentro do tema e foco no gameplay.

Neste link você pode baixar o jogo para Android, MacOS, Linux e Windows, e também o seu código fonte.

Game Design

Como tive pouco tempo para pensar em um jogo, decidi for em pensar apenas em uma mecânica que estivesse dentro do tema. Minha ideia foi fazer algo estilo faroeste onde dois pistoleiros se enfrentam em uma disputa de sacar e atirar por que o mundo é pequeno demais para ambos. Pra deixar a mecânica mais interessante o jogador só pode atirar se o inimigo estiver sacado a arma também, caso contrário não é um "fair play". A mesma regra vale para o inimigo, que pode atirar no jogador quando ele sacar a arma. Nada muito complicado, apenas um conceito/protótipo de uma mecânica que achei interessante para o tema.

Programação

Tenho que admitir que apesar de ser um jogo simples, eu pedir um certo tempo escrevendo "código bonito". Neste caso bonito quer dizer simples e legível, não sofisticado ou com design patterns. Não tenho muito o que falar aqui, funciona :P

O Unity Cloud Build funcionou muito bem para gerar as builds de Android, Windows, Linux e MacOS sem eu precisar parar para compilar o projeto.

Arte

Não sou artista, e acho que os jogos que fiz antes com estilo pixel art ficaram mais legais, mas pelo menos consegui passar a mensagem que eu queria. Apesar de parecer bonecos de porta de banheiro com chapéu estranho, as animações simples ajudaram a deixar as ações dos personagens simples de entender. Novamente, nada complicado aqui.

Conclusão

Na minha participação anterior eu tive todo o fim de semana livre e não consegui fazer algo muito legal, desta vez tive bem menos tempo mas consegui focar em uma mecânica que acreditei ser um bom conceito dentro do tema. Provavelmente com mais tempo teria feito algo maior e mais polido, mantendo a base simples e talvez adicionando uma opção de multiplayer.

Hoje também é um dia importante para o blog, pois é seu aniversário de 8 anos! Há 8 anos atrás comecei um simples blog pessoal para contar o que eu estava começando a aprender sobre desenvolvimento de jogos, que já passou por mudanças de hospedagem e tecnologia. Essa semana vou fazer um post sobre os 8 anos de blog, mas queria deixar isso registrado aqui. Obriado por acompanhar meus posts!

Final Frontier: Game Design Document

Thu, 30 Mar 2017 00:00:00 +0000

Estes 3 primeiros meses de 2017 foram bem parados para o blog mas logo vou voltar a postar com mais frequencia, principalmente posts sobre o andamento deste projeto (que também ficou parado nos últimos meses). Uma das coisas que deixei pendente no último post foi terminar uma primeira versão de um GDD (Game Design Document) para o projeto, com algumas informações importantes que eu tinha em um caderno.

Primeiro GDD

Uma das coisas que deixei pendente no último post foi terminar uma primeira versão de um GDD (Game Design Document) para o projeto, com algumas informações importantes que eu tinha em um caderno. Para manter tudo em um mesmo lugar, eu comecei o GDD em uma wiki dentro do repositório do projeto no GitHub, assim fica mais fácil para acessar do que deixar um documento público no Google Drive.

Um GDD não é um documento definitivo, ele costuma mudar bastante durante o desenvolvimento de um jogo. Por isso decidi escrever uma primeira versão bem básica para ter um ponto de partida, e enquanto o desenvolvimento do projeto avançar ou manter este documento atualizado. No meu caso não vale a pena ficar muito tempo escrevendo um GDD, por que eu não pensei em todo jogo ainda, mas valeu a pena passar para o arquivo minhas anotações.

Usei como base um modelo de GDD de 10 páginas que está no final do livro Level Up: Um guia para o design de grandes jogos, do Scott Rogers. Neste livro existe também um modelo de uma página e outro bem maior e com mais detalhes, porém achei suficiente começar me baseando no modelo intermediário. Recomendo bastante este livro de game design, o conteúdo é muito bom e ele é fácil de achar em livrarias grandes.

O GDD está divido em 10 partes, sendo que cada uma corresponde a uma página do modelo:

Página de título
História e gameplay
Fluxo de jogo
Personagens e controles
Conceitos de gameplay e características de plataforma
Mundo do jogo
Interface
Mecânicas e power-ups
Inimigos e bosses
Cutscenes, materiais bônus e concorrência

Apesar de simples é um ótimo modelo para começar a colocar as ideias do jogo em ordem, e a partir disso é possível expandir e adicionar mais detalhes sobre o projeto. Este é o meu objetivo, porém este GDD deve ficar sem atualizações até que grande parte do conteúdo desde documento já esteja implementado no jogo. Como todo conteúdo do projeto está em inglês, e o GDD está no mesmo repositório, decidi escrever em inglês.

De volta a Unity

Com minhas anotações ordanizadas em um GDD chegou a hora de voltar a programar, mas com uma noção mais clara de onde quero chegar. Vou mantar as tarefas do projeto atualizadas no repositório do projeto também, mas não vou planejar com muita antecedência tudo que pretendo fazer. Pelo menos o que está em andamento e o que foi desenvolvido estarão atualizados.

Embora eu tenha ficado uns 4 meses sem desenvolver este projeto, isso foi algo bom por que neste período aprendi bastante coisa legal que pretendo colocar em prática. Como escrevi no post anterior devo organizar melhor o projeto para que ele não seja só um playground, e eu nem vou chamar ele de protótipo mais. Final Frontier será um jogo completo, só não sei dizer quando terminarei ou até onde quero chegar, mas espero que eu consiga mostrar seu desenvolvimento aqui no blog.

Conclusão

Estou ansioso para continuar este projeto e postar sobre seu progresso aqui no blog! O andamento do projeto pode ser conferido no GitHub. Todos os posts desta série sobre meu projeto podem ser vistos na tag Final Frontier, e como sempre qualquer sugestão ou opinião é bem vinda!

Final Frontier: Algumas mudanças no projeto

Tue, 20 Dec 2016 00:00:00 +0000

Faz um mês que não escrevo sobre o andamento deste projeto por que ele está parado no momento, mas por alguns bons motivos. Agora está mais claro pra mim onde quero chegar com este projeto, e também como quero fazer isso.

O novo rumo do projeto

No primeiro post sobre este projeto eu falei de algumas referências que tinha para este projeto, e também que não sabia ao certo o que este jogo seria. Agora as coisas estão mais clara pra mim, e agora vou começar a escrever um GDD com tudo que planejo fazer para uma primeira versão e organizar as tarefas.

Encontrei uma referência que é o gameplay que tenho em mente para este jogo, o Galaxy On Fire 3 - Manticore (vídeo abaixo). Os controles em um dispositivo móvel são muito bons, e o gameplay tem muitos elementos que eu quero colocar no meu jogo. Provavelmente esta será minha maior referência para o gameplay, assim como o Destiny é para a interface do jogo. Pretendo fazer este jogo com as plataformas mobile e desktop em mente, então os controles precisam ser bons em qualquer lugar.

O desenvolvimento na Unity

Agora que eu tenho uma noção melhor do que o jogo será, não faz muito sentindo continuar com a ideia de descobrir uma mecânica em um playground. Por isso boa parte dos scripts de teste serão removidos do projeto, e tudo será refeito como um protótipo. Neste caso, não será um protótipo totalmente com um código que pode ser jogado fora, pois muitas coisas podem ser feitas de uma maneira melhor para agilizar a implementação do jogo na Unity (como utilizar prefabs sempre que possível).

O protótipo será algo jogável e próximo de um jogo final, porém provavelmente não terá integrações com backend, redes sociais, multiplayer, e qualquer outra coisa que tire o foco do gameplay single player. A ideia é ter algo que não precise de conexão para ser jogado, e que seja divertido por um bom tempo.

Quero implementar algumas coisas mais avançadas na arquitetura do jogo e explicar como estas coisas funcionam em um projeto Unity. Um exemplo disso é algo chamado dependency injection que foi utilizado no Pokemon Go através do framework Zenject, como pode ser visto na palestra abaixo do Unite deste ano. Outro exemplo é o padrão de troca de mensagens e busca de serviços utilizando o framework Frictionless, que já está em uso no projeto.

Conclusão

Este post foi mais um update do projeto e um pouco sobre seu rumo em 2017. Pretendo focar mais em seu desenvolvimento e tentar definir todo trabalho que será realizado para que eu possa ter uma data de término. O que vai acontecer depois eu não faço ideia, mas primeiro preciso chegar lá.

O andamento do projeto pode ser conferido no GitHub. Todos os posts desta série sobre meu projeto podem ser vistos na tag Final Frontier, e como sempre qualquer sugestão ou opinião é bem vinda!

Minha participação no Ludum Dare #37

Tue, 13 Dec 2016 00:00:00 +0000

Mais uma edição da game jam Ludum Dare passou, e desta vez o tema escolhido foi One Room (um quarto/espaço/local). Demorei para pensar no que fazer, e uma das opções que quase desenvolvi foi uma versão simplificada do jogo de tabuleiro Detetive em um quarto de hotel, algo meio adventure game. Como isso iria exigir mais arte do que consigo produzir (por ser programador), eu descartei a ideia.

Com o tempo se esgotando ao meio dia do domingo decidi fazer algo simples para poder terminar um jogo nesta edição do Ludum Dare, então minha ideia foi fazer um jogo onde com cavaleiro fica no centro de uma sala defendendo cookies de monstros que querem roubar. Assim nasceu o jogo monocromático That's My Cookie (aquele é o meu cookie), que demorou pouco menos de 8 horas para ser produzido.

Neste link você pode baixar o jogo para Android, macOS e Windows, e também o seu código fonte.

Game Design

A ideia era simples: uma sala, o jogador controla o cavaleiro para atacar os monstros e os monstros vão em direção ao cookie (não ao jogador). Um monstro entra na sala por uma das 4 portas e tenta ir em direção aos 3 cookies no centro da sala, e o jogador deve matar o monstro antes dele pegar o cookie.

Eu quiz simplificar os controles e que fosse algo simples de jogar em um dispositivo móvel, então para jogar basta clicar ou tocar na tela e o cavaleiro vai naquela direção. Para simplificar ainda mais, o cavaleiro muda para o modo ataque enquanto se move, e volta para o estado parado se o jogador não tocar na tela.

Quando os monstros pegarem os 3 cookies o jogo termina e a pontuação do jogador é o número de monstros que ele conseguiu matar antes de roubarem seus cookies. É um fim triste para o jogador, mas os monstros ficaram felizes com os cookies (olha a imagem da tela de game over).

Programação

Eu estava planejando utilizar o GameMaker ou a Torque 2D neste Ludum Dare, porém os dois softwares funcionam apenas em Windows e no momento estou só com meu Macbook. Por isso acabei escolhendo utilizar a cocos2d-x novamente e fazer o jogo em C++. Como tinha pouco tempo para fazer, já que demorei para pensar no que fazer, acabei ganhando tempo utilizando algo que eu já conhecia.

Fazer os monstros terem um caminho único, em direção ao cookie, facilitou bastante a programação. Não precisei me preocupar em fazer o monstro perseguir o jogador, ele apenas vai em direção ao cookie. O spawn deles também foi bem simples e eu utilizei o mesmo monstro sempre, sem precisar instanciar novos monstros todo vez que for necessário fazer ele aparecer pela porta.

Desta vez organizei melhor o projeto criando cenas diferentes para cada tela (início, jogo e game over) e criando classes para cada camada da tela. Tentei evitar utilizar singleton para acessar os objetos, mas não tive como fugir disso já que tinha pouco tempo e precisava de algo rápido.

Arte

Não sei explicar por que decidi fazer o jogo monocromático, mas acabei ganhando tempo não precisando pensar em cores para o jogo. O personagem tem apenas duas animações, uma parado e uma em ataque, e elas são trocadas de acordo com a ação do usuário. Na verdade nem posso chamar isso de animação, por que não utilizei uma classe de animação da cocos2d-x, são apenas dois sprites que ficam visíveis de acordo com o estado do input.

As telas de início e game over são duas imagens que fiz no Photoshop, não são montadas no jogo, por isso na tela de game over não aparecer a pontuação do jogador.

Conclusão

Não foi minha melhor participação, mas também não foi minha pior (eu acho). Além de não saber o que fazer eu estava desanimado para participar, e fiz um pouco obrigado. Tive o fim de semana todo livre, mas só comecei a fazer algo no meio dia do domingo. Provavelmente se eu estivesse motivado faria esse mesmo jogo na metade do tempo, ou usaria os dois dias para fazer um jogo maior e mais ambicioso.

Terminei o jogo às 19h e não queria mais trabalhar nele, fiquei mais uma hora para montar a página no Ludum Dare e gerar as builds. O prazo terminaria meia noite, mas eu não estava com vontade de continuar e nem quis fazer música ou efeitos sonoros para o jogo. Infelizmente, isso acontece.

O próximo Ludum Dare vai ser em comemoração aos 15 anos do game jam, e vou tentar me preparar melhor. Provavelmente usarei alguma engine que eu já conheço para tentar focar mais no game design, fazer algo mais divertido.

Final Frontier: Upgrades e Save Game

Sun, 20 Nov 2016 00:00:00 +0000

Estou um pouco atrasado com este projeto, mas ele não está parado! Neste último fim de semana tive mais tempo para trabalhar no projeto, e comecei a mover algumas coisas de playground para prototype. Isto significa que a fase de experimentar coisas está chegando ao fim e que logo (eu espero!) todos os testes que fiz serão um protótipo jogável.

Itens de Upgrade

Existe um recurso no Unity que eu gosto muito de usar, os Scriptable Objects. Eles são arquivos para armazenar dados gerados a partir de classes que pode ter qualquer coisa, desde que seja serializado. O vídeo abaixo é um treinamento da Unity e um excelente tutorial explicando como usar este recurso, vale a pena assistir!

Eu fiz uma classe para definir algumas características dos itens, como ID, bonus, tipo, e outras coisas que nem sei se vou usar mas coloquei para ter mais dados para testar. Também criei uma outra classe para armazenar todos os itens, assim eu posso selecionar qualquer item a partir de algum filtro usando LINQ.

Salvando o progresso do jogo

Ainda é cedo para o jogo ter um progresso para ser salvo, mas comecei a construir a base para poder montar o inventário baseado em um arquivo com os dados do jogador. Fiz uma classe para armazenar as informações básicas da nave, como nível, nome e classe, e uma matrix para armazenar itens por slot (10 slots na interface com 10 itens em cada). O video abaixo, também de um treinamento da Unity, é um excelente tutorial mostrando as diferenças entre usar o PlayerPrefs e serializar dados em uma classe.

Itens na interface

Criei um prefab com apenas um texto para testar adicionar os itens carregados a partir do save game na interface. Estou armazenando o ID do item como string, e usando LINQ busco por este ID na lista de scriptable objects.

Eu recomendo dar uma olhada no código do jogo no projeto para ver como isto foi implementado. Lembrando que este código é apenas um teste, e ainda será melhorado. Abaixo está o resultado de carregar os itens na interface, o próximo passo é carregar mais itens em cada slot e permitir alterar o item ativo.

Framework Frictioness

O Frictioness é um excelente framework para criar instâncias de classes como um serviço e enviar/receber mensagens. Por enquanto estou usando apenas o serviço RegisterSingleton para criar uma instância única da classe DataManager, mas em breve irei utilizar o serviço de RouteMessage.

Utilizar o Frictioness permite implementar uma maneira melhor de compartilhar instâncias e eventos pelo projeto do que referenciar ou passar objetos como parâmetros para classes static, como um singleton padrão. Nos próximos posts vou explicar mais sobre este framework e sua implementação quando adicionar mais coisas no projeto.

Conclusão

Se você olhar o código vai ver que tudo citado neste post requer um pouco mais trabalho do que parece, principalmente por eu ter desenvolvido tudo sem uma definição clara. Agora eu que estou começando a trabalhar mais no protótipo do jogo sinto a falta de ter pelo menos um GDD definindo algumas coisas básicas do jogo.

Outra coisa que me incomoda é o fato de eu ainda estar trabalhando na tarefa de interface do inventário. Claro que não é um inventário simples, mas gostaria de terminar isso logo e voltar ao gameplay. Provavelmente no próximo post da série devo estar próximo de terminar a mecânica básica do inventário, e vou poder integrá-lo com o jogo.

O andamento do projeto pode ser conferido no GitHub, e neste link você pode ver as alterações no projeto até este post. Todos os posts desta série sobre meu projeto podem ser vistos na tag Final Frontier, e como sempre qualquer sugestão ou opinião é bem vinda!

Final Frontier: Organizando tarefas

Fri, 04 Nov 2016 00:00:00 +0000

No post anterior sobre o projeto houve pouco progresso por que meus dias estavam corridos, porém estas duas últimas semana foram ainda mais corridas e não conseguir trabalhar projeto na Unity, porém conseguir pelo menos organizar as tarefas do projeto.

Organizando a casa

Quando comecei o projeto, há 4 meses atrás, estava pensando em criar um projeto no trello para organizar as tarefas e deixar público o andamento do projeto em um board. Porém, mês passado o GitHub lançou um mini-trello para organizar tarefas de um repositório. Apesar de ser limitado, é bem útil pois cada tarefa pode ser ligada com um issue e associado a um pull request.

Como o repositório está no GitHub e eu pretendo usar seus recursos, como a Wiki para o GDD, achei que faz sentido manter a organização de tarefas lá, assim fica tudo no mesmo lugar. Outra feature legal é que cada repositório pode ter vários projetos. Eu criei um projeto para o protótipo, depois posso criar um para bugs, releases, e qualquer outra coisa que fizer sentido.

Mini Scrum

Estou usando alguns conceitos de scrum, embora minha sprint seja indeterminada. No board criar as colunas de To Do (o que deve ser feito na sprint), Doing (o que está sendo feito) e Done (tudo que já foi feito em todas sprints do projeto). Adicionei também uma coluna chamada Backlog onde vou colocar tarefas que ainda não estão na sprint atual, mas um dia entrarão em alguma sprint. Por enquanto tem pouco coisa lá, mas agora que tenho um lugar para organizar o projeto mais tarefas irão surgir.

Neste link você pode acompanhar o desenvolvimento do projeto. É um board básico simples, porém é o essencial para este momento do projeto. Assim ficará mais clara pra mim e para você aonde o projeto está indo, o que está sendo feito e o que será feito. Como sempre, qualquer sugestão é sempre bem vinda!

Conclusão

Semana que vem vou fazer um post sobre o que fez eu não conseguir trabalhar neste projeto nas últimas duas semanas. Espero que nas próximas duas semanas eu consiga trabalhar mais neste projeto, não vejo a hora de poder ter algo jogável para compartilhar aqui.

O andamento do projeto pode ser conferido no GitHub. Todos os posts desta série sobre meu projeto podem ser vistos na tag Final Frontier, e como sempre qualquer sugestão ou opinião é bem vinda!

Final Frontier: Detalhes do Inventário

Wed, 19 Oct 2016 00:00:00 +0000

No post anterior fiz o inventário expandir quando o cursor estiver em cima de um slot. Desta vez comecei a adicionar alguns detalhes visuais, além de definir o que cada coluna da interface terá em relação a nave.

Partes da nave

A coluna da direita está dividida em cinto parte: asa esquerda, asa direita, frente, corpo e motor. Cada uma destas partes formarão a nave, possibilitando diversas combinações com diferentes pedaços. Isto também possibilitará a nave ter o mesmo conjunto ou ser totalmente sem padrão. As partes terão diferentes raridades e durabilidades, como uma armadura de um jogo de RPG. Ainda falta definir muitas coisas, mas quero que isto seja customizável e colecionável.

Upgrades da nave

Na coluna da esquerda estarão upgrades e armas que farão a nave ter um poder ofensivo maior, uma defesa maior, uma velocidade maior, entre outras coisas. As partes da nave irão influenciar, por exemplo uma nave com partes grandes será mais lenta do que uma nave com partes menores, e o upgrade de velocidade irá afetar ambas as naves de maneiras diferentes. Ainda não defini quais serão os upgrades, mas a ideia é que cada pedaço e upgrades afetarão o gameplay de uma maneira única (e balanceada, espero!).

Próximos passos

Este post foi mais curto do que os anteriores, não tive muito tempo livre para trabalhar neste projeto por causa de um outro jogo que estou desenvolvendo e uma outra novidade que vou contar em outro post mais pra frente. No próximo post espero ter finalizado o básico dos upgrades para poder integrar a tela de interface no jogo e continuar o desenvolvimento do gameplay.

Final Frontier: Expandindo o Inventário

Wed, 05 Oct 2016 00:00:00 +0000

No post anterior demonstrei como iniciei o desenvolvimento da interface do inventário da nave, baseado na interface do jogo Destiny. O inventário ainda não, e desta vez comecei a adicionar mais funções na interface.

Melhorias no inventário

Até o último post alguns itens na interface eram apenas uma imagem estática, porém estes precisavam ser elementos de interface dinâmicos para serem modificados pelos itens colocados em cada slot. Por ser apenas um protótipo utilizei o slider da Unity para criar as barras de cada status, e no script que controla estes valores é possível modificá-los através do editor. Para exibir os controles abaixo basta adicionar [Range(x, y)] acima da declaração da variável, onde x é o valor mínimo e y o valor máximo, de acordo com o tipo da variável (int, float, etc).

Modifiquei também o movimento da interface e da nave de acordo com o movimento do cursor. No post anterior coloquei um GIF mostrado como estava funcionando, e um durante a última semana achei que estava estranho. Modifiquei o movimento para ficar limitado a área do jogo (antes estava considerando mesmo o cursor fora do jogo), adicionei limites para a movimentação e deixei o movimento no geral mais suave. Este tipo de melhoria não faz sentido em um protótipo, porém estava atrapalhando o desenvolvimento do próximo item, que era expandir cada slot para mostrar as opções dele. Ah, também mudei o nome da nave para uma do jogo Star Realms.

Expandindo cada slot

Uma das features mais legais da interface do jogo Destiny é a expansão de cada slot revelando opções de armas ou armaduras para serem equipadas quando o cursor está em cima do item ativo. No caso do Destiny a solução é bem sofisticada, e inclusive possui um atrito que reduz o movimento do cursor quando ele passa por cima de um slot. No meu caso, quero algo simples e que funcione para alterar upgrades da nave no meu protótipo.

Utilizei os mesmos botões das colunas de slots, porém tive que reduzir seu tamanho para caber na tela. Criei um Panel como Horizontal Layout Group e adicionei três outros panels como Vertical Layout Group, contendo três botões em cada. O resultado é um conjunto com nove items em cada slot.

Esconder e exibir este panel no momento correto foi um pouco demorado, tive problemas utilizando OnPointerExit para esconder o panel, pois ele deveria ficar visível quando o cursor sair do panel mas está em cima do slot. A solução final ficou no script TestItem, onde na hora de esconder o panel eu verifico a direção do movimento e se ele está em cima do slot antes de esconder. Por ser um protótipo não tem problema, mas na versão final do jogo eu imagino que esta interface vai dar um bom trabalho para ficar do jeito que eu imagino.

Algumas tools para o editor

Esta semana no Live Training da Unity (que acontece a cada duas semanas) o tema foi como criar ferramentas básicas para o editor da Unity. O video abaixo mostra como fazer algumas coisas básicas como converter Texture2D para Sprite dependendo do diretório que o arquivo for importado, selecionar objetos por Tag e criar objetos de maneira mais fácil e customizável. Recomendo assistir, adicionei as tools do vídeo no projeto para ajudar no desenvolvimento.

Próximos passos

Ainda existem muitas coisas para fazer na interface antes de voltar ao gameplay como: adicionar alguns upgrades nos slots, mudar o upgrade ativo e fazer os upgrades afetarem os status da nave (ataque, defesa, velocidade e carga). Depois disso volto a programar o gameplay e fazer estes status serem modificadores da nave durante o jogo. Também pretendo adicionar suporte ao controle do Xbox e Steam para mover o cursor, por enquanto apenas o mouse está funcionando. Além disso, preciso dar uma geral em alguns scripts que estão com código antigo comentado e alguns que nem estão sendo usados.

Final Frontier: Interface do inventário

Wed, 21 Sep 2016 00:00:00 +0000

Os últimos posts foram sobre o desenvolvimento da mecânica do jogo, que por enquanto é apenas uma nave atirando em caixas que explodem. Este mês coloquei o gameplay um pouco de lado para trabalhar na interface de usuário (UI) do jogo, e comecei pela principal tela: upgrade e informações sobre a nave.

Quando eu penso na interface para gerenciar os upgrades da nave, na hora me vem na cabeça a interface do jogo Destiny. A ideia de usar um cursor para controlar a tela em um jogo de console foi bem arriscada, mas deu muito certo, e o melhor de tudo é que funcionaria bem em desktops. No caso de dispositivos móveis, basta remover o cursor e usar touch e drag para realizar as mesmas ações.

Inspiração para a interface

Toda semana procuro assistir alguns videos de palestras no canal da GDC no YouTube, e há algum tempo assisti o video abaixo, onde o designer de interface do Destiny conta como foi o processo para chegar no resultado que vemos hoje no jogo. Isto sem dúvidas me inspirou a começar a trabalhar na UI do meu jogo.

A interface do jogo No Man's Sky também é interessante para o que eu quero fazer, e muito similar a interface do Destiny em alguns aspectos, mas acredito que para o meu jogo não iria funcionar. Gosto da ideia de carregar alguns upgrades separados por tipo e selecionar um para ser o ativo para aquele determinado tipo, como o Destiny faz.

Há duas semanas a Unity lançou o video abaixo sobre criação de menus na Unity, que é algo que eu já sabia mas assisti mesmo assim por que sempre acabo aprendendo algo novo. Graças ao video descobri um novo pacote gratuito na asset store da Unity, o Unity Samples: UI, que tem artes com estilo futurista para UI e combinam muito bem com a ideia do jogo.

Criando a interface

Para não bagunçar a scene que estou usando para criar e testar o gameplay, criei uma nova scene chamada PlaygroundUI, onde comecei a trabalhar na UI para o gerenciamento de upgrades da nave. Antes de começar a criar a UI na Unity montei a imagem abaixo no Photoshop, pra ter uma noção de como ficaria antes de começar a montar direto na game engine.

Importei esta imagem na Unity e comecei a montar a UI por cima dela. Esta é uma boa dica para posicionar os elementos de uma nova UI sem perder muito tempo arrastando ou calculado sua localização. É como copiar um desenho com uma outra folha por cima, facilita bastante o trabalho. Utilizei os botões do asset que baixei e deixei com a cor branca transparente para os slots de upgrade, e adicionei umas labels para o textos. Apenas os status abaixo da nave permaneceram uma imagem por enquanto. O resultado na Unity está na imagem abaixo.

Com a UI pronta adicionei o modelo da nave e posicionei de uma maneira semelhante ao personagem no jogo Destiny, e coloquei um planeta bem grande atrás. Fiz um script simples para fazer o planeta girar lentamente e adicionei umas partículas do mesmo asset da UI, foram coisas simples mas que deixam o protótipo com uma cara ainda melhor.

Movimentando a interface

Por fim, comecei a fazer a UI se mover de acordo com a direção do cursor (também igual ao Destiny). A ideia era fazer a UI seguir a direção do cursor, porém fazer a nave ir na direção oposta. Ainda não terminei, preciso encontrar os melhores valores para a movimentação, mas no git abaixo é possível ver um pouco de como está ficando.

Me desculpe pelo gif horrível, é a primeira vez que tento exportar um video em gif e ficou maior do que eu esperava (3MB). Segui este tutorial, mas se alguém tiver uma sugestão de tool ou outra maneira de fazer isso deixe um comentário no post.

Para o movimento fiz um script chamado TestInventory que serve para ambos GameObject e UI, pois cada um tem um componente diferente para controlar o movimento, Transform e RectTransform, respectivamente. Pelo script é possível configurar o tipo do objeto, velocidade horizontal e vertical, e se o objeto deve ir para o sentido normal ou oposto ao cursor.

Para a movimentação utilizei Translate através de uma Coroutine quando o mouse se movimenta pela tela. Também é possível fazer a movimentação com Lerp, mas optei para usar o Translate no protótipo.

Próximos Passos

Acho que foi um bom início para a UI do inventário, pelo menos tenho uma ideia melhor de qual caminho seguir. A interface do Destiny é uma boa base para o meu jogo, mas é claro que ao longo do desenvolvimento vou modificar para ficar de acordo com meu jogo. Os próximos posts provavelmente serão sobre a UI, devo adicionar mais interação com o usuário e customizações nos slots. Quando estiver com o mínimo de recursos que eu preciso, vou adicioná-la na scene do jogo. Como podem ver na minha segunda lista de tarefas abaixo, agora a prioridade é a UI do jogo.

Final Frontier: Raycast, Spawn e MoSCoW

Thu, 08 Sep 2016 00:00:00 +0000

Faz um mês desde o último post sobre o andamento deste projeto, mas ele não está parado. Mês passado teve o Ludum Dare #36 e realizei uma palestra na USP sobre Game Jams, então meu tempo livre (e os posts do blog) foram voltados a estes eventos. Agora que tudo passou, vamos voltar ao Final Frontier.

Desta vez vou falar sobre a substituição da colisão de objetos do tiro por Raycast, uma classe para fazer Spawn de objetos usando o design pattern Prototype e o início da organização das tarefas do projeto usando o método MoSCoW.

Substituindo colisão do tiro por Raycast

No último post sobre o andamento do jogo eu mencionei que iria adicionar uma mira no centro da tela para o jogador ter uma noção melhor de onde está atirando. Eu adicionei, porém o tiro ficou estranho. Como a nave está em constante movimento, o tiro (que é uma bola) estava indo bem fora da mira se a nave estivesse virando. Geralmente no início do projeto do protótipo não devemos perder tempo em melhorias, mas neste caso faria toda diferença ter um tiro mais consistente.

Por isso decidi implementar a técnica de Raycast para determinar se hoje a colisão com o objeto (então explodi-lo). A Unity tem bastante coisa implementada para auxiliar no uso do Raycast, então não é algo complicado de implementar, apenas leva um tempo para ajustar. Para desenhar a linha do tiro, que seria como um laser, pesquisei como fazer e encontrei este excelente tutorial da Unity (video abaixo) que cobre também como fazer o Raycast.

O resultado final ficou muito melhor do que o tiro com as bolinhas. Não é algo final, talvez eu mude isto mesmo durante o protótipo, mas agora está mais consistente para eu poder continuar desenvolvendo o jogo, principalmente para adicionar novos objetos para serem destruídos. O video abaixo também é uma ótima referencia para o uso de Raycast na Unity.

Spawner de objetos com prototype

Agora que o tiro está bem melhor, decidi adicionar mais objetos para o jogador atirar. Por enquanto ainda estou utilizando a mesma caixa do início do projeto, porém criei um spawn aleatório. No momento limitei para gerar 10 grupos contendo 4 caixas (2x2) ao redor da nave, em qualquer direção. Antes estava usando um grupo de 9 caixas (3x3) e o frame rate caia demais na explosão, e por ser apenas um teste não vale a pena perder tempo nisso agora, então reduzi para menos caixas (que depois vai ser um asteroide ou algum outro objeto no espaço).

O spawn de objetos é algo muito simples de fazer utilizando o design pattern Prototype, principalmente na Unity onde o protótipo é um prefab. Utilizei o mesmo conceito em alguns jogos que fiz usando Unity em dois Ludum Dare, então copiei o código de lá e adicionei ao projeto.

Reaproveitar código de outros projetos, mesmo classes pequenas como esta que utilizei, ajudam a ganhar tempo por dois motivos: não perder tempo escrevendo o código e não perder tempo testando o código. É sempre bom ter alguns códigos prontos e, de preferência, escritos para serem reaproveitados em diferentes projetos. Algo ainda mais sofisticado seria criar módulos ou plugins (no caso da Unity), muitas empresas fazem isto para reaproveitar códigos que podem estar em qualquer projeto. Por isso, sempre é bom seguir o princípio K.I.S.S.

Método MoSCoW

Antes de pensar em fazer um GDD, é legal listar algumas ideias do que será o jogo. Eu fiz uma longa lista de features que gostaria de colocar no jogo, isto não significa que estão na versão final mas serão testadas durante a fase de prototipagem. Esta lista, que podemos chamar de backlog, contém diversas tarefas que podem ser divididas em partes menores. É o mesmo conceito de definir as tarefas de uma sprint no Scrum.

Mais tarde vou começar a criar o GDD na Wiki do projeto no GitHub, além de fazer um controle das tarefas utilizando Trello. Mas, por enquanto, vou utilizar papel e caneta, e um método chamado MoSCoW. Este método consiste em classificar as features ou tarefas em 4 tipos:

Must have: importante e obrigatório
Should have: importante, mas não necessário
Could have: desejável, mas não importante
Won't have: importante NÃO ter

Isto é algo bem simples que ajuda a organizar a prioridade de tarefas, mas sem burocracias ou dependência de uma ferramenta específica. Apenas anote os itens em cada uma das classificações e pronto, ai está sua lista de tarefas organizada. A ideia do "Won't have" é que não se deve perder tempo com as tarefas nesta classificação. Um exemplo disso seriam tarefas relacionadas a melhorias e polimentos não necessários em um protótipo.

Abaixo está a lista que montei para esta primeira parte do projeto desde seu início, e o número #01 indica que é a primeira lista. "Nice to have" e "Good to have" equivalem a "Should have" e "Could have", respectivamente, e não tem o "Won't have". Aprendi a separar as tarefas desta maneira com um produtor quando trabalhava na EA, sem saber que isto se chamava MoSCoW (e que tinha o Won't have).

No verso desta folha adicionei uma lista chamada "Backlog" para listar ideias que tive durante o desenvolvimento das tarefas, assim posso planejar a próxima lista considerando estas ideas como possíveis tarefas.

Próximos Passos

Agora que o tiro está bem melhor, e com uma mira para auxiliar sua direção, o próximo passo vai ser melhorar um pouco o movimento da nave, pois ela está saindo da tela com frequência e ficando em uma posição errada quando volta. É um detalhe que precisa ser arrumado antes de começar a pensar em adicionar features como inimigos ao protótipo. Outra coisa que quero fazer é uma interação com o planeja que está no cenário, fazendo aparecer um tela quando o jogador se aproximar do planeja e exibindo algumas ações disponíveis.

O andamento do projeto pode ser conferido no GitHub e neste link você pode ver as alterações no projeto até este post. Todos os posts desta série sobre meu projeto podem ser vistos na tag Final Frontier, e como sempre qualquer sugestão ou opinião é bem vinda!

Minha participação no Ludum Dare #36

Tue, 30 Aug 2016 00:00:00 +0000

Pela quinta vez consecutiva participei do Ludum Dare na competição de fazer um jogo sozinho em 48 horas. Desta vez o tema era Ancient Technology (tecnologia antiga) e depois de descartar ideias relacionadas ao Egito e Idade da Pedra (que eram meio obvias para o tema), acabei lembrando de um episódio da série Vikings onde eles usavam uma pedra para achar o sol em dias nublados, e meu jogo foi baseado nisso.

Antes de iniciar fiz uma pequena pesquisa para a entender como esta pedra conhecida como Sunstone era utilizada. Parece que não é certo que foram utilizadas historicamente, porém existem evidências que foram encontradas em navios naufragados e a região mais comum de encontrá-la é na Islândia, um lugar bem conhecido pelos Vikings. O video abaixo é um dos melhores que encontrei que explica um pouco sobre este assunto.

Game Design

Desta vez foi a maior prioridade do meu projeto, pensar bem no game design do jogo. Depois de ficar duas horas pensando no tema e chegando na conclusão acima, fiquei mais umas 2 ou 3 horas pensando na jogabilidade. Pensei em bastante coisa para este jogo, e achei que daria para fazer tudo, mas infelizmente não deu para fazer tudo.

A mecânica base do jogo é você encontrar o sol movendo a Sunstone pela tela. Quando os dois pontos ficam pretos na mesma intensidade (conforme imagem abaixo), lá é onde o sol está. Além desta informação o jogo fala a posição do sol: nascendo ou se pondo. Com estas duas informações é possível encontrar a direção em que você está navegando, e é assim que se acredita que Vikings navegaram antes da invenção do compasso.

O jogo te dá um objetivo: ir para uma direção e uma determinada distancia do centro do mapa, que é a posição inicial do jogo. Para tornar o jogo simples eu assumi que o sol sempre nasce no LESTE e sempre se poem no OESTE. Assim, é possível saber exatamente onde fica a direção do objetivo e chegar na ilha para entregar as encomendas, ganhar 10 pontos e receber uma nova missão. Além disso, o jogador ganha um upgrade do navio, que pode ser aumentar a velocidade em 10 ou aumentar a pontuação em 1.

Infelizmente levei boa parte dos dois dias para programar esta mecânica e fazer a arte necessária, então o resto do jogo saiu bem diferente do que planejei. A ideia inicial era que o jogador poderia escolher qual missão queria, sendo que elas iriam variar entre perto, médio e longe, e a distancia e recompensa seriam diferentes para cada uma. Também pensei em um upgrade de carga que faria o jogador poder aceitar entregas maiores.

O jogo terminaria em 7 dias de trabalho, sendo que cada dia o jogador teria 12 horas para fazer as missões, que consumiriam as horas de acordo com a distância navegada. No fim, não foi possível fazer nada disso e implementei uma pontuação simples onde o jogador tem 5 minutes (300 segundos) para fazer o máximo de pontos até o tempo acabar.

Programação

Repeti o mesmo erro consciente de usar uma engine/framework que não uso há um tempo ou que é novo para mim. No Ludum Dare anterior utilizei a Defold, que era nova pra mim. Desta vez utilizei uma velha conhecida, porém que não usava há alguns anos, a Cocos2d-x.

Atualmente a Cocos2d-x está na versão 3.12, e na última vez que utilizei estava na versão 2.X. Muita coisa mudou, muita mesmo, desde nome de classes até a maneira de utilizar algumas coisas. Na época nem tinha suporte ao C++11 e hoje está presente em praticamente tudo neste framework. Acabei não tendo tempo de me atualizar, então comecei a utilizar a versão mais nova da Cocos2d-x mais ou menos do jeito que eu lembrava, e sempre que esbarrava em algo consultava a documentação online (que hoje está muito boa e completa).

Desta vez decidi que o foco do meu jogo seria mobile, então desenvolvi no Mac OS X usando Xcode, sempre testando no emulador e em um aparelho Android. A Cocos2d-x está muito melhor hoje, e é bem simples compilar e testar outras plataformas sem precisar abrir outra IDE ou tools utilizando a linha de comando. Devido essa facilidade, era bem rápido testar. Eu desenvolvia no Xcode e testava no emulado, mas quando necessário rodava um simples comando para fazer o deploy e testar em um aparelho Android. Depois da compilação inicial que demora alguns minutos fica bem rápido, compilando apenas as alterações no código.

Nos últimos anos trabalhei muito com Unity, usando C#, e com HTML5, usando Javascript, e estava sentido falta de programar em C++. Praticamente desde a EA fechou em 2013 eu não programava em C++, e é uma sensação incrível pra mim. Vou tentar utilizar C++ com mais frequência, e também me atualizar com o C++11.

Este foi o primeiro Ludum Dare que utilizei um framework para fazer o jogo, sendo que nos quatro anteriores utilizei três vezes a Unity e uma vez a Defold, ambas game engines. Desenvolver um jogo sem algumas facilidades visuais que uma game engine tem dá mais trabalho, mas mesmo assim não me arrependo de ter utilizado a Cocos2d-x. Mas me arrependo de não ter utilizado algumas tools externas como TexturePacker e Tiled para me ajudar no desenvolvimento.

Arte

Não fiquei tão feliz com a arte como na minha participação anterior, mas mesmo assim foi muito melhor do que minhas demais participações. Mesmo sendo uma arte simples, fique feliz com o meu barco e a ilha. As nuvens foram um detalhe legal, e se você reparar elas se movem lentamente pela tela, sem tampar o campo de visão no centro da tela. Minha Sunstone ficou aceitável, porém não fazia ideia de como representá-la e esta foi minha melhor arte.

Infelizmente não consegui fazer música e efeitos sonoros. Esta foi a primeira vez que não coloquei nem efeitos sonoros, e a segunda vez que não coloquei música em um jogo no Ludum Dare. Acabei deixando para depois e não sobrou tempo, sendo que fiz a mecânica de pontuação na última meia hora antes das 48 horas acabarem.

Conclusão

Na minha última participação fique feliz com a programação e a arte, mas deixei o game design de lado. Desta vez foquei tanto no game design que pensei em um jogo grande demais para eu fazer em 48 horas, e isso acabou afetando a arte (ficou simples e sem som) e a programação (nas últimas horas a qualidade do código ficou bem ruim). Não fiquei feliz com o resultado, mas ainda assim fiquei feliz em ter participado e pelas lições que aprendi desta vez.

Esta foi a primeira vez que não fiz uma build para Web, e sinceramente isto não fez falta. O jogo está funcionando bem em aparelhos Android, iOS (infelizmente não tem como colocar uma build para download, mas da pra compilar o projeto e testar), Mac e Windows (se você não viu esta build lá é por que ainda não atualizei, preciso compilar em um Windows).

Ainda não encontrei um equilíbrio bom entre Arte, Programação e Game Design, mas acredito que estou chegando perto de saber a dose certa de atenção que devo ter em cada área para fazer um jogo completo em 48 horas. Desta vez tive praticamente as 48 horas livres, dormi bastante de sexta pra sábado e pouco de sábado para domingo. No fim não foi um grande problema, pois mesmo com 48 horas sem dormir o jogo ainda estaria grade demais para eu fazer em 48 horas do jeito que imaginei.

O código do jogo está disponível no GitHub e na página do jogo no Ludum Dare existem mais informações sobre como baixar e jogar. O próximo Ludum Dare será em dezembro e já estou bem ansioso! Talvez eu tente novamente utilizando C++, porém ainda estou em dúvida se utilizo Unreal Engine ou chuto o balde e tento fazer algo no Linux (já trabalhei usando Ubuntu e Debian para programar backend, mas nunca um jogo). Talvez eu mude de ideia até lá e utilize algo diferente, ou algo que já usei. Na verdade não sei ainda, mas já estou ansioso para a próxima vez.

Final Frontier: Câmera e controle

Wed, 03 Aug 2016 00:00:00 +0000

No último post deste série sobre o desenvolvimento do meu jogo Final Frontier falei sobre o novo skybox e melhorei a destruição da caixa que representa um asteroide. Desta vez trabalhei em melhorias para a câmera e o controle da nave, além de alterar novamente o skybox e adicionar um planeta.

Um planeta na galáxia

Um skybox adiciona detalhes incríveis ao jogo, e muitas vezes o jogador não repara na arte que está acima de suas cabeças. O mapa da Lua no jogo Destiny tem um skybox incrível, com a Terra e a ISS destruída em destaque no céu.

Eu decidi mudar o skybox para outra opção do mesmo asset pack, desta vez com uma névoa verde que adiciona mais detalhes. Também adicionei um novo asset pack gratuito chamado Vast Outer Space, que contém modelos de planetas, asteroides e algumas partículas. Adicionei o planeta abaixo, ele parece próximo mas está bem longe e aumentei o modelo 1000 vezes. Também alterei o Clipping Planes da câmera, aumentando o Far para 10000, assim o planeta aparece ao fundo mesmo estando bem longe.

Pilotando a nave

Até então o controle da nave era algo temporário, até mesmo para um quase protótipo. Decidi pesquisar como eu gostaria que o controle da minha nave fosse, e usei como referência alguns jogos que gostava de jogar no Nintendo 64 e Playstation 2. Estava em dúvida entre: Star Fox 64, onde a a câmera fica fixa seguindo a nave; Star Wars Rogue Squadron, onde o jogador tem mais liberdade porém com variação de zoom na nave; Star Wars Starfighter (video abaixo), onde encontrei a melhor referência para o que eu quero fazer no Final Frontier.

Eu poderia modificar o código que fiz para a movimentação da nave, adicionando ainda mais linhas de código, mas decidi pesquisar outras maneiras de controlar a nave. Mesmo sendo um código temporário, muitas linhas de código podem dificultar implementar novas features, portanto decidi melhorar esta parte do código. Usei como referência o video abaixo, que ensina a fazer um jogo simples de pilotar aviões.

O resultado final, que foi uma mistura do que eu tinha feito com novas coisas do video acima, ficou bem melhor do que eu esperava. Além dos direcionais do teclado agora também é possível controlar usando um controle conectado ao computador, testei com o Xbox 360 Controller for Windows e o Steam Controller. Para deixar o tiro mais simples e reduzir uma verificação no código adicionei o botão space como um trigger para o botão Fire1 no Input Manager (Edit > Project Settings > Input).

Câmera

Na versão anterior do controle da nave a câmera estava dentro do prefab da nave, o que dava a impressão de uma câmera dura seguindo a nave. Como alterei o controle, foi natural também adaptar a câmera para esta nova situação. Decidi tentar usar o LookAt como é mostrado no video acima, mas não funcionou muito bem no meu caso, pois quando a nave dava um loop a câmera girava e ficava de cabeça para baixo.

Meu erro foi assumir que tudo do video acima funcionaria no meu caso, porém a câmera tem um comportamento diferente, então removi o LookAt e fiz a rotação da câmera ser a mesma da nave, o que ficou exatamente como eu queria. Ajustei a distância da câmera adicionando um offset no script, assim ela ficou um pouco mais afastada, além de dar um efeito legal ao rodar o jogo (a nave sai de trás da câmera e vai para o local do offset).

Próximos passos

Agora que a movimentação da nave está melhor vou começar a trabalhar em uma mira na tela, para o jogador saber onde está atirando, e vou substituir a caixa branca por um modelo de asteroide. Provavelmente vou dar uma pesquisada em algum efeito de partícula para a nave e os tiros, substituindo as bolas brancas por algo que faça mais sentido ser atirado por uma nave no espaço.

Final Frontier: Skybox e mais destruição

Wed, 20 Jul 2016 00:00:00 +0000

No post anterior sobre o meu projeto Final Frontier eu escrevi sobre como estava utilizando o playground para testar o gameplay e como fiz um modelo 3D feito no Blender ser destruído na Unity. Nest post vou falar sobre skybox e algumas melhorias que fiz para a destruição ser maior, além de outros detalhes sobre a organização do projeto na Unity.

Ao infinito e além

Skybox é o nome da textura que fica no "fundo" do cenário renderizado pela câmera principal. O skybox padrão da Unity é um céu azul e um "chão" marrom no horizonte e, além de eu achar feio, este skybox padrão não combinava com meu jogo. Então, fui na Asset Store procurar uma opção gratuita e que fizesse mais sentido e foi então que encontrei o incrível Skybox Volume 2 (Nebula)!

Esta coleção de skyboxes possui 7 opções diferentes, todas bem interessantes e muito bem detalhadas. Por enquanto vou utilizar o Stars01 (imagem acima), mas vou colocar alguns exemplos abaixo de outras opções que eu gostei. Apesar de todas opções serem bem legais é bom manter no projeto apenas as que serão utilizadas por que esta coleção tem 80MB. Por enquanto vou deixar todas, mas ao longo do projeto provavelmente vou remover as que não irei utilizar. Existem outros assets no diretório Standard Assets que não estou usando e logo vou remover do projeto também.

Adicionando mais destruição

No post anterior eu tinha colocado apenas uma caixa que, quando o tiro colide com ela, o modelo 3D é substituído pela versão "destruída" e a física é aplicada nela para que os pedaços voem pelo ar. Desta vez decidi fazer uma parede de caixas que explode as demais quando os destroços de uma voarem após a colisão com o tiro, e o resultado fica conforme a sequencia abaixo.

Muitos modelos 3D voando pelo cenário com física para colisão podem fazer o jogo ficar pesado. Não é o caso para o meu jogo ainda, mas quando mais objetos estiverem no cenário, mais modelos serão desenhados na tela, o que pode ser um problema para alguns aparelhos com hardware limitado. É muito cedo para se preocupar em otimizar isso, pois ainda nem sei como o jogo será, mas fiz algumas alterações para minimizar este problema.

O modelo do tiro e dos da caixa destruída são removidos da cena pelo método da Unity chamado Destroy(gameObject, timer), onde o timer é o tempo para que o objeto seja destruído após sua criação. Nada demais, mas já ajuda a manter a memória livre de objetos desnecessários.

Organizando a casa

Uma das alterações que fiz, seguindo a sugestão do leitor Felipe, foi colocar os assets baixados em um diretório separado ao invés de deixá-los jogados no projeto. Não tinha feito isso antes por ter apenas o Astra Starship Fleet Package no projeto, mas agora com o Skybox Volume 2 (Nebula) já faz mais sentido começar a organizar melhor. Ambos assets estão na pasta ThirdParty Assets, como mostra a imagem abaixo. Geralmente utilizo este nome ou algo parecido para esta pasta.

Outra alteração que fiz foi criar um novo prefab chamado TestAsteroidGroup, e adicionei 9 caixas dentro dele para formar a parede. É sempre bom criar prefabs para agrupar objetos, mesmo sendo outros prefabs. Outro detalhe visto na imagem acima é que estou colocando prefabs e scripts em diretórios com o mesmo nome da minha cena Playground. Estou fazendo isto por que quero manter tudo usado no playground separado do protótipo, mas sem a necessidade de criar um novo projeto.

Próximos passos

Eu mencionei no post passado mas acabei não tendo tempo de trabalhar na movimentação da nave, pelo menos não na implementação. Pesquisei algumas opções de controle e câmera, e no próximo post vou falar mais sobre isto. Se eu tiver tempo também quero começar a fazer um sistema simples de spawn para os meteoros (e talvez até achar assets para substituir as caixas).

O andamento do projeto pode ser conferido no GitHub, e neste link você pode ver as alterações no projeto até este post (também sugestão do leitor Felipe). Todos posts desta série sobre meu projeto podem ser vistos na tag Final Frontier, e como sempre qualquer sugestão ou opinião é bem vinda!

Final Frontier: Playground e destruição

Wed, 06 Jul 2016 00:00:00 +0000

Este é o segundo post sobre o jogo que estou desenvolvendo no meu tempo livre, o Final Frontier. Neste post vou falar sobre como estou usando o playground para descobrir a mecânica do jogo e também como fiz um modelo 3D ser destruído.

O jogo está em desenvolvimento publicamente no GitHub, então dependendo de quando você ler este post pode ser que muita coisa tenha mudado. Mesmo assim, as dicas aqui podem ser aplicadas em seu projeto.

Como brincar no playground

Como disse no post anterior, o playground não é um protótipo. O playground é usado para experimentar ideias, enquanto o protótipo é usado para validar o gameplay. Por isso, existem algumas boas práticas que eu gosto de seguir aqui.

A primeira dica é deixar bem claro o que pertence ao playground no projeto. Como o playground pode fazer parte do projeto de um protótipo ou da versão final, é comum utilizar scripts e assets de test ou finais no playground. No meu caso eu estou usando este playground antes de iniciar o desenvolvimento do protótipo, então decidi separar prefabs e scripts em uma pasta "Playground".

Os scripts estão dentro de um namespace chamado "Playground", e quando usados exibem o log de warning abaixo. Este é uma dica que aprendi recentemente lendo a entrevista do John Romero, onde ele fala que é sempre bom exibir na tela o que está acontecendo, principalmente o que não é esperado. Como este projeto deve crescer e ter muitos scripts e prefabs, eu quero ter certeza de que algum prefab com script de playground será esquecido no jogo.

É sempre bom criar opções para debug visual enquanto o projeto está rodando e aproveitando os recursos do editor da Unity. Na imagem abaixo eu criei um Boolean chamado cameraFollow que pode ser habilitado durante a execução para fazer a câmera do jogo deixar de seguir a nave. Eu não coloquei o objeto da câmera dentro da nave para que durante sua movimentação não dê a impressão ser "dura". Isso vai fazer mais sentido quando implementar o controle completo da nave.

Destruindo objetos 3D

Destruição de objetos e cenário é algo que sempre quis implementar mas nunca tive uma oportunidade. Pode parecer algo muito complicado mas na verdade é simples de entender a idéia por trás. Basicamente você tem dois modelos: um normal e um "destruído", e quando o objeto é destruído você substitui pelo modelo destruído e aplica alguma física nos destroços se necessário.

Como eu quero utilizar apenas ferramentas e assets gratuitos neste projeto, escolhi utilizar o blender para fazer um moledo de um cubo inteiro e um cubo destruído. O video abaixo ensina como fazer isto no blender e como adicionar a física necessária na Unity, mas basicamente você precisa aplicar Cell Fracture com Noise no modelo e importar na Unity adicionando um Mesh Collider em cada pedaço.

Próximos passos

Vou tentar escrever um post sobre este projeto a cada duas semanas. Como costumo publicar um post por semana vou intercalar posts sobre o andamento do projeto com o conteúdo do blog, assim consigo falar do projeto e ainda mostrar técnicas e dicas que estou usando em seu desenvolvimento.

Fique a vontade para baixar o projeto no GitHub e comentar aqui no post suas opiniões e sugestões. Para o próximo post pretendo implementar o controle da nave, spawn de asteroides pelo caminho e mais alguns detalhes no playground. Embora demore duas semanas para eu publicar o próximo post, você pode acompanhar meu trabalho no jogo pelo GitHub, pois sempre que possível vou trabalhar neste projeto durante a semana.

Jogos · Game Developer

Minha participação no Ludum Dare #58

Conceito do jogo #

Do papel ao Unity #

Lições de uma game jam #

Minha participação no Ludum Dare #44

Minha não participação no Ludum Dare #41

Minha participação no Ludum Dare #40

Minha participação no Ludum Dare #39

Final Frontier: Refactoring e GitHub

Minha participação no Ludum Dare #38

Final Frontier: Game Design Document

Final Frontier: Algumas mudanças no projeto

Minha participação no Ludum Dare #37

Final Frontier: Upgrades e Save Game

Final Frontier: Organizando tarefas

Final Frontier: Detalhes do Inventário

Final Frontier: Expandindo o Inventário

Final Frontier: Interface do inventário

Final Frontier: Raycast, Spawn e MoSCoW

Minha participação no Ludum Dare #36

Final Frontier: Câmera e controle

Final Frontier: Skybox e mais destruição

Final Frontier: Playground e destruição

Conceito do jogo
#

Do papel ao Unity
#

Lições de uma game jam
#