[{"content":"","date":"18 de dezembro de 2025","externalUrl":null,"permalink":"/posts/","section":"Blog","summary":"","title":"Blog","type":"posts"},{"content":"","date":"18 de dezembro de 2025","externalUrl":null,"permalink":"/categories/","section":"Categorias","summary":"","title":"Categorias","type":"categories"},{"content":"","date":"18 de dezembro de 2025","externalUrl":null,"permalink":"/","section":"Game Developer","summary":"","title":"Game Developer","type":"page"},{"content":"No mês passado, participei do evento anual da Unity, o Unite, em Barcelona, onde apresentei a palestra Reusable technology: Saving development time with shared Unity plug-ins and SDKs. Durante a apresentação, compartilhei dicas e melhores práticas para desenvolver, compartilhar e manter SDKs e plugins para Unity.\nHoje, a Unite publicou a gravação da palestra em seu canal oficial, junto com as demais apresentações do evento. Você pode conferir o vídeo abaixo, assim como os slides da apresentação.\nApresentei a palestra em inglês, mas, caso seja mais fácil, no YouTube você pode selecionar uma dublagem gerada pelo Google em português nas configurações do vídeo ou adicionar legendas geradas em inglês.\nAbaixo estão os slides da apresentação, que publiquei no Slideshare junto com minhas outras palestras. O PDF também está disponível neste link para download.\nComente abaixo se tiver alguma pergunta ou dúvida sobre a minha apresentação. Este é um assunto que faz parte do meu dia a dia trabalhando na Ubisoft, e tenho bastante coisa para compartilhar.\n","date":"18 de dezembro de 2025","externalUrl":null,"permalink":"/palestra-unite-2025-reusable-technology-mobile-sdks/","section":"Blog","summary":"No mês passado, participei do evento anual da Unity, o Unite, em Barcelona, onde apresentei a palestra Reusable technology: Saving development time with shared Unity plug-ins and SDKs. Durante a apresentação, compartilhei dicas e melhores práticas para desenvolver, compartilhar e manter SDKs e plugins para Unity.\n","title":"Minha palestra na Unite 2025 em Barcelona","type":"posts"},{"content":"","date":"18 de dezembro de 2025","externalUrl":null,"permalink":"/categories/palestras/","section":"Categorias","summary":"","title":"Palestras","type":"categories"},{"content":"Neste post você vai aprender como configurar um repositório Git em projetos Unity, seja antes de iniciar um novo projeto ou em um projeto já existente.\nNo vídeo, explico o passo a passo da configuração, compartilho boas práticas e dicas importantes para trabalhar com controle de versão e mostro como o mesmo processo funciona no GitHub, podendo ser adaptado facilmente para GitLab e Bitbucket.\nAssista ao vídeo abaixo para acompanhar o tutorial completo.\nLinks mencionados no vídeo:\nSite oficial do git Software visual para git: Sourcetree Software visual para git: GitKraken Repositórios git: GitHub Repositórios git: GitLab Repositórios git: BitBucket Arquivos grandes com Git LFS Mais conteúdo sobre git:\nGit e LFS em projetos Unity Introdução ao GitHub: um guia que não é técnico Modelo de desenvolvimento com GIT usando branches Como criar atalhos com git alias ","date":"15 de dezembro de 2025","externalUrl":null,"permalink":"/git-no-unity/","section":"Blog","summary":"Neste post você vai aprender como configurar um repositório Git em projetos Unity, seja antes de iniciar um novo projeto ou em um projeto já existente.\n","title":"Git no Unity: Como configurar um repositório do zero","type":"posts"},{"content":"","date":"15 de dezembro de 2025","externalUrl":null,"permalink":"/categories/unity/","section":"Categorias","summary":"","title":"Unity","type":"categories"},{"content":"Unite é o evento anual da game engine Unity, que aconteceu este ano novamente em Barcelona, entre os dias 17 e 20 de Novembro. Foi minha primeira vez no evento, e tive a honra de participar não apenas como espectador, mas também como palestrante e Unity Insider.\nO título da minha palestra foi Reusable technology: Saving development time with shared Unity plug-ins and SDKs, onde compartilhei como desenvolvemos SDKs para Android e iOS, plugins para Unity, e como testamos e publicamos. Este é parte do trabalho que minha equipe realiza na Ubisoft, e foi uma experiência incrível compartilhar isso no maior evento da Unity. Vou fazer outro post sobre a minha palestra quando a gravação for publicada no canal da Unity no YouTube, e comentar mais sobre o assunto.\nAlém de palestrar, também participei de um encontro com outros membros do programa Unity Insiders, do qual faço parte desde 2022. Também vou escrever outro post sobre este programa e os criadores de conteúdo que conheci pessoalmente no evento.\nNeste post, quero destacar alguns anúncios do Keynote, a inesperada parceria entre Unity e Unreal, e o Roadmap da game engine para o próximo ano.\nKeynote # O grande destaque do keynote deste ano foi a ausência de produtos e serviços baseados em Inteligência Artificial generativa, o que considero um ponto muito positivo. Tudo que foi apresentado no keynote, e depois detalhado no roadmap, mostra que a Unity está focada nos desenvolvedores de jogos e em tornar sua engine uma ferramenta sólida, ao invés de seguir o hype da I.A. para agradar acionistas.\nAlguns jogos feitos com Unity lançados este ano foram apresentados, com destaque para Tiny Bookshop, Megabonk e Peak. Os desenvolvedores de Peak subiram ao palco para compartilhar como conseguiram criar um jogo em apenas 10 semanas, com 7 desenvolvedores, e que já vendeu mais de 10 milhões de cópias. Eles enfatizaram a facilidade de prototipar e iterar utilizando a engine.\nOutro dado interessante apresentado foi que 70% dos jogos para dispositivos móveis são feitos utilizando Unity, o que demonstra a dominância desta game engine nesta plataforma. Além disso, 33% dos jogos no Steam são feitos com Unity, e na web o número é de aproximadamente 50%. Não foram mostrados dados para consoles, mas acredito que sejam inferiores aos do Steam, caso contrário teriam sido apresentados.\nDurante o keynote, foi apresentado que a Unity consolidou seus esforços em três categorias que representam o ciclo de vida de um projeto: Develop (Desenvolver), Deploy (Lançar), e Grow (Crescer). Cada novo serviço, funcionalidade ou melhoria apresentada durante o evento está dentro destas categorias. Abaixo, fiz um resumo de algumas novidades que estão por vir.\nDevelop # Em parceria com a Konami, a Unity desenvolveu e lançou um jogo para Switch 2, o Survival Kids, o que permitiu observar de perto a utilização da engine para criar um jogo do início ao fim, além de adicionar suporte ao Switch 2 no lançamento.\nEste jogo foi desenvolvido pela Unity Studios, e mais jogos serão lançados para ajudar a aprimorar a engine. Levou quase 20 anos para a Unity perceber que, ao utilizar sua própria engine, poderiam entender melhor as necessidades dos desenvolvedores. Isso também faz parte de outra iniciativa da Unity, chamada Production Verification, onde garantem que uma versão da Unity foi utilizada e verificada por eles mesmos em produção (ou seja, lançaram um jogo).\nAo que tudo indica, a Unity 7 (ou o que estava sendo chamado de Unity 7 até então) foi \u0026quot;cancelada\u0026quot;. Em vez de uma nova versão, a Unity lançará versões incrementais da Unity 6 (semelhante ao ciclo de lançamento da Unreal). A Unity 6.3 LTS acabou de ser lançada, e no final de 2026 teremos a Unity 6.7 LTS, sendo que as versões lançadas entre estas duas (6.4, 6.5, 6.6) trarão melhorias, mas sem o Long Time Support (LTS).\nOutras novidades incluem uma nova ferramenta para utilizar modelos 3D em jogos 2D (não é 2.5D), a validação de pacotes instalados pelo Package Manager com uma assinatura que garante a autenticidade deles, entre outras melhorias detalhadas no vídeo do roadmap.\nOutro destaque é a migração do .Net para o Core CLR, que deve melhorar várias áreas da engine, como redução do tempo de compilação (projetos com mais de 50% de redução), suporte a versões mais novas do C#, e maior estabilidade para o editor. A migração está prevista para começar na versão 6.4 e ser concluída na versão 6.7.\nDeploy # O principal destaque aqui foi o Platform Toolkit, um novo pacote da Unity que promete acelerar a publicação de jogos em diversas plataformas. Os desenvolvedores precisarão de apenas uma API para cada funcionalidade específica das plataformas, como conquistas, e a Unity garantirá que isso funcione em todas as plataformas suportadas, sem necessidade de alterações no código.\nOutra promessa é que isso deve ajudar no processo de certificação dos jogos para lançamento em consoles, um processo complexo e exigente. Com este novo pacote, a Unity busca facilitar o lançamento de jogos em mais plataformas, reduzindo ou até eliminando complexidades específicas de cada uma.\nGrow # A Unity apresentou uma nova ferramenta chamada Vector AI, que analisa o mercado e os dados do jogo para oferecer direções e sugestões para aumentar o engajamento dos jogadores. Esta foi provavelmente a única menção a uma ferramenta utilizando I.A., e parece ser uma ideia promissora, especialmente para pequenos estúdios e desenvolvedores independentes que não possuem equipes dedicadas para coleta e análise de dados.\nOutra novidade é uma ferramenta para In-App Purchase (compras dentro do jogo), que permite a utilização de meios de pagamento de terceiros, como Stripe e Coda, além de uma ferramenta para gerenciar o inventário do jogador. Graças ao processo da Epic contra o monopólio da Apple e Google em suas lojas digitais, o suporte a meios de pagamento de terceiros está se tornando mais comum em jogos para dispositivos móveis.\nUnity x Epic # O momento mais surpreendente do evento foi, sem dúvidas, o anúncio da inédita parceria entre Unity e Epic, com os CEOs de cada empresa no palco. A parceria permitirá que desenvolvedores na Unreal utilizem a nova ferramenta de In-App Purchase da Unity, provavelmente disponibilizando um plugin para Unreal e permitindo o acesso ao serviço.\nAlém disso, foi anunciado que jogos feitos com a Unity poderão ser lançados dentro do ecossistema do Fortnite. Detalhes ainda não foram anunciados, mas estou curioso para saber como isso funcionará. Sem dúvidas, isso abre um novo mercado para jogos feitos com Unity, beneficiando desenvolvedores e jogadores.\nRoadmap # Além do keynote, por enquanto o único vídeo publicado do evento foi o roadmap abaixo, que mostra em detalhes tudo que foi mencionado no keynote.\nComo o vídeo acima aborda basicamente o mesmo assunto do keynote, porém com muito mais detalhes, não vou escrever sobre a apresentação em si.\nConclusão # Fiquei feliz pela ausência de I.A. generativa e por ver que a Unity está levando a sério melhorias na engine com os desenvolvedores em mente. Após o fiasco do runtime fee (cancelado) e a troca de CEO, a Unity parece estar focada em tornar sua engine mais estável, com funcionalidades e serviços alinhados às necessidades dos desenvolvedores.\nEsta foi minha primeira vez no Unite, e também a primeira vez apresentando uma palestra em Inglês. Fiquei feliz de participar do evento como palestrante, insider, e por reencontrar amigos e colegas de trabalho. Isso me faz lembrar que a indústria de jogos é \u0026quot;pequena\u0026quot; e sempre reencontramos pessoas ou conhecemos alguém com contatos em comum.\n","date":"24 de novembro de 2025","externalUrl":null,"permalink":"/unity-unite-2025/","section":"Blog","summary":"Unite é o evento anual da game engine Unity, que aconteceu este ano novamente em Barcelona, entre os dias 17 e 20 de Novembro. Foi minha primeira vez no evento, e tive a honra de participar não apenas como espectador, mas também como palestrante e Unity Insider.\n","title":"Minha participação na Unite 2025 em Barcelona","type":"posts"},{"content":"","date":"10 de outubro de 2025","externalUrl":null,"permalink":"/categories/jogos/","section":"Categorias","summary":"","title":"Jogos","type":"categories"},{"content":"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.\nLembro 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.\nComo 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.\nConceito 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.\nMinha 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.\nComo 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.\nDo 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.\nMeu 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.\nCostumo 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.\nComecei 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.\nConforme comecei a programar, também fui ajustando a ideia e reduzindo bastante o escopo, pra garantir que conseguiria terminar algo dentro do prazo.\nA 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.\nMantive 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.\nEsse é 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.\nA 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.\nApesar 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 \u0026amp; Ice.\nLiçõ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:\nPense em ideias de jogos com base na lista de possíveis temas antes da game jam começar.\nUse uma game engine que você já conheça e tenha experiência.\nFaça rascunhos da sua ideia pra ter uma visão mais clara do que vai criar.\nÉ 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í.\nExporte o jogo para web (se possível), assim outras pessoas conseguem jogar sem precisar fazer download.\nE aqui vão as coisas que fiz errado e quero evitar da próxima vez:\nTer 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.\nFalando em colisão, tive vários problemas que só percebi depois de enviar o jogo. Usando 2D, boa parte disso nem teria acontecido.\nComo 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.\nVocê pode jogar Fire \u0026amp; Ice aqui. O código-fonte está disponível no meu GitHub (um dos requisitos do modo Compo).\nSe você perdeu esta edição do Ludum Dare, recomendo ficar de olho na próxima, que vai acontecer em abril de 2026.\n","date":"10 de outubro de 2025","externalUrl":null,"permalink":"/ludum-dare-58/","section":"Blog","summary":"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.\n","title":"Minha participação no Ludum Dare #58","type":"posts"},{"content":"Nesta sexta começa a edição de número 58 da game jam Ludum Dare, o melhor game jam! Uma ótima oportunidade para criar um jogo para o seu portfólio, colocar em prática algo que está aprendendo, ou apenas se divertir fazendo um jogo durante o fim de semana.\nConseguir um primeiro emprego na indústria de jogos não requer apenas conhecimento - ter um portfólio para demonstrar suas habilidades ajuda bastante. Game jams são uma ótima maneira de conseguir fazer um jogo em um tempo e tema pré-determinados, o que também ajuda a focar e não perder muito tempo pensando no que fazer.\nExistem muitas game jams online e presenciais, mas para mim a Ludum Dare é a melhor para quem está começando a fazer jogos, ou mesmo se está querendo participar de algo mais casual do conforto de casa, sozinho ou em grupo.\nO tema da Ludum Dare é anunciado antes do seu início na sexta-feira, e é o resultado de uma votação aberta que acontece durante a semana que antecede o evento.\nVocê pode participar de dois formatos, e cada um tem suas características e audiência:\nCompo: 24 horas para fazer um jogo do zero e sozinho - você não pode usar nada que já esteja pronto. Este é o modo mais hardcore que vai forçar a sua criatividade, e as pessoas não vão julgar sua arte se o gameplay for bem feito e divertido. Jam: 72 horas para fazer um jogo sozinho ou em grupo, e você pode usar qualquer coisa que já esteja pronta para ajudar a criar o jogo. Este é um formato mais tranquilo, onde você tem menos pressão e mais ajuda para terminar seu jogo. É tão de boas que também permite submeter um jogo fora do tema, desde que você tenha feito ele durante o Ludum Dare. Se esta é a primeira vez que você está participando de uma game jam, eu recomendo o formato Jam que é mais tranquilo, mesmo se você já tem alguma experiência desenvolvendo jogos. Mas, se você estiver confiante, participe do Compo e faça o seu melhor.\nA minha primeira participação foi no Ludum Dare #32, dez anos atrás, e desde então participei de mais de 10 edições no formato Compo. Consegui terminar o jogo em algumas, em outras falhei, mas isso tudo é parte do aprendizado que uma game jam pode te dar.\nAqui estão algumas dicas que podem te ajudar:\nQuando começar a rodada de votação final na sexta-feira, você vai ter uma lista dos possíveis temas - tente pensar qual jogo consegue fazer dentro do tema no final de semana. Utilize uma game engine ou framework que você já conhece e se sente confortável em utilizar para poder focar em fazer o jogo. Se você quiser participar do modo ultra hardcore (inventei isso), utilize uma game engine ou framework que você nunca utilizou antes - isso aumenta o desafio e também é uma oportunidade de experimentar algo novo. Pegue leve e descanse - planeje o seu final de semana, quantas horas vai focar no seu jogo, e lembre-se de que você precisa sobreviver para enviar seu jogo no final. Coloque uma roupa confortável e sua melhor playlist, tente focar especialmente no primeiro dia para conseguir um bom progresso. Divirta-se! Lembre-se de que isso faz parte de um game jam. Eu pretendo participar do formato Compo e espero que possa compartilhar meu jogo e minha experiência na próxima semana.\n","date":"1 de outubro de 2025","externalUrl":null,"permalink":"/esta-semana-comeca-o-ludum-dare-58/","section":"Blog","summary":"Nesta sexta começa a edição de número 58 da game jam Ludum Dare, o melhor game jam! Uma ótima oportunidade para criar um jogo para o seu portfólio, colocar em prática algo que está aprendendo, ou apenas se divertir fazendo um jogo durante o fim de semana.\n","title":"Esta semana começa o Ludum Dare #58","type":"posts"},{"content":"","date":"1 de outubro de 2025","externalUrl":null,"permalink":"/categories/noticias/","section":"Categorias","summary":"","title":"Notícias","type":"categories"},{"content":"","date":"13 de julho de 2025","externalUrl":null,"permalink":"/categories/como-programar-jogos/","section":"Categorias","summary":"","title":"Como Programar Jogos","type":"categories"},{"content":"Após minha graduação em Ciência da Computação, iniciei uma pós-graduação em Produção e Programação de Jogos com o objetivo de mudar minha carreira e entrar na indústria de jogos. Isso foi em 2009, e uma das primeiras ferramentas de desenvolvimento de jogos que tive contato foi o SDL2, onde fiz o meu primeiro projeto de game com SDL e C++ em uma disciplina da pós-graduação. De lá pra cá utilizei o SDL em diversos projetos, principalmente game jams e para aprender a programar homebrew para Nintendo DS e PSP, e sempre foi um framework fácil de usar e bem completo para jogos 2D.\nCriar um projeto novo utilizando Visual Studio e configurar o SDL2 era um pouco mais trabalhoso, e inclusive escrevi este tutorial pra mim mesmo por que eu sempre esquecia de algum passo. Alguns meses atrás, o SDL3 foi oficialmente lançado, e trouxe algumas mudanças para simplificar o desenvolvimento de jogos e sua configuração. Neste post vou mostrar como criar um projeto novo no Visual Studio, adicionar o SDL3 como uma dependência usando git submodule, configurar o projeto para compilar um Hello World, e como automatizar builds em cada commit utilizando GitHub Workflows.\nSDL como dependência usando git submodule # A parte mais importante de todo este post é este primeiro passo, pois aqui vamos configurar o projeto como um repositório git e adicionar o SDL3 como um submodule. Existem diversos conteúdos muito bons sobre git, então não vou alongar muito com uma introdução, e vamos direto ao ponto. Caso não tenha git na sua máquina, você pode instalar aqui.\nPrimeiro, precisamos criar um repositório local. Os comandos abaixo são os mesmos em qualquer sistema operacional, mas como vamos utilizar o Visual Studio neste tutorial, pode assumir que estou utilizando Windows. Criei um novo diretório no seu computador com o nome HelloWorldSDL3. Após criar o diretório, abra o prompt de comandos do Windows (cmd ou power shell), nave até a nova pasta criada e, dentro dela, execute o comando abaixo:\ngit init Este commando vai criar uma pasta invisível chamada .git. Caso algum erro aconteça, como comando não encontrado, certifique-se que o git foi instalado e está adicionado no path do Windows. Em seguida, vamos adicionar o repositório do SDL como um submodule usando os comandos abaixo:\ngit submodule add https://github.com/libsdl-org/SDL.git SDL Este comando vai adicionar um arquivo .gitmodules com uma referência do SDL no repositório local, e baixar o projeto em uma pasta chamada SDL. Se tudo der certo, seu diretório deverá estar com esta estrutura abaixo:\nHelloWorldSDL3/ ├── .git/ ├── SDL/ └── .gitmodules Neste momento você pode criar um repositório no GitHub (necessário criar uma conta gratuita se não tiver). No meu exemplo abaixo, estou criando um repositório público com o nome hello-world-sdl, e não selecionei nenhuma opção para inicializar o repositório com algum arquivo.\nDepois de criar o repositório, volte para o prompt de comandos e digite os seguintes comandos (substitua USERNAME pelo seu usuário no github):\ngit add . git commit -m \u0026#34;SDL submodule\u0026#34; git branch -M main git remote add origin https://github.com/USERNAME/hello-world-sdl.git git push -u origin main E, após executar os comandos acima com sucesso, o seu repositório estará parecido com o meu na imagem abaixo:\nIsso é tudo que precisamos por agora, mas vamos voltar ao github no final deste post para configurar a automação de compilação no GitHub Workflow.\nCriação de um projeto no Visual Studio # O SDL3 tem uma documentação bem simples e fácil de seguir. A configuração do projeto no Visual Studio pode ser vista aqui, porém vou adicionar os passos em português abaixo com algumas modificações que fiz.\nA principal diferença é que, ao invés de fazer o download do código fonte, nós vamos usar o submodule que configuramos no passo anterior em nosso repositório git.\nNovo projeto no Visual Studio # O Visual Studio 2022 (ou mais novo) pode ser baixado aqui, e a versão Community é gratuita para desenvolvedores solo, uso acadêmico, ou projetos open source. Siga os passos do instalador e lembre de marcar as opções para adicionar Desktop Development with C++ (você também pode marcar as opções de Unity e game development mas não são necessárias para o SDL).\nDepois de instalado, selecione a opção Create a new project e procure por Empty Project com C++, como na imagem abaixo. Se você não estiver vendo essa opção, volte no instalador e veja se as opções de suporte ao C++ foram instaladas no Visual Studio.\nApós selecionar Empty Project com C++, na próxima janela digite HelloGame em Project name, e no campo Location selecione o caminho em que está o repositório que criamos no início deste post. As configurações do novo projeto devem estar iguais a imagem abaixo.\nDepois de criar o novo projeto no Visual Studio, esta é a estrutura do nosso repositório atualizada:\nHelloWorldSDL3/ ├── .git/ ├── HelloGame/ ├── SDL/ └── .gitmodules Adicionando código # Agora que temos um projeto em branco, vamos adicionar um arquivo de C++ e configurar o projeto para utilizar o SDL que está no mesmo diretório. É importante adicionar um arquivo de código fonte em C++ antes de continuar por que isso vai habilitar as opções que vamos configurar mais pra frente.\nClique com o botão direito no projeto HelloGame e, em seguida, selecione a opção Add | New Item... e digite main.cpp. No novo arquivo criado, copie e cole o código abaixo. Não se preocupe com os erros de compilação agora, nós ainda vamos configurar o projeto para localizar o SDL e poder compilar com sucesso.\n#define SDL_MAIN_USE_CALLBACKS 1 #include \u0026lt;SDL3/SDL.h\u0026gt; #include \u0026lt;SDL3/SDL_main.h\u0026gt; static SDL_Window* window = NULL; static SDL_Renderer* renderer = NULL; SDL_AppResult SDL_AppInit(void** appstate, int argc, char* argv[]) { if (!SDL_CreateWindowAndRenderer(\u0026#34;Hello World\u0026#34;, 800, 600, SDL_WINDOW_MAXIMIZED, \u0026amp;window, \u0026amp;renderer)) { SDL_Log(\u0026#34;Couldn\u0026#39;t create window and renderer: %s\u0026#34;, SDL_GetError()); return SDL_APP_FAILURE; } return SDL_APP_CONTINUE; } SDL_AppResult SDL_AppEvent(void* appstate, SDL_Event* event) { if (event-\u0026gt;type == SDL_EVENT_KEY_DOWN || event-\u0026gt;type == SDL_EVENT_QUIT) { return SDL_APP_SUCCESS; } return SDL_APP_CONTINUE; } SDL_AppResult SDL_AppIterate(void* appstate) { const char* message = \u0026#34;Hello World!\u0026#34;; int w = 0, h = 0; float x, y; const float scale = 4.0f; SDL_GetRenderOutputSize(renderer, \u0026amp;w, \u0026amp;h); SDL_SetRenderScale(renderer, scale, scale); x = ((w / scale) - SDL_DEBUG_TEXT_FONT_CHARACTER_SIZE * SDL_strlen(message)) / 2; y = ((h / scale) - SDL_DEBUG_TEXT_FONT_CHARACTER_SIZE) / 2; SDL_SetRenderDrawColor(renderer, 0, 0, 0, 255); SDL_RenderClear(renderer); SDL_SetRenderDrawColor(renderer, 255, 255, 255, 255); SDL_RenderDebugText(renderer, x, y, message); SDL_RenderPresent(renderer); return SDL_APP_CONTINUE; } void SDL_AppQuit(void* appstate, SDL_AppResult result) { } O código acima é uma variação do hello.c disponibilizado no repositório do SDL. As mudanças que fiz foram mudar a extensão para .cpp, remover os comentários para não ficar tão longo aqui, e configurar a janela usando SDL_WINDOW_MAXIMIZED (modo janela) ao invés do original que criava a janela em modo tela cheia.\nAdicionando SDL como dependência # Agora vamos adicionar o SDL no Visual Studio junto com o nosso projeto. Para isso, clique com o botão direito na Solution 'HelloGame', selecione Add | Existing Project e, na nova janela navegue até SDL/VisualC/SDL (dentro do nosso repositório), e selecione o arquivo SDL.vcxproj. Depois de adicionar o projeto SDL junto ao nosso projeto HelloGame, você deve ter a estrutura abaixo no Visual Studio:\nO próximo passo agora é adicionar o SDL como uma referência no projeto HelloGame. Cliquei com o botão direito no projeto HelloGame, selecione Add | Reference... e, na nova janela, selecione o projeto SDL e clique em OK. Isso vai garantir que o nosso projeto use o SDL como uma dependência para compilar o código.\nPor fim, vamos adicionar os headers do SDL na configuração do nosso projeto. Para isso, clique com o botão direto no projeto HelloGame e selecione a opção Properties. Na nova janela, mude o filtro acima para All Configurations e All Platforms (se já não estiver assim). Em seguida, expanda a opção C/C++ no menu da esquerda, selecione General, e no primeiro campo Additional Include Directories, selecione Edit e adicione o caminho SDL/includes (dentro do nosso repositório).\nA imagem baixo mostra como a configuração deste janela deve estar depois dos passos acima:\nRodando o projeto # Se tudo deu certo, agora basta rodar o projeto no Visual Studio utilizando o botão play verde ou pressionando F5, e você deverá ver a tela abaixo:\nCaso encontre algum erro, dê uma revisada nos passos anteriores e compare as imagens que adicionei no post para ajudar. Se mesmo assim tiver dúvidas ou problemas, deixe um comentário que tentarei ajudar assim que possível.\nNós temos um repositório configurado no GitHub com o SDL adicionado como uma dependência e também o nosso projeto configurado para rodar no Visual Studio. O próximo passo agora é um extra, mas que com certeza vai ajudar o desenvolvimento ao médio e longo prazo.\nAutomação com GitHub Workflow # Automação é algo muito comum e essencial em empresas, não só em jogos. A automação pode ser desde rodar alguns testes unitários, compilar o projeto, e até rodar o jogo em um teste pré-definido. Para isso, muitas vezes precisamos de outras máquinas ou até servidores dedicados a rodar nosso projeto sempre que precisar de um teste, ou até mesmo a cada alteração.\nÉ ai que entra o GitHub Workflow, onde podemos automatizar muita coisa no nosso repositório utilizando servidores Windows, Linux e macOS do GitHub. Existem alguns limites, mas mesmo uma conta gratuita tem o suficiente para bastante coisa em projetos pequenos e até médios. Você também pode registrar uma máquina sua como servidor e não se preocupar com limites (já fiz isso com um raspberry pi e funcionou bem para projetos pequenos!).\nNão vou entrar em muitos detalhes sobre o GitHub Workflow em si, por que é algo muito grande e complexo de explicar tudo, mas recomendo dar uma olhada na documentação e pesquisar sobre também.\nPara adicionar suporte a automação em nosso projeto, precisamos apenas adicionar um arquivo no repositório. No repositório, cria uma nova pasta .github e outra pasta dentro dela chamada workflows. Dentro da pasta workflows, adicione um novo arquivo chamado msbuild.yml. Seu repositório deve estar assim:\nHelloWorldSDL3/ ├── .git/ ├── .github/workflows/msbuild.yml ├── HelloGame/ ├── SDL/ └── .gitmodules Por fim, abra o arquivo msbuild.yml em qualquer editor e copie e cole o conteúdo abaixo:\nname: MSBuild on: push: branches: [ \u0026#34;main\u0026#34; ] pull_request: branches: [ \u0026#34;main\u0026#34; ] env: SOLUTION_FILE_PATH: ./HelloGame BUILD_CONFIGURATION: Release permissions: contents: read jobs: build: runs-on: windows-latest steps: - uses: actions/checkout@v4 with: submodules: recursive - name: Add MSBuild to PATH uses: microsoft/setup-msbuild@v1.0.2 - name: Restore NuGet packages working-directory: ${{env.GITHUB_WORKSPACE}} run: nuget restore ${{env.SOLUTION_FILE_PATH}} - name: Build working-directory: ${{env.GITHUB_WORKSPACE}} run: msbuild /m /p:Configuration=${{env.BUILD_CONFIGURATION}} ${{env.SOLUTION_FILE_PATH}} - name: Upload a Build Artifact uses: actions/upload-artifact@v4.6.2 with: name: hellogame-x64-release path: ./HelloGame/x64/Release/ O arquivo acima parece um pouco confuso, mas se você ler cada linha vai começar a fazer sentido:\nEste workflow roda quando commits forem adicionados no branch main ou quando tiver um pull request para ele. O nosso env está configurado com o caminho do projeto HelloGame e a build Release. O job vai rodar em máquinas windows. Estamos utilizando msbuild para compilar o projeto pela linha de comando (já que é um servidor sem interface). Depois de compilar, a build do jogo vai ficar arquivada como um artefato deste workflow. Assim que adicionarmos esse arquivo no repositório e fizermos um commit para o branch main, este workflow vai rodar em gerar uma build que podemos baixar e testar, e vai estar no menu Actions do repositório no GitHub.\nAlém disso, é possível ver todo o processo de compilação e os logs do servidor. Caso algum erro aconteça, é lá que você vai entender o por que.\nConclusão # Este post demorou um pouco mais do que planejei para escrever, e ficou mais longo do que imaginei, mas acho que no fim é uma boa introdução de como criar um projeto novo usando SDL3, configurar o Visual Studio, e ainda como usar git submodule e GitHub Workflows para automação.\nTudo que fiz neste post pode ser visto no meu repositório público hello-worlds-sdl3. Fique a vontade para usar este repositório como um template ou base para o seu projeto, este é um dos motivos que fiz para mim mesmo.\nMuito obrigado se você leu até o final, e espero que tenha sido útil. Qualquer dúvida, problemas no passo-a-passo, ou sugestões deixe um comentário abaixo.\n","date":"13 de julho de 2025","externalUrl":null,"permalink":"/sdl3-git-submodule-github-workflow/","section":"Blog","summary":"Após minha graduação em Ciência da Computação, iniciei uma pós-graduação em Produção e Programação de Jogos com o objetivo de mudar minha carreira e entrar na indústria de jogos. Isso foi em 2009, e uma das primeiras ferramentas de desenvolvimento de jogos que tive contato foi o SDL2, onde fiz o meu primeiro projeto de game com SDL e C++ em uma disciplina da pós-graduação. De lá pra cá utilizei o SDL em diversos projetos, principalmente game jams e para aprender a programar homebrew para Nintendo DS e PSP, e sempre foi um framework fácil de usar e bem completo para jogos 2D.\n","title":"SDL3 com Visual Studio, git submodule, e GitHub Workflow","type":"posts"},{"content":"Mês passado foi o aniversário de 16 anos deste blog que, desde 2009, já passou por diferentes tecnologias e servidores para publicar o conteúdo. Chegou a hora de mais uma mudança, e desta vez escolhi migrar o blog do Jekyll para o Docusaurus.\nEvolução do blog # Em 2009 eu comecei o meu blog utilizando o bom e velho Wordpress, que ainda é uma das maneiras mais rápidas e fáceis de se criar um blog que pode ser totalmente customizado. Depois de um tempo utilizando Wordpress, eu decidi levar o blog para um próximo nível que me daria mais flexibilidade, e decidi ter o meu próprio servidor para hospedar o blog.\nPassei por diversos servidores de hospedagem, sempre procurando um melhor custo benefício já que pagava um valor mensal para manter o blog no ar. Em 2016, comecei a procurar por alternativas para reduzir meu custo e aumentar a performance do blog, já que um dos gargalos era a constante conexão do PHP com o bando de dados MySQL usado pelo Wordpress. Foi então que eu fiz uma primeira migração de framework do blog, dando adeus ao Wordpress, e olá ao Ghost.\nO Ghost é um pouco parecido com Wordpress - você pode ter um blog hospedado por eles ou sua própria hospedagem. Porém, uma vantagem, que também foi uma gambiarra, era que eu podia rodar o servidor local, e \u0026quot;compilar\u0026quot; o site em páginas estáticas, e ai então publicar essas páginas no GitHub Pages. Consegui eliminar o meu custo mensal e ainda fazer o site ficar incrivelmente rápido já que conteúdo estático não precisa de conexão com banco de dados.\nDepois que me acostumei com o blog em formato estático, comecei a ficar incomodado em ter que rodar um servidor local toda vez que ia publicar algo no blog. A interface do Ghost era bem legal, porém não uma necessidade. Foi então que, em 2017, dei adeus ao Ghost, e olá ao Jekyll. Diferente to Ghost (e do Wordpress), o Jekyll não tem uma interface por padrão, apenas arquivos em um repositório que são \u0026quot;compilado\u0026quot; para gerar um site estático. Isso reduziu a necessidade de rodar um servidor local, pois para publicar posts eu não precisava disso - apenas escrever e fazer um commit no git, e então o site era atualizado já que o GitHub pages consegue fazer essa \u0026quot;compilação\u0026quot;.\nMinha última mudança foi em 2018, quando decidi dar adeus ao GitHub Pages, e olá ao Netlify. Na época o GitHub Pages era um pouco limitado, e além disso era possível ter apenas um site estático por conta no GitHub, e eu queria publicar um novo site para o meu portfólio, também utilizando Jekyll. Foi então que migrei de plataforma, indo para o Netlify, que além de ter muito mais do que preciso, também é gratuito e suporta diversos sites ao mesmo tempo.\nForam 8 anos utilizando Jekyll no blog, e aos poucos comecei a encontrar alguns problemas que me fizeram pensar em outras opções, inclusive voltar para o Ghost, porém encontrei a solução perfeita pra mim: Docusaurus.\nMudança para Docusaurus # Jekyll é um framework incrível para criar sites estáticos, desde um simples blog ou documentação de um sistema, até sites completos com E-commerce. Existem muitos layouts (themes) gratuitos e pagos, a flexibilidade nele é imensa. Porém, é um framework um pouco velho que já está mostrando sinais de que precisa se modernizar. Um dos maiores problemas que eu tinha era depender de versões específicas de Ruby para compilar o blog, e sempre tinha problemas de incompatibilidade entre as dependências em diferentes computadores. Além disso, a maioria das dependências não eram atualizadas e eu ficava cada vez mais preso em coisas antigas.\nEu descobri o Jekyll no trabalho, pois era como a documentação era feita na época, e a mesma coisa aconteceu quando descobri o Docusaurus. Muitos dos meus problemas estão listados na comparação do Jekyll com Docusaurus, o que foi mais um incentivo para mudar. Docusaurus é uma plataforma open source desenvolvida pela Meta, e é feita com React, também mantido pela mesma empresa.\nPor utilizar frameworks mais modernos, como React, o Docusaurus não possui problemas de dependências e tem uma melhor consistência entre diferentes sistemas operacionais. Configurar um site nele é bem rápido e fácil, e publicar ele no Netlify foi ainda mais fácil e rápido do que o Jekyll.\nPorém, nem tudo é perfeito, e existem algumas limitações no Docusaurus que podem ser um problema. A customização nele é bem menos flexível do que o Jekyll, e não existe tantos layouts disponíveis para ele. Além disso, o foco do Docusaurus é documentação, e o blog é um sistema secundário nele e bem limitado. A customização nele é mais fechada, e requer o uso de swizzling, onde você pode expandir ou \u0026quot;ejetar\u0026quot; um componente dele para customizar. Nem todo componente é customizável, e os que são possuem um alerta dizendo que podem deixar de funcionar em atualizações futuras.\nEu tive que desativar a parte de documentação, fazer algumas mudanças no blog e customizar alguns componentes, e apesar das limitações estou bem feliz com o resultador. Vai demorar um pouco para me acostumar com o Docusaurus, mas por enquanto ele está cumprindo todos meus requisitos para um blog:\nSimples, rápido e fácil de usar Boa performance, moderno e fácil de manter Me permite focar em escrever Sem custo adicional Apesar da limitação em customização e layouts disponíveis (comparando com o Jekyll), acho que o Docusaurus é o que eu estava procurando para este momento do blog. Provavelmente irei atrás de um layout melhor no futuro, mas por enquanto este layout básico e comum já está muito bom.\nNovas funcionalidades # Uma das coisas que sempre tentei adicionar no blog, e sempre sem sucesso, foi uma ferramenta de busca. É uma limitação para sites estáticos, e é necessário algo externo para poder funcionar. Felizmente, o Docusaurus tem suporte nativo para uma ferramenta de busca chamada Algolia, e como você pode ver ali no canto superior direito, funciona muito bem. Tive que ajustar algumas configurações e aprender como funcionar a indexação, mas valeu o trabalho e fiquei feliz com o resultado.\nUm pouco menos importante, mas também uma novidade, é poder mudar o tema do blog entre dark e light (botão à esquerda da busca ali no topo). Isso também era algo que queria adicionar ao blog, mas ficava preso os layouts do Jekyll que não tinham esse suporte porém eram gratuitos.\nOutra mudança significativa pra mim foi abandonar o Google Analytics em favor do Cloudflare Analytics, que é bem mais leve e menos intrusivo, com foco em privacidade ao invés de capturar dados para publicidade. Eu utilizava o Google Analytics desde ~2010, quando movi meu blog do Wordpress para um servidor próprio, e por mais que tenho anos de dados lá, não vai fazer falta. Costumo utilizar esse tipo de ferramenta para ver quais posts são mais acessados e como leitores chegam no blog.\nO Docusaurus também tem uma ferramenta que valida links quebrados e impede a publicação do site (esse comportamento é configurável). Isso ajuda demais a não deixar passar links que não funcionam, mas também foi um dos maiores trabalhos que tive quando migrei - corrigir todos links quebrados ao longo dos últimos 16 anos.\nPor fim, por ser moderno e utilizar React, isso também me possibilita estudar algo novo, como o irmão React Native, muito utilizado para aplicativos.\nConclusão # Já estava na hora de uma atualização na tecnologia por trás do blog, e apesar do Docusaurus parecer menos flexível do que o Jekyll, ele é mais moderno e fácil de manter. Agora é arrumar detalhes que possam estar quebrados e focar em publicar mais conteúdo por aqui, e também migrar meu portfólio para Docusaurus.\n","date":"4 de maio de 2025","externalUrl":null,"permalink":"/ola-docusaurus/","section":"Blog","summary":"Mês passado foi o aniversário de 16 anos deste blog que, desde 2009, já passou por diferentes tecnologias e servidores para publicar o conteúdo. Chegou a hora de mais uma mudança, e desta vez escolhi migrar o blog do Jekyll para o Docusaurus.\n","title":"Adeus Jekyll, olá Docusaurus","type":"posts"},{"content":"","date":"4 de maio de 2025","externalUrl":null,"permalink":"/categories/blog/","section":"Categorias","summary":"","title":"Blog","type":"categories"},{"content":"O padrão Message Queue é uma maneira simples e eficiente de desacoplar o código no seu projeto de jogo. Uma das formas mais fáceis e eficazes de desacoplar o código em um jogo é implementando o padrão Message Queue, também conhecido como Event Queue.\nEsse padrão consiste em enviar mensagens quando você deseja atualizar algo na interface do jogo, por exemplo, sem precisar manter uma referência direta ao objeto da interface ou utilizar um padrão Singleton para expor acesso a ele. Em vez disso, a interface escutará o tipo de mensagem necessário para atualizar a interface, e essa mensagem será enviada apenas quando um sistema do jogo precisar atualizar a interface.\nVamos dividir o padrão Message Queue em três partes: o gerenciador da fila, responsável pela fila em si; a mensagem, que contém o que queremos enviar; e os ouvintes, que ficam esperando a mensagem para executar alguma ação assim que a receberem.\nO gerenciador Message Queue # O núcleo do padrão Message Queue é uma classe responsável por armazenar uma lista de ouvintes, além de adicionar e remover ouvintes e enviar mensagens para cada ouvinte que estiver escutando um tipo específico de mensagem.\nNo código abaixo, criamos nossa classe MessageQueue e definimos um Dictionary para armazenar nossos ouvintes, organizando-os por tipo. Cada Type possui uma List de Delegate, que são callbacks executados quando um tipo específico de mensagem é recebido.\nusing System; using System.Collections.Generic; public class MessageQueue { private readonly Dictionary\u0026lt;Type, List\u0026lt;Delegate\u0026gt;\u0026gt; _listeners; private MessageQueue() { _listeners = new Dictionary\u0026lt;Type, List\u0026lt;Delegate\u0026gt;\u0026gt;(); } } Em seguida, adicionamos métodos à nossa classe MessageQueue. O primeiro é o AddListener, que tem o tipo genérico T para o parâmetro listener.\npublic void AddListener\u0026lt;T\u0026gt;(Action\u0026lt;T\u0026gt; listener) { if (_listeners.TryGetValue(typeof(T), out List\u0026lt;Delegate\u0026gt; listeners)) { listeners.Add(listener); } else { listeners = new List\u0026lt;Delegate\u0026gt; { listener }; _listeners.Add(typeof(T), listeners); } } O próximo método é o RemoveListener, que remove um ouvinte da lista e, caso a lista fique vazia, a remove do Dictionary.\npublic void RemoveListener\u0026lt;T\u0026gt;(Action\u0026lt;T\u0026gt; listener) { if (_listeners.TryGetValue(typeof(T), out List\u0026lt;Delegate\u0026gt; listeners)) { listeners.Remove(listener); if (listeners.Count == 0) { _listeners.Remove(typeof(T)); } } } Por fim, o método SendMessage encontra uma lista de ouvintes aguardando um tipo de mensagem e chama cada um como callback, passando a mensagem como parâmetro.\npublic void SendMessage(object message) { if (_listeners.TryGetValue(message.GetType(), out List\u0026lt;Delegate\u0026gt; listeners)) { for (int i = 0; i \u0026lt; listeners.Count; i++) { listeners[i].DynamicInvoke(message); } } } O objeto Message # O objeto mensagem pode ser qualquer classe. No exemplo abaixo, criamos uma classe que representa uma mensagem contendo uma propriedade NewColor.\nusing UnityEngine; public class UpdateColorMessage { public Color NewColor; } O uso dos ouvintes # A classe MessageQueueExample é um MonoBehaviour que pode ser adicionado a qualquer GameObject no Unity. Ela usa o MessageQueue para adicionar e remover um callback.\nusing UnityEngine; public class MessageQueueExample : MonoBehaviour { private readonly MessageQueue _messageQueue = new MessageQueue(); private void OnEnable() { _messageQueue.AddListener\u0026lt;UpdateColorMessage\u0026gt;(UpdateColor); } private void OnDisable() { _messageQueue.RemoveListener\u0026lt;UpdateColorMessage\u0026gt;(UpdateColor); } private void UpdateColor(UpdateColorMessage message) { // Use o message.NewColor para atualizar a cor } } Os métodos OnEnable e OnDisable são executados uma vez pelo Unity, garantindo que os ouvintes sejam sempre adicionados e removidos corretamente.\nEnviando mensagens # Abaixo estão três métodos que enviam mensagens para mudar a cor para vermelho, verde e azul.\npublic void ChangeColorToRed() { var message = new UpdateColorMessage { NewColor = Color.red }; _messageQueue.SendMessage(message); } public void ChangeColorToGreen() { var message = new UpdateColorMessage { NewColor = Color.green }; _messageQueue.SendMessage(message); } public void ChangeColorToBlue() { var message = new UpdateColorMessage { NewColor = Color.blue }; _messageQueue.SendMessage(message); } Cada método cria uma instância de UpdateColorMessage e define a propriedade NewColor antes de enviar a mensagem aos ouvintes.\nConclusão # O padrão Message Queue é muito poderoso para desacoplar o código e facilitar a comunicação entre sistemas usando mensagens. Espero que este artigo tenha ajudado você a entender como implementá-lo usando C# no Unity.\nO código deste artigo, assim como um exemplo completo implementado no Unity, pode ser encontrado no meu repositório do GitHub.\nVocê já utilizou esse padrão em algum projeto? Compartilhe sua experiência nos comentários e me avise se tiver alguma dúvida!\n","date":"3 de fevereiro de 2025","externalUrl":null,"permalink":"/message-queue-pattern-unity/","section":"Blog","summary":"O padrão Message Queue é uma maneira simples e eficiente de desacoplar o código no seu projeto de jogo. Uma das formas mais fáceis e eficazes de desacoplar o código em um jogo é implementando o padrão Message Queue, também conhecido como Event Queue.\n","title":"Como implementar o padrão Message Queue no Unity","type":"posts"},{"content":"Fiquei sem atualizar o blog nos últimos meses, e hoje posso compartilhar o motivo: escrevi meu primeiro livro!\nDa concepção à publição foram meses dedicando meu tempo livre para escrever um livro que combinasse minha experiência profissional de quase 14 anos desenvolvendo jogos, sendo 10 anos utilizando Unity como minha principal engine. Foi uma oportunidade incrível e que não seria possível sem a editora Packt para me apoiar e fornecer o suporter necessário para revisão de textos, código, e muito mais.\nCom pouco mais de 550 páginas, em Inglês, o livro vai te ensinar a fazer um jogo RTS na Unity 2023 utilizando C#. O foco do livro é criar um jogo RTS do início ao fim, porém, todo conteúdo do livro é facilmente aplicável a praticamente qualquer outro tipo jogo, já que muitos conceitos e algoritmos são os mesmos. Apesar de ter sido um desafio ainda maior pra mim, escrever o livro em Inglês possibilita que mais pessoas tenham acesso ao seu conteúdo.\nO livro já está em pré-venda, e será lançado no próximo dia 13 de Outubro na Amazon Brasil em todas as outras, inclindo algumas livrarias nos EUA e Reino Unido, e no próprio side da editora. O livro estará disponível em formato digital (Kindle) e físico.\nAbaixo está uma descrição do livro sobre o conteúdo. Ficarei feliz de responder qualquer pergunta sobre o livro e seu conteúdo, e agradesço desde já se você puder adquirir o livro.\nDescrição do Livro # Construir um jogo de estratégia em tempo real de sucesso é desafiador, devido às mecânicas complexas e à necessidade de equilibrar diferentes elementos, garantindo que os jogadores desfrutem de criar e executar estratégias contra a inteligência artificial do jogo. \u0026quot;Creating an RTS game in Unity 2023\u0026quot; irá ensinar você a instalar e configurar o motor de jogo Unity, criar um novo projeto 3D e construir um editor de níveis para facilitar a modificação e adição de mapas ao jogo.\nAo longo do livro, o seu RTS começará a ganhar forma à medida que você aprender a implementar sistemas centrais, como batalhas corpo a corpo e à distância, geradores de unidades, controles de câmera, geração dinâmica de mapas, IA básica de inimigos e o algoritmo de pathfinding. Você também dominará a implementação de unidades de comando para executar ações, produção e gestão de recursos, física básica e detecção de colisões, tudo isso enquanto constrói um jogo de estratégia em tempo real do zero, utilizando C# e as últimas funcionalidades da Unity.\nO Que Você Irá Aprender # Configuração do Unity e criação de projetos 3D. Desenvolvimento de um editor de níveis personalizado. Implementação de mecânicas de combate e unidades. Controles de câmera envolventes para o jogador. Geração dinâmica de mapas e IA de inimigos. Algoritmo de pathfinding para movimentação eficiente das unidades. Comandos de unidades para execução de ações estratégicas. Gestão de recursos e produção de unidades. Física e detecção de colisões para um gameplay realista. Construção completa de um RTS usando C# e Unity. Ao final deste livro, você estará apto a criar jogos de estratégia em tempo real profissionais e de alta qualidade, utilizando as melhores práticas e técnicas da indústria de jogos. PS: Comenta se você reconheceu a imagem da capa do livro, e se inscreva no meu canal no YouTube por que muito contéudo novo está por vir!\n","date":"1 de outubro de 2023","externalUrl":null,"permalink":"/creating-an-rts-game-in-unity/","section":"Blog","summary":"Fiquei sem atualizar o blog nos últimos meses, e hoje posso compartilhar o motivo: escrevi meu primeiro livro!\nDa concepção à publição foram meses dedicando meu tempo livre para escrever um livro que combinasse minha experiência profissional de quase 14 anos desenvolvendo jogos, sendo 10 anos utilizando Unity como minha principal engine. Foi uma oportunidade incrível e que não seria possível sem a editora Packt para me apoiar e fornecer o suporter necessário para revisão de textos, código, e muito mais.\n","title":"Meu primeiro livro: Criando um Jogo RTS na Unity 2023","type":"posts"},{"content":"Desenvolver jogos é um processo complexo e desafiador, mas o uso de técnicas de desenvolvimento de software pode ajudar a tornar esse processo mais eficiente e eficaz. Um desses métodos é o Test-Driven Development (TDD), que pode ser aplicado ao desenvolvimento de jogos com Unity.\nO TDD é um processo iterativo de desenvolvimento de software que consiste em escrever testes automatizados antes de escrever o código final. O processo começa com a escrita de um teste automatizado que falha e, em seguida, a escrita de código que faça o teste passar. Isso ajuda a garantir que o código escrito atenda aos requisitos definidos pelos testes e reduz o risco de erros e defeitos.\nAo usar o TDD no desenvolvimento de jogos com o Unity, é importante seguir algumas boas práticas recomendadas para garantir que o processo seja eficaz e eficiente.\nEscreva testes para cada nova funcionalidade # Cada nova funcionalidade que você adiciona ao seu jogo deve ter seus próprios testes automatizados. Isso ajudará a garantir que o código funcione como esperado e que não há efeitos colaterais indesejados em outras partes do jogo.\nEscreva testes para cada cenário de uso # Além de testar cada nova funcionalidade, é importante testar cada cenário de uso do jogo. Por exemplo, se o jogo tiver uma fase em que o personagem precisa coletar moedas, é importante testar se todas as moedas são coletadas corretamente. Isso ajuda a garantir que o jogo seja jogável e livre de bugs.\nEscreva testes para detectar erros comuns # Alguns erros são comuns no desenvolvimento de jogos com Unity, como erros de colisão e de controle de personagens. Escreva testes para detectar esses erros comuns e corrigi-los antes que eles se tornem problemas maiores.\nEscreva testes antes de implementar o código final # O TDD requer que os testes sejam escritos antes do código final ser implementado. Isso ajuda a garantir que o código final atenda aos requisitos definidos pelos testes e ajuda a evitar a introdução de erros no código.\nExecute testes automaticamente durante o processo de construção # Os testes automatizados devem ser executados automaticamente durante o processo de construção do jogo. Isso ajuda a garantir que todas as alterações no código sejam testadas e que nenhum erro seja introduzido no código existente.\nRefatore o código à medida que novos testes são adicionados # À medida que novos testes são adicionados, pode ser necessário refatorar o código existente para que ele atenda aos requisitos dos novos testes. Isso ajuda a garantir que o código seja fácil de manter e que não haja erros ou problemas de desempenho.\nO uso do TDD no desenvolvimento de jogos com Unity pode ajudar a garantir que o jogo seja jogável, livre de erros e fácil de manter. Ao seguir as práticas recomendadas acima, você pode maximizar os benefícios do TDD e tornar o processo de desenvolvimento de jogos mais eficiente e eficaz.\nDevo admitir que TDD é algo que está na minha lista para me aperfeiçoar a anos, e ainda não saí do básico que é criar os testes na Unity e tentar lembrar de rodar eles. Por isso automatizar os testes com Integração Contínua (CI) ou adicionar um script que obrigue rodar os testes antes de um git push pode ajudar a introduzir o uso do TDD cada vez mais ao dia-a-dia.\nMas cuidado, o TDD não pode ser visto como uma barreira que atrasa o desenvolvimento - apenas entendendo e usando o TDD pensando sempre na qualidade do código pode fazer ver seu uso mais como uma garantia bem-vinda do que um empecílio.\n","date":"4 de março de 2023","externalUrl":null,"permalink":"/unity-tdd/","section":"Blog","summary":"Desenvolver jogos é um processo complexo e desafiador, mas o uso de técnicas de desenvolvimento de software pode ajudar a tornar esse processo mais eficiente e eficaz. Um desses métodos é o Test-Driven Development (TDD), que pode ser aplicado ao desenvolvimento de jogos com Unity.\n","title":"Desenvolvimento de jogos em Unity com TDD","type":"posts"},{"content":"O comando git alias é um recurso muito poderoso do git que permite customizar comandos e ganhar tempo combinando uma sequencia de operações. Desde que aprendi a usar o git alias há alguns anos não consigo trabalhar sem algumas combinações de comandos que uso diáriamente.\nTodos alias criados ficam na configuração local do git na sua máquina. Para criar um alias, basta usar o comando abaixo substituindo o NAME pelo nome do seu alias (sem espaços ou acentos) e substituindo o COMMAND pelo comando que quer executar.\n$ git config --global alias.NAME COMMAND No exemplo abaixo estamos criando um alias com nome s para o comando status. Então, ao invés de usar git status podemos usar git s para o mesmo comando, como um atalho.\n$ git config --global alias.s status Caso você não queira mais o alias criado, basta utilisar o comando abaixo com o nome criado para que ele seja removido das configurações:\n$ git config --global --unset alias.s Agora que já sabemos criar um alias vamos ver o poder real dele: a combinação de comandos. Para poder combinar os comandos precisamos:\nIniciar a sequencia de comandos com exclamação ! Separar os comandos por e comercial duplo \u0026amp;\u0026amp; Por fim, todos os comandos deve ficar dentre de aspas simples No exemplo abaixo estamos criar um alias com o nome s que irá executar, em sequencia, os comandos git status e git pull.\n$ git config --global alias.s \u0026#39;!git status \u0026amp;\u0026amp; git pull\u0026#39; Incrível, não? Confesso que uso e abuso deste recurso, e isso me ajuda demais no dia-a-dia. Abaixo vou deixar meus alias preferidos: o git pizza que limpa e atualiza o repositório; e o git nuke que faz a mesma coisa porém descarta tudo que está no gitignore, como se o repositório tivesse sido clonado sem nada além do que está no remote.\n$ git config --global alias.pizza \u0026#39;!git clean -fd \u0026amp;\u0026amp; git reset --hard \u0026amp;\u0026amp; git fetch -fp \u0026amp;\u0026amp; git pull\u0026#39; $ git config --global alias.nuke \u0026#39;!git clean -fdx \u0026amp;\u0026amp; git reset --hard \u0026amp;\u0026amp; git fetch -fp \u0026amp;\u0026amp; git pull\u0026#39; Um dos motivos de escrever este post foi ter estes comandos fáceis de achar quando eu precisar, além de compartilhar algo que acho bem interessante e produtivo no uso do git. Se você tem alguma dica legal para usar o git deixe aqui nos comentários.\n","date":"17 de agosto de 2022","externalUrl":null,"permalink":"/git-alias/","section":"Blog","summary":"O comando git alias é um recurso muito poderoso do git que permite customizar comandos e ganhar tempo combinando uma sequencia de operações. Desde que aprendi a usar o git alias há alguns anos não consigo trabalhar sem algumas combinações de comandos que uso diáriamente.\n","title":"Como criar atalhos com git alias","type":"posts"},{"content":"","date":"17 de agosto de 2022","externalUrl":null,"permalink":"/categories/gamedev/","section":"Categorias","summary":"","title":"Game Dev","type":"categories"},{"content":"O game designer e fundador da Rogue Snail, Mark Venturelli, apresentou uma brilhante palestra no Big Festival 2022 sobre sua visão para o futuro do game design e da indústria de games.\nApesar da qualidade baixa, é possível assistir a palestra na íntegra no vídeo abaixo. Esta é a primeira vez que não quero comentar o conteúdo da palestra para não dar spoilers, pois recomendo assistir para entender onde Mark leva o espectador com sua apresentação. Posso adiantar que concordo com ele.\nO vídeo acima foi publicado no canal do Mark, e ele também disponibilizou os slides da apresentação neste link.\n","date":"8 de agosto de 2022","externalUrl":null,"permalink":"/futuro-game-design-venturelli/","section":"Blog","summary":"O game designer e fundador da Rogue Snail, Mark Venturelli, apresentou uma brilhante palestra no Big Festival 2022 sobre sua visão para o futuro do game design e da indústria de games.\n","title":"O Futuro do Game Design: Palestra de Mark Venturelli","type":"posts"},{"content":"Uma forma interessante de exibir uma mensagem de boas vindas ou informações sobre o projeto ao ser carregado é exibir um conteúdo similar à um arquivo README que pode ser customizado e exibido na janela do inspector dentro do editor da Unity. Neste vídeo eu mostro como criar um ScriptableObject, alterar sua visualização utilizando um CustomEditor e, por fim, colocar o foco do projeto e do inspector neste arquivo ao carregar o projeto na Unity.\nAbaixo estão os códigos das duas classes criadas no vídeo como referência, Readme e ReadEditor, respectivamente.\nusing System.Collections; using System.Collections.Generic; using UnityEngine; [CreateAssetMenu(fileName = \u0026#34;Readme\u0026#34;, menuName = \u0026#34;Create Readme\u0026#34;)] public class Readme : ScriptableObject { public string Title; public List\u0026lt;string\u0026gt; Sections = new List\u0026lt;string\u0026gt;(); } using UnityEngine; using UnityEditor; [CustomEditor(typeof(Readme))] [InitializeOnLoad] public class ReadmeEditor : Editor { static ReadmeEditor() { EditorApplication.delayCall += SelectReadme; } static void SelectReadme() { EditorApplication.delayCall -= SelectReadme; var readmeObject = Resources.Load\u0026lt;Readme\u0026gt;(\u0026#34;Readme\u0026#34;); if (readmeObject != null) { EditorUtility.FocusProjectWindow(); Selection.activeObject = readmeObject; } } protected override void OnHeaderGUI() { Readme readme = (Readme)target; GUILayout.BeginHorizontal(); var style = GUI.skin.GetStyle(\u0026#34;label\u0026#34;); style.fontSize = 32; GUILayout.Label(readme.Title, style); GUILayout.EndHorizontal(); } public override void OnInspectorGUI() { Readme readme = (Readme)target; foreach(string section in readme.Sections) { var style = GUI.skin.GetStyle(\u0026#34;label\u0026#34;); style.fontSize = 18; style.wordWrap = true; GUILayout.Label(section, style); GUILayout.Space(18); } } } Veja a playlist do canal com mais vídeos sobre Unity clicando aqui.\nDúvidas, comentários ou sugestões para futuros vídeos deixem aqui no post ou lá no vídeo no YouTube.\n","date":"16 de abril de 2022","externalUrl":null,"permalink":"/unity-readme/","section":"Blog","summary":"Uma forma interessante de exibir uma mensagem de boas vindas ou informações sobre o projeto ao ser carregado é exibir um conteúdo similar à um arquivo README que pode ser customizado e exibido na janela do inspector dentro do editor da Unity. Neste vídeo eu mostro como criar um ScriptableObject, alterar sua visualização utilizando um CustomEditor e, por fim, colocar o foco do projeto e do inspector neste arquivo ao carregar o projeto na Unity.\n","title":"Como exibir um README na Unity ao abrir o projeto","type":"posts"},{"content":"Neste vídeo demonstro como criar um botão na interaface da Unity, algumas customizações que podem ser aplicadas nele, e como executar um script a partir do evento OnClick. Além de um script, também mostro como executar métodos de outros objetos da Unity no OnClick.\nVeja a playlist do canal com mais vídeos sobre Unity clicando aqui.\nDúvidas, comentários ou sugestões para futuros vídeos deixem aqui no post ou lá no vídeo no YouTube.\n","date":"15 de janeiro de 2022","externalUrl":null,"permalink":"/unity-ui-button/","section":"Blog","summary":"Neste vídeo demonstro como criar um botão na interaface da Unity, algumas customizações que podem ser aplicadas nele, e como executar um script a partir do evento OnClick. Além de um script, também mostro como executar métodos de outros objetos da Unity no OnClick.\n","title":"Como adicionar e utilizar botões na Unity","type":"posts"},{"content":"Neste vídeo mostro um exemplo de como utilizar o design patter Object Pool para reutilizar game objects em situações onde várias cópias são necessárias, como tiros ou inimigos, porém utilizando este design pattern para garantir um bom uso de memória.\nA ideia do Object Pool é ter um conjunto de objetos na memória que podem ser reutilizados. Na sua inicialização, um número pré-determinado de objetos são instanciados e ficam disponíveis porém não habilitados. Quando um objeto é requisitado, ele é habilitado e fica indisponível neste conjunto. E, quando não é mais necessário, ele fica desabilitado ao invés de ser destruído para que possa ser utilizado novamente.\nO projeto do vídeo está disponível neste repositório no meu GitHub. Dúvidas, comentários ou sugestões para futuros vídeos deixem aqui no post ou lá no vídeo no YouTube.\n","date":"24 de dezembro de 2021","externalUrl":null,"permalink":"/object-pool-unity/","section":"Blog","summary":"Neste vídeo mostro um exemplo de como utilizar o design patter Object Pool para reutilizar game objects em situações onde várias cópias são necessárias, como tiros ou inimigos, porém utilizando este design pattern para garantir um bom uso de memória.\n","title":"Utilizando Object Pool pattern na Unity","type":"posts"},{"content":"A Unity possui um sistema de build onde você pode exportar seu projeto para diferentes plataformas e otimizaçoes. Este sistema é um pouco limitado quando utilizado através da interface do Editor, porém ele possui uma excelente API que pode ser utilizada para criar sistemas de build bem flexíveis e robustos.\nNeste vídeo eu demonstro como utilizar a API BuildPipeline da Unity e como gerar uma build através da linha de comando sem precisar abrir o projeto - o que pode ser utilizado em conjunto com sistemas de integraçao contínua, como o Jenkins. Apesar de não mostrar detalhes de como configurar, ao final do vídeo mostro como o Jenkins pode ser utilizado para gerar a build do exemplo do vídeo.\nAlguns links mencionados no vídeo:\nUnity BuildPipeline Unity Editor command line arguments Rodando Jenkins em um Raspberry Pi Zero W Abaixo está a linha de comando executada para gerar as builds no vídeo. Os caminhos nesta linha de comando são do meu computador e podem não funcionar no seu, modifique de acordo com o seu ambiente de desenvolvimento.\n\u0026#34;C:\\Program Files\\Unity\\Hub\\Editor\\2020.3.23f1\\Editor\\Unity.exe\u0026#34; \\ -quit \\ -batchmode \\ -projectPath \u0026#34;C:\\Projects\\unity-build-system-sample\u0026#34; \\ -executeMethod BuildSystem.BuildAll \\ -logFile \u0026#34;C:\\Projects\\unity-build-system-sample\\BuildLog.txt\u0026#34; O projeto do vídeo está disponível neste repositório no meu GitHub. Dúvidas, comentários ou sugestões para futuros vídeos deixem aqui no post ou lá no vídeo no YouTube.\n","date":"18 de dezembro de 2021","externalUrl":null,"permalink":"/sistema-build-unity/","section":"Blog","summary":"A Unity possui um sistema de build onde você pode exportar seu projeto para diferentes plataformas e otimizaçoes. Este sistema é um pouco limitado quando utilizado através da interface do Editor, porém ele possui uma excelente API que pode ser utilizada para criar sistemas de build bem flexíveis e robustos.\n","title":"Como fazer um sistema de build na Unity","type":"posts"},{"content":"","date":"31 de maio de 2021","externalUrl":null,"permalink":"/categories/unreal/","section":"Categorias","summary":"","title":"Unreal","type":"categories"},{"content":"Quase um ano após seu anúncio a Unreal Engine 5 já está disponível para testes através do programa de Early Access da Epic Games. Na prática isso quer dizer que desenvolvedores podem começar a utilizar a nova versão da engine para estudar e desenvolver protótipos, porém ela não está pronta para ser utilizada em um jogo comercial no momento.\nPara ter acesso ao Early Access da UE5 basta relizar o download ou atualizar o launcher da Epic Games, ir na sessão Unreal Engine do menu esquerdo e selecionar UE5 no menu superior. O download tem cerca de 10GB e a após a instalação o espaço ocupado é de aproximadamente 31GB (praticamente o mesmo espaço ocupado pela UE4).\nAssim como na versão anteriore da engine, o seu código-fonta também está disponível no GitHub. A Epic Games também disponibilizou dois cursos em sua plataforma online para quem quiser começar a estudar a UE5. UE5 Early Access Quickstart é um curso de 2 horas que serve como uma introdução a nova versão da engine, enquando que o curso Upgrading to UE5 Early Acess possui apenas 20 minutos e tem como objetivo mostrar como importar um projeto feito na UE4.\nO vídeo abaixo é uma pequena introdução do que está presente na Unreal Engine 5 Early Access.\n","date":"31 de maio de 2021","externalUrl":null,"permalink":"/unreal-engine-5/","section":"Blog","summary":"Quase um ano após seu anúncio a Unreal Engine 5 já está disponível para testes através do programa de Early Access da Epic Games. Na prática isso quer dizer que desenvolvedores podem começar a utilizar a nova versão da engine para estudar e desenvolver protótipos, porém ela não está pronta para ser utilizada em um jogo comercial no momento.\n","title":"Unreal Engine 5 está disponível em Early Access","type":"posts"},{"content":"Há um tempo atrás escrevi este post sobre sites para baixar sprites e modelos de jogos. Por mais que seja legal utilizar artes dos nossos jogos favoritos, existem leis de copyright que não permitem que um jogo seja feito e comercializado com propriedade intelectual de outras empresas.\nPensando nisso montei a lista de links abaixo, que são de sites onde artistas e animadores disponibilizam seu trabalho. Existe muito conteúdo gratuito mas lembre de sempre creditar o autor em seu jogo. Mesmo que não seja necessário para alguns casos, é um tipo de reconhecimento e divulgação muito bem vinda para alguem que dedicou horas (e até dias) criando uma arte ou animação, e depois disponibilizando gratuitamente.\nExistem artes e animações que são pagas, muitas com preço bem acessível. Se você está fazendo um prótipo ou apenas testando algo, o conteúdo gratuito deve ser o suficiente para te ajudar em seu projeto. Porém, se você está desenvolvendo um jogo para ser lançado, recomendo dar uma olhada nas artes pagas pois existem muitas tão incríveis que vão deixar seu jogo ainda mais profissional, além de ajudar um artista talentoso.\nSketchfab # Conteúdo: Modelos 3D e animações (pagos e gratuitos). Possui plugins para Unity, Unreal e Godot.\nSite: https://sketchfab.com\nTurbo Squid # Conteúdo: Modelos 3D e animações (pagos e gratuitos).\nSite: https://turbosquid.com\nUnity Asset Store # Conteúdo: Modelos 3D e animações (pagos e gratuitos).\nSite: https://assetstore.unity.com\nUnreal Marketplace # Conteúdo: Modelos 3D e animações (pagos e gratuitos).\nSite: https://unrealengine.com/marketplace\nKenny # Conteúdo: Modelos 3D (pagos e gratuitos).\nSite: https://kenney.nl\nOpen Game Art # Conteúdo: Modelos 3D (gratuitos).\nSite: https://opengameart.org\nConhece algum que não está a lista? Deixe um comentário abaixo pra eu poder incluir na lista.\nModelo 3D da capa: The Lighthouse.\n","date":"9 de abril de 2021","externalUrl":null,"permalink":"/download-modelos-3d-jogos/","section":"Blog","summary":"Há um tempo atrás escrevi este post sobre sites para baixar sprites e modelos de jogos. Por mais que seja legal utilizar artes dos nossos jogos favoritos, existem leis de copyright que não permitem que um jogo seja feito e comercializado com propriedade intelectual de outras empresas.\n","title":"Download de modelos 3D para jogos","type":"posts"},{"content":"A SDL é uma biblioteca para desenvolvimento de jogos cross-platform com código aberto que existe desde 1998. Diversos jogos foram publicados utilizando SDL, como por exemplo, Half-Life 2, Left 4 Dead 2, Dying Light, Factorio, FTL, entre muitos outros. Sua linguagem de programação principal é C e C++, porém existem alguns bindings que permitem programar em outras linguagens como C#, Go, Lua, Rust e Python. Por ser \u0026quot;apenas\u0026quot; uma biblioteca, não possui uma interface gráfica como a Unity ou Unreal. Neste post vou demonstrar o passo a passo para criar um projeto utilizando o Visual Studio no Windows.\nPara começar faça o download do runtime binaries da sua plataforma. Se você está utilizando Windows 10, pode fazer download da versão 64-bit Windows. Também é possível utilizar o código fonte, mas o runtime binaries é o suficiente para iniciar um projeto. Para referência, a versão da SDL utilizada é 2.0.14.\nConfiguração no Visual Studio # Estou utilizando o Visual Studio 2019 Community Edition que pode ser baixado aqui. Apesar das imagens abaixo serem da versão 2019 a configuração é a mesma em outras versões do Visual Studio.\nApós realizar o download da SDL faça a extração em algum local do seu computador sem espaços no nome dos diretórios. Eu gosto de colocar meus projetos em C:\\Projects e qualquer biblioteca ou dependência (como os arquivos da SDL) em C:\\Dev.\nVamos criar um projeto novo do tipo Console App. Este projeto vai ter apenas um arquivo cpp, onde vamos adicionar o código do Hello World. O nome deste arquivo não importa, mas gosto de renomeá-lo para main.cpp.\nCom o projeto criado basta clicar com o botão direito no Project (dentro da Solution) e selecionar a última opção chamada Properties. A seguir iremos adicionar o caminho para as pastas include e lib\\x64 em VC++ Directories, e as libs SDL2.lib e SDL2main.lib em Linker/Input, conforme as imagens abaixo. Lembre-se de selecionar All Platforms antes de iniciar a configuração.\nPor fim, precisamos copiar o arquivo SDL2.dll que está em lib\\x64 para dentro do projeto, junto com o nosso arquivo cpp. Esta é a última etapa para configurar o Visual Studio e compilar o projeto com a SDL.\nComo realizamos toda a configuração utilizando a lib\\x64 lembre de selecionar x64 na Visual Studio antes de compilar e executar o projeto.\nHello World # Um projeto com SDL segue uma sequência bem definida de métodos, os quais devem ser executados para que tudo funcione corretamente. O código abaixo é a base que iremos utilizar, contendo a importação do SDL, o tamanho da tela e da imagem que vamos exibir e o método principal da aplicação. Este código não faz nada, mas pode ser executado para testar se a SDL está configurada corretamente no projeto do Visual Studio.\n#include \u0026lt;SDL.h\u0026gt; #define WINDOW_WIDTH 640 #define WINDOW_HEIGHT 480 #define IMAGE_WIDTH 256 #define IMAGE_HEIGHT 256 int main(int argc, char* args[]) { return 0; } Os trechos de código a seguir estão dentro do método main(). Em primeiro lugamos vamos inicializar a SDL e verificar se foi inicializada com sucesso. Caso algum erro seja retornado, iremos exibir a mensagem de erro no console utilizando SDL_Log() e finalizar a aplicação. Mais detalhes do método de inicialização aqui.\nif (SDL_Init(SDL_INIT_EVERYTHING) != 0) { SDL_Log(\u0026#34;SDL_Init Error: %s\\n\u0026#34;, SDL_GetError()); return -1; } A seguir criaremos nossa Window onde o jogo será exibido. No código abaixo, a janela será criada no centro da tela com o tamanho definido anteriormente, e o título Hello World SDL2. Você pode ver aqui todos os parâmetro em detalhes.\nSDL_Window* window = SDL_CreateWindow(\u0026#34;Hello World SDL2\u0026#34;, SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED, WINDOW_WIDTH, WINDOW_HEIGHT, SDL_WINDOW_SHOWN); if (window == nullptr) { SDL_Log(\u0026#34;SDL_CreateWindow Error: %s\\n\u0026#34;, SDL_GetError()); return -1; } O último item necessário para terminarmos a inicialização da SDL é o Renderer, responsável por \u0026quot;desenhar\u0026quot; na tela criada anteriormente. Os detalhes da criação do renderer podem ser vistos aqui.\nSDL_Renderer* renderer = SDL_CreateRenderer(window, -1, SDL_RENDERER_ACCELERATED); if (renderer == nullptr) { SDL_Log(\u0026#34;SDL_CreateRenderer Error: %s\\n\u0026#34;, SDL_GetError()); return -1; } Com a SDL inicializada e a window e o renderer criados, podemos desenhar uma imagem na tela. O código abaixo carrega uma imagem no formato BMP e a exibe no centro da tela. Primeiro criamos uma surface para então criar a texture. Com a textura criada, podemos remover a surface da memória (a texture será removida só no final da aplicação). O SDL_Rect possui as coordenadas onde a imagem será desenhada e seu tamanho, considerando que o ponto de origem da imagem é no seu centro. Por fim, desenhamos a texture na tela utilizando o SDL_Render.\nSDL_Surface* image = SDL_LoadBMP(\u0026#34;image.bmp\u0026#34;); if (image == nullptr) { SDL_Log(\u0026#34;SDL_LoadBMP Error: %s\\n\u0026#34;, SDL_GetError()); return -1; } SDL_Texture* texture = SDL_CreateTextureFromSurface(renderer, image); if (texture == nullptr) { SDL_Log(\u0026#34;SDL_CreateTextureFromSurface Error: %s\\n\u0026#34;, SDL_GetError()); return -1; } SDL_FreeSurface(image); SDL_Rect rect; rect.x = (int)(WINDOW_WIDTH * 0.5f - IMAGE_WIDTH * 0.5f); rect.y = (int)(WINDOW_HEIGHT * 0.5f - IMAGE_HEIGHT * 0.5f); rect.w = IMAGE_WIDTH; rect.h = IMAGE_HEIGHT; SDL_RenderClear(renderer); SDL_RenderCopy(renderer, texture, nullptr, \u0026amp;rect); SDL_RenderPresent(renderer); Todo esse código acontece antes do main loop, ou seja, será executado apenas uma vez. A imagem do exemplo será desenhada apenas uma vez na tela e, como no loop abaixo não tem outra chamada para o SDL_Render, ela continuará desenhada até o fim. Este loop é usado apenas para ler o input do jogador e sair do loop se a janela for fechada.\nwhile (true) { SDL_Event e; if (SDL_PollEvent(\u0026amp;e)) { if (e.type == SDL_QUIT) { break; } } } Quando o jogador fechar a tela e o jogo sair do loop vamos finalizar a SDL. Para isso tiramos tudo que foi alocado da memória, como texture, renderer e window. E por fim finalizamos a SDL.\nSDL_DestroyTexture(texture); SDL_DestroyRenderer(renderer); SDL_DestroyWindow(window); SDL_Quit(); Assim temos nosso Hello World com uma imagem desenhada na tela. A class completa pode ser vista neste gist. Se tiver alguma dúvida sobre os métodos e objetos da SDL acesse a documentação da biblioteca, a qual contem bastante informação e exemplos práticos.\nCuidados # Pelo tamanho do post é possível ver que desenhar uma simples imagem na tela exige uma boa quantidade de código. Enquanto na Unity, isso pode ser feito praticamente arrastando uma imagem para dentro da engine, com a SDL tudo é mais \u0026quot;manual\u0026quot;. Isso pode dar mais trabalho, mas também da mais controle ao programador. Por isso, é preciso prestar atenção para não fazer algo errado sem perceber.\nQuando estava criando este exemplo para o post, percebi que o simples fato de desenhar uma imagem na tela estava utilizando 97% da minha GPU (o que é um absurdo). Notei que meu erro foi executar os métodos SDL_RenderClear(), SDL_RenderCopy() e SDL_RenderPresent() a cada loop (é um exagero para uma imagem estática).\nMovendo as chamadas destes métodos para fora do loop, a utilização da GPU caiu para 1%. Existem algumas técnicas para controlar melhor o main loop e o frame rate, assim como desenhar apenas quando a imagem mudar de posição, entre outras possibilidades. O que me pegou de surpresa foi a própria documentação ter este exemplo, de uma imagem estática sendo desenhada todo frame.\nConclusão # Trabalhar com a SDL é um pouco lento no início até ter a base do jogo pronta, depois disso é a programação do jogo em si. É mais complicado do que utilizar a Unity e C#, por exemplo, com uma curva de aprendizado bem maior. Porém, é bem recompensador e importante aprender a programar (e programar jogos) em um \u0026quot;nível mais baixo\u0026quot; do que em uma engine que já te dá tudo pronto e você não vê muito bem o que acontece por trás do seu script.\nO código completo está disponível neste link. Caso queira se aprofundar, recomendo olhar a documentação oficial. Este site também possui bons exemplos de programação de jogos com SDL.\n","date":"21 de março de 2021","externalUrl":null,"permalink":"/hello-world-sdl-visual-studio/","section":"Blog","summary":"A SDL é uma biblioteca para desenvolvimento de jogos cross-platform com código aberto que existe desde 1998. Diversos jogos foram publicados utilizando SDL, como por exemplo, Half-Life 2, Left 4 Dead 2, Dying Light, Factorio, FTL, entre muitos outros. Sua linguagem de programação principal é C e C++, porém existem alguns bindings que permitem programar em outras linguagens como C#, Go, Lua, Rust e Python. Por ser \"apenas\" uma biblioteca, não possui uma interface gráfica como a Unity ou Unreal. Neste post vou demonstrar o passo a passo para criar um projeto utilizando o Visual Studio no Windows.\n","title":"Hello World usando SDL no Visual Studio","type":"posts"},{"content":"Existem algumas estruturas possíveis para implementar um plugin Android na Unity. Quando utilizamos um plugin desenvolvido por terceiros é comum que a sua distribuição seja através de um arquivo AAR, que é uma biblioteca java para Android, junto com alguns scripts em C# para sua utilização. Esta é a opção mais simples, pois a Unity já reconhece o arquivo AAR como uma biblioteca Android e cuida do resto na compilação. Também é possível utilizar um arquivo JAR, mas não é um formato muito utilizado hoje em dia para desenvolvimento com Android, e até exige um pouco mais de configuração para ser utilizado na Unity.\nOutra maneira de desenvolver um plugin dentro da Unity é mantendo o código java dentro do próprio projeto e, com ajuda de alguns outros arquivos, a Unity consegue configurar e compilar seu código Java como uma biblioteca para Android. Neste post não vou explicar como criar um arquivo AAR, mas é tão simples quanto criar um projeto de library no Android Studio e compilar para exportar o AAR, e a partir daí pode pular para a integração em C# na Unity.\nEstrutura # Para usar o código java dentro da Unity precisamos montar a estrutura abaixo, assim a engine vai compilar o código corretamente como uma biblioteca Android. Qualquer plugin com código nativo deve sempre ser colocado dentro de uma pasta Plugins, e em uma sub-pasta com o nome da plataforma, no caso Android. Na pasta Android é onde fica a biblioteca Android, onde no exemplo abaixo é chamada native-test-lib. Agora precisamos de pelo menos mais 3 arquivos, que eu irei descrever em seguida.\n├───Plugins │ │ │ └───Android │ │ │ └───native-test-lib │ │ AndroidManifest.xml │ │ build.gradle │ │ project.properties │ │ │ └───src │ │ │ └───com │ │ │ └───cicanci │ │ │ └───unity │ NativeTest.java Arquivo de configuração # No arquivo project.properties é necessário colocar apenas dois parâmetros para que o projeto seja reconhecido como uma biblioteca Android, a versão da API do Android que será a target (não é a versão mínima e não necessariamente a versão que será utilizada na compilação), e o parâmetro que habilita o projeto como library.\ntarget=android-21 android.library=true Android Manifest # O AndroidManifest.xml utilizado na library tem a o mínimo necessário para a definição deste arquivo: package e versão. O package é o mesmo que será utilizado no arquivo Java, e neste exemplo é com.cicanci.unity.\n\u0026lt;?xml version=\u0026#34;1.0\u0026#34; encoding=\u0026#34;utf-8\u0026#34;?\u0026gt; \u0026lt;manifest xmlns:android=\u0026#34;http://schemas.android.com/apk/res/android\u0026#34; package=\u0026#34;com.cicanci.unity\u0026#34; android:versionCode=\u0026#34;1\u0026#34; android:versionName=\u0026#34;1.0\u0026#34; \u0026gt; \u0026lt;application\u0026gt;\u0026lt;/application\u0026gt; \u0026lt;/manifest\u0026gt; Compilação com gradle # Por fim, precisaremos apenas do arquivo build.gradle que também define o projeto como library e mostra para o compilador onde está o AndroidManifest.xml e o código Java (na pasta src). Aqui também temos definidas algumas versões para o SDK do Android utilizado para compilação e o mesmo target definido no arquivo project.properties. Este arquivo será compilado pela Unity junto com o gradle do projeto.\napply plugin: \u0026#39;android-library\u0026#39; android { sourceSets { main { manifest.srcFile \u0026#39;AndroidManifest.xml\u0026#39; java.srcDirs = [\u0026#39;src\u0026#39;] } } compileSdkVersion 30 buildToolsVersion \u0026#39;30.0.3\u0026#39; defaultConfig { targetSdkVersion 21 } } Com todos os arquivos acima definidos e utilizando a estrutura mostrada no início do post, a Unity irá reconhecer o projeto como um plugin para Android, como podemos ver na imagem abaixo.\nCódigo java # Eu quis manter este exemplo bem simples por que meu objetivo é demonstrar como criar um plugin e utilizá-lo na Unity, por isso o código abaixo faz algo bem simples: recebe e retorna strings e inteiros. O package aqui deve ser o mesmo definido no AndroidManifest.xml. Este é um exemplo simples, porém não existem limites para uma library Android aqui quando comparada com um aplicativo para Android feito fora da Unity.\npackage com.cicanci.unity; public class NativeTest { private int counter = 0; private String message = \u0026#34;Hello from Android\u0026#34;; public int getCounter() { return ++this.counter; } public String getMessage() { return this.message; } public void setCounter(int counter) { this.counter = counter; } public void setMessage(String message) { this.message = message; } } A localização do arquivo Java dentro do plugin deve ter ser em uma estrutura de pastas que reflitam o package. Como neste exemplo o package é com.cicanci.unity, o arquivo NativeTest.java deve ficar dentro de Plugins/Android/native-test-lib/src/com/cicanci/unity/ - a localização do plugin Android na Unity + a pasta que o arquivo build.gradle vai procurar o código Java que é src + estrutura que reflete o package no AndroidManifest.xml.\nImplementação no C# # A parte final do plugin é sua utilização na Unity através do C#, e nisso a engine ajuda bastante com a classe AndroidJavaObject. Com esta class iremos criar nosso objeto com o nome completo da classe (package + nome da classe). Após criar o objeto podemos executar métodos da classe Java utilizando o método Call(), que também possui parâmetro para retornar um tipo quando o método Java não é void.\n#if UNITY_ANDROID using UnityEngine; public class NativeTestAndroid { private readonly AndroidJavaObject _nativeTestClass; public NativeTestAndroid() { _nativeTestClass = new AndroidJavaObject(\u0026#34;com.cicanci.unity.NativeTest\u0026#34;); } public int GetCounter() { return _nativeTestClass.Call\u0026lt;int\u0026gt;(\u0026#34;getCounter\u0026#34;); } public string GetMessage() { return _nativeTestClass.Call\u0026lt;string\u0026gt;(\u0026#34;getMessage\u0026#34;); } public void SetCounter(int counter) { _nativeTestClass.Call(\u0026#34;setCounter\u0026#34;, counter); } public void SetMessage(string message) { _nativeTestClass.Call(\u0026#34;setMessage\u0026#34;, message); } } #endif Não existe muito segredo, é realmente bem simples executar um código de uma library Android em Java no C# da Unity. Basta prestar atenção no tipo do retorno do método e no seu nome na hora de definir os métodos no C#. Outra dica é colocar seu código C# dentro de um #if UNITY_ANDROID para evitar erros de compilação em outras plataformas já que a classe AndroidJavaObject existe apenas quando a plataforma é Android na Unity.\nConclusão # Neste post quis mostrar como é criar um plugin para Android na Unity e, a partir deste template é possível fazer muitas coisas. Na época da Unity 5 era mais comum criar plugins para Android, já que a engine tinha um suporte bem limitado para esta plataforma, isso mudou bastante nas versões posteriores. Hoje muito do que você precisa já tem suporte para Android na Unity, porém pode ser que seja limitado ou que você queira ter controle sobre o código - nestes casos é bom fazer seu próprio plugin.\nQuando preciso desenvolver um plugin para Android na Unity eu geralmente crio um projeto novo no Android Studio e faço tudo por lá, inclusive com um aplicativo de testes. Desta forma é possível utilizar todas as ferramentas de desenvolvimento presentes na IDE antes de ir para a Unity, onde seria mais difícil e nada prático desenvolver uma library Android mais complexa. Eu prefiro exportar o projeto como um arquivo AAR, porém para algo simples e pequeno eu acabo deixando o código dentro da Unity e evito manter um projeto Android apenas para esta finalidade.\nTodo o código deste post e um exemplo de uso está disponível neste repositório no GitHub. Pretendo escrever outro post mostrando como fazer o mesmo plugin para iOS e sua utilização na Unity.\n","date":"1 de março de 2021","externalUrl":null,"permalink":"/unity-plugin-android/","section":"Blog","summary":"Existem algumas estruturas possíveis para implementar um plugin Android na Unity. Quando utilizamos um plugin desenvolvido por terceiros é comum que a sua distribuição seja através de um arquivo AAR, que é uma biblioteca java para Android, junto com alguns scripts em C# para sua utilização. Esta é a opção mais simples, pois a Unity já reconhece o arquivo AAR como uma biblioteca Android e cuida do resto na compilação. Também é possível utilizar um arquivo JAR, mas não é um formato muito utilizado hoje em dia para desenvolvimento com Android, e até exige um pouco mais de configuração para ser utilizado na Unity.\n","title":"Como fazer um plugin para Android em Java na Unity","type":"posts"},{"content":"A Unity publicou esta semana o 2021 Game Report contendo informações e muitos dados sobre a indústria de jogos em 2020, apontando tendências para 2021. Os dados analisados no relatório são de desenvolvedores que utilizam a engine e, apesar de representar apenas quem publicou jogos utilizando a Unity, ainda assim é bem relevante como mostram os dados.\nOs números impressionantes demonstram um crescimento da engine e da indústria de jogos. De acordo com a Unity, jogos desenvolvidos com a engine foram baixados cerca de 5 bilhões de vezes por mês em 2020, sendo que o número de jogadores ativos mensal foi em média 2.8 bilhões. A rede de publicidade Unity Ads teve 23 bilhões de impressões de anúncios por mês.\nO relatório também mostra que a pandemia do COVID-19 contribuiu para o aumento da quantidade de jogadores que buscaram jogos mid/hardcore ao invés de casuais, que eram mais populares principalmente por quem utilizava com frequencia o transporte público. O gráfico abaixo faz um comparativo entre 2019 e 2020 e mostra que os jogadores estão dando preferência por jogos com mais contéudo já que possuem mais tempo disponível sem interrupções para jogar.\nO revenue, que é a receita que o jogo faz, também cresceu em comparação com o ano anterior. O gráfico abaixo mostra que no D1, ou seja, no dia seguinte após a primeira vez que o jogo foi aberto (D0), a receita gerada por compras dentro do jogo (IAP) aumentou bastante. Este aumento de revenue também foi bem expressivo em jogos que possuem ads (publicidade) como fonte de receita.\nEstes dados e muito mais estão disponíveis gratuitamente no relatório da Unity, disponível aqui em Inglês. Recomendo a leitura e análise dos dados, principalmente se você tem algum projeto em desenvolvimento para ser lançado em breve - muitos dados ainda são válidos e podem ser considerados indicadores para um produto.\nPor fim, a Unity fez algumas previsões baseadas nas tendências observadas durante 2020:\nMudanças em privacidade terão um grande impacto em jogos mobile (exemplo disso é o AppTrackingTransparency da Apple que vai ser habilitado em breve no iOS 14.5). Cross-platform entre mobile e HD (desktop/consoles) é o futuro. Mesmo após o COVID-19 o número de jogadores vai continuar alto. Eu pessoalmente concordo e acredito nas previsões da Unity, principalmente na questão do cross-platform entre mobile e desktop/consoles. Além disso, acredito que a geração anterior de consoles, PS4 e Xbox One, vão continuar com novos lançamentos por um tempo maior do que na geração do PS3 e Xbox 360. A base de jogadores é bem grande e acho que vai demorar para a maioria migrar para a geração atual do PS5 e Xbox Series X/S. E você, leitor, tem alguma outra previsão para a indústria de jogos em 2021?\n","date":"25 de fevereiro de 2021","externalUrl":null,"permalink":"/unity-gaming-report-2021/","section":"Blog","summary":"A Unity publicou esta semana o 2021 Game Report contendo informações e muitos dados sobre a indústria de jogos em 2020, apontando tendências para 2021. Os dados analisados no relatório são de desenvolvedores que utilizam a engine e, apesar de representar apenas quem publicou jogos utilizando a Unity, ainda assim é bem relevante como mostram os dados.\n","title":"Relatório da Unity sobre jogos e tendências","type":"posts"},{"content":"Já escrevi algumas vezes sobre cursos e tutoriais para aprender a programar jogos, porém é sempre bom relembrar este assunto com novas referências para quem está começando hoje. Então, decidi escrever um post bem simples e direto com recomendações, para diferentes níveis de conhecimento, combinando aprendizado em programação, inglês e desenvolvimento de jogos.\nO conteúdo deste post são recomendações pessoais, baseadas na minha experiência e com certeza não são as únicas opções disponíveis no mercado. Não adicionei cursos acadêmicos, apenas cursos livres e sites com tutoriais.\nConhecimento Básico ou Nenhum # Se você está começando a estudar desenvolvimento de jogos, seja por hobby ou para entrar na indústria de jogos, é bom começar do básico e com conteúdo de qualidade. Nenhum destes cursos substitui uma formação acadêmica, que eu recomendo fazer, porém são complementares para entender como é desenvolver um jogo, ou para ter um primeiro contato e validar se é algo que realmente quer investir como carreira.\nAlura\nÉ um serviço de cursos online com excelente conteúdo para quem quer aprender a programar, ou até expandir seus conhecimentos. É um serviço pago, mas que o conteúdo vale cada centavo investido, já que a plataforma conta com mais de 1242 cursos até o momento. Confira os cursos de desenvolvimento de jogos disponíveis. E não se preocupe se sentir que não está pronto para iniciar direto com programação de jogos, é possível começar a aprender com alguns cursos de programação para se familiarizar um pouco, antes de partir para games. Acesse aqui.\nUdemy\nSe você ainda não tem certeza que é isso que quer estudar, talvez seja interessante ter um primeiro contato com um curso livre no Udemy, que possui cursos de desenvolvimento de jogos muito bons em português ou com legenda disponível. Lembre sempre de verificar se o curso está disponível em português ou se existem legendas, além de verificar os comentários dos alunos sobre o curso desejado. Acesse aqui.\nConhecimento Intermediário à Avançado # Para quem já tem um conhecimento prévio em programação e inglês, porém não necessariamente um conhecimento de programação de jogos, existem excelentes conteúdos disponíveis gratuitamente. Neste ponto é importante focar em uma game engine, como a Unity ou a Unreal. Com exceção do site da Unreal, todos os links abaixo são sobre Unity, já que é a game engine que trabalho há anos e tenho mais referências para indicar. Este conteúdo também é indicado para quem já teve um primeiro contato com desenvolvimento de games e quer se aprofundar mais.\nUnreal Online Learning\nNo site oficial da Unreal Engine existe uma boa quantidade de tutoriais para aprender a desenvolver jogos utilizando esta tecnologia, seja através de C++ ou Blueprints. Existem tutoriais para todo nível de conhecimento, porém é necessário um conhecimento prévio em inglês para poder aproveitar melhor os cursos. O canal no YouTube da Unreal também possui muito conteúdo bom, recomendo seguir. Acesse aqui\nUnity Learn\nA Unity também tem o seu portal de tutoriais e cursos, o Unity Learn, que ficou totalmente gratuito no início do ano passado. Já fiz vários cursos disponíveis e não canso de recomendar esta plataforma para todos que queiram aprender a fazer jogos com Unity ou aprimorar seus conhecimentos na engine. O canal no YouTube da Unity também é um ótimo lugar para encontrar mais conteúdo sobre a engine. Acesse aqui.\nBrackeys\nInfelizmente, este canal deixou de produzir conteúdo desde o final do ano passado, com os criadores anunciando que vão focar em novos projetos. Porém, ainda existe muito conteúdo bom neste canal para estudar. Acesse aqui.\nCode Monkey\nCom vídeos curtos e objetivos, o Code Monkey explica muito bem como fazer algo bem específico na Unity. O canal tem crescido bastante, com tutoriais cada vez melhores e atuais. Acesse aqui.\nGame Dev Guide\nEste canal também possui vídeos curtos e objetivos, com excelente explicações, mas com uma frequência de postagem menor. Acesse aqui.\nInfallible Code\nPor fim, um canal que conheci a pouco tempo, com alguns vídeos bem interessantes. O autor realiza lives com frequência discutindo assuntos bem relevantes, vale conferir. Acesse aqui.\nConhecimento Avançado e Específico # Com um nível avançado em programação, desenvolvimento de jogos e entendimento de conteúdos em inglês, começa a surgir uma necessidade de se especializar em determinado assunto. Na minha opinião, é difícil um curso de desenvolvimento de jogos ser para um público avançado, uma vez que a base necessária para desenvolver um jogo já existe. Assim, faz mais sentido para mim aprender e recomendar técnicas diferentes, assuntos específicos e palestras sobre o desenvolvimento de grandes jogos.\nGDC\nA Game Developers Conference (GDC) é um evento anual que reúne profissionais da indústria do mundo todo com palestras e workshops sobre técnicas e tecnologias utilizadas para o desenvolvimento de jogos. O evento conta com palestras desde postmortems até soluções bem inovadores utilizadas na geração atual de consoles. Mesmo que boa parte do conteúdo seja com base em game engines restritas, é possível abstrair e ter boas ideias para implementar em seu próprio projeto, ou aprender como um determinado desafio técnico foi solucionado. Acesse aqui.\nSebastian Lague\nDescobri este canal recentemente e fiquei impressionado com os tutoriais. O Sebastian explica um pouco rápido, mas é possível aprender muita coisa sobre shader e técnicas avançadas para desenvolvimento de jogos na Unity. Alguns destaques são as playlists sobre geração procedural de planetas e simulação de ecossistemas, além de muito conteúdo sobre matemática aplicada em programação de jogos. Acesse aqui.\nAI and Games\nSe a especialização que você procura é em Inteligência Artificial, este canal tem muitos vídeos que vão te abrir os olhos para como determinadas técnicas são implementadas em jogos. Acesse aqui.\nThe Cherno\nO Cherno faz vídeos sobre C++, OpenGL e tem uma série mostrando como desenvolver uma game engine do zero. Mesmo que não seja seu interesse criar uma game engine, este conhecimento é excelente para saber o que acontece por trás do seu código. Acesse aqui.\nGame Maker's Toolkit\nUm canal bem grande sobre game design. Seus vídeos dissecam mecânicas e sistemas implementados em jogos, com discussões desde geração de números aleatórios e até o que torna uma Inteligência Artificial boa para um game. Acesse aqui.\nGame Brain\nEste canal é mais focado em game design e discussões sobre como alguns problemas foram resolvidos em determinados jogos. Apesar de não ter programação, seu conteúdo é bem técnico. Acesse aqui.\nO que mais posso fazer para aprender? # Jogos. Desenvolva jogos sempre que puder. Busque inspirações em outros jogos ou em coisas que você gosta e tem interesse, sempre mostre seu projeto e peça feedback para você saber onde deve melhorar. Lembre-se que você deve fazer um jogo para alguém jogar, e não deixar escondido no seu computador.\nTem mais alguma dica de curso ou tutoriais que quer recomendar? Deixe um comentário aqui no post.\n","date":"3 de janeiro de 2021","externalUrl":null,"permalink":"/cursos-tutoriais-programacao-jogos/","section":"Blog","summary":"Já escrevi algumas vezes sobre cursos e tutoriais para aprender a programar jogos, porém é sempre bom relembrar este assunto com novas referências para quem está começando hoje. Então, decidi escrever um post bem simples e direto com recomendações, para diferentes níveis de conhecimento, combinando aprendizado em programação, inglês e desenvolvimento de jogos.\n","title":"Cursos e tutoriais para aprender a programar jogos","type":"posts"},{"content":"Sempre recomendo o livro Game Programming Patterns, que possui versões física e digital à venda, além de uma online gratuita disponibilizada pelo autor, Robert Nystrom. Este livro revisita os design patterns definidos na década de 1990 pela \u0026quot;Gangue dos Quatro\u0026quot;, focando no seu uso para o desenvolvimento de jogos.\nO livro conta com excelentes exemplos e com pseudocódigo baseado em C/C++, além de descreve situações em que cada programming pattern pode ser utilizado. Já realizei algumas palestras sobre este assunto e utilizei este livro como base, sendo a mais recente na TDC Porto Alegre 2019. Meu objetivo com este post e, com os próximos que virão, é criar exemplos do uso de cada programming pattern na game engine Unity e com a linguagem de programação C#.\nSeguindo a ordem do livro, este primeiro post será sobre o Design Pattern Command. O código deste exemplo, assim como de todos os próximos, pode ser acessado neste repositório do GitHub.\nDesign Pattern Command # O Command é um design pattern que tem como objetivo encapsular um método ou ação. Em uma definição muito simples pode-se dizer que é um padrão para callbacks. Um exemplo bem prático do Command é o input de um jogo. Imagine que seu jogo possui uma opção para que o jogador modifique as ações de cada botão, seja por preferencia pessoal ou acessibilidade. Com a Implementação do Command fica simples modificar o comando que um botão executa, como demonstrado no exemplo a seguir.\nImplementação na Unity com C# # Neste exemplo de implementação existem duas ações possíveis para o jogador: Pular e Atirar. Para simplificar o exemplo, cada ação será apenas uma mensagem de log. O código abaixo define exatamente isso, dois comandos que podem ser executados. É importante ter uma interface neste caso, ou pelo menos uma classe base, para que o código que executar estas ações não precise necessariamente saber o tipo de cada classe derivada.\npublic interface ICommand { void Execute(); } public class JumpCommand : ICommand { public void Execute() { Debug.Log(\u0026#34;Execute command: Jump\u0026#34;); } } public class FireCommand : ICommand { public void Execute() { Debug.Log(\u0026#34;Execute command: Fire\u0026#34;); } } E é basicamente isso, uma interface com o método que executará uma ação e duas implementações desta interface. Agora ambas ações podem ser utilizadas em outra classe, como será demonstrado no MonoBehaviour abaixo. A classe abaixo possui dois métodos públicos executados por botões na Unity, o ButtonA() e o ButtonB(). Estes métodos executam qualquer comando associado com as respectivas variáveis, as quais possuem o tipo da interface ICommand.\npublic class DesignPatternCommand : MonoBehaviour { private ICommand _buttonA; private ICommand _buttonB; private void Start() { _buttonA = new JumpCommand(); _buttonB = new FireCommand(); } public void ButtonA() { _buttonA.Execute(); } public void ButtonB() { _buttonB.Execute(); } } Quando executado, o código acima irá atribuir a ação de pular para o botão A e a ação de atirar para o botão B. Agora imagine que, neste exemplo, teremos uma opção que permite o jogador inverter os comandos dos botões. Para isso, um método como este abaixo irá alterar o comando dos botões sem a necessidade de qualquer outra modificação no código.\nprivate void ChangeButtons() { _buttonA = new FireCommand(); _buttonB = new JumpCommand(); } Este é um exemplo bem simples para explicar o conceito por trás deste programming pattern. A partir disso pode-se ver como o Command é um poderoso recurso para todo programador, pois permite alterar ações sem criar dependências no código. Existem outros exemplos interessantes para o seu uso, como um sistema de avançar e voltar no tempo onde todas as ações do jogador podem ser uma lista de comandos executados. Isso pode ser utilizado até mesmo em um editor para desfazer e refazer uma determinada ação.\nExemplo # Neste repositório do GitHub existe um exemplo utilizando o código acima, porém com 4 botões de ações do jogador e um outro botão que permite embaralhar as ações.\nO Command é um padrão simples, mas que é muito poderoso quando entendido e utilizado corretamente na arquitetura de um jogo. Imagine ter que adicionar novos botões no exemplo acima, ou um hardware diferente para o input. Tudo isso pode ser feito de forma prática com o Command. Este programming pattern é um bom aliado para tornar um jogo mais acessível, permitindo a customização do controle do jogo pelo jogador.\n","date":"29 de dezembro de 2020","externalUrl":null,"permalink":"/design-pattern-command/","section":"Blog","summary":"Sempre recomendo o livro Game Programming Patterns, que possui versões física e digital à venda, além de uma online gratuita disponibilizada pelo autor, Robert Nystrom. Este livro revisita os design patterns definidos na década de 1990 pela \"Gangue dos Quatro\", focando no seu uso para o desenvolvimento de jogos.\n","title":"Exemplo do Design Pattern Command na Unity com C#","type":"posts"},{"content":"Neste post quero compartilhar algumas dicas e boas práticas para uso do Debug.Log() na Unity. Pode parecer intuitivo utilizar a API da Unity para registrar todo tipo de ação que o jogador fizer, mas existem algumas maneiras de fazer isso que podem tornar o processo de debug e teste mais fácil, além de registrar logs apenas do que realmente é necessário.\nEm um jogo publicado não faz sentido ter chamadas para o Debug.Log(), pois que utilidade existe em registar uma mensagem do tipo \u0026quot;Item found!\u0026quot; se isso não é relevante para o jogador e você não poderá ver esta mensagem no aparelho dele? O uso do Debug.Log() pode ser muito útil enquanto está desenvolvendo e testando um jogo. Mas, mesmo assim, as mensagens precisam ser úteis e ter um contexto que ajude a entender o que está acontecendo.\nMensagens relevantes # Vamos analisar a seguinte sequencia de mensagens:\nButton pressed! Button pressed! Player killed monster Monster drops: 2 Apesar de ser possível entender o que aconteceu, estas mensagens são bem pobres em informações. Nas mensagens acima não é possível saber qual botão foi pressionado, qual monstro foi derrotado, e qual item o monstro largou. Perceba que nem é possível ver se o jogador pegou o item a partir destes logs, e se algum erro acontecer será bem difícil de reproduzir e corrigir. Por isso, é importante registrar mensagens relevantes e com contexto suficiente para entender o que aconteceu. Vamos analisar agora a mesma sequencia, porém com mais detalhes:\nState changed: EXPLORING -\u0026gt; START_BATTLE Player attacked monster blue and caused 10 damage (critical). Monster blue has 5HP Player attacked monster blue and caused 7 damage. Monster blue has 0HP Monster blue was defeated. Drops: {\u0026#34;potion\u0026#34;: \u0026#34;potion_red\u0026#34;,\u0026#34;gold\u0026#34;: 10}. Experience: +2XP State changed: START_BATTLE -\u0026gt; END_BATTLE Player picked up items: {\u0026#34;potion\u0026#34;: \u0026#34;potion_red\u0026#34;,\u0026#34;gold\u0026#34;: 10} Player received 2XP. Now has 32/50 State changed: END_BATTLE -\u0026gt; EXPLORING Ao invés de registrar um botão foi pressionado, é registrada a ação desencadeada pelo botão, o ataque e qual a consequência da ação, que foi causar dano no monstro blue. Na mesma linha do log é possível ver quanto dano foi causado, se foi um ataque crítico e quanta vida resta para o monstro. Após ser derrotado, é possível ver quais itens o monstro derrubou e quanta experiência deu ao jogador.\nPodemos ver também que o jogador pegou os itens, recebeu a experiência, quanta experiência tem no momento (32), e quanto precisará para o próximo nível (50). Um detalhe a mais são os registros de mudança de estado: a batalha inicia e tem um fim. Assim, fica fácil ver que todas aquelas ações aconteceram em uma batalha, o que torna mais simples de entender e reproduzir um determinado comportamento para corrigir um erro ou até ajustar o balanceamento do jogo.\nMensagens seletivas # Apesar das mensagens acima terem contexto e serem relevantes, ainda assim, podem criar uma quantidade desnecessária de logs em uma sessão de jogo. Em alguns momentos vamos querer ver os logs da batalha em detalhes, porém em outros, vamos querer ver apenas os logs de mudança de estados. E em outros nenhum log, apenas erros (quando acontecerem).\nUma das maneiras de escolher quais logs devem ser exibidos no jogo é utilizar Scripting Define Symbols no código e habilitá-los no Player Settings da Unity para a plataforma desejada. Assim, é possível habilitar determinados logs para determinadas situações. Uma solução bem prática é criar uma classe estática responsável por chamar a API de logs da Unity, e fazer o jogo utilizá-la ao invés de chamar Debug.Log() diretamente.\npublic static class Logger { [System.Diagnostics.Conditional(\u0026#34;ENABLE_LOG_BATTLE\u0026#34;)] public static void LogBattle(string message) { UnityEngine.Debug.Log(message); } [System.Diagnostics.Conditional(\u0026#34;ENABLE_LOG_STATE\u0026#34;)] public static void LogChangeState(string message) { UnityEngine.Debug.Log(message); } public static void LogWarn(string message) { UnityEngine.Debug.LogWarning(message); } public static void LogError(string message) { UnityEngine.Debug.LogError(message); } } Os métodos LogBattle() e LogChangeState() possuem o atributo Conditional com os define symbols \u0026quot;ENABLE_LOG_BATTLE\u0026quot; e \u0026quot;ENABLE_LOG_STATE\u0026quot;, respectivamente. Desta maneira, é possível chamar ambos os métodos a qualquer momento no jogo, mas eles só serão executados se os respectivos define symbols estiverem habilitados no Player Settings, conforme imagem abaixo. Adicionei também métodos para Warnings e Errors, assim todos os logs podem ser concentrados nesta classe. Outra vantagem de centralizar tudo em uma classe é poder customizar as mensagens adicionando qualquer tipo de informação ou formatação.\nVale lembrar que os define symbols são por plataforma, ou seja, é necessário defini-los para cada plataforma que será utilizada. Uma maneira bem prática de adicionar e remover os define symbols é criando um script que faça isso. Este script pode ser usado a partir de um menu, ou até em um sistema de build. Isso é muito útil para gerar builds em um CI como o Jenkins, por exemplo, parametrizando a build para ter ou não determinados logs.\nUtilizar uma classe como a Logger causa um efeito colateral e pode ser visto no Editor: ao clicar duas vezes em uma mensagem de log será aberto o script do Logger ao invés do script que executou o método, como acontece quando usamos diretamente o Debug.Log(). Isto pode ser corrigido modificando o código e adicionando um delegate.\npublic static class Logger { public static class Logger { public delegate void LogHandler(string message); #if ENABLE_LOG_BATTLE public static LogHandler LogBattle = UnityEngine.Debug.Log; #else public static LogHandler LogBattle = (message) =\u0026gt; { }; #endif #if ENABLE_LOG_STATE public static LogHandler LogChangeState = UnityEngine.Debug.Log; #else public static LogHandler LogChangeState = (message) =\u0026gt; { }; #endif public static LogHandler LogWarn = UnityEngine.Debug.LogWarning; public static LogHandler LogError = UnityEngine.Debug.LogError; } } O código fica um pouco mais complexo, porém agora ao clicar duas vezes em uma mensagem de log no Editor o script que executou o Logger será aberto. Infelizmente, não é possível utilizar o atributo Conditional, pois estamos usando uma propriedade ao invés de um método, por isso é necessário utilizar o #if ... #else ... #endif. Quando o define symbol não estiver no Player Settings, nada acontece.\nExistem outras coisas que podemos fazer para melhorar os logs em um jogo, desde cores e formatação até um sistema mais robusto para ligar e desligar mensagens em determinado tipo de build. Meu objetivo neste post foi mostrar algumas coisas que considero boas práticas e muito úteis para um projeto. Logs são muito importantes para um jogo, e devem ser tratados como tal. Gaste um minuto a mais para escrever uma mensagem útil, com informações que vão realmente te ajudar a entender o que está acontecendo.\nMinha sugestão de centralizar os logs em uma classe e combinar com define symbols ajudam, porém muitas mensagens podem poluir e esconder informações úteis e até causar problemas de performance no jogo sem perceber. Seja bem crítico para não deixar seu projeto se tornar um mar de mensagens inúteis e planeje um tempo para revisar as mensagens de tempos em tempos.\n","date":"26 de outubro de 2020","externalUrl":null,"permalink":"/unity-debug-log/","section":"Blog","summary":"Neste post quero compartilhar algumas dicas e boas práticas para uso do Debug.Log() na Unity. Pode parecer intuitivo utilizar a API da Unity para registrar todo tipo de ação que o jogador fizer, mas existem algumas maneiras de fazer isso que podem tornar o processo de debug e teste mais fácil, além de registrar logs apenas do que realmente é necessário.\n","title":"Boas práticas para uso de logs na Unity","type":"posts"},{"content":"Raspberry Pi é um computador muito simples e com hardware limitado e, por esse motivo é muito barato e usado para as mais diversas coisas, desde um simples desktop até robôs e máquinas de jogos retrô. Esses são alguns exemplos, mas basta procurar pra ver a quantidade de projetos feitos utilizando esse simples pedaço de hardware.\nO modelo mais simples atualmente é o Raspberry Pi Zero que custa USD 5 e possui um processador single-core de 1 GHz, 512MB de RAM, slot para micro SD, uma porta micro USB para conectar periféricos, uma porta micro USB para energia e uma porta mini HDMI. A versão que usei para configurar o Jenkins é o Raspberry Pi Zero W, que possui o mesmo hardware porém, com Wi-Fi e Bluetooth, o que faz o valor aumentar para USD 10.\nA ideia de rodar o Jenkins neste hardware limitado surgiu como um primeiro projeto para poder entender como é trabalhar com um Raspberry Pi, e os requisitos mínimos para instalar este sistema de integração contínua (CI) estão dentro das configurações do hardware. Estou utilizando um micro SD de 64GB, que é mais do que suficiente.\nO primeiro passo é baixar o Raspberry Pi Imager para o seu sistema operacional e conectar o card micro SD em sua máquina para ser formatado e instalar o OS. Aqui vem o primeiro detalhe: Apesar de ter alguns sistemas operacionais na lista, como o Ubuntu, o processador do Raspberry Pi Zero é um ARM6, e por esse motivo ele é limitado aos sistemas operacionais desta arquitetura. A única opção deste lista é o Raspberry Pi OS, que é um port do Debian.\nÉ possível conectar monitor, mouse e teclado no Raspberry Pi Zero, utilizando os devidos conectores. Mas, no meu caso, quero acessá-lo pela rede como um servidor, por isso não preciso de uma interface de desktop. Sendo assim, instalei o Raspberry Pi OS Lite, que não possui desktop. Caso você queira rodar outros sistemas operacionais, um hardware mais robusto como o Raspberry Pi 4 pode ser uma opção melhor.\nCom o micro SD formatado e com o Raspberry Pi OS Lite devidamente instalado nele, é preciso fazer apenas duas configurações antes de colocá-lo no Raspberry Pi Zero e iniciar seu sistema. O acesso por SSH vem desabilitado por padrão, e para habilitá-lo precisamos criar um arquivo com nome SSH na raiz do micro SD. Além disso, como o acesso vai ser feito por Wi-Fi, é preciso criar um arquivo com o nome da rede e senha para que ele conecte automaticamente na rede. Os comandos abaixo podem ser utilizamos no macOS para criar os arquivos.\ntouch /Volumes/boot/ssh touch /Volumes/boot/wpa_supplicant.conf Em seguida, abra o arquivo wpa_supplicant.conf no notepad ou similar para editar seu conteúdo. Cole o texto abaixo, mas lembre de substituir os valores para sua rede Wi-Fi e senha.\ncountry=US ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev update_config=1 network={ ssid=\u0026#34;NETWORK-NAME\u0026#34; psk=\u0026#34;NETWORK-PASSWORD\u0026#34; } Agora pode-se remover o micro SD e colocá-lo no Raspberry Pi Zero, e então conectá-lo na energia para ser iniciado. Por mais que sua fonte de alimentação seja um cabo micro USB, não conecte em sua máquina, mas sim utilize um adaptador para ligá-lo na tomada. Depois de algumas piscadas o LED verde da placa deve ficar estável, e então abra seu terminal e utilize os comandos abaixo para conectar no Raspberry Pi Zero. O usuário padrão é pi e a senha padrão é raspberry, lembre-se de alterá-la depois.\nssh pi@raspberrypi.local Após conectar com sucesso no Raspberry Pi Zero, é preciso atualizar seus pacotes e instalar o Java 1.8, o qual é necessário para rodar o Jenkins. Instalar o Java padrão irá causar diversos erros por causa da arquitetura do hardware. Por isso, utilizei o OpenJava, que possui uma versão do Java 1.8 para o ARM6. Conforme as linhas abaixo:\nsudo apt-get update -y sudo apt-get upgrade -y sudo apt-get install openjdk-8-jdk Por fim, para instalar o Jenkins. Lembre-se de que o Raspberry Pi OS é um port do Debian, por isso é necessário executar os passos para instalação do Jenkins no Debian. Se você estiver utilizando outro sistema operacional, procure as instruções adequadas no site oficial. A última linha do bloco abaixo, adicionar o Jenkins como um serviço para sempre ser inicializado junto com o sistema operacional.\nwget -q -O - https://pkg.jenkins.io/debian-stable/jenkins.io.key | sudo apt-key add - sudo sh -c \u0026#39;echo deb https://pkg.jenkins.io/debian-stable binary/ \u0026gt; /etc/apt/sources.list.d/jenkins.list\u0026#39; sudo apt-get update -y sudo apt-get install jenkins sudo systemctl enable --now jenkins Com todos estes comandos executados com sucesso, você está pronto para abrir o navegador em http://raspberrypi.local:8080 e começar a configurar o Jenkins seguindo os passos no navegador. Parabéns, você tem um CI rodando em um Raspberry Pi!\nExiste um pequeno detalhe que só descobri depois de tudo isso. Apesar do Raspberry Pi Zero estar nos requisitos mínimos para rodar o Jenkins, ele é extremamente lento. Se prepare para ver a tela acima por vários minutos antes de fazer qualquer coisa no Jenkins. E tenha paciência para configurar jobs, muita paciência mesmo! O hardware é muito limitado, e apesar de um projeto interessante, não recomendo utilizá-lo como um servidor local de CI. Provavelmente um Raspberry Pi 4 funcione melhor, pois possui um processador quad-core e o principal gargalo nesse sistema é o processamento.\nCom muita paciência consegui criar um servidor Node e fazer o deploy de uma aplicação bem simples utilizando o Jenkins, tudo rodando no mesmo servidor do Raspberry Pi Zero - algo bem impressionante, beirando o limite de memória RAM do hardware.\n","date":"7 de setembro de 2020","externalUrl":null,"permalink":"/raspberry-pi-zero-w-jenkins/","section":"Blog","summary":"Raspberry Pi é um computador muito simples e com hardware limitado e, por esse motivo é muito barato e usado para as mais diversas coisas, desde um simples desktop até robôs e máquinas de jogos retrô. Esses são alguns exemplos, mas basta procurar pra ver a quantidade de projetos feitos utilizando esse simples pedaço de hardware.\n","title":"Rodando Jenkins em um Raspberry Pi Zero W","type":"posts"},{"content":"A utilização de Asset Bundles na Unity é uma boa solução da própria engine para download de recursos. É comum utilizar esta forma de distribuição de assets para poder atualizar ou adicionar conteúdo ao jogo após o lançamento, não sendo necessário publicar um novo binário do jogo. Desta forma, jogos podem adicionar personagens, níveis, ou fazer correções em modelos e imagens sem precisar de uma versão nova do jogo. A única limitação é não poder adicionar novos scripts ou utilizar scripts em versões diferentes dos que estão no binário, o que faz os desenvolvedores pensarem em formas de tornar seus jogos mais flexíveis e extrair o máximo dos asset bundles.\nPorém, existem mais vantagens em utilizar asset bundles do que apenas atualizar o conteúdo do jogo: é possível reduzir o tamanho do jogo, o uso de memória, uso de CPU e até tempo de loading ajustando algumas opções de compressão na Unity. O objetivo deste post é explorar algumas combinações de compressão, utilizando a plataforma Android como exemplo, e comparar os resultados. Se você quiser saber mais sobre asset bundles, recomendo este curso gratuito da Unity.\nConfiguração # Escolhi a plataforma Android para o teste por ser mais simples de compilar e testar em um aparelho. Utilizei um Samsung Galaxy S9 com Android 8.0.0 nos testes e instalei um total de 27 builds nele, cada uma contendo uma combinação de compressão no APK e nos asset bundles. Para deixar o teste mais simples, todos asset bundles foram carregados a partir da pasta StreamingAssets. A versão da Unity utilizada foi a 2019.4.7f1 e todas as builds foram geradas em modo release.\nA primeira variação foi a configuração do APK gerado pela Unity no Player Settings. Realizei testes com o Scripting Backend Mono e IL2CPP, além de testar com as arquiteturas ARMv7 e AMR64, já que o aparelho utilizado no teste suporta ambas.\nNo Build Settings testei os métodos de compressão do APK: Default (ZIP), LZ4 (recomendado para development) e LZ4HC (melhor compressão, porém processo de build mais lento). Esta configuração, assim como as anteriores, não afetam os asset bundles, porém são algumas mudanças no APK que quis testar para ver a influência na build.\nAs últimas configurações foram feitas na geração dos asset bundles, utilizando o Unity package Asset Bundle Browser versão 1.0.7. Para o teste foram gerados 3 conjuntos de asset bundles, cada um com opção de compressão:\nNo compression: sem compressão, carregamento rápido. LZMA: menor tamanho de arquivo, porém mais lento para carregar por causa da descompressão. LZ4: compressão com tamanho maior, porém, descompressão mais rápida. Teste # Para realizar o teste escrevi um script bem simples para gerar todas as builds Android, as quais iriam utilizar no teste, considerando as seguintes variações e resultado em um total de 27 APKs:\nScripting backend: Mono, IL2CPP Architecture: ARMv7, ARM64 Build compression: Default, LZ4, LZ4HC Asset bundles compression: No compression, LZMA, LZ4 Com os 27 APKs gerados, instalei cada um no aparelho, sempre desinstalando o anterior. Cada APK foi iniciado apenas uma vez, com os seguintes dados coletados:\nTamanho da builds Tempo até executar o método Awake() no único MonoBehaviour em um Game Object na Scene Tamanho do asset bundle Média do tempo para carregar um asset bundle usando a API AssetBundle.LoadFromFileAsync() O projeto de teste contém 5 asset bundles, todos são cubos padrões da Unity com um material diferente em cada para modificar a cor (green, orange, purple, red, yellow). Cada asset bundle foi carregado sequencialmente, e o tempo considerado foi a média do tempo para carregar cada um deles.\nprivate IEnumerator Start() { yield return CreateCube(\u0026#34;green\u0026#34;, \u0026#34;cube_green\u0026#34;, new Vector3(0, 0, 0)); yield return CreateCube(\u0026#34;orange\u0026#34;, \u0026#34;cube_orange\u0026#34;, new Vector3(0, 1.5f, 0)); yield return CreateCube(\u0026#34;purple\u0026#34;, \u0026#34;cube_purple\u0026#34;, new Vector3(0, -1.5f, 0)); yield return CreateCube(\u0026#34;red\u0026#34;, \u0026#34;cube_red\u0026#34;, new Vector3(1.5f, 0, 0)); yield return CreateCube(\u0026#34;yellow\u0026#34;, \u0026#34;cube_yellow\u0026#34;, new Vector3(-1.5f, 0, 0)); } private IEnumerator CreateCube(string bundleName, string assetName, Vector3 position) { string path = Path.Combine(Application.streamingAssetsPath, bundleName); AssetBundleCreateRequest assetBundleRequest = AssetBundle.LoadFromFileAsync(path); yield return assetBundleRequest; GameObject sphere = assetBundleRequest.assetBundle.LoadAsset\u0026lt;GameObject\u0026gt;(assetName); Instantiate(sphere, position, sphere.transform.rotation, transform); } O script acima é uma versão simplificada do que utilizei para o teste. Omiti os logs e medições para mostrar como carreguei cada asset bundle e instanciei o game object.\nResultado # O resultado das 27 execuções de cada build está na tabela abaixo, ordenada pelo menor tempo médio para carregar um asset bundle.\nBuild Backend Arch. APK Startup Bundle Size Avg. ^ LZ4HC IL2CPP ARM64 84.5MB 2.04s No 15.4MB 46.4ms LZ4HC Mono ARMv7 94.5MB 2.14s No 15.4MB 49.4ms LZ4HC IL2CPP ARM64 46.2MB 2.03s LZ4 7.7MB 50ms LZ4 IL2CPP ARM64 84.6MB 2.04s No 15.4MB 52.4ms Default IL2CPP ARM64 84.5MB 2.04s No 15.4MB 54.8ms LZ4 IL2CPP ARM64 46.2MB 2.04s LZ4 7.7MB 55.4ms LZ4 IL2CPP ARMv7 45.6MB 2.03s LZ4 7.7MB 55.8ms LZ4HC IL2CPP ARMv7 84.0MB 2.03s No 15.4MB 56ms LZ4 IL2CPP ARMv7 84.0MB 2.04s No 15.4MB 56.8ms Default IL2CPP ARM64 46.1MB 2.04s LZ4 7.7MB 57.6ms LZ4HC IL2CPP ARMv7 45.6MB 2.03s LZ4 7.7MB 57.8ms LZ4 Mono ARMv7 94.6MB 2.14s No 15.4MB 58.2ms Default Mono ARMv7 56.1MB 2.14s LZ4 7.7MB 59.8ms Default IL2CPP ARMv7 83.9MB 2.04s No 15.4MB 61.2ms Default IL2CPP ARMv7 45.5MB 2.03s LZ4 7.7MB 61.4ms Default Mono ARMv7 94.5MB 2.13s No 15.4MB 62.4ms LZ4 Mono ARMv7 56.2MB 2.13s LZ4 7.7MB 62.8ms LZ4HC Mono ARMv7 56.2MB 2.13s LZ4 7.7MB 67.8ms LZ4HC IL2CPP ARM64 39.4MB 2.03s LZMA 6.4MB 1331.6ms Default IL2CPP ARM64 39.3MB 2.03s LZMA 6.4MB 1343ms LZ4 Mono ARMv7 49.4MB 2.13s LZMA 6.4MB 1355.8ms LZ4 IL2CPP ARM64 39.4MB 2.03s LZMA 6.4MB 1358.6ms LZ4HC Mono ARMv7 49.4MB 2.13s LZMA 6.4MB 1369.2ms LZ4 IL2CPP ARMv7 38.8MB 2.04s LZMA 6.4MB 1376.4ms LZ4HC IL2CPP ARMv7 38.8MB 2.03s LZMA 6.4MB 1378.8ms Default IL2CPP ARMv7 38.7MB 2.04s LZMA 6.4MB 1394ms Default Mono ARMv7 49.3MB 2.13s LZMA 6.4MB 1414.8ms Legenda da tabela:\nBuild: compression method do Build Settings Backend: scripting backend do Player Settings Arch.: architecture do Player Settings APK: tamanho do APK Startup: tempo até carregar o MonoBehaviour Bundle: compression do Asset Bundle Build Size: tamanho do asset bundle Avg.: tempo médio para carregar um asset bundle Conclusão # O projeto utilizado no teste era bem pequeno e, apesar do foco ser a compressão de asset bundles, foi interessante ver como as demais configurações influenciam no todo. Qual a melhor configuração para o seu projeto? Depende.\nNão comprimir asset bundles faz o carregamento ser muito rápido, porém, isso aumenta tanto o tamanho dos arquivos baixados e da build (quando possuem asset bundles), o que é bem raro um jogo grande utilizar. A compressão LZMA deixa um tamanho menor para download, reduzindo o tempo para o jogador poder jogar e até diminuindo o custo do CDN, porém, aumenta bastante o tempo de loading por causa da descompressão. O LZ4 pode ser o melhor dos dois mundos, sendo relativamente rápido para carregar e não tão pesado, mas ainda assim depende muito do projeto.\nJá nas configurações específicas do Android, LZ4HC mostrou um bom desempenho para carregar o jogo, assim como o IL2CPP. Sempre que possível inclua as duas arquiteturas, ARMv7 e ARM64, no APK ou no Android App Bundle (AAB) - o Android vai fazer o resto e decidir qual é a melhor arquitetura presente no app para ser utilizada. No caso do teste, eu forcei builds apenas com ARMv7 e ARM64 para poder comparar os resultados, já que se incluísse ambas apenas a ARM64 seria utilizada.\nLembrando novamente que, este teste foi realizado em um projeto pequeno e simples, mas que serviu para mostrar qual seria a melhor combinação para este jogo. Mais do que isso, este teste mostra que existem muitas variáveis nas configurações do projeto na Unity, as quais podem influenciar bastante a performance do jogo, e conhecê-las te ajudará a escolher qual é a melhor para seu projeto. Lembre-se de não decidir sem testar, algumas horas do seu dia podem melhorar muito o desempenho do seu jogo.\n","date":"24 de agosto de 2020","externalUrl":null,"permalink":"/unity-asset-bundle-compression/","section":"Blog","summary":"A utilização de Asset Bundles na Unity é uma boa solução da própria engine para download de recursos. É comum utilizar esta forma de distribuição de assets para poder atualizar ou adicionar conteúdo ao jogo após o lançamento, não sendo necessário publicar um novo binário do jogo. Desta forma, jogos podem adicionar personagens, níveis, ou fazer correções em modelos e imagens sem precisar de uma versão nova do jogo. A única limitação é não poder adicionar novos scripts ou utilizar scripts em versões diferentes dos que estão no binário, o que faz os desenvolvedores pensarem em formas de tornar seus jogos mais flexíveis e extrair o máximo dos asset bundles.\n","title":"Compressão de Asset Bundles na Unity","type":"posts"},{"content":"","date":"1 de agosto de 2020","externalUrl":null,"permalink":"/categories/postmortem/","section":"Categorias","summary":"","title":"Postmortem","type":"categories"},{"content":"Pouco mais de 2 anos se passaram desde o último postmortem que publiquei aqui no blog. Desta vez, recebi um texto do Luiz Felipe da Silva Marian, que criou sozinho o jogo Call of Coronga. Inspirado na pandemia do COVID-19, o jogo está disponível no Steam para PC. Confira abaixo o que deu certo e o que deu errado em seu desenvolvimento, e leia também os outros postmortems postados aqui no blog.\nOlá, eu sou \u0026quot;Luiz Felipe da Silva Marian\u0026quot;, tenho 19 anos e desde muito novo sou fascinado por criar novas coisas. No universo da programação achei um mundo perfeito para dar vida as minhas ideias, o desenvolvimento de jogos e softwares é incrível, pois não existem limites, tudo que você imaginar é possível ser criado dessa maneira você fica a mercer da sua imaginação.\nPostmortem : Call of Coronga # A ideia surgiu no inicio da pandemia, eu como um grande fã da franquia \u0026quot;Call of Duty\u0026quot; de maneira rápida se acendeu na minha cabeça uma lâmpada \u0026quot;por que não criar um jogo inspirado no modo Zumbi?\u0026quot; melhor ainda ao invés de zumbis os vilões seriam pessoas infectadas.\nO objetivo era trazer um pouco de humor e alegria nessa infeliz pandemia. Todo o jogo foi projetado em torno do modo Gripados no qual é inspirado no modo zumbi, porém eu queria mais, não apenas esse estilo, eu queria homenagear as vítimas do vírus e ao mesmo tempo criar um história macabra sobre a origem do mesmo, então surgiu o modo História. Produção:\nCriar um jogo das dimensões que é \u0026quot;Call of Coronga\u0026quot; sozinho foi uma tarefa extremamente difícil e desgastante, felizmente meu foco foi todo destinado apenas na parte gráfica da interface e nos milhares de códigos escritos, pois todos os modelos 3D eu comprei ou usei os próprios fornecidos pela UNITY, mesmo assim a construção dos cenários com a riqueza de detalhes que eu queria me custaram dezenas de horas cada pedra tinha que estar no local certo, a configuração do cenário é muito desgastante, a correta interconexão entre códigos e objetos 3D é fundamental para um jogo não conter bugs, desta maneira estou muito satisfeito com todos os grandes cenários e animações que eu criei para cada parte do jogo.\nProblemas / Dificuldades # Criação dos cenários\nUm dos problemas mais cansativos foi dar vida ao ambiente do jogo, pois foi preciso que eu construísse mais de 10 cenários do zero, desde uma pedrinha no chão até o reflexo do sol tudo tinha que estar no local correto, ao mesmo tempo o cenário tinha que ser rico em detalhes e divertido para a jogabilidade ser fluída. Como o jogo é feito em Low poly, os modelos 3D não se encaixavam muito bem toda hora surgia uma falha na colisão que lhe jogava para o eterno limbo.\nAnimações\nUma parte realmente chata! Para desenvolvedores independentes esta etapa é um \u0026quot;pé no saco\u0026quot; para cada ação do player deve existir uma animação, fazer essas animações me custaram realmente muitas horas.\nPouco público e divulgação\nApesar do grande esforço para divulgar meu jogo, até o presente momento tenho um público muito pequeno e enxuto, como disse antes é muito difícil fazer sucesso com um jogo independente principalmente sem financiamento destinado para a divulgação paga.\nOnline\nSem sombra de dúvidas, tirando a construção do cenário, essa foi a parte mais árdua de todo o projeto, criar um jogo online é extremamente complexo a sincronização dos códigos em diferentes redes pelo mundo me custaram dezenas de horas, para piorar cada modificação que eu fazia no código eu tinha que criar uma nova BUILD do jogo para poder testar, cada build demora em torno de 15 minutos.\nSucesso / Aprendizado # Modelos 3d comprados\nComo eu usei modelos 3D comprados ou disponibilizados gratuitamente na unity, isso me proporcionou uma economia de tempo absurdamente relevante, com isso não precisei modelar e texturizar os assets.\nMeu primeiro jogo online\nMesmo enfrentando as maiores dificuldades que já tive em um projeto, o Call of Coronga foi o estopim para meu aprendizado em relação aos recursos de rede, após este jogo me sinto capaz de criar qualquer outro jogo online.\nCódigos já escritos\nComo eu uso a unity a muito tempo, eu tinha um grande acervo de scripts, os quais usei como modelo ou guia para os novos scripts do Call of Coronga.\nO baixo custo do projeto\nPara a conclusão do projeto eu gastei relativamente bem pouco, utilizei modelos 3D já comprados a algum tempo, o único valor considerável que eu investi foi os 100 dólares para poder publicar o jogo na steam.\nO sentimento de satisfação\nNão existe nada mais satisfatório que dar vida a algo e realmente acreditar que sua criação ficou boa, os diversos feedbacks que recebi foram muito gratificantes para mim, ver pessoas jogado meu jogo e curtido foi uma das melhores sensações que já tive.\nConclusão # A experiência adquirida na produção do projeto desde o inicio até o fim, foi incrível em todos os aspectos, com certeza diversos erros foram cometidos, mas também muitos acertos me possibilitaram disponibilizar o jogo para o público em apenas 3 meses de desenvolvimento.\nPor fim, eu quero deixar claro que se você tem um sonho, objetivo ou meta corra atrás, pois apenas seus esforços e seus méritos serão capazes de lhe proporcionar a conclusão do seu objetivo, seja ele qual for, dedique-se, aprenda a analisar as críticas positivas e negativas para sempre melhorar e evoluir, pois o mundo está em completa evolução, e nós seres humanos não podemos ficar para trás.\nObrigado. Luiz Felipe da Silva Marian Email: mushroomangelsgames@gmail.com\n","date":"1 de agosto de 2020","externalUrl":null,"permalink":"/postmortem-call-of-coronga/","section":"Blog","summary":"Pouco mais de 2 anos se passaram desde o último postmortem que publiquei aqui no blog. Desta vez, recebi um texto do Luiz Felipe da Silva Marian, que criou sozinho o jogo Call of Coronga. Inspirado na pandemia do COVID-19, o jogo está disponível no Steam para PC. Confira abaixo o que deu certo e o que deu errado em seu desenvolvimento, e leia também os outros postmortems postados aqui no blog.\n","title":"Postmortem: Call of Coronga","type":"posts"},{"content":"Este tutorial chamado Making A Flappy Bird Style Game feito pela Unity esta disponível no site Unity Learn e é dividido em 10 partes. Não é um tutorial novo, foi publicado em 2006, porém existem muitas coisas interessantes nestes vídeos que ainda são bem atuais para desenvolvimento de jogos 2D na Unity, além de muitas dicas de como ser mais produtivo no editor.\nEsta série de vídeos, que tem menos de 2 horas no total, é um conteúdo rápido e muito bom para aprender algumas coisas básicas na Unity, além de exemplos de design patterns na prática. Eu recomendo pra quem tem experiência com Unity também, pois sempre temos algo a aprender. Eu assiti todo o curso e realmente aprendi e relembrei algumas coisas.\nOs vídeos estão disponíveis no site Unity Learn e também no canal da Unity no Youtube. Listei todos abaixo, mas recomendo fortemente acompanhar pelo site da Unity Learn por que em cada vídeo tem o código em seguida pra você ver em detalhes.\nVale lembrar que todo conteúdo premium da Unity Learn está disponível de graça por um tempo. O conteúdo criado pela Unity é muito bom, e tem vídeos para todas as áreas - de arte a programação. Aproveita que você está em casa e assiste alguns dos vídeos, e depois comenta aqui os que você mais gostou de ver lá.\n","date":"18 de abril de 2020","externalUrl":null,"permalink":"/unity-video-tutorial-flappy-bird/","section":"Blog","summary":"Este tutorial chamado Making A Flappy Bird Style Game feito pela Unity esta disponível no site Unity Learn e é dividido em 10 partes. Não é um tutorial novo, foi publicado em 2006, porém existem muitas coisas interessantes nestes vídeos que ainda são bem atuais para desenvolvimento de jogos 2D na Unity, além de muitas dicas de como ser mais produtivo no editor.\n","title":"Um ótimo tutorial feito pela Unity para criar um Flappy Bird","type":"posts"},{"content":"Uma forma comum de compartilhar código, modulos e até plugins nativos sempre foi criar um package - exportar um arquivo .unitypackage para ser importado em outro projeto. É uma forma prática de distribuir conteúdo para Unity, porém tem problemas como falta de versionamento, não ter um canal de distribuição centralizado, não avisar de atualizações, permitir que seu conteúdo seja modificado ou removido, entre outros. Isso tudo, quando existia, dependia do desenvolvedor criar uma ferramenta para controlar a integridade e o versionamento do pacote.\nFelizmente, a Unity criou uma ferramenta que ajuda em todos os pontos acima e mais alguns, chamada Unity Package Manager. Para utilizá-lo, é necessário criar um projeto seguindo o padrão de package, que pode depois ser importado como um projeto local, um tarball, um repositório git, e até distribuído por npm.\nNeste post vou falar mostrar como eu fiz para criar o meu package chamado Cicanci Utils e como configurei para ele ser distribuído em um repositório público no GitHub. O conteúdo do package em si é bem básico no momento - apenas um script para enviar e receber mensagens que criei neste post. Minha ideia é adicionar mais scripts úteis neste package, sempre com algum post explicando seu funcionamento.\nCriando um package # Criar um package é bem simples, e começa com um projeto novo na Unity. Depois de criar um projeto novo, você precisa criar os seguintes arquivos, sendo que alguns são obrigatórios como o package.json e a estrutura abaixo para código e teste.\nO package.json é um arquivo com toda informação necessária sobre o pacote, e é o que vai ser exibido na janela do Package Manager. Este arquivo contém campos importantes como nome, versão do pacote, versão mínima suportada, e dependencias de outros packages. Abaixo está o exemplo do meu, que contém também dados de autor, palavras-chave e o tipo do pacote.\n{ \u0026#34;name\u0026#34;: \u0026#34;com.cicanci.unity-utils\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;1.0.0\u0026#34;, \u0026#34;displayName\u0026#34;: \u0026#34;Cicanci Utils\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;Useful pieces of code for Unity projects.\u0026#34;, \u0026#34;unity\u0026#34;: \u0026#34;2017.4\u0026#34;, \u0026#34;keyworks\u0026#34;: [ \u0026#34;library\u0026#34;, \u0026#34;utility\u0026#34;, \u0026#34;utils\u0026#34; ], \u0026#34;author\u0026#34;: { \u0026#34;name\u0026#34;: \u0026#34;Bruno Cicanci\u0026#34;, \u0026#34;email\u0026#34;: \u0026#34;bruno@cicanci.com\u0026#34;, \u0026#34;url\u0026#34;: \u0026#34;https://cicanci.com\u0026#34; }, \u0026#34;type\u0026#34;: \u0026#34;library\u0026#34; } Adicionando conteúdo # No meu caso, eu criei um package do tipo library e adicionei o código do pacote em uma pasta chamada Runtime e os testes unitários em uma outra pasta chamada Test\\Runtime. Além dos scripts, é necessário criar um arquivo asmdef para cada um desses dois diretórios. Dentro destas pastas pode ter a estrutura de namespace que você quiser.\nPara funcionar os testes eu tive que adicionar no asmdef dele uma referência para o pacote da Unity chamado Test Runner (engine e editor). Caso contrário, um erro de compilação acontece por que uma pasta com asmdef não consegue importar e usar namespaces de pacotes que não estão adicionados como referência, além da API padrão da Unity.\nPublicando no GitHub # Eu tive alguns problemas para publicar o package no GitHub e fazer ele ser reconhecido pela Unity. O primeiro problema é a estrutura, pois a Unity não reconhece como um package um projeto na raiz do repositório. Para funcionar é necessário adicionar o conteúdo do package direto na raiz do repositório, como mostrado na image abaixo.\nO segundo problema que tive, depois que resolvi a estrutura do repositório, foi com os arquivos .meta. Eu acho que não eram necessários, já que no repositório não é mais um projeto Unity. Porém, eu estava enganado e é necessário sim adicionar estes arquivos.\nEsta estrutura é bem simples, porém dificulta um pouco na hora de atualizar o pacote e publicar. A melhor maneira que encontrei foi criar um projeto na Unity e clonar o repositório dentro dele. Provavelmente existe alguma maneira melhor de manter um package publicado no GitHub, se você souber por favor comenta a baixo.\nEu publiquei como um repositório público por ser mais simples e poder realmente divulgar o package, porém também é possível configurar um repositório privado para ser usado na sua empresa ou em seus projetos, por exemplo. Não li sobre como fazer, mas li que é possível sim com alguma configuração a mais.\nImportando em seu projeto # Por fim, vamos a parte da utilização do package. É bem simples, basta abrir o Package Manager e adicionar um novo package como git URL. Você pode adicionar o link SSH ou HTTPS, ambos funcionam. No meu pacote o link é https://github.com/cicanci/cicanci-utils.git.\nDepois de importado, basta usar como normalmente é feito. Importe o namespace na sua classe e está pronto para utilizar todo conteúdo do package. Abaixo está um exemplo de uso, que também está disponível no README do repositório.\nusing Cicanci.Utils; using UnityEngine; public class MessageBehaviour : MonoBehaviour { private void Start() { MessageManager.Instance.AddListener\u0026lt;MyMessage\u0026gt;(OnMessageReceived); } private void OnDestroy() { MessageManager.Instance.RemoveListener\u0026lt;MyMessage\u0026gt;(OnMessageReceived); } private void OnMessageReceived(MyMessage message) { Debug.Log(message.Greetings); } public void SendMessage() { MyMessage message = new MyMessage { Greetings = \u0026#34;Hello, World!\u0026#34; }; MessageManager.Instance.SendMessage(message); } } public class MyMessage { public string Greetings; } Conclusão # Apesar de dar um pouco mais de trabalho para configurar do que apenas exportar seu projeto como um .unitypackage, as vantagens de utilizar o novo sistema de package é bem grande. É bem simples para outros desenvolvedores usarem seu código e conteúdo, e mais fácil para manter atualizado e organizado seguindo um padrão pré-definido pela engine.\nMeu package Cicanci Utils é bem simples e pequeno, eu criei apenas para estudar como criar e distribuir um pacote, e poder postar o resultado aqui no blog. Minha idea é adicionar mais scripts úteis neste package, junto com posts explicando o que tem de novo nele. É bom ter um lugar organizado e centralizado onde posso jogar meus scripts que uso com frequência ao invés de copiar e colar de outros projetos.\nVou deixar uma referência muito boa que é este vídeo do canal Infallible Code explicando praticamente tudo que escrevi neste post, com exceção da parte de publicá-lo no GitHub. Recomendo assistir os demais vídeos deste canal, o conteúdo é muito bom.\nO que você achou do Package Manager? Usaria em seu projeto? Se já usou e tem dicas para compartilhar, deixe um comentário abaixo.\n","date":"1 de março de 2020","externalUrl":null,"permalink":"/custom-unity-packages/","section":"Blog","summary":"Uma forma comum de compartilhar código, modulos e até plugins nativos sempre foi criar um package - exportar um arquivo .unitypackage para ser importado em outro projeto. É uma forma prática de distribuir conteúdo para Unity, porém tem problemas como falta de versionamento, não ter um canal de distribuição centralizado, não avisar de atualizações, permitir que seu conteúdo seja modificado ou removido, entre outros. Isso tudo, quando existia, dependia do desenvolvedor criar uma ferramenta para controlar a integridade e o versionamento do pacote.\n","title":"Como criar e utilizar um Unity Package","type":"posts"},{"content":"Hoje apresentei uma palestra sobre o uso de design patterns no desenvolvimento de jogos na The Developer's Conference (TDC) 2019 em Porto Alegre, na trilha de Games e Realidade Aumentada. Confira os slides da apresentação no post.\n","date":"30 de novembro de 2019","externalUrl":null,"permalink":"/palestra-tdc-porto-alegre-2019/","section":"Blog","summary":"Hoje apresentei uma palestra sobre o uso de design patterns no desenvolvimento de jogos na The Developer's Conference (TDC) 2019 em Porto Alegre, na trilha de Games e Realidade Aumentada. Confira os slides da apresentação no post.\n","title":"Palestra sobre design patterns para jogos - TDC Porto Alegre 2019","type":"posts"},{"content":"Em agosto apresentei uma palestra no evento Unity Developer Day São Paulo, junto com dois colegas da Aquiris. O conteúdo da apresentação foi sobre as otimizações que fizemos no jogo Looney Tunes World of Mayhem para resolver problemas de uso elevado de memória e CPU em dispositivos móveis.\nApesar das informações presentes nos slides, é um pouco difícil de entender ou interprestar algumas partes. Eu pensei em gravar esta apresentação, para poder explicar melhor as técnicas de otimização utilizadas. Deixem um comentário se é algo interessante para eu fazer e disponibilizar aqui.\n","date":"28 de novembro de 2019","externalUrl":null,"permalink":"/palestra-unity-dev-days-2019/","section":"Blog","summary":"Em agosto apresentei uma palestra no evento Unity Developer Day São Paulo, junto com dois colegas da Aquiris. O conteúdo da apresentação foi sobre as otimizações que fizemos no jogo Looney Tunes World of Mayhem para resolver problemas de uso elevado de memória e CPU em dispositivos móveis.\n","title":"Palestra sobre otimização para dispositivos móveis - Unity Developer Day São Paulo","type":"posts"},{"content":"Neste post adicionei uma lista atualizada dos sites que eu conheço e uso para baixar sprites e modelos para jogos. São artes de jogos já lançados e artes que podem ser utilizadas comercialmente para seu próprio jogo.\nTodo programador que não sabe nada de arte, como eu, sempre precisa de alguma imagem ou modelo para um teste técnico, protótipo ou até seu próprio jogo. É importante que, para um programador, a arte não seja uma barreira para programar, por isso estes sites são muito úteis.\nSprite Database # Conteúdo: Sprites e spritesheets de jogos desde o Atari até o Playstation 4.\nSite: http://spritedatabase.net\nThe Spriters Resource # Conteúdo: Sprites e spritesheets de jogos desde o Atari até o Playstation 3.\nSite: https://www.spriters-resource.com\nThe Models Resource # Conteúdo: Models 3D de jogos desde o Playstation 1 até o Playstation 4.\nSite: https://www.models-resource.com\nThe Models Resource # Conteúdo: Modelos 3D de jogos desde o Playstation 1 até o Playstation 4.\nSite: https://www.models-resource.com\nThe Textures Resource # Conteúdo: Texturas de jogos desde o Playstation 1 até o Playstation 3.\nSite: https://www.textures-resource.com\nThe Sounds Resource # Conteúdo: Efeitos sonoros de jogos desde o Playstation 1 até o Playstation 4.\nSite: https://www.sounds-resource.com\nGame Art 2D # Conteúdo: Sprites e spritesheets para o seu jogo (pagos e gratuitos).\nSite: https://www.gameart2d.com\nCraftpix # Conteúdo: Sprites e spritesheets para o seu jogo (pagos e gratuitos).\nSite: https://craftpix.net\nOpen Game Art # Conteúdo: Sprites e modelos 3D para o seu jogo (gratuitos).\nSite: https://opengameart.org\nUnity Asset Store # Conteúdo: Sprites e modelos 3D para o seu jogo (pagos e gratuitos).\nSite: https://assetstore.unity.com\nKenny # Conteúdo: Sprites e modelos 3D para o seu jogo (pagos e gratuitos).\nSite: https://kenney.nl/assets\nConhece algum que não está a lista? Deixe um comentário abaixo pra eu poder incluir aqui.\n","date":"11 de novembro de 2019","externalUrl":null,"permalink":"/download-sprites-jogos/","section":"Blog","summary":"Neste post adicionei uma lista atualizada dos sites que eu conheço e uso para baixar sprites e modelos para jogos. São artes de jogos já lançados e artes que podem ser utilizadas comercialmente para seu próprio jogo.\n","title":"Sites para baixar sprites e modelos de jogos - atualizado!","type":"posts"},{"content":"Este é o segundo post da série com dicas para teste técnico utilizando Unity e C#. No primeiro post, o foco foi como organizar o projeto para facilitar seu desenvolvimento, e como enviar após o término. Agora, vamos falar um pouco de código, cobrindo um dos erros comuns que vejo em testes técnicos, especialmente relacionado a API da Unity.\nNesta série de posts sobre dicas para teste técnico, o assunto código vai ser bem recorrente, mas não vamos deixar de lado tópicos relacionados a configuração da engine, e features que podemos usar sem necessariamente escrever código pra isso. A Unity possui diversas ferramentas, e meu objetivo aqui vai ser sempre ajudar a evitar alguns erros comuns e mostrar o que é interessante demonstrar em um teste técnico nesta engine.\nUso do GetComponent na Unity # Meu objetivo não é falar para usar ou não usar uma determinada chamada da API da Unity, mas sim mostrar o lugar ideal para colocá-la quando utilizada. Vamos começar por uma das mais comuns: GetComponent, utilizado para buscar um componente, de um tipo específico, no gameObject. O GetComponent possui algumas variações, como: GetComponents, para retornar uma lista de um tipo; o GetComponentInParent, que busca no pai do gameObject; e o GetComponentInChildren, que busca no filho do gameObject. Estes dois últimos também possuem uma variação para retornar uma lista do tipo desejado.\nVamos para alguns exemplos e, nos códigos a seguir, imagine que o script está em um gameObject na scene. No código abaixo, você consegue identificar qual é o problema?\npublic class MyGame : MonoBehaviour { private void Awake() { GetComponent\u0026lt;SpriteRenderer\u0026gt;().enabled = false; } } Neste exemplo, estamos buscando o componente SpriteRenderer e assumindo que ele existe para, logo em seguida, mudar o valor de uma propriedade sua. Se o componente não existir, vamos gerar um NullReferenceException logo no Awake() do MonoBehaviour. Vamos modificar um pouco o código para corrigir isso.\npublic class MyGame : MonoBehaviour { private void Awake() { if(GetComponent\u0026lt;SpriteRenderer\u0026gt;() != null) { GetComponent\u0026lt;SpriteRenderer\u0026gt;().enabled = false; } } } Parece mais seguro agora, não? Evitamos o uso do NullReferenceException, mas ainda tem algo que não é o ideal ali. Estamos usando duas vezes a chamada do GetComponent(), podemos reduzir para uma chamada com a modificação abaixo.\npublic class MyGame : MonoBehaviour { private void Awake() { var spriteRenderer = GetComponent\u0026lt;SpriteRenderer\u0026gt;(); if(spriteRenderer != null) { spriteRenderer.enabled = false; } } } Podemos, também, garantir que o objeto vai ter um determinado script anexado usando o RequireComponent, assim não precisamos verificar se o componente existe.\n[RequireComponent(typeof(SpriteRenderer))] public class MyGame : MonoBehaviour { private void Awake() { var spriteRenderer = GetComponent\u0026lt;SpriteRenderer\u0026gt;(); spriteRenderer.enabled = false; } } Voltando um pouco, vamos falar agora o que o GetComponent faz por trás da chamada. O código C# da Unity está no seu GitHub para ser usado como referência, assim fica fácil de ver o que alguma determinada API faz. Não é o código inteiro da engine, apenas a parte C#, mas já ajuda muito a aprender o que cada API faz. No caso, o GetComponent faz isso:\npublic unsafe T GetComponent\u0026lt;T\u0026gt;() { var h = new CastHelper\u0026lt;T\u0026gt;(); GetComponentFastPath(typeof(T), new System.IntPtr(\u0026amp;h.onePointerFurtherThanT)); return h.t; } Não precisa ser muito experiente em C# para ver que existem duas alocações ali, um CastHelper e um System.IntPtr, além do que o GetComponentFastPath() deve executar no código C++ da Unity (essa parte não está disponível para consulta). Não é muita coisa, e não é algo que vai fazer muita diferença de performance, mas podemos evitar o uso do GetComponent em alguns casos, como o exemplo abaixo, onde a variável é recebida pelo Inspector, e podemos até usar o GetComponent caso ela não seja referenciada no gameObject.\npublic class MyGame : MonoBehaviour { [SerializeField] private SpriteRenderer _spriteRenderer = null; private void Awake() { if(_spriteRenderer == null) { _spriteRenderer = GetComponent\u0026lt;SpriteRenderer\u0026gt;(); } _spriteRenderer.enabled = false; } } A modificação acima não vai fazer muita diferença, o GetComponent é rápido o suficiente pra não causar problemas de performance. Porém, com base em tudo que escrevi neste post, o código abaixo não é recomendado. É um caso exagerado onde queremos garantir que o SpriteRenderer esteja desabilitado por qualquer motivo, usando um Update() para a validação.\npublic class MyGame : MonoBehaviour { private void Update() { if(!GetComponent\u0026lt;SpriteRenderer\u0026gt;().enable) { GetComponent\u0026lt;SpriteRenderer\u0026gt;().enable = true; } } } O código acima, em um projeto médio/grande, pode causar alguns problemas de performance, especialmente se esse padrão estiver espalhado pelo projeto e a plataforma algo for Android ou iOS. Aparelhos mais antigos podem ter uma redução no FPS ou apresentar algumas travadas rápidas em transições. Então, sempre que possível, faça cache do GetComponent.\nO post ficou um pouco longo, mas espero que eu tenha conseguido mostrar algumas maneiras de usar o GetComponent e, principalmente, recomendações do que deve ser evitado. Tudo isso é analisado em um teste técnico, independente do tamanho do projeto, pois ajuda a entender como o programador pensar e o quanto conhece da Unity, a game engine em questão. Deixei passar algo no post? Usa o GetComponent de alguma mandeira diferente? Comenta abaixo, sempre temos muito o que aprender, por isso compartilhar sempre acrescenta.\n","date":"14 de outubro de 2019","externalUrl":null,"permalink":"/dicas-teste-tecnico-unity-2/","section":"Blog","summary":"Este é o segundo post da série com dicas para teste técnico utilizando Unity e C#. No primeiro post, o foco foi como organizar o projeto para facilitar seu desenvolvimento, e como enviar após o término. Agora, vamos falar um pouco de código, cobrindo um dos erros comuns que vejo em testes técnicos, especialmente relacionado a API da Unity.\n","title":"Dicas para teste técnico com Unity #2","type":"posts"},{"content":"O canal no YouTube Code Monkey tem diversos vídeos muito bons sobre desenvolvimento de jogos, com uma ótima didática e bem resumidos. O autor do canal é um programador, que já publicou alguns dos seus jogos no Steam e, através do seu canal, compartilha tudo que já usou para fazer seus jogos utilizando Unity e C#.\nNo site do Code Monkey estão todos os seus vídeos, como no YouTube, e algum conteúdo extra, como seu pacote Code Monkey Utilities, com diversos scripts muito úteis para acelearar o desenvolvimento de jogos na Unity, e também é usado em seus vídeos.\nVou listar alguns vídeos que gostei abaixo, não deixei de conferir o seu canal no YouTube para ver mais conteúdo. Outro canal muito bom, que já indiquei aqui no blog, é o Brackeys.\n","date":"4 de outubro de 2019","externalUrl":null,"permalink":"/youtube-unity-code-monkey/","section":"Blog","summary":"O canal no YouTube Code Monkey tem diversos vídeos muito bons sobre desenvolvimento de jogos, com uma ótima didática e bem resumidos. O autor do canal é um programador, que já publicou alguns dos seus jogos no Steam e, através do seu canal, compartilha tudo que já usou para fazer seus jogos utilizando Unity e C#.\n","title":"Canal no Youtube com tutorials em Unity","type":"posts"},{"content":"O Humble Bundle é um site que vende bundles (pacotes) com jogos ou livros digitais pelo preço que você quiser pagar, e ainda permite escolher dividir seu pagamento entre caridade e/ou para o desenvolvedor. Este mês ele fez uma parceria com a Unity e lançou um bundle contendo recursos e ferramentas da Asset Store, um curso do GameDevHQ, e 1 ano de acesso aos cursos do Unity Learn Premium.\nA soma total de todo conteúdo do bundle é de mais de $1000 dólares, e você pode pagar apenas $15 dólares por tudo isso (valor mínimo para pegar tudo). Só os cursos do Unity Learn Premium já valem o preço e, além disso, alguns assets e ferramentas do pacote são essenciais para agilizar o desenvolvimento de um projeto ou até fazer um protótipo para testar uma ideia.\nVou colocar abaixo alguns vídeos de assets e ferramentas contidos nesse bundle, como: Eazy Mobile Pro, praticamente tudo que você precisa para um jogo mobile (IAP, Ads, Login, etc); DoozyUI, para fluxos de UI; Aura 2, que possui efeitos incríveis de luz; e o famoso PlayMaker, uma ferramenta de visual scripting para Unity.\nO Humble Bundle Unity vai até o dia 14 de Outubro. Se você está começando a estudar Unity, recomendo pegar pelos cursos. Se você já tem experiência, recomendo pelos cursos e assets. Considerando a cotação do dólar de hoje esse bundle me custou R$70, um valor muito baixo pela quantidade de conhecimento e assets de qualidade incluídos no pacote. No lugar de comprar aquele jogo em promoção no Steam, aproveite para aprimorar seu conhecimento em Unity.\n","date":"30 de setembro de 2019","externalUrl":null,"permalink":"/unity-humble-bundle/","section":"Blog","summary":"O Humble Bundle é um site que vende bundles (pacotes) com jogos ou livros digitais pelo preço que você quiser pagar, e ainda permite escolher dividir seu pagamento entre caridade e/ou para o desenvolvedor. Este mês ele fez uma parceria com a Unity e lançou um bundle contendo recursos e ferramentas da Asset Store, um curso do GameDevHQ, e 1 ano de acesso aos cursos do Unity Learn Premium.\n","title":"Humble Bundle Unity com cursos, ferramentas e assets","type":"posts"},{"content":"Parte do meu trabalho na Aquiris é avaliar testes e realizar entrevistas técnicas com candidatos. Nos últimos anos aplicando testes, percebi que existe um padrão de erros básicos que, infelizmente, são comuns até para Senior Programmers. Este será o primeiro de uma série com dicas e sugestões do que fazer e não fazer em um teste técnico, focando Unity e C#.\nQuando uma empresa de jogos pede para um candidato realizar um teste técnico utilizando Unity, pode ser algo desde criar um jogo do zero, corrigir ou expandir um projeto existente. A qualidade do código também é avaliada, mas parte do teste consiste em ver o conhecimento do candidato em desenvolvimento de jogos, boas práticas, organização e conhecimento na própria engine em questão. Antes de falar de assuntos mais técnicos, vamos começar com um bem simples: como enviar o teste.\nMelhores práticas para enviar o resultado de um teste técnico # Submeter o teste técnico feito na Unity não é simplesmente zipar toda a pasta do projeto e enviar. Isso requer não enviar algumas pastas e arquivos, o que também é avaliado por demonstrar conhecimento da estrutura básica da Unity e boas práticas de organização do projeto. Um projeto Unity, basicamente, é composto pelas seguinte pastas:\nAssets: Onde fica o projeto em si Packages: JSON com as dependências do projeto ProjectSettings: Configuração do projeto Qualquer outra pasta além destas não é necessário adicionar, isso é o mínimo para rodar qualquer projeto Unity. Nunca inclua a pasta Library, ela não é necessária para rodar o jogo e aumenta muito o tamanho do projeto. Se um zip contém mais de 1MB, eu ja suspeito que esta pasta, desnecessária para o projeto, foi incluída.\nSe você utilizar um repositório git em um servíco como o GitHub (recomendo), na criação do repositório é possível escolher iniciar o repositório com um arquivo .gitignore com a configuração da Unity para ignorar qualquer arquivo e pasta desnecessária.\nOutras recomendações são sempre criar o repositório como privado, já que é um teste técnico para uma vaga, e marcar a opção de adicionar o arquivo README. Neste arquivo inclua toda e qualquer informação relevante sobre o projeto, como rodar o jogo e detalhes que sejam relevantes para o teste técnico. Use este arquivo para documentar o que for necessério, assim todas informações ficarão junto ao projeto/repositório, e não perdidas em um arquivo externo ou em um e-mail.\nConfigurando o repositório corretamente, além de facilitar o seu desenvolvimento, vai simplificar a submissão, pois você precisa apenas baixá-lo como zip e enviar. Isso é importante, envie como zip. Quem vai revisar o teste técnico pode estar usando um macOS e não precisa ser obrigado a baixar um app pra descompactar rar ou outro formato diferente.\nPor fim, após ter o seu arquivo zip enxuto, envie por e-mail e compartilhe através do Google Drive ou similares, assim a pessoa que receber o seu teste técnico vai ter mais de uma maneira de baixá-lo caso tenha algum problema. Enviar o resultado é uma tarefa simples, mas você ganhará pontos em se preocupar com estes detalhes.\nPor mais que o tempo para fazer o teste técnico seja curto, você não levará mais do que alguns minutos para configurar o projeto e deixar tudo pronto para uma submissão tranquila, então falta de tempo não é desculpa para enviar o resultado do teste de qualquer jeito.\nGostou dessa dica? Comente abaixo compartilhando sua experiência realizando testes técnicos para vagas em desenvolvmento de jogos. No próximo post vou abortar um erro comum relacionado a programação e uso das APIs da Unity.\n","date":"25 de setembro de 2019","externalUrl":null,"permalink":"/dicas-teste-tecnico-unity-1/","section":"Blog","summary":"Parte do meu trabalho na Aquiris é avaliar testes e realizar entrevistas técnicas com candidatos. Nos últimos anos aplicando testes, percebi que existe um padrão de erros básicos que, infelizmente, são comuns até para Senior Programmers. Este será o primeiro de uma série com dicas e sugestões do que fazer e não fazer em um teste técnico, focando Unity e C#.\n","title":"Dicas para teste técnico com Unity #1","type":"posts"},{"content":"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.\nAté 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.\nGame Design\nMinha 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.\nDepois 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.\nProgramação\nDecidi 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.\nOutro 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.\nArte\nNã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.\nConclusão\nApesar 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.\n","date":"4 de maio de 2019","externalUrl":null,"permalink":"/ludum-dare-44/","section":"Blog","summary":"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.\n","title":"Minha participação no Ludum Dare #44","type":"posts"},{"content":"Semana passada realizei uma palestra sobre carreira na indústria de games, com foco em programação de jogos, no Senac de Porto Alegre. Foram 2h conversando e tirando dúvidas sobre como é trabalhar desenvolvendo jogos, foi uma ótima oportunidade de compartilhar minha experiência de quase 9 anos na indústria.\nMuito obrigado pelo convite e pela oportunidade de apresentar este conteúdo!\n","date":"30 de abril de 2019","externalUrl":null,"permalink":"/palestra-senac-porto-alegre/","section":"Blog","summary":"Semana passada realizei uma palestra sobre carreira na indústria de games, com foco em programação de jogos, no Senac de Porto Alegre. Foram 2h conversando e tirando dúvidas sobre como é trabalhar desenvolvendo jogos, foi uma ótima oportunidade de compartilhar minha experiência de quase 9 anos na indústria.\n","title":"Minha palestra sobre carreira no Senac Porto Alegre","type":"posts"},{"content":"Hoje começa a edição de número 44 da game jam Ludum Dare, uma ótima chance de desenvolver um jogo em um final de semana sozinho ou com amigos e adicionar um projeto em seu portfólio.\nEscrevi este post com algumas dicas sobre o que fazer e o que não fazer para se preparar antes e durante uma game jam, e vou deixar a parte mais importante aqui:\nNa semana do Ludum Dare o tema escolhido sai de uma lista com algumas opções, é bom pensar no que pode ser feito pra cada tema e estar preparado.\nEscolha a linguagem de programação, framework ou game engine antes de começar e tenha certeza de que tudo está atualizado para não perder tempo esperando downloads.\nEsteja confortável com a tecnologia escolhida e faça alguns tutoriais se não estiver confiante que consegue fazer um jogo em pouco tempo com ela.\nVai ser necessário criar arte e som, então já se prepare antecipadamente para isso (mesmo que você ache que não vai dar tempo, se prepare pois vai que dá).\nSe você tem dificuldade em se concentrar, não deixe a TV ligada e evite YouTube, tente ouvir trilha sonoras ou músicas que você gosta.\nParece bobo mas planeje como serão suas refeições, e tente não sair pra comer pois isso pode te custar um tempo precioso. E café!\nPlaneje o que fazer em caso de falta de internet e/ou falta de energia elétrica, é sempre bom ter um plano B e um lugar pra ir (algo tipo Starbucks, por exemplo).\nConfira aqui as minhas participações anteriores. O ludum dare acontece a cada 4 meses e dura apenas 48 horas (fazendo o jogo sozinho) ou 72 horas (fazendo o jogo em grupo), e eu recomendo muito participar. O objetivo é fazer um jogo simples (no tema mais votado) e se divertir!\nImagem da capa: https://ldjam.com/events/ludum-dare/44/$140885/ludum-dare-44-wallpaper-thread\n","date":"26 de abril de 2019","externalUrl":null,"permalink":"/esta-semana-comeca-o-ludum-dare-44/","section":"Blog","summary":"Hoje começa a edição de número 44 da game jam Ludum Dare, uma ótima chance de desenvolver um jogo em um final de semana sozinho ou com amigos e adicionar um projeto em seu portfólio.\n","title":"Esta semana começa o Ludum Dare #44","type":"posts"},{"content":"Quando comecei este blog tinha acabado de me formar em Ciência da Computação e iniciado uma pós-graduação em Produção e Programação de Games. Na época fiquei em dúvida e quase escolhi fazer Engenharia de Software, porém decidi arriscar por que sempre tive interesse em jogos e computação gráfica. Foi uma escolha bem feliz, e 10 anos depois consegui construir minha carreira nesta indústria tão pequena, grande, lenta e rápida - é tudo ao mesmo tempo.\nMeu primeiro post no blog, iniciado no Wordpress, foi um misto de coragem e ingenuidade. Eu não fazia ideia do que esperar, tinha acabado de me formar e conseguido um bom emprego como Analista de Sistemas, mas estava disposto a arriscar uma mudança na minha carreira em uma indústria que eu estava apenas começando a conhecer suas barreiras e dificuldades.\nEu sempre corri atrás do que quis, nada veio fácil, mas admito que eu estava no lugar certo e na hora certa. Comecei a pós-graduação em 2009, quando ainda não existiam estúdios indies contratando no Brasil, porém empresas grandes como Gameloft, Ubisoft, Electronic Arts e Glu estavam por aqui fazendo jogos. Duraram pouco tempo, mas tive uma oportunidade incrível de fazer parte da história da Glu e da EA no Brasil.\nMinha carreira na indústria de jogos começou no meio de 2010, quando estava no final da pós-graduação e tinha uma boa ideia do que era necessário para desenvolver um game. Quase 9 anos depois reconheço que o blog me ajudou bastante na minha trajetória. Conheci muitas pessoas da indústria, participei de eventos, e também gosto de pensar que ajudei algumas pessoas que entraram em contato com dúvidas sobre como trabalhar nesta indústria tão conhecida e tão fechada.\nNestes anos o que mais me motivou a continuar com o blog foram os e-mails e comentários que sempre recebi, elogiando meu trabalho e cheios de perguntas que sempre gostei muito de responder. Quando comecei o blog estava perdido, e se não fosse a pós-graduação teria ficado perdido o até desistido de tentar entrar nesta indústria. Com os anos fui aprendendo muitas coisas, e sempre tive vontade de compartilhar meu conhecimento para que outras pessoas ficassem menos perdidas.\nConfesso que, apesar de não desistir do blog, eu nunca fui muito constante. O gráfico abaixo mostra meu número de postagens nestes 10 anos. Eu gostaria muito de fazer a barrinha de 2019 ficar acima dos 40 posts, e tentar trazer minha frequência perto dos números de posts que escrevi entre 2012 e 2016, vamos ver se consigo.\nEu queria muita fazer algum tipo de comemoração para estes 10 anos. Isso é algo que pensei em fazer nos últimos 2 anos, mas apesar de várias ideias não coloquei nada em prática. Parte disso foi por que esse ano só escrevi 1 post em 4 meses (2 se contar este), e não senti que o blog estava em um clima de comemoração. Eu quero e preciso voltar a escrever com frequência aqui, continuar compartilhando minhas experiências, mas ainda não sei como.\nUm terço da minha vida até agora foi ao lado desse blog, meu companheiro que tenho negligenciado. Parece que perdi algo nos últimas anos, e ainda não encontrei. Não quero me forçar a escrever por escrever, por isso preciso desse algo para continuar a escrever. Muito obrigado a todos leitores que fizeram e fazem parte da história do blog, cada um de vocês é muito importante pra mim e para o blog, e é o que me faz querer continuar escrevendo. Até o próximo post, e que venham mais 10 anos!\n","date":"24 de abril de 2019","externalUrl":null,"permalink":"/10-anos/","section":"Blog","summary":"Quando comecei este blog tinha acabado de me formar em Ciência da Computação e iniciado uma pós-graduação em Produção e Programação de Games. Na época fiquei em dúvida e quase escolhi fazer Engenharia de Software, porém decidi arriscar por que sempre tive interesse em jogos e computação gráfica. Foi uma escolha bem feliz, e 10 anos depois consegui construir minha carreira nesta indústria tão pequena, grande, lenta e rápida - é tudo ao mesmo tempo.\n","title":"10 anos","type":"posts"},{"content":"No meu post Comparando delegates e Unity Events o leitor Carlos Roger fez um comentário pergutando sobre versionamento de aquivos grandes no Git, e deixou como sugestão um post sobre o assunte. Neste post vou descrever como projetos Unity podem tirar vantagem do Git Large File System (LFS).\nA ideia por trás do LFS é armazenar arquivos grandes como audio, textura, vídeo, PSD, entre outros, em um servidor remoto. No repositório do Git cada arquivo armazenado no LFS se torna um arquivo texto com informações sobre onde está o arquivo real no LFS. A vantagem disso é que estes arquivos não contam para o tamanho do repositório, deixam o git clone e git fetch mais rápidos, e os arquivos podem ter até alguns gigas de tamanho (não recomendado, mas pode).\nO LFS tem um arquivo de configuração próprio chamado .gitattributes que faz o track de arquivos que devem ficar no armazenamento externo ao repositório. Este arquivo pode fazer track de arquivos por nome, mas o idea é fazer por extensão de arquivo. Assim, todo arquivo novo daquele tipo já vai para o LFS automaticamente usando o mesmo comando git add que os arquivos no repostório.\nCopiei o exemplo abaixo do site do Git LFS. O primeiro bloco instala o LFS no repositório, adiciona a extensão PSD para entrar automaticamente no LFS, e por fim adiciona o arquivo gerado por este comando no Git. A primeira e terceira linhas são necessárias apenas na primeira vez que está configurando o LFS, depois só é necessário adicionar os arquivos no track do LFS.\ngit lfs install git lfs track \u0026#34;.psd\u0026#34; git add .gitattributes Uma vez que o LFS está configurado, é só utilizar os comandos do Git para adicionar arquivos de fazer push deles no repositório. É neste momento que o LFS substitui o arquivo por um texto e sobe o arquivo real para o armazenamento externo ao repositório.\ngit add file.psd git commit -m \u0026#34;Add design file\u0026#34; git push origin master Não existe muito mistério, é bem simples de utilizar. Porém, vale a pena descrever alguns detalhes. Por padrão o LFS não é instalado junto com o Git, é necessário baixar o instalador para Windows ou utilizar o Homebrew para MacOS (existem outras formas, mas recomendo essa). Softwares como Sourcetree instalam o LFS junto com o Git, não sendo necessário rodar os comandos do LFS mas é sempre bom conhecer como funcionam.\nOutro detalhe é que, após realizar um git clone, é necessário rodar o git lfs install para que o Git possa baixar os arquivos reais localmente (isso não é automático). É bem comum esquecer de iniciar o LFS e não conseguir rodar o projeto por que os arquivos reais não foram baixados. Para isso, é necessário rodar os comandos git lfs fetch e git lfs pull, após iniciar o LFS.\nUma conta gratuíta no GitHub e no Bitbucket te dão direito a 1GB de armazenamento no seus respectiveos servidores LFS, e isso não conta para o tamanho do repositório. Mas, dependendo do tamanho do projeto, 1GB é muito pouco. Em ambos serviços é possível comprar armazenamento extra por um valor mensal, sendo $5 dólares por 50GB adicionais no GitHub e $10 dólares por 5GB no Bitbucket.\nPara projetos médios e grandes com muitos arquivos pesados é recomendado utilizar o LFS e contratar o espaço extra necessário. Como o GitHub agora tem repositórios privados gratuitos ilimitados, ele tem o melhor custo benefício.\nOutra dica que vou deixar neste post é utilizar o .gitignore do GitHub para projetos Unity. É possível adicionar este arquivo automaticamente na hora de criar um repositório novo no GitHub, com na imagem abaixo.\nO .gitignore do GitHub, junto com o LFS, é tudo que você precisa para manter seu projeto Unity bem organizado, junto com a utilização do modelo de desenvolvimento git-flow.\n","date":"11 de fevereiro de 2019","externalUrl":null,"permalink":"/unity-git-lfs/","section":"Blog","summary":"No meu post Comparando delegates e Unity Events o leitor Carlos Roger fez um comentário pergutando sobre versionamento de aquivos grandes no Git, e deixou como sugestão um post sobre o assunte. Neste post vou descrever como projetos Unity podem tirar vantagem do Git Large File System (LFS).\n","title":"Git e LFS em projetos Unity","type":"posts"},{"content":"No meu vídeo sobre um padrão para enviar mensagens na Unity utilizando delegate tive um comentário perguntando se não seria melhor utilizar o UnityEvents por questões de performance. Eu respondi o comentário dizendo que não era um problema tão grande, até por que o envio de mensangens não é algo que quero fazer o tempo todo, mas fiquei pensando sobre outro ponto que comentei em relação a flexibilidade. Decidi fazer este post comparando o código do meu post com o UnityEvents.\nVocê pode ver o código completo da classe MessageManager no meu post, mas vou postar um dos métodos aqui para ficar mais fácil de escrever sobre ele. Este é o SendMessage(), responsável por executar o DynamicInvoke, que usa reflection para resolver o tipo do delegate e aloca memória pra isso. Neste link do StackOverflow existe uma boa explicação comparando o DynamicInvoke com o Invoke, porém para a minha classe MessageManager precisei utilizá-lo sacrificando um pouco de performance por mais flexibilidade, além de deixar o código mais claro.\npublic void SendMessage(object message) { List\u0026lt;Delegate\u0026gt; messages = null; if(_listeners.TryGetValue(message.GetType(), out messages)) { for(int i = 0; i \u0026lt; messages.Count; i++) { messages[i].DynamicInvoke(message); } } } Para comparar com o UnityEvents criei duas classes de teste, uma para chamar ele e o MessageManager uma vez por Update e outra para escutá-los. Para deixar o resultado mais limpo no profiler eu enviei sempre o mesmo objeto que foi criado no Awake da classe.\npublic static UpdateTestEvent TestEvent; private UpdateTestData _updateTestData; private void Awake() { TestEvent = new UpdateTestEvent(); _updateTestData = new UpdateTestData { Counter = 1 }; } private void Update() { MessageManager.Instance.SendMessage(_updateTestData); TestEvent.Invoke(_updateTestData); } UpdateTestEvent e UpdateTestData são uma struct e um UnityEvent, respectivamente. Ambos MessageManager e UnityEvents enviam o mesmo objeto.\npublic struct UpdateTestData { public int Counter; } public class UpdateTestEvent : UnityEvent\u0026lt;UpdateTestData\u0026gt; { } E abaixo está o resto do código, responsável por adicionar e remover os listeners. Eu não adicionar todo do código pra não deixar o post ainda maior, mas o que falta abaixo é só a parte que soma Counter em outra variável e mostrar isso em um Text na UI.\nprivate void OnEnable() { MessageManager.Instance.AddListener\u0026lt;UpdateTestData\u0026gt;(OnUpdateTestMessage); TestSender.TestEvent.AddListener(OnUpdateTestEvent); } private void OnDisable() { MessageManager.Instance.RemoveListener\u0026lt;UpdateTestData\u0026gt;(OnUpdateTestMessage); TestSender.TestEvent.RemoveListener(OnUpdateTestEvent); } private void OnUpdateTestMessage(UpdateTestData message) { } public void OnUpdateTestEvent(UpdateTestData message) { } Agora vamos o resultado do profiler. Eu marquei dois momentos em que há a chamada do GC.Alloc, o primeiro é relacionado ao DynamicInvoke, e o segundo não consegui entender da onde veio mas está relacionado ao SendMessage() também, alocando um total de 68 bytes por cada vez que o MessageManager é usado para enviar um objeto e demora 0.03 milisegundos. Já o UnityEvents não está alocando nada de memória extra e nem demora para ser executado.\nEntão isso quer dizer que o UnityEvents é o melhor para este caso? Depende. Evitar usar um delegate com DynamicInvoke para enviar um objeto como mensagem de vez em quando não vai causar impacto suficiente para reduzir o uso de memória ou aumentar o FPS do seu jogo. Neste exemplo, e no exemplo do meu vídeo, o uso do UnityEvents é praticamente o mesmo que o MessageManager, então seria um bom caso para evitar o DynamicInvoke desnecessário.\nEu não consegui pensar em um exemplo onde o meu código se encaixaria melhor do que o UnityEvents, mas como escrevi no outro post meu objetivo era mostrar uma implementação do design patter Observer. É importante entender como os padrões funcionam para saber qual pode ser útil em uma determinada situação, mesmo que seja para usar uma \u0026quot;solução pronta\u0026quot; como o UnityEvents.\n","date":"9 de setembro de 2018","externalUrl":null,"permalink":"/unity-events/","section":"Blog","summary":"No meu vídeo sobre um padrão para enviar mensagens na Unity utilizando delegate tive um comentário perguntando se não seria melhor utilizar o UnityEvents por questões de performance. Eu respondi o comentário dizendo que não era um problema tão grande, até por que o envio de mensangens não é algo que quero fazer o tempo todo, mas fiquei pensando sobre outro ponto que comentei em relação a flexibilidade. Decidi fazer este post comparando o código do meu post com o UnityEvents.\n","title":"Comparando delegates e Unity Events","type":"posts"},{"content":"Em quase 2 anos trabalhando na Aquiris não pude falar sobre o jogo que estava desenvolvendo, que não era o Horizon Chase Turbo como muitos me perguntaram. Hoje posso finalmente compartilhar este projeto gigantesco chamado Looney Tunes World of Mayhem, que sai em breve para Android e iOS.\nEste jogo, desenvolvido em parceria com a publisher norte americana Scopely e a Warner Bros., está sendo um aprendizado enorme para toda equipe e em todas as áreas. Eu nunca tinha trabalhado em um projeto tão grande, tão longo e com tanta gente ao mesmo tempo.\nJá está disponível o pré-registro no Google Play para baixar o jogo assim que sair. Até a hora que escrevi este post tinha saído uma notícia no IGN Brasil e no site Variety, lá alguns detalhes sobre o jogo.\nPor enquanto é isso que posso escrever, mas só de poder compartilhar qual é o projeto e divulgar o pré-registro já me deixa bem feliz. Um projeto desse tamanho e complexidade é um desafio enorme e novo pra muita gente na equipe, e todos nós estamos aprendendo muito com ele. Não vejo a hora do Looney Tunes ser lançado e ver pessoas jogando ele por ai!\n#somoslooney\n","date":"16 de agosto de 2018","externalUrl":null,"permalink":"/aquiris-looney-tunes/","section":"Blog","summary":"Em quase 2 anos trabalhando na Aquiris não pude falar sobre o jogo que estava desenvolvendo, que não era o Horizon Chase Turbo como muitos me perguntaram. Hoje posso finalmente compartilhar este projeto gigantesco chamado Looney Tunes World of Mayhem, que sai em breve para Android e iOS.\n","title":"O que estou fazendo na Aquiris? Looney Tunes World of Mayhem!","type":"posts"},{"content":"Semana que vem começa a edição de número 42 da game jam Ludum Dare. Sempre recomendo participar de game jams, e esta em especial é a minha favorita pela sua simplicidade e frequencia. As vezes o tema escohido não é dos melhores, mas ainda assim te ajuda a pensar em um jogo criativo.\nNovamente não vou participar, não me programei com antecedência e vou ter uma viagem no fim de semana do LD, que também é dia dos pais. Vou deixar abaixo a lista de dicas que sempre coloco nos posts sobre Ludum Dare, que também podem ser aplicadas em outras game jams e sempre tento atualizar esta lista e adicionar novas dicas.\nNa semana do Ludum Dare o tema escolhido sai de uma lista com algumas opções, é bom pensar no que pode ser feito pra cada tema e estar preparado.\nEscolha a linguagem de programação, framework ou game engine antes de começar e tenha certeza de que tudo está atualizado para não perder tempo esperando downloads ou configurando seu computador.\nEsteja confortável com a tecnologia escolhida e faça alguns tutoriais se não estiver confiante que consegue fazer um jogo em pouco tempo com ela.\nVai ser necessário criar arte e som, então já se prepare antecipadamente para isso baixando os softwares necessários (mesmo que você ache que não vai dar tempo, se prepare pois vai que dá).\nSe você tem dificuldade em se concentrar, não deixe a TV ligada e evite YouTube, tente ouvir trilha sonoras ou músicas que você gosta mas que não tirem seu foco.\nParece bobo mas planeje como serão suas refeições, e tente não sair pra comer pois isso pode te custar um tempo precioso. E café!\nPlaneje o que fazer em caso de falta de internet e/ou falta de energia elétrica, é sempre bom ter um plano B e um lugar pra ir (algo tipo Starbucks, por exemplo).\nFazer um planejamento rápido das tarefas pode ser bem útil, utilizando Trello ou até papel e post-its, mas cuidado para não perder muito tempo detalhando as tarefas.\nConfira aqui as minhas participações anteriores. O ludum dare acontece a cada 4 meses e dura apenas 48 horas (fazendo o jogo sozinho) ou 72 horas (fazendo o jogo em grupo), e eu recomendo muito participar. O objetivo é fazer um jogo simples (no tema mais votado) e se divertir!\n","date":"30 de julho de 2018","externalUrl":null,"permalink":"/proxima-semana-comeca-o-ludum-dare-42/","section":"Blog","summary":"Semana que vem começa a edição de número 42 da game jam Ludum Dare. Sempre recomendo participar de game jams, e esta em especial é a minha favorita pela sua simplicidade e frequencia. As vezes o tema escohido não é dos melhores, mas ainda assim te ajuda a pensar em um jogo criativo.\n","title":"Na próxima semana começa o Ludum Dare #42","type":"posts"},{"content":"Recentemente voltei a estudar Inteligência Artificial (I.A.), mais específicamente Machine Learning, e acabei encontrando este framework chamado Accord.NET que por ser desenvolvido com .NET é compatível com a game engine Unity.\nEu estudei I.A. na minha graduação e na pós-graduação, mas em ambos não saí muito da teoria. Até implementei algo para trabalhos nessas matérias, mas lembro que foram bem básicos. Um tempo depois eu fiz um curso online chamado Introdução à Inteligência Artificial, em uma plataforma que depois se tornou o Udacity. O curso ainda existe lá (em Inglês), e eu recomendo bastante pra quem quer rever o básico de I.A. ou ter um primeiro contato. Quando fiz ele tinha duração de 2 meses se não me engano, hoje ele dura 4 meses e deve ser mais completo.\nMas, mesmo depois deste curso, nunca parei para implementar algo relevante. Nas últimas semanas voltei a me interessar pelo assunto que comecei a pesquisar frameworks para implementar soluções envolvendo I.A. e encontrei este framework chamado Accord.NET. Por ser compatível com a Unity me animei a tentar fazer um jogo com alguma mecânica simples que envolva Machine Learning.\nPor enquanto estou apenas estudando e entendendo como utilizar o Accord.NET. No seu repositório no GitHub existem exemplos para Unity, mas sem saber o que eles fazem ou usam do framework não tem muito sentido ainda pra mim. Para integração com a Unity existe este guia, que é necessário mesmo para rodar os exemplos que estão no projeto.\nNo site do Accord.NET existe bastante informação interessante, como a página de exemplos que tem muita coisa legal feita com o framework, e a página de Getting Started que mostra o básico do framework e possui links para conteúdos mais avançados. Existem também mais de 100 artigos acadêmicos publicados que utilizaram o Accord.NET.\nAlém de Machine Learning este framework também possui métodos para Estatística, Visão Computacional e Processamento de Imagem, e pode ser utilizado com Windows, Xamarin, Unity, aplicações desktop, Linux e mobile. Eu estou começando a me familiarizar com o Accord.NET, e assim que possível quero fazer um post ou até um vídeo monstrando como fazer algum exemplo na Unity.\n","date":"10 de junho de 2018","externalUrl":null,"permalink":"/accord-net-framework/","section":"Blog","summary":"Recentemente voltei a estudar Inteligência Artificial (I.A.), mais específicamente Machine Learning, e acabei encontrando este framework chamado Accord.NET que por ser desenvolvido com .NET é compatível com a game engine Unity.\n","title":"Accord.NET: framework para Machine Learning compatível com Unity","type":"posts"},{"content":"No começo de um projeto na Unity é comum adicionarmos referências de outros objetos em um mesmo MonoBehaviour, como um campo de texto que precisa ser atualizado. Porém, quando maior o projeto fica, mais díficl é manter todos scripts que tem referência atualizados, sem falar que é muito fácil quebrar uma referência dessas. Uma solução para isso é desacoplar o máximo possível componentes que não precisam conhecer outros para realizar seu objetivo, e enviar mensagens é um padrão de desenvolvimento que pode ajudar muito nesse caso.\nNo video eu começo com um exemplo simples de um projeto que tem dois botões que interagem com o mesmo componente de texto, e o problema é que o script que cuida do inventário do jogador não precisa ter a responsabilidade de atualizar a UI também. Para resolver este problema, e desacoplar a UI do inventário do jogador, eu removo essa dependência utilizando um sistema de enviar e receber mensagens através do MessageManager.\nComo mencionei no vídeo, este padrão de enviar mensagens lembra o Observer mas com algumas diferenças. O script abaixo é uma versão simplificada do que encontrei no framework Frictionless.\nusing System; using System.Collections.Generic; public class MessageManager { private readonly Dictionary\u0026lt;Type, List\u0026lt;Delegate\u0026gt;\u0026gt; _listeners; private static MessageManager _instance; public static MessageManager Instance { get { return _instance ?? (_instance = new MessageManager()); } } private MessageManager() { _listeners = new Dictionary\u0026lt;Type, List\u0026lt;Delegate\u0026gt;\u0026gt;(); } public void SendMessage(object message) { List\u0026lt;Delegate\u0026gt; messages = null; if(_listeners.TryGetValue(message.GetType(), out messages)) { for(int i = 0; i \u0026lt; messages.Count; i++) { messages[i].DynamicInvoke(message); } } } public void AddListener\u0026lt;T\u0026gt;(Action\u0026lt;T\u0026gt; message) { List\u0026lt;Delegate\u0026gt; messages = null; if(_listeners.TryGetValue(typeof(T), out messages)) { messages.Add(message); } else { messages = new List\u0026lt;Delegate\u0026gt; { message }; _listeners.Add(typeof(T), messages); } } public void RemoveListener\u0026lt;T\u0026gt;(Action\u0026lt;T\u0026gt; message) { List\u0026lt;Delegate\u0026gt; messages = null; if(_listeners.TryGetValue(typeof(T), out messages)) { messages.Remove(message); } } } Espero que o audio tenha ficado melhor neste vídeo, também editei algumas partes dele para ficar mais fluído, algo que não tinha feito nos dois anteriores. Se você gostou do vídeo e quer mais conteúdo neste formato deixe seu comentário aqui ou no vídeo, e se inscreva no canal para ser notificado quando novos vídeos forem adicionados. Qualquer dúvida ou sugestão para outros vídeos fique a vontade para comentar!\n","date":"2 de junho de 2018","externalUrl":null,"permalink":"/unity-message-manager/","section":"Blog","summary":"No começo de um projeto na Unity é comum adicionarmos referências de outros objetos em um mesmo MonoBehaviour, como um campo de texto que precisa ser atualizado. Porém, quando maior o projeto fica, mais díficl é manter todos scripts que tem referência atualizados, sem falar que é muito fácil quebrar uma referência dessas. Uma solução para isso é desacoplar o máximo possível componentes que não precisam conhecer outros para realizar seu objetivo, e enviar mensagens é um padrão de desenvolvimento que pode ajudar muito nesse caso.\n","title":"Novo vídeo: Enviando mensagens na Unity","type":"posts"},{"content":"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.\nO 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.\nNas ú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.\nAcho 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.\nFaz 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.\n","date":"17 de maio de 2018","externalUrl":null,"permalink":"/ludum-dare-41/","section":"Blog","summary":"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.\n","title":"Minha não participação no Ludum Dare #41","type":"posts"},{"content":"Na próxima sexta-feira começa a edição de número 41 da game jam Ludum Dare, uma ótima chance de desenvolver um jogo em um final de semana sozinho ou com amigos e adicionar um projeto em seu portfólio.\nEsta seria minha décima participação, mas provavelmente eu não vou conseguir desenvolver um jogo durante a game jam por que esqueci completamente que seria na próxima semana e vou viajar. Talvez eu consiga fazer algo bem simples dependendo do tema, mas baseado nas minhas últimas participações que eu falhei mesmo tendo tempo não me sinto confiante desta vez.\nEscrevi este post com algumas dicas sobre o que fazer e o que não fazer para se preparar antes e durante uma game jam, e vou deixar a parte mais importante aqui:\nNa semana do Ludum Dare o tema escolhido sai de uma lista com algumas opções, é bom pensar no que pode ser feito pra cada tema e estar preparado.\nEscolha a linguagem de programação, framework ou game engine antes de começar e tenha certeza de que tudo está atualizado para não perder tempo esperando downloads.\nEsteja confortável com a tecnologia escolhida e faça alguns tutoriais se não estiver confiante que consegue fazer um jogo em pouco tempo com ela.\nVai ser necessário criar arte e som, então já se prepare antecipadamente para isso (mesmo que você ache que não vai dar tempo, se prepare pois vai que dá).\nSe você tem dificuldade em se concentrar, não deixe a TV ligada e evite YouTube, tente ouvir trilha sonoras ou músicas que você gosta.\nParece bobo mas planeje como serão suas refeições, e tente não sair pra comer pois isso pode te custar um tempo precioso. E café!\nPlaneje o que fazer em caso de falta de internet e/ou falta de energia elétrica, é sempre bom ter um plano B e um lugar pra ir (algo tipo Starbucks, por exemplo).\nConfira aqui as minhas participações anteriores. O ludum dare acontece a cada 4 meses e dura apenas 48 horas (fazendo o jogo sozinho) ou 72 horas (fazendo o jogo em grupo), e eu recomendo muito participar. O objetivo é fazer um jogo simples (no tema mais votado) e se divertir!\n","date":"13 de abril de 2018","externalUrl":null,"permalink":"/esta-semana-comeca-o-ludum-dare-41/","section":"Blog","summary":"Na próxima sexta-feira começa a edição de número 41 da game jam Ludum Dare, uma ótima chance de desenvolver um jogo em um final de semana sozinho ou com amigos e adicionar um projeto em seu portfólio.\n","title":"Esta semana começa o Ludum Dare #41","type":"posts"},{"content":"Paragon é um MOBA desenvolvido pela Epic Games que será fechado em abril deste ano. Hoje, durante a GDC 2018, a Epic disponibilizou boa parte dos assets do jogo de graça no Unreal Engine Marketplace.\nSegundo o site da Unreal Engine, a Epic disponibilizou 20 personagens com qualidade AAA, incluindo animações, VFX, voice over e skins, além de 1.500 assets usados nos cenários do jogo. O desenvolvido destes assets custou $12 milhões de dólares e podem ser usado de graça, e mais assets de personagens vão ser disponibilizados nos próximos meses.\nApesar do jogo não ter sido um sucesso achei incrível a Epic colocar esses assets de graça no marketplace, uma solução melhor do que deixar eles no esquecimento e ainda deve incentivar desenvolvedores e estudantes a experimentarem a Unreal Engine com assets de um jogo lançado para PC e consoles. Se ficou curioso para ver a qualidade dos assets, dá uma olhada no treiler do jogo abaixo que foi anunciado em 2015 (até a música é épica).\nFaz muito tempo que eu quero fazer algo com a Unreal além de seguir um tutorial, e com esses assets confesso que fiquei tentado a começar um projeto com a engine.\n","date":"19 de março de 2018","externalUrl":null,"permalink":"/unreal-paragon-assets/","section":"Blog","summary":"Paragon é um MOBA desenvolvido pela Epic Games que será fechado em abril deste ano. Hoje, durante a GDC 2018, a Epic disponibilizou boa parte dos assets do jogo de graça no Unreal Engine Marketplace.\n","title":"Epic disponibiliza assets do jogo Paragon no marketplace da Unreal Engine","type":"posts"},{"content":"Sabe quando um jogador te diz um erro aconteceu com ele, mas você não consegue reproduzir por que não tem informação do que o jogo está fazendo naquele momento? Não seria ainda melhor ver este error sem ter que esperar um jogador reclamar dele? Neste video vou mostrar como utilizar o Unity Analytics para eventos customizados e como podemos pegar um erro que está acontecendo no jogo e enviar para o analytics.\nNeste vídeo explico como capturar mensagens que são enviadas para o console da Unity, como filtrar para pegar apenas os tipo de log desejado, e como enviar isso para o Unity Analytics utilizando Custom Event. Utilizei o analytics da Unity por que ele já está na próxima engine e não precisa ser importado no projeto, é necessária apenas uma configuração bem simples também mostrada no vídeo.\nO código abaixo é praticamente tudo que é necessário para enviar erros customizados para o analytics da Unity, e precisa apenas ser adicionado a um GameObject em uma scene. Apesar do exemplo ser com o serviço da Unity, qualquer outro analytics pode ser utilizado, e o que mudaria no código abaixo é apenas método HandleError.\nusing System.Collections; using System.Collections.Generic; using UnityEngine; using UnityEngine.Analytics; public class AnalyticsManager : MonoBehaviour { private void Awake() { Application.logMessageReceived += DelegateLog; } private void OnDestroy() { Application.logMessageReceived -= DelegateLog; } private void DelegateLog(string message, string StackTraceLogType, LogType type) { if(type == LogType.Error) { HandleError(message); } } private void HandleError(string message) { Dictionary\u0026lt;string, object\u0026gt; extras = new Dictionary\u0026lt;string, object\u0026gt;(); extras.Add(\u0026#34;message\u0026#34;, message); Analytics.CustomEvent(\u0026#34;game_error\u0026#34;, extras); } } Este é apenas meu segundo vídeo e espero que tenha sido útil pra você, e se não ainda viu assita o prímero vídeo sobre como utlizar o profiler da Unity. Qualquer dúvida, sugestão ou crítica deixe um comentário aqui no post ou no vídeo, quero ouvir feedbacks pra poder gravar vídeos melhores.\n","date":"14 de março de 2018","externalUrl":null,"permalink":"/unity-analytics-custom-event/","section":"Blog","summary":"Sabe quando um jogador te diz um erro aconteceu com ele, mas você não consegue reproduzir por que não tem informação do que o jogo está fazendo naquele momento? Não seria ainda melhor ver este error sem ter que esperar um jogador reclamar dele? Neste video vou mostrar como utilizar o Unity Analytics para eventos customizados e como podemos pegar um erro que está acontecendo no jogo e enviar para o analytics.\n","title":"Novo vídeo: Eventos customizados para analytics de erros na Unity","type":"posts"},{"content":"Não parece que fazem 9 anos desde que escrevi este post começando o blog. Mas sempre que decido mudar layout ou a tecnologia usada nele, e tenho que revisar todos os 330 posts, ai sim vejo o quanto fiz em quase uma década trabalhando na indústria de games e tentando manter o blog atualizado. Também vejo onde falhei e o quanto ainda quero fazer pela minha carreira e pelo blog, que me ajudou a abrir muitas portas.\nNesses anos eu mudei muito minha maneira de pensar sobre diversos assuntos relacionados a desenvolvimento de jogos e a indústria, mas mesmo assim deixo os posts antigos com minhas opiniões antigas pra eu perceber essas mudanças e ver como eu era idiota hahaha. 9 anos e 330 posts parecem números grandes pra mim, mas já deixei de postar tantas coisas por aqui e sei que este número poderia ser muito maior. As desculpas pra isso foram variadas: falta de tempo, falta de planejamento, falta de inspiração, falta de vontade e falta de ânimo.\nMas sempre voltei a publicar posts e melhorar o blog por que, por mais que eu tenha bloqueios, receber um e-mail ou um comentário de alguém elogiando um post ou até contando que segue o blog há anos e de alguma maneira eu consegui ajudar esta pessoa não tem preço pra mim. Eu nem imaginava algo assim quando comecei o blog, queria compartilhar o que eu estava aprendendo e conhecendo na indústria por que não encontrei muita coisa sobre isso em português quando comecei. Com o tempo percebi que eu estava realmente ajudando pessoas que estavam passando pelo mesmo problema: falta de informação.\nFelizmente hoje existem outros blogs, sites e podcasts sobre o assunto, e cada vez mais pessoas tem acesso a informações sobre a área de desenvolvimento de games no Brasil e fora do país, e isso está ajudando muita gente que achava que trabalhar com jogos era algo impossível. Fico feliz em fazer parte disso, e esse é o meu maior incentivo para continuar e investir mais tempo no blog. Nunca quis usar o blog para me mostrar, mas sim para compartihar conhecimento, e vou continuar fazendo isso por muito tempo!\nQuem me indicou este novo esse layout, que é um tema para o Jekyll, foi o Baldi do GGDevCast, que também está fazendo sua parte com os demais integrantes do podcast. E isso é o que todos que trabalham na área precisam fazer: compartilhar conhecimento.\nAno que vem o blog e minha carreira em games fazem 10 anos, isso é 1/3 da minha vida. Esta atualização de layout é uma das coisas que estava preparando para que esta data seja especial, e este é apenas o início. Meu canal no YouTube começou tímido mas logo vou publicar mais vídeos sobre desenvolvimento de jogos. Muito obrigado por acompanhar meu blog, seja por anos ou minutos, isso significa muito pra mim.\nA imagem da capa sou eu navegando pelo Guaíba por que não fazia ideia do que colocar neste post, mas o leme é de mentira.\n","date":"11 de março de 2018","externalUrl":null,"permalink":"/9-anos-novo-layout/","section":"Blog","summary":"Não parece que fazem 9 anos desde que escrevi este post começando o blog. Mas sempre que decido mudar layout ou a tecnologia usada nele, e tenho que revisar todos os 330 posts, ai sim vejo o quanto fiz em quase uma década trabalhando na indústria de games e tentando manter o blog atualizado. Também vejo onde falhei e o quanto ainda quero fazer pela minha carreira e pelo blog, que me ajudou a abrir muitas portas.\n","title":"9 anos de blog e novo layout","type":"posts"},{"content":"Eu arrisco dizer que esta é a primeira vez que recebo um postmortem de um jogo lançado no Steam pelo Greelight, pelo menos lançado quando recebi o postmortem. Where's my helmet? é um jogo desenvolvido pelo Mega Boss Game Studio, e no texto abaixo há um pouco sobre o desenvolvimento do jogo que foi lançado em 2016. Senti falta de compartilhar detalhes sobre o lançamento do jogo no Steam, mas acredito que o postmortem foi mais focado no desenvolvido do que na publicação. Leiam também os outros postmortems postados aqui no blog.\nWhere’s​ ​My​ ​Helmet?​ ​é​ ​um​ ​jogo​ ​de​ ​plataforma​ ​inspirado​ ​nos​ ​antigos​ ​clássicos. Porém​ ​ele​ ​traz​ ​uma​ ​mecânica​ ​diferenciada,​ ​que​ ​permite​ ​que​ ​o​ ​jogador​ ​desenvolva maneiras​ ​diferentes​ ​de​ ​avançar​ ​as​ ​fases. O​ ​jogador​ ​controla​ ​Axel,​ ​um​ ​viking​ ​que​ ​teve​ ​seu​ ​capacete​ ​trocado​ ​por​ ​um​ ​boné,​ ​ele utiliza​ ​dois​ ​machados​ ​que​ ​possuem​ ​tempo​ ​de​ ​recarga​ ​ao​ ​serem​ ​arremessados,​ ​eles podem​ ​serem​ ​usados​ ​para​ ​atacar​ ​os​ ​inimigos​ ​ou​ ​como​ ​auxílio​ ​indispensável​ ​para subir​ ​nas​ ​plataformas. O​ ​jogo​ ​foi​ ​lançado​ ​para​ ​Steam​ ​em​ ​Maio​ ​de​ ​2016\nConcepção # Nós​ ​estávamos​ ​por​ ​volta​ ​de​ ​um​ ​ano​ ​e​ ​meio​ ​desenvolvendo​ ​alguns​ ​jogos​ ​menores para​ ​mobile,​ ​então​ ​resolvemos​ ​que​ ​estava​ ​na​ ​hora​ ​de​ ​fazer​ ​algo​ ​um​ ​pouco​ ​mais complexo​ ​e​ ​com​ ​mais​ ​tempo​ ​de​ ​desenvolvimento.​ ​Aproveitamos​ ​também​ ​para explorar​ ​a​ ​plataforma​ ​Steam,​ ​já​ ​que​ ​tem​ ​um​ ​público​ ​um​ ​pouco​ ​diferente​ ​e​ ​nos​ ​faria encarar​ ​o​ ​projeto​ ​com​ ​mais​ ​seriedade. Escolhemos​ ​o​ ​gênero​ ​de​ ​plataforma​ ​por​ ​ser​ ​mais​ ​amigável​ ​e​ ​possível​ ​de​ ​fazer​ ​um projeto​ ​legal​ ​com​ ​pouco​ ​recurso.\nDesenvolvimento # Começamos​ ​a​ ​prototipar​ ​como​ ​seria​ ​a​ ​mecânica​ ​de​ ​arremessar​ ​os​ ​machados, quanto​ ​tempo​ ​levaria​ ​para​ ​re-aparecerem,​ ​como​ ​seriam​ ​lançados,​ ​se​ ​funcionaria nos​ ​combates​ ​e​ ​etc. Durante​ ​esse​ ​mesmo​ ​período​ ​também​ ​foi​ ​criado​ ​um​ ​rascunho​ ​do​ ​GDD​ ​e​ ​uma concepção​ ​do​ ​personagem​ ​e​ ​do​ ​visual​ ​do​ ​jogo. Trabalhamos​ ​todos​ ​remotos​ ​e​ ​no​ ​tempo​ ​livre​ ​de​ ​cada​ ​um,​ ​fazíamos​ ​conferências semanais,​ ​e​ ​reuniões​ ​presenciais​ ​mais​ ​ou​ ​menos​ ​a​ ​cada​ ​45​ ​dias.​ ​Como​ ​já​ ​havíamos feito​ ​outros​ ​jogos​ ​juntos,​ ​o​ ​workflow​ ​funcionava​ ​bem.\nO​ ​Visual # Como​ ​o​ ​personagem​ ​utilizava​ ​machados,​ ​achamos​ ​que​ ​casaria​ ​muito​ ​bem​ ​se​ ​ele fosse​ ​um​ ​viking,​ ​e​ ​utilizássemos​ ​elementos​ ​da​ ​cultura​ ​nórdica.​ ​Porém,​ ​não queríamos​ ​que​ ​fosse​ ​apenas​ ​mais​ ​um​ ​viking,​ ​queríamos​ ​algum​ ​elemento​ ​que ajudasse​ ​a​ ​destacar​ ​o​ ​personagem​ ​e​ ​deixá​ ​lo​ ​mais​ ​cativante,​ ​e​ ​com​ ​isso​ ​veio​ ​o boné​ ​e​ ​o​ ​título​ ​Where’s​ ​my​ ​Helmet?​ ​como​ ​desculpa.\nLevel​ ​Design # Iniciamos​ ​definindo​ ​qual​ ​seria​ ​o​ ​tamanho​ ​do​ ​personagem​ ​na​ ​tela​ ​e​ ​qual​ ​a​ ​altura​ ​do seu​ ​pulo,​ ​assim​ ​ficaria​ ​mais​ ​fácil​ ​de​ ​decidirmos​ ​o​ ​tamanho​ ​dos​ ​obstáculos​ ​e​ ​onde seria​ ​necessário​ ​ou​ ​não​ ​utilizar​ ​os​ ​machados. Depois​ ​disso,​ ​o​ ​level​ ​designer​ ​criou​ ​um​ ​rascunho​ ​de​ ​uma​ ​fase​ ​para​ ​que​ ​fosse possível​ ​listarmos​ ​um​ ​pack​ ​inicial​ ​de​ ​assets​ ​de​ ​obstáculos​ ​para​ ​serem​ ​produzidos​ ​e replicados​ ​nas​ ​outras​ ​fases.\nDificuldades # Mesmo​ ​tendo​ ​feito​ ​outros​ ​jogos​ ​anteriormente,​ ​nunca​ ​havíamos​ ​feito​ ​um​ ​projeto desse​ ​tamanho,​ ​desse​ ​gênero​ ​e​ ​para​ ​essa​ ​plataforma.​ ​Isso​ ​dificulta​ ​em​ ​acertar​ ​um escopo​ ​e​ ​deadline​ ​mais​ ​correto.\nPublicação​ ​e​ ​Divulgação # Nossa​ ​principal​ ​estratégia​ ​para​ ​gerar​ ​um​ ​público​ ​antes​ ​da​ ​data​ ​do​ ​lançamento,​ ​foi divulgar​ ​desde​ ​o​ ​início​ ​algumas​ ​imagens​ ​do​ ​desenvolvimento​ ​na​ ​nossa​ ​fanpage​ ​e em​ ​grupos​ ​relacionados. A​ ​participação​ ​no​ ​Greenlight​ ​também​ ​fazia​ ​as​ ​pessoas​ ​verem​ ​o​ ​seu​ ​jogo​ ​antes​ ​do lançamento. Além​ ​disso,​ ​distribuímos​ ​algumas​ ​keys​ ​para​ ​canais​ ​do​ ​Youtube​ ​e​ ​blogs,​ ​que​ ​nos resultou​ ​alguns​ ​reviews​ ​bem​ ​interessantes.\nErros​ ​e​ ​Acertos # Playtest​:​ ​Acredito​ ​que​ ​o​ ​nosso​ ​maior​ ​erro​ ​foi​ ​não​ ​ter​ ​realizado​ ​testes​ ​externos, principalmente​ ​no​ ​início​ ​do​ ​projeto.​ ​Ficamos​ ​um​ ​pouco​ ​fechados​ ​nas​ ​nossas decisões,​ ​e​ ​não​ ​enxergamos​ ​alguns​ ​caminhos​ ​diferentes​ ​que​ ​poderiam​ ​ser seguidos.\nLevels​:​ ​Optamos​ ​por​ ​fazer​ ​um​ ​jogo​ ​mais​ ​enxuto​ ​e​ ​com​ ​poucas​ ​fases.​ ​Porém​ ​não nos​ ​atentamos​ ​que​ ​a​ ​curva​ ​de​ ​aprendizagem​ ​que​ ​o​ ​jogador​ ​deveria​ ​fazer​ ​precisava ser​ ​mais​ ​suave,​ ​e​ ​com​ ​isso​ ​alguns​ ​jogadores​ ​se​ ​frustraram​ ​muito​ ​rápido.\nRefinamento​:​ ​Nós​ ​não​ ​tínhamos​ ​muita​ ​ideia​ ​do​ ​quanto​ ​de​ ​refinamento​ ​um​ ​jogo desse​ ​tipo​ ​precisaria​ ​no​ ​final,​ ​e​ ​nem​ ​dos​ ​updates​ ​após​ ​a​ ​publicação.​ ​Optamos​ ​por encerrar​ ​o​ ​projeto​ ​na​ ​data​ ​estipulada​ ​e​ ​sacrificar​ ​um​ ​pouco​ ​de​ ​refinamento,​ ​algo​ ​que hoje​ ​em​ ​dia​ ​nos​ ​programamos​ ​melhor​ ​para​ ​essa​ ​etapa.\nPlataforma​:​ ​Desenvolver​ ​para​ ​Steam​ ​nos​ ​deu​ ​outra​ ​visão​ ​de​ ​desenvolvimento​ ​e​ ​nos ensinou​ ​muita​ ​coisa,​ ​o​ ​público​ ​dela​ ​é​ ​muito​ ​mais​ ​engajado​ ​e​ ​participativo. Além​ ​de​ ​ser​ ​muito​ ​mais​ ​rentável​ ​para​ ​nós​ ​do​ ​que​ ​a​ ​Playstore.\nMecânica​ ​e​ ​Temática​:​ ​Apesar​ ​dos​ ​problemas​ ​que​ ​tivemos​ ​em​ ​relação​ ​a​ ​dificuldade do​ ​jogo​ ​e​ ​controles,​ ​a​ ​aceitação​ ​do​ ​público​ ​em​ ​relação​ ​a​ ​mecânica​ ​principal​ ​e​ ​o visual​ ​do​ ​jogo,​ ​foram​ ​muito​ ​bem​ ​aceitas.​ ​O​ ​jogo​ ​se​ ​torna​ ​bem​ ​divertido​ ​quando​ ​o jogador​ ​entende​ ​a​ ​variedade​ ​de​ ​opções​ ​que​ ​ele​ ​tem​ ​para​ ​avançar​ ​pelas​ ​fases.\nConclusões​ ​finais # Where’s​ ​my​ ​Helmet?​ ​é​ ​um​ ​jogo​ ​que​ ​temos​ ​muito​ ​orgulho,​ ​e​ ​desenvolver​ ​para​ ​Steam nos​ ​trouxe​ ​uma​ ​grande​ ​realização​ ​pessoal​ ​e​ ​acredito​ ​que​ ​mais​ ​credibilidade. Essa​ ​experiência​ ​nos​ ​mostrou​ ​o​ ​quanto​ ​é​ ​importante​ ​o​ ​planejamento​ ​para melhorias,​ ​updates,​ ​e​ ​colher​ ​feedback​ ​do​ ​público​ ​desde​ ​o​ ​início​ ​do​ ​projeto. Este​ ​Postmortem​ ​serve​ ​justamente​ ​para​ ​que​ ​seja​ ​possível​ ​nós​ ​analisarmos​ ​o​ ​jogo como​ ​um​ ​todo,​ ​e​ ​tomar​ ​melhores​ ​decisões​ ​nos​ ​próximos​ ​projetos.​ ​Esperamos​ ​que assim​ ​como​ ​nos​ ​ajudou,​ ​te​ ​ajude​ ​de​ ​alguma​ ​forma​ ​a​ ​estruturar​ ​melhor​ ​os​ ​seus projetos​ ​e​ ​tirá​ ​los​ ​do​ ​papel​ ​de​ ​forma​ ​mas​ ​efetiva. Muito​ ​obrigado​ ​por​ ​lerem​ ​até​ ​aqui.\nInformações​ ​Gerais # Desenvolvedor​:​ ​Mega​ ​Boss​ ​Game​ ​Studio\nData​ ​de​ ​Lançamento​:​ ​Maio​ ​de​ ​2016\nPlataforma​:​ ​Steam\nTime​:​ ​3​ ​integrantes​ ​fixos​ ​mais​ ​1​ ​contribuinte\nTempo​ ​de​ ​Desenvolvimento​:​ ​6​ ​meses\nFerramentas​:​ ​Construct​ ​2,​ ​Spriter,​ ​Adobe​ ​Photoshop\nWhere’s​ ​my​ ​Helmet?:​ ​ ​https://www.facebook.com/wheresmyhelmet/\nMega​ ​Boss​ ​Game​ ​Studio: https://www.facebook.com/Mega-Boss-Game-Studio-709739855717025/ ","date":"2 de fevereiro de 2018","externalUrl":null,"permalink":"/postmortem-where-is-my-helmet/","section":"Blog","summary":"Eu arrisco dizer que esta é a primeira vez que recebo um postmortem de um jogo lançado no Steam pelo Greelight, pelo menos lançado quando recebi o postmortem. Where's my helmet? é um jogo desenvolvido pelo Mega Boss Game Studio, e no texto abaixo há um pouco sobre o desenvolvimento do jogo que foi lançado em 2016. Senti falta de compartilhar detalhes sobre o lançamento do jogo no Steam, mas acredito que o postmortem foi mais focado no desenvolvido do que na publicação. Leiam também os outros postmortems postados aqui no blog.\n","title":"Postmortem: Where's my helmet?","type":"posts"},{"content":"Há 2 anos atrás escrevi este post contando a minha mudança do Wordpress para o Ghost, e 1 ano depois escrevi este outro post contando a mudança do Ghost para Jekyll. Em ambos os casos eu hospedei o blog no GitHub Pages, um serviço gratuído e muito bom. Porém, após 2 anos utilizando comecei a esbarrar em algumas limitações, e então conheci o Netlify.\nLimitações do GitHub Pages # Eu tinha dois sites hospedados no GitHub Pages, meu blog e o meu portfólio. Para poder hospedar os dois tive que criar uma organização para o blog, pois o GitHub Pages suporta apenas um site por conta, considerando que a URL única gerada para cada site tem o login da conta como sub domínio. Este ano mudei minha conta no GitHub para poder ter repositórios privados, e decidi mudar os dois repositórios dos sites pra mesma conta. Não consegui fazer dois sites funcionarem com URLs diferentes, por que o segundo site da conta acabava ficando em um diretório dentro do site principal.\nDecidi mudar os dois sites para um respositório privado por que estou planejando mudar o layout do blog para comemorar os seus 10 anos e provavelmente vou contratar alguem pra fazer isso, e não quero que o layout tenha seu fonte disponível. Outro ponto é que eu quero fazer mudanças e testar sem que essas mudanças fiquem visíveis para quem acessar o repositório.\nOutro ponto que vai me ajudar muito na frequencia de postagens é que, embora o Jekyll não tenha agendamento de posts, eu posso criar um branch novo e abrir um Pull Request para cada post novo, e quando quiser publicar basta fazer o merge deste branch. Neste caso também não queria deixar isso público no repositório, por que muitos posts que escrevo acabam nem sendo publicados ou deixo arquivado para outro momento. Ter que sempre passar um post escrito em outro lugar para o blog me dava preguiça as vezes, então acredito que escrever com antecedência direto no repositório eu deixar como um branch vai me ajudar bastante.\nO Netlify # Pesquisando como fazer funcionar mais de uma hospedagem no GitHub Pages com URLs diferentes passei por muita coisa, como algumas configurações de DNS que até pareciam funcionar para redirecionamento, mas tudo parecia dar muito trabalho. Até pensei em juntar o blog e o portfólio no mesmo repositório, mas ia quebrar muitas URLs e causar ainda mais problemas. Em uma destas pesquisas encontrei o Netlify, e foi amor a primeira vista.\nA funcionalidade dele que me conquistou foi poder ter ilimitados sites de repositórios públicos e privados, e foi muito rápido e fácil de configurar. Ele já suporte Jekyll, igual o GitHub Pages, mas tem suporte também a outras tecnologias e dá mais flexibilidade para se fazer um site estático. Ele ainda possui um plano pago que é possível criar deploys complexos e baseados em scripts, mas o básico de atualizar o site em cada commit em um determinado branch já é mais do que o suficiente.\nAlém disso, ele também possui algo muito útil que é criar um site temporário, com uma URL temporária, pra cada Pull Request que você abrir no seu repositório. Isso permite fazer preview de posts e até de mudanças de layout sem precisar publicar, e até mandar pra alguem ver.\nEle possui suporte a configurações de DNS, e até funciona como um servidor NS, mas não consegui fazer isso funcionar direito. Fiz o básico de apontar o domínio para a URL que ele gera para o repositório e funciona muito bem. E, além de tudo isso, tem certificado SSL gratuito! Se você reparar, meu blog e meu portfólio agora são redirecionados para HTTPS.\nO GitHub Pages é muito bom e funciona sem grandes problemas para um único site, e continuo recomendando ele pra todos. Mas se você tiver 5 minutos, vale a pena configurar e testar o Netlify. Eu falei só do básico que já me atende, mas ele tem muito mais coisas legais que vou explorar com o tempo.\n","date":"1 de fevereiro de 2018","externalUrl":null,"permalink":"/ola-netlify/","section":"Blog","summary":"Há 2 anos atrás escrevi este post contando a minha mudança do Wordpress para o Ghost, e 1 ano depois escrevi este outro post contando a mudança do Ghost para Jekyll. Em ambos os casos eu hospedei o blog no GitHub Pages, um serviço gratuído e muito bom. Porém, após 2 anos utilizando comecei a esbarrar em algumas limitações, e então conheci o Netlify.\n","title":"Adeus GitHub Pages, olá Netlify","type":"posts"},{"content":"Faz um bom tempo que não publico um postmortem de um leitor aqui no blog, e desta vez é o jogo Deathfense feito pelo Lucas Meneses durante o 365 Indies Jam 2017. O texto abaixo foi postado no blog dele chamado Game Indie Developer. Leiam também os outros postmortems postados aqui no blog.\nDescrição # Deathfense é um jogo 2D para browser do gênero tower defense, onde o jogador assume o controle da Morte que deve impedir que hordas de almas fujam do submundo. O jogo consiste em uma única fase contendo 6 hordas, cada horda possuindo uma quantidade definida de almas a serem ceifadas e cada alma uma determinada quantia de hit points. Para ceifar as almas o jogador conta com três opções, o Ataque Automático que tira apenas 1 hit point, o Ataque Forte que tirar 3 hit points, porém é necessário esperar um timer de 10 segundos e por ultimo, mas não menos importante, o Especial que ceifa todas as almas que estiverem em volta da Morte, mas também é preciso esperar um timer, nesse caso de 60 segundos.\nO jogo foi desenvolvido entre os dias 15 e 25 de setembro para a 365 Indies Jam 2017 que teve como tema a frase “A morte é útil”. Ficando no rank 22 de 101 jogos onde foram avaliados jogabilidade, acabamento e fidelidade ao tema. A engine utilizada no projeto foi o Contruct 2, tendo como principal critério de escolha a facilidade e rapidez que ela oferece. A equipe foi composta por 4 integrantes, sendo eles os irmãos Gabriel e Augusto Santana que fizeram a arte e animação, Bettina Calmon que fez a musica tema e, por fim, eu, Lucas Meneses, que fiquei com o game design e a programação.\nPara conferir o jogo CLIQUE AQUI.\nPontos negativos # Movimentação\nEsse foi um ponto negativo que acabou se tornando positivo. Mas mesmo assim achei que seria interessante compartilha-lo com vocês. A ideia inicial era fazer a movimentação usando as setas do teclado com o behavior 8 Moviments.\n(Arte do personagem usada apenas para o protótipo)\nLogo percebi que a movimentação com as setas tornava o jogo um pouco lento e esse não era o objetivo. Fiz alguns testes aumentando a velocidade do personagem, mas mesmo assim sentia o gameplay travado. Fiquei uns dois dias pensando em como resolver esse problema até que me veio a ideia de usar o mouse como input invés do teclado o que deixaria o jogo mais rápido e ágil. A solução que encontrei para fazer isso foi utilizar o behavior de movimento Pathfinding, que geralmente é usado para fazer AI de inimigos que perseguem o jogador, só que no caso usei o clique do mouse como alvo para a trajetória do personagem. O resultado foi bem satisfatório e eu acredito que deixou o gameplay mais divertido.\nBalanceamento\nForam vários os motivos que fizeram o jogo não ter um polimento melhor no quesito balanceamento. O principal deles foi o fato de ter sido ‘gasto’ mais tempo do que o esperado com a programação, mais especificamente corrigindo os vários bugs que foram aparecendo. O que acarretou em um gameplay que transita do fácil para o difícil de uma forma muita brusca, podendo até mesmo frustrar o jogador.\nHordas\nO sistema de hordas foi feito usando algumas variáveis que fazem a contagem de almas ceifadas.\nA horda 1 possui 10 almas, logo ela termina e a horda 2 começa quando o placar de almas ceifadas for igual a 10. A horda 2 possui 20 almas e tem o termino quando o placar for igual a 30, porque são somadas as 10 almas da horda anterior. E assim segue até a ultima horda. O problema estava ocorrendo na horda 5, quando o placar deveria marca 200 almas, mas, por algum motivo que não sei explicar, sempre faltava uma alma fechando o placar em 199 almas. Esse resultado impedia o progresso do jogo, já que a quantidade de almas é o gatilho que aciona as hordas. A única forma que encontrei de driblar o problema foi alterando a quantidade de almas na horda 5 para 190. O bug não foi totalmente resolvido, mas pelo menos assim o jogo funciona.\nLimitações da Engine\nSem sombra de duvidas, esse foi o ponto que mais trouxe dificuldade e retrabalho ao projeto. Fazer um jogo usando apenas os 100 eventos da versão free do Construct 2 é no mínimo de se admirar. O termo Keep It Simple, Stupid nunca fez tanto sentido para mim. Tudo tinha que ser bem pensando, feito da forma mais eficiente possível para economizar os tão preciosos eventos. A ideia era fazer no mínimo 15 hordas e um boss no final, mas o máximo que consegui foram 6 hordas sem o boss. Muitas coisas tiveram que ser cortadas e as que ficaram foram alteradas para se encaixarem nas limitações impostas pela engine.\nBug na Musica\nEsse foi um erro que só percebi depois do lançamento do jogo, quando o Gabriel reclamou que a musica não estava tocando no Google Chrome e como eu uso o Vivaldi não notei esse bug. Pesquisando um pouco e conversando com algumas pessoas descobrir que o possível motivo desse problema está relacionado com o formato do arquivo de áudio, que no caso é o OGG.\nPontos Positivos # Experiencia\nÉ incrível a quantidade de conhecimento que é possível adquirir em uma game jam, ainda mais se você for um aspirante a desenvolvedor de jogos assim como eu. O tempo limitado te faz buscar soluções criativas que, talvez, não seriam possíveis em uma situação onde os prazos não fosse um problema.\nTrabalho em equipe\nFoi muito divertido e gratificante trabalhar ao lado de pessoas tão talentosas, que sem elas esse projeto não seria realidade. A comunicação entre os membros aconteceu de forma bem fácil, o que tornou o desenvolvimento mais assertivo e com menos erros.\nRealização\nVer o meu primeiro jogo publicado em uma game jam foi algo que mexeu comigo. Há mais de 2 anos venho pesquisando sobre game design, engines, metodologias, entre outras coisas, só que nunca tinha finalizado um projeto. Foram raras as ideias que viraram um protótipo, as vezes não saiam nem dos esboços inicias. Mas após concluir esse jogo me sinto muito mais confiante em prosseguir na carreira de desenvolvedor de jogos. Esse foi apenas o primeiro passo de muitos que ainda viram.\n","date":"28 de janeiro de 2018","externalUrl":null,"permalink":"/postmortem-deathfense/","section":"Blog","summary":"Faz um bom tempo que não publico um postmortem de um leitor aqui no blog, e desta vez é o jogo Deathfense feito pelo Lucas Meneses durante o 365 Indies Jam 2017. O texto abaixo foi postado no blog dele chamado Game Indie Developer. Leiam também os outros postmortems postados aqui no blog.\n","title":"Postmortem: Deathfense","type":"posts"},{"content":"Algo que sempre quis fazer mas sempre deixava pra depois que é gravar vídeos sobre desenvolvimento de jogos. Como tive um bom feedback sobre isso decidi começar, e este é o meu primeiro vídeo para o blog.\nO tema que escolhi pra começar foi como usar o Profiler da Unity para identificar e otimizar o código do jogo. É claro que esse vídeo não é um guia absoluto, eu mostrei apenas um pouco sobre a ferramenta e como identificar o que está acontecendo na chamada de Update do MonoBehaviour na Unity. É algo simples e muito útil que eu faço no meu dia-a-dia.\nMinha ideia era fazer um vídeo curto e eu juro que na minha cabeça ia ficar entre 10 e 20 minutos. Quando vi que deu mais de 40 minutos fiquei bastante surpreso por que passou muito rápido. Não editei o vídeo pra ficar mais rápido e fácil de publicar, se não ia demorar ainda mais pra eu fazer isso e não queria mais nada me impedindo de publicar.\nExistem muitos canais e vídeos ensinando desenvolvimento de jogos e Unity, por isso quis fazer algo mais informal como se eu estivesse mostrando algo pra alguém ao invés de ensinar. Eu até pulei muita coisa pra poder focar no meu objetivo que era mostrar como eu uso o Profiler.\nComentem no vídeo ou no blog se vocês gostaram desse formato, seu feedback é importante pra eu saber se estou indo no caminho certo. Ah, e façam sugestões de temas para próximos vídeos!\n","date":"20 de janeiro de 2018","externalUrl":null,"permalink":"/meu-primeiro-video-unity-profiler/","section":"Blog","summary":"Algo que sempre quis fazer mas sempre deixava pra depois que é gravar vídeos sobre desenvolvimento de jogos. Como tive um bom feedback sobre isso decidi começar, e este é o meu primeiro vídeo para o blog.\n","title":"Meu primeiro vídeo: Usando o Profiler da Unity","type":"posts"},{"content":"Esta semana quis fazer um post com uma lista de alguns videos sobre desenvolvimento de jogos que assisti recentemente e gostei bastante. Há algum tempo fiz algo parecido neste post sobre videos no YouTube, e este aqui é uma segunda lista com mais vídeos.\nVou tentar faz um post assim sempre que tiver uma lista interessante de recomendações, e como sempre recomendo acompanhar os canais da Unity e GDC no YouTube. No próximo post com sugestões vou adicionar videos de outros canais também, se tiver sugestões deixe nos comentários.\n","date":"12 de janeiro de 2018","externalUrl":null,"permalink":"/videos-gamedev-unity-gdc/","section":"Blog","summary":"Esta semana quis fazer um post com uma lista de alguns videos sobre desenvolvimento de jogos que assisti recentemente e gostei bastante. Há algum tempo fiz algo parecido neste post sobre videos no YouTube, e este aqui é uma segunda lista com mais vídeos.\n","title":"Videos de desenvolvimento de jogos da GDC e Unity","type":"posts"},{"content":"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.\nDesta 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.\nGame Design\nMinha 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:\nProduzir 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á.\nNã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.\nA 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.\nProgramação\nEsta 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.\nArte\nEste 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.\nConclusão\nPelo 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.\n","date":"7 de dezembro de 2017","externalUrl":null,"permalink":"/ludum-dare-40/","section":"Blog","summary":"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.\n","title":"Minha participação no Ludum Dare #40","type":"posts"},{"content":"Na meia noite de sexta para sábado começa o Ludum Dare #40 e minha nona participação consecutiva nesta game jam, apesar de não ter conseguido terminar meu jogo na edição anterior.\nNas minhas últimas participações eu sempre tentei usar algum framework ou engine que eu queria testar, e fazer um jogo no Ludum Dare é um bom teste. Quando não tinha tempo para tentar aprender a usar algo novo durante a game jam acabava usando Unity. Desta vez vou ter tempo, os dois dias livres para me dedicar, porém decidi utilizar a Unity por que quero focar em fazer um jogo bom e maior do que os anteriores.\nNeste post eu dei algumas dicas sobre o que fazer e o que não fazer para se preparar antes e durante esta game jam, vale a pena a leitura. Outra sugestão que dou, e que tenho feito nas minhas últimas participações, é olhar para a lista final de temas e já começar a pensar no que eu faria para cada tema, assim fico preparado quando o tema final for revelado no início da game jam. Abaixo está a lista final de temas para esta edição, um deles será o escolhido:\nFloating islands The more you have, the worse it is A single resource Limited space Expanding You are not the main character Tiny machines Only three colors Broken world Start with nothing You control the scenario, not the character One level, but constantly changing Death is useful One minute Into the unknown Everything is connected Confira aqui as minhas participações anteriores. O ludum dare acontece a cada 4 meses e dura apenas 48 horas (fazendo o jogo sozinho) ou 72 horas (fazendo o jogo em grupo), e eu recomendo muito participar. O objetivo é fazer um jogo simples (no tema mais votado) e se divertir!\n","date":"29 de novembro de 2017","externalUrl":null,"permalink":"/esta-semana-comeca-o-ludum-dare-40/","section":"Blog","summary":"Na meia noite de sexta para sábado começa o Ludum Dare #40 e minha nona participação consecutiva nesta game jam, apesar de não ter conseguido terminar meu jogo na edição anterior.\n","title":"Esta semana começa o Ludum Dare #40","type":"posts"},{"content":"Conheço a Unity desde 2009, quando estava no meu primeiro ano da pós-graduação, mas só fui trabalhar com ela profissionalmente em 2014 na 2Mundos. Já utilizei Unity em freelas, game jams, projetos pessoais e para trabalhos na faculdade, participei de todos eventos da Unity que foram realizados em São Paulo nos últimos anos, o Unite, assisto com frequência videos de palestras no YouTube e já li alguns livros e artigos sobre desenvolvimento de jogos com Unity. Hoje trabalho na Aquiris, uma das maiores referências em Unity no mundo, inclusive fizeram a demo para a Unity 3 que foi a versão que usei em 2009. E depois de tantos anos e experiências, ainda não sei nada de Unity.\nTrabalhar na Aquiris me dá a oportunidade de aprender cada vez mais sobre desenvolvimento de jogos e Unity com pessoas que tem muita experiência no assunto. Toda semana estou aprendendo algo novo, simples ou não, e isso me motivou a escrever mais sobre o assunto aqui no blog. A Unity é uma ótima game engine, e costumo recomendar para todo iniciante começar por ela.\nNesta série de posts sobre Unity não vou falar da engine em si ou por que usar ela, mas sim focar em algumas coisas simples que fazem diferença no seu uso, seja você iniciante ou não. Tudo que vou escrever aqui é baseado nas minhas experiências, e pode ser um pouco diferente do que você viu por ai.\nO método Awake\nO Awake está em todo MonoBehaviour, faz parte do lifecycle da Unity e é executado apenas uma vez enquanto o script ou seu GameObject não for destruído. Diferente do Start que é executado quando um objeto é habilitado, o Awake é um método de inicialização e sua execução acontece um frame antes da interface ser exibida. Por este motivo, o Awake, quando utilizado, deve ser breve e sem chamadas que podem demorar e fazer o seu jogo ficar esperando por uma resposta para continuar.\nMuitas coisas inicializadas no Awake geralmente não precisam estar lá, podem ser movidas para o Start ou até mesmo para dentro de um método específico para a situação. Inicializar código no Awake não é ruim, e não vai melhorar absurdamente a performance do jogo, mas é uma boa prática que pode fazer seu jogo ter menos travadas em inicializações de cenas ou objetos. Isto também ajuda a você repensar se todas variáveis inicializadas no Awake realmente precisam ser globais pra classe ou se podem ser locais no método que são utilizadas. Quando é necessário fazer o cache da variável, sempre verifique se ela já foi inicializada, e caso contrário faça isso onde é necessário (se for possível tirar do Awake).\nPrimeira scene do jogo\nJá vi muitos jogos (muitos mesmo) que tem tudo em uma única scene. Um dos pontos negativos disso em projetos com equipes grandes é que a chance de dar conflitos quando duas pessoas alteram a scene é muito grande, mas uma vantagem é que depois do loading da scene todo jogo flui sem precisa carregar nada (considerando que todos prefabs estão na scene). A decisão de qual abordagem utilizar depende muito do jogo, mas o que eu quero compartilhar aqui é que a mesmo com uma única scene, uma boa prática é ter uma scene vazia com apenas um script que vai chamar a scene principal do jogo.\nQuando seu jogo é carregado, parte do load é a Unity inicializando a engine antes de chamar sua scene. Por este motivo, se a sua primeira scene for muito grande (e ainda tiver muita coisa no método Awake), o load do seu jogo vai demorar mais do que deveria. Por este motivo, é uma boa prática criar uma scene vazia com apenas um script, que sua única função é chamar outra scene. Assim como no tópico anterior, isto não vai solucionar todos seus problemas, mas é uma boa prática que vai ajudar a fazer seu jogo inicializar melhor. É importante que este script e a scene não inicie nada, seu único objetivo é realmente ser carregado rápido o suficiente pra apenas chamar a próxima scene, que pode ser uma tela de loading ou seu jogo inteiro.\nGuias de melhores práticas da Unity\nA Unity tem um serviço premium que, quando uma empresa solicita, ela envia um engenheiro para analisar o jogo e ajudar a solucionar problemas que a equipe de desenvolvimento está enfrentando, e até a mostrar problemas que eles nem perceberam. Após uma visita dessas, a Unity envia um relatório para a empresa com informações sobre o que podem melhorar. E, em muitos casos, parte desses relatórios viram guias de melhores práticas e são publicados no site da Unity em Best practice guides.\nComo estes guias são gerados a partir de revisões de projetos de empresas grandes, eles podem ter conteúdo muito técnico e avançado. Atualmente existem conteúdos publicados para melhores práticas em otimização, física, loading de assets e otimizações de UI. Eu recomendo que leiam estes guias, porém não comecem a implementar tudo que está lá por que muitas vezes não se aplicam a sua situação atual, mas são técnicas úteis de conhecer quando você estiver em uma situação parecida.\nEstude, mas não coloque tudo em prática\nOs guias de melhores práticas possuem muita informação útil, mas não caia na armadilha de querer fazer tudo que está lá. Parte do processo de aprendizagem é parar e pensar se você realmente precisa daquilo no seu jogo antes de escrever código sem parar. Além dos guias, a Unity também tem uma ótima área no site com tutoriais para iniciantes, que também podem ser usadas ou não em seu jogo. Também recomendo os vídeos do canal da Unity e do canal Brackeys.\nMelhores práticas para jogos 2D\nEscrevi estes três posts há muito tempo sobre melhores práticas para jogos 2D na Unity. Na época eu estava na 2Mundos, a Unity não tinha sua UI nativa, então utilizei o plugin NGUI. Apesar de datados, estes posts possuem informações relevantes e que ainda podem ser aplicadas hoje em dia:\nMelhores práticas para 2D na Unity - Parte 1 Melhores práticas para 2D na Unity - Parte 2 Melhores práticas para 2D na Unity - Parte 3 Meu objetivo com esta nova série de posts sobre Unity é compartilhar minha experiência profissional na engine. Não vou prometer uma frequência regular, mas vou postar sempre que possível. Tenho uma lista de assuntos que quero discutir aqui, e vou sempre postar poucos para que eu possa escrever mais sobre eles. Qualquer dúvida, crítica ou sugestão fique a vontade para deixar um comentário aqui.\n","date":"6 de setembro de 2017","externalUrl":null,"permalink":"/unity-melhores-praticas-1/","section":"Blog","summary":"Conheço a Unity desde 2009, quando estava no meu primeiro ano da pós-graduação, mas só fui trabalhar com ela profissionalmente em 2014 na 2Mundos. Já utilizei Unity em freelas, game jams, projetos pessoais e para trabalhos na faculdade, participei de todos eventos da Unity que foram realizados em São Paulo nos últimos anos, o Unite, assisto com frequência videos de palestras no YouTube e já li alguns livros e artigos sobre desenvolvimento de jogos com Unity. Hoje trabalho na Aquiris, uma das maiores referências em Unity no mundo, inclusive fizeram a demo para a Unity 3 que foi a versão que usei em 2009. E depois de tantos anos e experiências, ainda não sei nada de Unity.\n","title":"Melhores práticas na Unity #1","type":"posts"},{"content":"No quinto episódio do podcast GAMEDEV BR entrevistamos o artista técnico Juliano \u0026quot;Juca\u0026quot; Silveira, que trabalha na Aquiris. Na conversa perguntamos sobre sua carreira, seu projeto pessoal Nebula Wander, e o que é um artista \u0026quot;teco\u0026quot;.\nUma das coisas que mais falamos foi sobre Shaders, algo que conheço bem pouco mas está na minha lista de coisas para estudar faz um bom tempo. Este é o episódio com conteúdo mais técnico até agora, e recomendo dar uma olhada nos links que colocamos na página do podcast para aprender mais sobre o assunto.\nClique aqui para ouvir\nEle também está disponível no iTunes, procurem por GAMEDEVBR. Como sempre, qualquer crítica e sugestões são sempre bem vindas, e obrigado pelo apoio!\n","date":"17 de agosto de 2017","externalUrl":null,"permalink":"/podcast-gamedevbr-005-artista-teco/","section":"Blog","summary":"No quinto episódio do podcast GAMEDEV BR entrevistamos o artista técnico Juliano \"Juca\" Silveira, que trabalha na Aquiris. Na conversa perguntamos sobre sua carreira, seu projeto pessoal Nebula Wander, e o que é um artista \"teco\".\n","title":"GAMEDEV BR: 005 Artista \"Teco\"","type":"posts"},{"content":"","date":"17 de agosto de 2017","externalUrl":null,"permalink":"/categories/podcasts/","section":"Categorias","summary":"","title":"Podcasts","type":"categories"},{"content":"Muita gente que quer trabalhar com jogos durante a faculdade tem a ideia de tentar fazer um jogo como trabalho de conclusão de curso (TCC), e eu digo tentar por que dependendo da faculdade e do curso podem não aceitar que este projeto seja um jogo, em muitos casos por falta de conhecimento dos professores e orientadores.\nExistem também os cursos de desenvolvimento de jogos, onde este é o objetivo principal do curso, porém isto também pode esbarrar na falta de conhecimento de professores e orientadores, e quem paga o preço são os alunos que começam o curso querendo fazer um MMORPG e terminam sem conseguir fazer um PONG.\nA indústria de jogos no Brasil é pequena, e a parcela de profissionais que também dão aulas é ainda menor. Por este motivo é bem comum que em cursos de desenvolvimento de jogos apenas parte dos professores tenham feito um jogo. E eu digo feito no sentido de fazer e publicar, e ver como é difícil este processo para poder transmitir esta experiência em aula, poder mostrar seus erros e acertos na carreira.\nQuando fiz meu jogo para o TCC da pós-graduação, o Oniro, eu escrevi este post contando sobre o início do projeto e quais eram minhas dúvidas, principalmente em relação a tecnologia. Eu quase escolhi algo que não conhecia para fazer o jogo, uma linguagem de programação e um framework/engine que nunca tinha usado mas que estava na moda, e eu quase cometi este erro. No fim acabei escolhendo utilizar o que eu tinha mais segurança e conhecimento para fazer o jogo, que foi XNA e C#, e isso me deu tempo para focar em realmente fazer um jogo ao invés de aprender a programar em outra linguagem. Eu tive a sorte de perceber isso sozinho, principalmente por que fiz a mesma escolha na graduação e usei C# para o TCC pelo mesmo motivo, e este é o tipo de ajuda que um orientador com experiência em desenvolvimento de jogos pode dar para alunos iniciantes.\nDurante o desenvolvimento do meu TCC eu consegui entrar em uma empresa de jogos, a Glu, e tive que dividir meu pouco tempo livre entre continuar o TCC e estudar o que estava usando no trabalho (J2ME). Se eu tivesse escolhido usar C++ e SDL, por exemplo, que eram ambas coisas novas pra mim, eu não teria feito nem metade do jogo, ou pelo menos não com a qualidade que queria. No meu post sobre o término do TCC, coloquei as coisas que deram certo e as que não deram, e usar algo que eu conhecia foi o que deu mais certo. Outra coisa que coloquei lá é que, como não tinha um artista pra me ajudar, usei sprites que encontrei na internet pra fazer o jogo, sem me preocupar em fazer arte ou procurar alguém pra fazer, e isso deu tão certo que eu estava com o jogo pronto 1 mês antes da entrega, e passei este 1 mês atualizando a arte, som e interface do jogo. Esta é outra dica que não me deram, e que me ajudou muito a não ficar parado sem ter arte pra fazer o jogo.\nExistem mais coisas que deram errado: cobrar que parte da entrega do TCC fosse um plano de negócios detalhando como seria feita a empresa, custos, etc. Na minha opinião isso é algo inútil, pois é muito raro um jogo feito durante o TCC, por alunos sem experiência, ter a qualidade para ser publicado. O resultado é que muitos, e eu também, fizemos isso de qualquer jeito só pela nota e para \u0026quot;agradar\u0026quot; o professor da disciplina. Isto foi há 7 anos atrás, e ainda hoje é difícil fazer alunos e professores entenderem o que é fazer jogos.\nSeu primeiro projeto é para você aprender a fazer um jogo, entender todos os desafios e obstáculos, e ver se é isso que você realmente quer. Colocar na cabeça de alunos que este projeto pode ser lançado no final do curso e que podem ganhar dinheiro com isso é muito errado, e isso causa mais casos de desistência do que de sucesso. Falo isso tudo por experiência, por tudo que vi nesses 7 anos trabalhando na indústria de jogos. É muito melhor ter um jogo simples mas bem polido do que algo grande demais que não vai ficar pronto a tempo ou vai ficar muito ruim, e este é o trabalho que muitos orientadores não fazem: orientar. Ao invés disso o projeto se torna um trabalho para agradar o orientador, a banca e a faculdade.\nFazer jogos é difícil, por isso você precisa escolher isso pelos motivos certos, motivos que te animem a acordar cedo e se dedicar a aprender e fazer uma experiência que outras pessoas vão querer jogar. Escrevi este post ano passado com uma pergunta, Por que você faz ou quer fazer jogos?, e são coisas assim que pra mim estão muito acima de querer fazer jogos para ganhar dinheiro, e é isso que falta ser ensinado. Menos empreendedorismo com falsas esperanças, mais jogo como arte e forma de expressão.\nImagem da capa: Angry man using bazooka do Shutterstock.\n","date":"13 de agosto de 2017","externalUrl":null,"permalink":"/jogo-para-tcc/","section":"Blog","summary":"Muita gente que quer trabalhar com jogos durante a faculdade tem a ideia de tentar fazer um jogo como trabalho de conclusão de curso (TCC), e eu digo tentar por que dependendo da faculdade e do curso podem não aceitar que este projeto seja um jogo, em muitos casos por falta de conhecimento dos professores e orientadores.\n","title":"Projeto de jogo para TCC","type":"posts"},{"content":"E chegou ao fim mais um Ludum Dare, e minha oitava participação nesta game jam teve uma novidade: eu falhei.\nO 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).\nNeste link você pode baixar o meu jogo incompleto para Android e MacOS, e também ver seu código fonte no GitHub.\nGame Design\nA ideia do jogo foi baseada na primeira parte da raid \u0026quot;Crota's End\u0026quot; do Destiny, chamada \u0026quot;The Abyss\u0026quot; (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.\nA 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.\nNa página do jogo classifiquei ele como \u0026quot;não terminado\u0026quot;, 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 é \u0026quot;empurrado\u0026quot; pelos tiros.\nProgramação\nEscolhi 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.\nEscolher 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.\nArte\nAcredite 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.\nConclusão\nEu 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 \u0026quot;não terminado\u0026quot;.\nDaqui 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.\n","date":"1 de agosto de 2017","externalUrl":null,"permalink":"/ludum-dare-39/","section":"Blog","summary":"E chegou ao fim mais um Ludum Dare, e minha oitava participação nesta game jam teve uma novidade: eu falhei.\n","title":"Minha participação no Ludum Dare #39","type":"posts"},{"content":"Na próxima sexta-feira começa o Ludum Dare #39, e esta vai ser ser minha oitava participação seguida nesta game jam. Na última participação não tive muito tempo sobrando para fazer um jogo e acabei escolhendo usar Unity, a tecnologia que eu uso no meu dia-a-dia, para poder pelo menos fazer um protótipo e demonstrar uma mecânica dentro do tema.\nDesta vez estou pensando em utilizar Corona, um framework para desenvolvimento mobile que utiliza a linguagem de programação Lua. Já utilizei Corona para fazer alguns protótipos e projetos pessoais há um tempo e é bem fácil de usar e conseguir um resultado rápido. Estava vai ser a segunda vez que vou utilizar Lua em um Ludum Dare, na edição #35 fiz um jogo utilizando Defold, e de todas as minhas participações foi o jogo com o maior conteúdo que fiz para uma game jam (apesar de ter falhas no game design e não ter ficado divertido de jogar). Uma boa dica para utilizar Corona é utilizar o Sublime ou Atom e configurar plugins que ajudam no desenvolvimento, como esta lista de plugins do Gregório para Sublime.\nConfira aqui as minhas participações anteriores. Se você está em dúvida sobre o que utilizar, dê uma lida neste post sobre algumas engines e frameworks gratuitos que estão no GitHub.\nNeste post eu dei algumas dicas sobre o que fazer e o que não fazer para se preparar antes e durante esta game jam, vale a pena a leitura. O ludum dare acontece a cada 4 meses e dura apenas 48 horas (fazendo o jogo sozinho) ou 72 horas (fazendo o jogo em grupo), e eu recomendo muito participar. O objetivo é fazer um jogo simples (no tema mais votado) e se divertir!\n","date":"24 de julho de 2017","externalUrl":null,"permalink":"/esta-semana-comeca-o-ludum-dare-39/","section":"Blog","summary":"Na próxima sexta-feira começa o Ludum Dare #39, e esta vai ser ser minha oitava participação seguida nesta game jam. Na última participação não tive muito tempo sobrando para fazer um jogo e acabei escolhendo usar Unity, a tecnologia que eu uso no meu dia-a-dia, para poder pelo menos fazer um protótipo e demonstrar uma mecânica dentro do tema.\n","title":"Esta semana começa o Ludum Dare #39","type":"posts"},{"content":"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.\nApó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.\nRefactoring preguiçoso\nComo 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.\nUma 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.\nOutra 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.\nscene_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.\nFeatures do GitHub\nOutra 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.\nSe 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.\nPróximo passo\nAtualmente 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.\nO 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!\n","date":"14 de julho de 2017","externalUrl":null,"permalink":"/final-frontier-refactoring/","section":"Blog","summary":"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.\n","title":"Final Frontier: Refactoring e GitHub","type":"posts"},{"content":"No quarto episódio do podcast GAMEDEV BR falamos sobre erros comuns que iniciantes em desenvolvimento de jogos cometem, e praticamente todos foram baseados nas nossas experiências aprendendo ou situações que presenciamos.\nComo somos programadores, muitos dos erros que citamos envolvem programação, mas boa parte deles também se aplica a artistas, designers, produtores, e todo mundo que quer trabalhar com jogos. Nós aprendemos cometendo estes erros, e a ideia de falar deles é que outras pessoas também aprendam. Se você já cometeu algum erro comum que não citamos, deixe um comentário!\nClique aqui para ouvir\nEle também está disponível no iTunes, procurem por GAMEDEVBR. Como sempre, qualquer crítica e sugestões são sempre bem vindas, e obrigado pelo apoio!\n","date":"13 de julho de 2017","externalUrl":null,"permalink":"/podcast-gamedevbr-004-erros-de-iniciantes/","section":"Blog","summary":"No quarto episódio do podcast GAMEDEV BR falamos sobre erros comuns que iniciantes em desenvolvimento de jogos cometem, e praticamente todos foram baseados nas nossas experiências aprendendo ou situações que presenciamos.\n","title":"GAMEDEV BR: 004 Erros de iniciantes em gamedev","type":"posts"},{"content":"A Corona Labs decidiu unir seus dois modelos de negócio, Corona SDK (que já era gratuito) e Corona Enterprise (que era pago), em um único produto agora chamado apenas de Corona. As vantagens para desenvolvedores são que não há limites ou taxas, e que é possível desenvolver código nativo sem precisar pagar a mais por isso. Porém, agora toda build terá uma splash screen da Corona (como a Unity faz na versão gratuita), que pode ser removida comprando um plugin que custa $99 dólares por ano.\nJá utilizei o Corona SDK para alguns projetos pessoais, principalmente protótipos pela facilidade de programar features simples em 2D com a linguagem script Lua. Nunca usei a versão Enterprise, e isso é algo que pretendo testar em breve pra ver como o desenvolvimento nativo funciona nela. A Corona conta com uma loja de assets e plugins, bem similar à da Unity, onde desenvolvedores podem encontrar de tudo, como templates de jogos bem úteis para estudar desenvolvimento na Corona.\nCorona está disponível para Windows e macOS. Recomendo baixar e testar, é uma ótima ferramenta para desenvolvimento de jogos 2D para dispositivos móveis e desktop. Para programar em Lua com a Corona já usei muito o Sublime, mas hoje recomendo o Atom por ser gratuito e mais simples de instalar plugins.\n","date":"26 de junho de 2017","externalUrl":null,"permalink":"/corona-agora-gratuita/","section":"Blog","summary":"A Corona Labs decidiu unir seus dois modelos de negócio, Corona SDK (que já era gratuito) e Corona Enterprise (que era pago), em um único produto agora chamado apenas de Corona. As vantagens para desenvolvedores são que não há limites ou taxas, e que é possível desenvolver código nativo sem precisar pagar a mais por isso. Porém, agora toda build terá uma splash screen da Corona (como a Unity faz na versão gratuita), que pode ser removida comprando um plugin que custa $99 dólares por ano.\n","title":"Corona agora é gratuita","type":"posts"},{"content":"No terceiro episódio do podcast GAMEDEV BR convidamos dois Game Designers para comentar sobre suas experiências e seu dia-a-dia no trabalho. Os convidados Felipe Dal Molin, da Aquiris, e Bruno Barbosa, da Tapps, comentam como começaram, o que um Game Designer faz e dão dicas muito boas para quem quer trabalhar com jogos.\nEu não participei da gravação deste episódio, mas como o foco foram os convidados não vão sentir falta de ouvir minha voz baixa na gravação haha. Este episódio ficou bem longo, e esse foi um dos motivos do atraso, mas acreditamos que o conteúdo ficou muito bom e não está cansativo.\nClique aqui para ouvir\nEle também está disponível no iTunes, procurem por GAMEDEVBR. Como sempre, qualquer crítica e sugestões são sempre bem vindas, e obrigado pelo apoio!\n","date":"19 de junho de 2017","externalUrl":null,"permalink":"/podcast-gamedevbr-003-game-design/","section":"Blog","summary":"No terceiro episódio do podcast GAMEDEV BR convidamos dois Game Designers para comentar sobre suas experiências e seu dia-a-dia no trabalho. Os convidados Felipe Dal Molin, da Aquiris, e Bruno Barbosa, da Tapps, comentam como começaram, o que um Game Designer faz e dão dicas muito boas para quem quer trabalhar com jogos.\n","title":"GAMEDEV BR: 003 Vida de Game Designer","type":"posts"},{"content":"Este é o segundo episódio do podcast GAMEDEV BR que estou gravando com dois amigos que trabalham comigo na Aquiris. Desta vez o assunto foi falar sobre as nossas experiências com Game Engines, o que já usamos profissionalmente e em projetos pessoais, o que levar em consideração para escolher uma tecnologia, e o que recomendamos. Assim como o episódio anterior, o conteúdo do podcast é baseado na nossa experiência.\nMuito obrigado a todos pelo apoio e feedback que recebemos no primeiro episódio, ficamos felizes com a recepção e isso nos motivou muito!\nClique aqui para ouvir\nEle também está disponível no iTunes, procurem por GAMEDEVBR. Como sempre, qualquer crítica e sugestões são sempre bem vindas!\n","date":"29 de maio de 2017","externalUrl":null,"permalink":"/podcast-gamedevbr-002-game-engines/","section":"Blog","summary":"Este é o segundo episódio do podcast GAMEDEV BR que estou gravando com dois amigos que trabalham comigo na Aquiris. Desta vez o assunto foi falar sobre as nossas experiências com Game Engines, o que já usamos profissionalmente e em projetos pessoais, o que levar em consideração para escolher uma tecnologia, e o que recomendamos. Assim como o episódio anterior, o conteúdo do podcast é baseado na nossa experiência.\n","title":"GAMEDEV BR: 002 Game Engines","type":"posts"},{"content":"Eu e mais dois amigos que trabalham comigo na Aquiris, Márcio Freitas e Gregório Benatti, decidimos começar um podcast para falar sobre desenvolvimento de jogos. Esta ideia surgiu quando percebemos que nossas conversas de depois do almoço poderiam render um bom conteúdo para que tem interesse em desenvolver jogos, ou até pra quem já trabalha na indústria. Decidimos fazer o podcast como uma conversa informal, porém cada episódio com um assunto específico.\nNosso objetivo com o podcast, chamado GAMEDEV BR, não é falar o que é certo e errado, mas sim compartilhar nosso conhecimento e experiência que adquirimos nos últimos anos trabalhando e estudando desenvolvimento de jogos. Uma das nossas referências é o PodQuest, um podcast criado por 3 brasileiros que trabalham na indústria de jogos fora do país.\nO primeiro episódio já está disponível no site do podcast e fala sobre a importância de se ter um portfólio e como isso nos ajudou a entrar na indústria de jogos:\nClique aqui para ouvir\nEm breve ele também estará disponível no iTunes. Ouçam, comentem e nos deem seu feedback, é muito importante pra sabermos se estamos indo na direção certa!\n","date":"16 de maio de 2017","externalUrl":null,"permalink":"/podcast-gamedevbr-001-portfolio/","section":"Blog","summary":"Eu e mais dois amigos que trabalham comigo na Aquiris, Márcio Freitas e Gregório Benatti, decidimos começar um podcast para falar sobre desenvolvimento de jogos. Esta ideia surgiu quando percebemos que nossas conversas de depois do almoço poderiam render um bom conteúdo para que tem interesse em desenvolver jogos, ou até pra quem já trabalha na indústria. Decidimos fazer o podcast como uma conversa informal, porém cada episódio com um assunto específico.\n","title":"GAMEDEV BR: 001 Portfólio","type":"posts"},{"content":"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 \u0026quot;A Small World\u0026quot; (um mundo pequeno), e eu tentei fazer algo não muito óbvio.\nTive 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.\nNeste link você pode baixar o jogo para Android, MacOS, Linux e Windows, e também o seu código fonte.\nGame Design\nComo 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 \u0026quot;fair play\u0026quot;. 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.\nProgramação\nTenho que admitir que apesar de ser um jogo simples, eu pedir um certo tempo escrevendo \u0026quot;código bonito\u0026quot;. 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\nO Unity Cloud Build funcionou muito bem para gerar as builds de Android, Windows, Linux e MacOS sem eu precisar parar para compilar o projeto.\nArte\nNã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.\nConclusão\nNa 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.\nHoje 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!\n","date":"24 de abril de 2017","externalUrl":null,"permalink":"/ludum-dare-38/","section":"Blog","summary":"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.\n","title":"Minha participação no Ludum Dare #38","type":"posts"},{"content":"Na sexta-feira começa o Ludum Dare #38, e desta vez será realizado pelo novo site. Na edição passada estava planejada para ser no novo site, mas infelizmente tiveram alguns problemas e este será o primeiro ludum dare no novo sistema. Por isso é bom ficar de olho nas notícias no site novo, no antigo e no Twitter caso algo mude durante o game jam.\nEu gosto de tentar usar frameworks ou game engines que eu não costumo usar ou que não tenho experiência, mas dessa vez vou ter pouco tempo disponível e provavelmente vou usar Unity por ter mais experiência e usar no meu dia-a-dia.\nConfira aqui as minhas participações anteriores. Se você está em dúvida sobre o que utilizar, dê uma lida neste post sobre algumas engines e frameworks gratuitos que estão no GitHub.\nNeste post eu dei algumas dicas sobre o que fazer e o que não fazer para se preparar antes e durante esta game jam, vale a pena a leitura. O ludum dare acontece a cada 4 meses e dura apenas 48 horas (fazendo o jogo sozinho) ou 72 horas (fazendo o jogo em grupo), e eu recomendo muito participar. O objetivo é fazer um jogo simples (no tema mais votado) e se divertir!\n","date":"17 de abril de 2017","externalUrl":null,"permalink":"/esta-semana-comeca-o-ludum-dare-38/","section":"Blog","summary":"Na sexta-feira começa o Ludum Dare #38, e desta vez será realizado pelo novo site. Na edição passada estava planejada para ser no novo site, mas infelizmente tiveram alguns problemas e este será o primeiro ludum dare no novo sistema. Por isso é bom ficar de olho nas notícias no site novo, no antigo e no Twitter caso algo mude durante o game jam.\n","title":"Esta semana começa o Ludum Dare #38","type":"posts"},{"content":"Em outubro do ano passado fui contratado pela Aquiris Game Studio, e foi uma grande mudança na minha vida e carreira. Mudar de São Paulo para Porto Alegre tem sido uma experiência legal, e as vezes algumas diferenças culturais fazem parecer que estou em outro país. Até o idioma parece diferente as vezes, mas com o tempo vou ficar mais fluente em gauches (bah!).\nSério, eu poderia fazer um post inteiro sobre a minha experiência de morar aqui, um lugar que faz mais calor do que eu esperava, mas neste post vou falar do que me fez vir pra cá: a oportunidade de trabalhar na Aquiris, uma empresa brasileira muito respeitada e admirada aqui e fora do país, e uma referência para desenvolveres de jogos que usam Unity.\nMês passado a Aquiris completou 10 anos, e para uma empresa que desenvolve jogos no Brasil é um grande feito. Em seu portfólio estão jogos como The Great Prank War, Copa Toon, Horizon Chase, Ballistic Overkill (que saiu do Steam Early Access mês passado), sua famosa demo feita para a Unity 3.0, o Bootcamp, entre muitos outros.\nApesar de usarem Unity para desenvolver seus projetos, este não é um requisito obrigatório para aplicar em uma vaga de programador. Claro que conhecer a Unity e ter feito jogos com ela é um diferencial, mas o legal aqui é que eles dão mais importância em contratar bons programadores.\nEm São Paulo eu conhecia a boa fama da Aquiris, inclusive vi algumas palestras em eventos do Unite, e eu estava com uma certa espectativa antes de vir. Fiquei muito feliz quando vi todas minhas expectativas sendo superadas. Não estou sendo puxa saco, até por que isso nem exista lá.\nEstou trabalhando com Unity, o que não é uma surpresa, mas mesmo já conhecendo a game engine e ter feito jogos com ela estou aprendendo bastante lá dentro. Este é um grande fator de motivação pra mim, continuar aprendendo, e é o que acontece comigo praticamente todo dia.\nAinda não posso revelar o projeto que estou trabalhando, mas assim que for publicado vou escrever um post sobre ele. Se você tem interesse em trabalhar na Aquiris, sempre tem alguma vaga aberta no site. Lembrando que, como sempre falo, ter um portfólio é muito importante pra mostrar o que você sabe fazer. Recomendo também conhecer os jogos da Aquiris, principalmente o Horizon Chase e o Ballistic Overkill.\n","date":"9 de abril de 2017","externalUrl":null,"permalink":"/meu-trabalho-na-aquiris/","section":"Blog","summary":"Em outubro do ano passado fui contratado pela Aquiris Game Studio, e foi uma grande mudança na minha vida e carreira. Mudar de São Paulo para Porto Alegre tem sido uma experiência legal, e as vezes algumas diferenças culturais fazem parecer que estou em outro país. Até o idioma parece diferente as vezes, mas com o tempo vou ficar mais fluente em gauches (bah!).\n","title":"Meu trabalho na Aquiris Game Studio ","type":"posts"},{"content":"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.\nPrimeiro GDD\nUma 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.\nUm 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.\nUsei 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.\nO GDD está divido em 10 partes, sendo que cada uma corresponde a uma página do modelo:\nPá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.\nDe volta a Unity\nCom 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.\nEmbora 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.\nConclusão\nEstou 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!\n","date":"30 de março de 2017","externalUrl":null,"permalink":"/final-frontier-gdd/","section":"Blog","summary":"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.\n","title":"Final Frontier: Game Design Document","type":"posts"},{"content":"Há um ano eu decidi migrar o meu blog feito no Wordpress para alguma plataforma que permitisse eu ter um blog estático (sem banco de dados, apenas HTML/CSS) e usar a hospedagem gratuita do GitHub Pages. Na época eu acabei escolhendo usar o Ghost, como contei em detalhes neste post. Um ano depois percebi que não foi a melhor escolha, pois apesar de solucionar os meus problemas acima não era nada prática publicar um post.\nO GitHub Pages funciona apenas com HTML/CSS estático ou Jekyll, por isso precisei utilizar uma tool em Python chamada Buster para converter o blog feito no Ghost para páginas estáticas, e então publicar no GitHub Pages. E aqui começaram meus problemas: eu precisava de depois repositórios para o projeto: um rodando o blog em Ghost, que é uma aplicação NodeJS, e outro com as páginas estáticas no GitHub. Então para cada post novo ou alteração eu precisava rodar o projeto em um servidor local, rodar a tool para exportar em páginas estáticas, e depois fazer um commit para o repositório no GitHub. Além de deste processo não ser prático eu dependia de ter um computador configurado para postar no blog.\nO Ghost é uma ótima plataforma, leve e rápida, porém não foi a melhor escolha para o meu blog. Fiquei empolgado em conseguir migrar do Wordpress para o Ghost rapidamente e não pensei em fazer testes ou verificar se não teria problemas. Além da dificuldade de publicar um post, tive problemas com a tool Buster que exportava o blog para páginas estáticas, e por estar sem suporte há alguns anos eu tive que corrigir algumas coisas no seu script Python. Cheguei até a escrever um script Ruby para automatizar boa parte do processo de publicar que, apensar de funcionar bem, dependia de mais configurações na máquina para rodar todo processo.\nAcho que depois de uns 6 meses eu percebi que continuar com este processo não era uma boa opção, então decidi fazer um teste usando o Jekyll. Para aprender e testar esta opção, e não cometer o mesmo erro anterior, eu decidi fazer um projeto pequeno mas até o final. Assim refiz o meu portifólio, que antes eram apenas páginas estáticas feitas a partir de um template do Bootstrap, e hoje é algo bem prático para eu atualizar com novos projetos. Como o conteúdo era relativamente pequeno eu demorei apenas 1 semana para refazer o portfólio, e fiquei muito feliz com o resultado.\nTão feliz que decidi refazer o blog usando Jekyll, e planejei este projeto para Janeiro deste ano, assim poderia terminar o ano sem interrupções nos posts. Eu não queria apenas migrar o conteúdo, como fiz quando migrei do Wordpress para o Ghost, mas sim corrigir problemas e adicionar funcionalidades ao blog. Estas eram minhas metas com este novo blog:\nContinuar utilizando hospedagem gratuita do GitHub Pages Tornar o processo de publicar um post simples Poder escrever e publicar de qualquer lugar, sem depender configurações Adicionar um campo de busca para achar o conteúdo Melhorar as categorias Layout simples e rápido Corrigir todas imagens e links quebrados de posts antigos Utilizando a tool do Jekyll de migração a partir do Ghost, a base do meu portólio e um template básico do Bootstrap para blogs, iniciei o projeto que teve duração de pouco mais de 1 mês. A migração foi bem simples, e ajustar o layout usando HTML e CSS no Jekyll não demorou tanto quanto pensei. Meu maior problema foi cumprir a última meta e corrigir mais de 300 posts que escrevi nos últimos 8 anos. Foi um trabalho muito longo e cansativo, mas valeu muito a pena. Talvez ainda exista algo que deixei passar sem querer, mas acredito que hoje o blog está tão redondo quanto no seu início. O código-fonte do blog está no GitHub.\nMuitas coisas quebraram das migrações que fiz de servidores e serviços. Meu blog começou no próprio Wordpress, depois migrei para o Uol Host (não recomendo), depois para o Bluehost (não recomendo). Após péssimas experiências decidi configurar meu próprio servidor no Digital Ocean (recomendo!), depois migrei para o Amazon Web Services (recomendo!) usando serviços separados para o banco de dados (RDS) e aplicação (Elastic beanstalk). Passei 6 anos pagando em média $10 dólares para manter este blog no ar, além de renovar o domínio todo ano, e então decidi migrar para algo mais rápido e gratuito. O resto da história está neste post.\nEspero que gostem do resultado, afinal fiz tudo isso para você que vem de vez em quando por aqui ler meus posts. Este ano no dia 24 de Abril o blog vai fazer 8 anos e muita coisa mudou aqui e na minha carreira. No início nem imaginava que eu teria passado por empresas de jogos internacionais, e nem que hoje estaria em Porto Alegre trabalhando na Aquiris. De vez em quando volto aos meus primeiros posts para me lembrar dos sonhos que tinha, ficar feliz onde cheguei, e sempre lembrar que ainda estou começando.\n","date":"14 de fevereiro de 2017","externalUrl":null,"permalink":"/ola-jekyll/","section":"Blog","summary":"Há um ano eu decidi migrar o meu blog feito no Wordpress para alguma plataforma que permitisse eu ter um blog estático (sem banco de dados, apenas HTML/CSS) e usar a hospedagem gratuita do GitHub Pages. Na época eu acabei escolhendo usar o Ghost, como contei em detalhes neste post. Um ano depois percebi que não foi a melhor escolha, pois apesar de solucionar os meus problemas acima não era nada prática publicar um post.\n","title":"Adeus Ghost, olá Jekyll","type":"posts"},{"content":"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.\nO novo rumo do projeto\nNo 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.\nEncontrei 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.\nO desenvolvimento na Unity\nAgora 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).\nO 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.\nQuero 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.\nConclusão\nEste 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á.\nO 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!\n","date":"20 de dezembro de 2016","externalUrl":null,"permalink":"/final-frontier-algumas-mudancas-no-projeto/","section":"Blog","summary":"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.\n","title":"Final Frontier: Algumas mudanças no projeto","type":"posts"},{"content":"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.\nCom 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.\nNeste link você pode baixar o jogo para Android, macOS e Windows, e também o seu código fonte.\nGame Design\nA 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.\nEu 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.\nQuando 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).\nProgramação\nEu 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.\nFazer 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.\nDesta 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.\nArte\nNã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.\nAs 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.\nConclusão\nNã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.\nTerminei 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.\nO 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.\n","date":"13 de dezembro de 2016","externalUrl":null,"permalink":"/ludum-dare-37/","section":"Blog","summary":"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.\n","title":"Minha participação no Ludum Dare #37","type":"posts"},{"content":"Está curioso para saber como foi o desempenho do mercado de games em 2016? O Rafael Querido do site Segredo dos Games reuniu algumas informações a respeito e montou o infográfico abaixo, as referências estão no final da imagem.\nEste ano foi um bom para jogos em VR e continuou muito bom para jogos mobile. Eu acredito que no próximo ano jogos em VR serão mais fortes e acessíveis com mais opções de hardware, e que o Nintendo Switch vai trazer a Nintendo de volta a briga.\nEsse infográfico sobre o mercado de Games foi desenvolvido pelo site Segredo dos Games.\nImagem da capa: Mercado de Games no Brasil do Segredo dos Games.\n","date":"12 de dezembro de 2016","externalUrl":null,"permalink":"/mercado-de-games-2016/","section":"Blog","summary":"Está curioso para saber como foi o desempenho do mercado de games em 2016? O Rafael Querido do site Segredo dos Games reuniu algumas informações a respeito e montou o infográfico abaixo, as referências estão no final da imagem.\n","title":"Mercado de games no Brasil em 2016","type":"posts"},{"content":"Na sexta-feira às 23h (horário de Brasilia) começa o Ludum Dare #37, e desta vez será realizado pelo novo site (que ainda está em desenvolvimento). Ano que vem o Ludum Dare completa 15 anos e esta próxima edição irá testar este novo sistema que será utilizado para expandir esta game jam nas próximas edições.\nEu ainda não decidi qual engine ou framework irei utilizar na próxima edição. Talvez eu utilize a Unity para testar algumas coisas novas que aprendi nos últimos meses e foque mais no jogo em si, ou vou utilizar algo em C++ como SDL ou cocos2d-x novamente. Estou com pouco tempo para testar algo antes do Ludum Dare, então vou tentar escolher algo que conheço pelo menos um pouco.\nConfira aqui as minhas participações anteriores, este vai ser o meu sexto Ludum Dare. Se você está em dúvida sobre o que utilizar, dê uma lida neste post sobre algumas engines e frameworks gratuitos que estão no GitHub.\nNeste post do último Ludum Dare eu dei algumas dicas sobre o que fazer e o que não fazer para se preparar antes e durante esta game jam, vale a pena a leitura.\n","date":"5 de dezembro de 2016","externalUrl":null,"permalink":"/esta-semana-comeca-o-ludum-dare-37/","section":"Blog","summary":"Na sexta-feira às 23h (horário de Brasilia) começa o Ludum Dare #37, e desta vez será realizado pelo novo site (que ainda está em desenvolvimento). Ano que vem o Ludum Dare completa 15 anos e esta próxima edição irá testar este novo sistema que será utilizado para expandir esta game jam nas próximas edições.\n","title":"Esta semana começa o Ludum Dare #37","type":"posts"},{"content":"Acredito que se você está lendo este texto existem grandes chances de você querer desenvolver jogos ou já trabalhar na área. É muito provável que alto te motivou a querer isso, algo mais sério do que \u0026quot;escolhi por que eu gosto de jogar\u0026quot;, já que exige muita dedicação para fazer carreira na indústria de jogos.\nPra mim o interesse surgiu por que eu gostava de jogar, mas quando comecei a estudar Ciência da Computação percebi que era algo muito desafiador de criar e compensador de ver alguém jogando o que você criou. Já escrevi alguns posts sobre este assunto, e recomendo dar uma lida no O dia em que vi uma pessoa jogando um jogo que fiz na Electronic Arts e no É por isso que faço jogos!, ambos são exemplos de recompensa que um desenvolvedor de jogos por ter. Algo tão simples, mas que faz todo trabalho valer a pena (pelo menos pra mim).\nSemana passada aconteceu o Video Game Awards em Los Angeles, um premiação para as empresas e pessoas que criaram as melhores experiências no ano. Fiquei com vontade de escrever este posts pois dois prêmios tiveram discursos muito emocionantes, que descrevem tudo que escrevi aqui. Confiram abaixo o discurso do desenvolvedor do That Dragon, Cancer e do youtuber Boogie2988.\nEntão, por que você faz ou quer fazer jogos?\nImagem da capa: Playing game do Shutterstock.\n","date":"3 de dezembro de 2016","externalUrl":null,"permalink":"/por-que-voce-faz-ou-quer-fazer-jogos/","section":"Blog","summary":"Acredito que se você está lendo este texto existem grandes chances de você querer desenvolver jogos ou já trabalhar na área. É muito provável que alto te motivou a querer isso, algo mais sério do que \"escolhi por que eu gosto de jogar\", já que exige muita dedicação para fazer carreira na indústria de jogos.\n","title":"Por que você faz ou quer fazer jogos?","type":"posts"},{"content":"O GitHub é uma ótima plataforma para versionamento de projetos com código aberto usando git, mas ele não é apenas isso. Existem muitas features no GitHub que as vezes parecem escondidas mas valem muito a pena ver. Uma parte que eu descobri recentemente foi a página Showcases, que agrupa listas de projetos por categorias. Não todos, mas os mais populares.\nNeste link está a lista de game engines e frameworks que são open source, populares e ativos no GitHub. Abaixo vou comentar sobre algumas engines e frameworks que eu conheço e já usei, mas recomendo você a conhecer todas as 24 que estão no link (assim como eu também vou fazer!).\ncocos2d-x\nEsta é um dos meus frameworks preferidos para fazer jogos em C++. Conheci há uns 4 anos quando estava trabalhando na Electronic Arts, e desde então sempre usei para fazer protótipos e até um jogo na última edição do Ludum Dare.\nNesses 4 anos este framework cresceu muito, ganhou ótimas tools e suporte de muitos desenvolvedores. Mudou tanto que quando fui utilizar no Ludum Dare tive que dar uma estudada novamente na documentação por que mudaram praticamente todas as classes e a maneira de usar algumas coisas, principalmente se adaptando ao C++11.\nCRYENGINE\nEmbora eu conheça este engine há um tempo, só quando se tornou open source que eu tive oportunidade de testar. Ainda não fiz algo maior que um protótipo simples com ela, mas quem sabe no futuro não uso em algum projeto ou game jam. A linguagem de programação utilizada também é C++.\nSe o seu computador consegue rodar Crysis baixe esta engine e faça alguns tutoriais para conhecê-la. Uma curiosidade: a engine da Amazon, Lumberyard, foi feita em cima da CRYENGINE.\nMonoGame\nO Mono surgiu como um projeto open source para permitir o desenvolvimento de software com C# em sistemas Unix (Linux e Mac), e o MonoGame surgiu como um framework semelhante ao XNA da Microsoft para desenvolvimento de jogos.\nO XNA foi um framework muito especial pra mim, fiz vários projetos nele quando comecei a estudar desenvolvimento de jogos, e até o meu TCC por eu ter experiência com C# na época. Eu usei o MonoGame algumas vezes mas não gostei muito, acho que estava esperando algo realmente como o XNA, porem ele tem suas próprias características. Mesmo assim, vale a pena dar uma olhada.\nTorque2D e Torque3D\nA Torque foi a primeira engine que eu ouvi falar por que um amigo estava fazendo seu TCC com ela quando eu trabalhei na Level Up! Games. Naquela época ela era a opção com melhor custo/benefício, e acho que existia apenas a versão 3D.\nHá algum tempo a GarageGames abriu o código das suas duas engines para poder continuar atraindo desenvolvedores, já que hoje existem muitas opções gratuitas.\nOutras engines e frameworks\nEmbora não esteja nesta lista, por ser um repositório privado, a Unreal Engine tem seu código aberto e basta se cadastrar no site para ter acesso. Existem outras engines e frameworks que são open source porém não estão hospedadas no GitHub, como os frameworks SDL e Irrlicht. Como o objetivo do post foi comentar sobre esta lista do GitHub não coloquei aqui as opções que não estão lá, mas basta dar uma olhada na Wikipedia que você encontrará muitas opções.\nImagem da capa: Game Developing on the Golden Gears do Shutterstock.\n","date":"27 de novembro de 2016","externalUrl":null,"permalink":"/engines-frameworks-open-source-github/","section":"Blog","summary":"O GitHub é uma ótima plataforma para versionamento de projetos com código aberto usando git, mas ele não é apenas isso. Existem muitas features no GitHub que as vezes parecem escondidas mas valem muito a pena ver. Uma parte que eu descobri recentemente foi a página Showcases, que agrupa listas de projetos por categorias. Não todos, mas os mais populares.\n","title":"Engines e frameworks open source no GitHub","type":"posts"},{"content":"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.\nItens de Upgrade\nExiste 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!\nEu 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.\nSalvando o progresso do jogo\nAinda é 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.\nItens na interface\nCriei 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.\nEu 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.\nFramework Frictioness\nO 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.\nUtilizar 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.\nConclusão\nSe 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.\nOutra 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.\nO 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!\n","date":"20 de novembro de 2016","externalUrl":null,"permalink":"/final-frontier-upgrades-e-save-game/","section":"Blog","summary":"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.\n","title":"Final Frontier: Upgrades e Save Game","type":"posts"},{"content":"Esta é uma prática muito comum em empresas de médio e grande porte, mas na minha opinião poderia ser algo que muitas empresas pequenas deveriam tentar adicionar ao seu processo de desenvolvimento. Existem algumas maneiras formais de fazer revisão de código, mas neste post quero comentar da minha experiência em revisão de código.\nNa primeira vez que conheci este processo na prática foi quando trabalhei na Electronic Arts. Em projetos que estão em desenvolvimento existe uma exigência muito grande por parte dos líderes de que todo código seja revisado antes de fazer o merge das alterações para o branch principal do projeto.\nPara a revisão funcionar é necessário que a equipe trabalhe com o conceito de branches. Isto pode ser facilmente feito em ferramentas de versionamento como git e perforce (este é o que a EA usa). Cada feature ou bug fix deve ser feita em um branch separado, e quando terminada o merge é feito para o branch principal de desenvolvimento. É neste ponto que a revisão de código acontece.\nA revisão do código, sempre feita por outro programador que não trabalhou no branch, pode ser algo mais leve como só verificar se existe algo que pode ser melhorado ou algo mais exigente, como verificar se o código está escrito no padrão do projeto (nomes de variáveis e métodos, espaçamento, quebras de linha, entre outros). No início, para um programador novo na equipe, é normal que o código necessite alterações, mas com o tempo tudo fica mais natural. Caso o revisor aprove o código, ele pode ser mergeado no branch de desenvolvimento. Caso contrário, o revisor enviará uma lista de alterações e até sugestões para melhorar o código.\nUm dos benefícios da revisão de código não é só garantir que os padrões de desenvolvimento do projeto estejam sendo seguidos, mas também ajuda a evitar que novos códigos sejam adicionados em lugares errados ou que algo que já exista seja escrito novamente. A revisão de código ensina o programador a ter mais cuidado com o código que está escrevendo.\nÉ importante lembrar que a revisão do código não é um teste unitário e muito menos gerar uma build e testar. Os testes de código provavelmente serão executados no momento de gerar uma build para algum QA testar ou após o merge do código no branch de desenvolvimento. A revisão do código busca a qualidade do código escrito e o padrão de desenvolvimento do projeto.\nOutro ponto para se lembrar é que a revisão de código só funciona se todos programadores da equipe tiverem o bom senso de seguir os padrões do projeto. Não adianta introduzir algo que não será seguido por que alguém acha que é besteira ou perda de tempo, e prefere escrever o código de qualquer jeito só para terminar suas tarefas antes do prazo. Escrever código com qualidade nunca é perda de tempo, e qualquer processo que possa garantir a qualidade do código é útil em projetos com muita gente trabalhando ao mesmo tempo.\nImagem da capa: Programmer working do Shutterstock.\n","date":"19 de novembro de 2016","externalUrl":null,"permalink":"/revisao-de-codigo/","section":"Blog","summary":"Esta é uma prática muito comum em empresas de médio e grande porte, mas na minha opinião poderia ser algo que muitas empresas pequenas deveriam tentar adicionar ao seu processo de desenvolvimento. Existem algumas maneiras formais de fazer revisão de código, mas neste post quero comentar da minha experiência em revisão de código.\n","title":"Revisão de código","type":"posts"},{"content":"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.\nOrganizando a casa\nQuando 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.\nComo 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.\nMini Scrum\nEstou 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.\nNeste 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!\nConclusão\nSemana 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.\nO 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!\n","date":"4 de novembro de 2016","externalUrl":null,"permalink":"/final-frontier-organizando-tarefas/","section":"Blog","summary":"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.\n","title":"Final Frontier: Organizando tarefas","type":"posts"},{"content":"Uma das dicas que sempre falo para quem está começando é montar um portfólio pois, mesmo que no início tenha apenas jogos curtos ou projetos de cursos, é algo para mostrar e é um opcional praticamente obrigatório em um processo seletivo na área de jogos.\nExistem algumas coisas importantes que vale sempre lembrar. Se você é um programador, ninguém vai cobrar pela arte, design ou audio do seu jogo, mas vão cobrar (e perguntar) sobre as técnicas de programação, engine, linguagem, design patterns e qualquer outra coisa técnica que possa ser relevante ao jogo.\nAté 2013 meu portfólio era uma categoria aqui no blog que listava os posts relacionados a meus projetos, porém isto não era muito prático para mostrar ou mesmo aplicar para vagas fora do país. Neste momento eu decidi separar o meu portfólio do blog e escrever o conteúdo dele em Inglês.\nNo início eu queria algo bem simples e fiz meu portfólio de 2014 utilizando apenas bootstrap. Meus projetos estavam lá, porém o layout estava bem ruim. Continuei utilizando apenas o bootstrap no meu portfólio de 2015, que acabou ficando inacabado por falta de tempo.\nPorém, este ano, decidi refazer o portfólio mas queria ir um pouco mais além de apenas uma página estática. Decidi que queria hospedar o portfólio no GitHub Pages, o mesmo lugar que está hospedado este blog, porém não queria utilizar a combinação Ghost + Buster para publicar.\nFoi então que decidi utilizar o Jekyll, um framework possui algumas features bem legal para criar blogs e sites, e o melhor é que o GitHub Pages suporta Jekyll nativamente. Inclusive estou pensando em refazer este blog utilizado Jekyll, mas isto é um projeto maior que exigem um certo planejamento para não quebrar algumas coisas.\nMeu portfólio atual foi desenvolvido em poucos dias, utilizando meu tempo livre, e o resultado foi melhor do que o esperado. Você pode ver o projeto neste repositório e o portfólio aqui. Além dos projetos profissionais, também adicionei meus projetos pessoais e jogos que desenvolvi em game jams.\nColoquei apenas os jogos que foram desenvolvidos até o fim e publicados no meu blog ou em algum site, junto com imagens, videos e informações. Eu demorei mais para juntar toda essa informação e recursos do que montar o portfólio, mas todo esforço valeu a pena e hoje estou feliz com o resultado. Com o tempo vou adicionar mais detalhes sobre cada projeto, mas a base está pronta.\nMinha sugestão é fazer o portfólio em Inglês e em um lugar separado. Nem precisa ser no GitHub Pages, pois existem diversos outros serviços como o Carbonmade e o Behance, ou você pode simplesmente colocar seus jogos em sites como GameJolt ou Itch.io, mas lembre de colocar detalhes do que você fez no projeto.\nDeixe um comentário aqui com sugestões para melhorar meu portfólio, e também o link do seu para eu poder ver!\n","date":"27 de outubro de 2016","externalUrl":null,"permalink":"/meu-novo-portfolio/","section":"Blog","summary":"Uma das dicas que sempre falo para quem está começando é montar um portfólio pois, mesmo que no início tenha apenas jogos curtos ou projetos de cursos, é algo para mostrar e é um opcional praticamente obrigatório em um processo seletivo na área de jogos.\n","title":"Meu novo portfólio","type":"posts"},{"content":"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.\nPartes da nave\nA 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.\nUpgrades da nave\nNa 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!).\nPróximos passos\nEste 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.\nO 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!\n","date":"19 de outubro de 2016","externalUrl":null,"permalink":"/final-frontier-detalhes-do-inventario/","section":"Blog","summary":"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.\n","title":"Final Frontier: Detalhes do Inventário","type":"posts"},{"content":"A Game Developers Conference (GDC) é bem famosa na indústria, e com certeza o maior evento para desenvolvedores de jogos. A GDC tem sua edição principal nos EUA e algumas edições um pouco menores na Europa e Asia, assim como edições especiais, como a VRDC. Todo conteúdo das palestras ficam disponíveis no site GDC Vault, que possui alguns conteúdos gratuitos mas sua maioria precisa de uma assinatura mensal para ter acesso.\nAno passado a GDC começou um canal no YouTube, e a cada dia eles postam um video do seu conteúdo pago. Muitas vezes as palestras são curtas, ou até de alguns anos atrás, mas eles também postam videos recentes e longos. Vale muito a pena acompanhar este canal e assistir seus videos, muitas vezes são melhores do que aulas.\nOs videos abaixo são alguns dos meus favoritos, recomendo assistir pois são verdadeiras aulas sobre desenvolvimento de jogos!\nQuais são seus favoritos?\n","date":"15 de outubro de 2016","externalUrl":null,"permalink":"/videos-da-gdc-no-youtube/","section":"Blog","summary":"A Game Developers Conference (GDC) é bem famosa na indústria, e com certeza o maior evento para desenvolvedores de jogos. A GDC tem sua edição principal nos EUA e algumas edições um pouco menores na Europa e Asia, assim como edições especiais, como a VRDC. Todo conteúdo das palestras ficam disponíveis no site GDC Vault, que possui alguns conteúdos gratuitos mas sua maioria precisa de uma assinatura mensal para ter acesso.\n","title":"Videos da GDC no YouTube","type":"posts"},{"content":"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.\nMelhorias no inventário\nAté 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).\nModifiquei 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.\nExpandindo cada slot\nUma 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.\nUtilizei 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.\nEsconder 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.\nAlgumas tools para o editor\nEsta 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.\nPróximos passos\nAinda 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.\nO 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!\n","date":"5 de outubro de 2016","externalUrl":null,"permalink":"/final-frontier-expandindo-o-inventario/","section":"Blog","summary":"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.\n","title":"Final Frontier: Expandindo o Inventário","type":"posts"},{"content":"Neste livro, publicado pela Editora Novatec, o autor Luiz Fernando Estevarengo ensina conceitos básicos de desenvolvimento de jogos para dispositivos móveis utilizando os frameworks Phaser, Intel XDK e Cordova/Phonegap.\nO livro é bem direito ao ponto: explica como baixar e configurar os frameworks utilizados; explica o básico de HTML e CSS; apresenta um bom resumo sobre JavaScript; desenvolve três jogos diferentes (Frogger, Plataforma e Top Down); explica como publicar o jogo nas lojas Google Play, App Store e Windows Store. Esta organização dividiu muito bem o livro e o torna fácil de consultar a procura de alguma informação, e torna a leitura bem prática.\nOs exemplos de jogos escolhidos foram ótimos. No primeiro jogo desenvolvido, similar ao Frogger, muitos conceitos básicos são ensinados para que o leitor possa desenvolver o jogo. Não é uma explicação teórica e profunda, mas é o básico para entender como funciona o game loop e máquinas de estado, por exemplo. O segundo jogo é de plataforma, similar ao Super Mario Bros, e parte do princípio que o leitor entendeu bem os conceitos do capítulo anterior e introduz novidades (por isso é importante fazer o projeto junto, para não ter dúvidas no próximo capítulo). O terceiro e último jogo é um top down, similar a um Zelda ou Final Fantasy do SNES, mais conceitos são apresentados para a conclusão deste projeto.\nPelos capítulos são apresentados o básico de detecção de colisão, som, utilização de sprites, animações, inputs, e outras coisas básicas para começar a desenvolver um jogo. Com certeza ao final do livro (se o leitor fizer os projetos) é possível ter uma boa noção para começar o seu próprio projeto e aprender mais sobre desenvolvimento de jogos. No final do livro tem um bom resumo de como exportar e publicar seu jogo nas principais lojas de aplicativos e jogos mobile.\nEste livro é ótimo para quem tem noção de HTML/CSS/JavaScript e quer começar a desenvolver jogos. Mesmo quem não tem noção nenhuma de programação, e está disposta a aprender, vai gostar de ler este livro. Porém, se você já tem um conhecimento de programação, ou mesmo desenvolvimento de jogos, este livro pode ser básico demais. O código fonte dos projetos estão no GitHub do autor.\nNa minha opinião sobre a tecnologia, HTML5 não serve para fazer jogos mobile, como expliquei neste post. É uma ótima tecnologia para aprender e fazer os primeiros jogos, mas projetos maiores serão melhores atendidos por tecnologias como Unity ou Unreal, entre outras. Não é uma crítica ao livro (que é muito bom para iniciantes), mas sim a tecnologia que é limitada para dispositivos móveis.\nMuito obrigado a Editora Novatec por me enviar este livro para fazer esta review. Você pode comprar este livro e outros sobre desenvolvimento de jogos no site da Novatec, e utilize o código GAMEDEVELOPER para ter desconto na compra!\n","date":"28 de setembro de 2016","externalUrl":null,"permalink":"/desenvolvendo-jogos-mobile-com-html5/","section":"Blog","summary":"Neste livro, publicado pela Editora Novatec, o autor Luiz Fernando Estevarengo ensina conceitos básicos de desenvolvimento de jogos para dispositivos móveis utilizando os frameworks Phaser, Intel XDK e Cordova/Phonegap.\n","title":"Desenvolvendo Jogos Mobile com HTML5","type":"posts"},{"content":"","date":"28 de setembro de 2016","externalUrl":null,"permalink":"/categories/livros/","section":"Categorias","summary":"","title":"Livros","type":"categories"},{"content":"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.\nQuando 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.\nInspiração para a interface\nToda 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.\nA 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.\nHá 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.\nCriando a interface\nPara 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.\nImportei 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.\nCom 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.\nMovimentando a interface\nPor 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.\nMe 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.\nPara 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.\nPara 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.\nPróximos Passos\nAcho 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.\nO 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!\n","date":"21 de setembro de 2016","externalUrl":null,"permalink":"/final-frontier-interface-da-nave/","section":"Blog","summary":"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.\n","title":"Final Frontier: Interface do inventário","type":"posts"},{"content":"Isto é algo que já escrevi aqui no blog, mas recentemente percebi que eu não estava fazendo. Ultimamente tenho jogado sempre os mesmos jogos, e isto ficou refletido nos últimos jogos que fiz participando do Ludum Dare.\nDesde o ano passado comecei a jogar muitos jogos de tabuleiro novos pra mim, principalmente pelo rápido crescimento deste mercado no Brasil. Há alguns anos existiam poucos jogos e poucas empresas publicando por aqui, mas atualmente temos centenas de jogos disponíveis para todos os gostos, e muito mais está por vir. Por jogar com mais frequência jogos de tabuleiro do que jogos digitais, acabei lendo e pesquisando mais sobre eles, o que fez meu pensamento ficar limitado a mecânicas de jogos analógicos quando precisei criar algo digital.\nDos 5 jogos que fiz nos últimos Ludum Dares, 3 deles são claramente mecânicas de jogos analógicos, e eu não tinha percebido isto até o quinto jogo. Embora eu tenha jogado jogos de tabuleiro diferentes, muitos compartilham as mesmas mecânicas ou temas. No quarto jogo que fiz comecei a perceber que estava faltando algo no game design, mas não era apenas isso, minha visão estava limitada a jogos analógicos. Tentei mudar no último jogo, mas meus recursos de game design foram limitados pelas minhas experiências recentes em jogos de tabuleiro.\nÉ engraçado que até neste outro jogo que estou desenvolvendo e postando aqui, o Final Frontier, minhas referências iniciais também são alguns jogos de tabuleiro. Felizmente percebi que estava com esse pensando de mecânicas analógicas e decidi fazer algumas coisas diferentes para mudar, principalmente voltar a jogar jogos digitais. Mas, como já escrevi neste post, não adianta ficar jogando sempre as mesmas coisas.\nDurante este ano inteiro eu joguei apenas 3 jogos diferentes por um tempo considerável: Destiny, Overwatch e No Man's Sky. Não adianta eu voltar a jogar os mesmos jogos se quero começar a pensar em mecânicas diferentes, por isso listei abaixo o que estou fazendo para mudar isso e voltar a pensar em mecânicas de jogos digitais para jogos digitais. Os itens se resumem a jogar jogos, porém de uma maneira que sejam diferentes e fora da zone de conforto (e sem gastar comprando vários jogos).\nJogos gratuitos no Steam - eu recomendo ir na lista de lançamentos populares ao invés de ir na lista de jogos mais populares, assim você tem jogos novos, gratuitos e diferentes para jogar\nJogos gratuitos no Game Jolt - este site é ótimo para publicar jogos (aqui estão alguns meus) e também descobrir alguns jogos indie, jogue os destaques da página inicial\nHumble Bundle - por $1 dólar é possível comprar um bundle de jogos (aproveite para comprar o GameMaker esta semana lá), geralmente com jogos indie\nSe você assina a PSN Plus ou Xbox Live Gold, todo mês tem alguns jogos grátis para jogar - eu sempre ignorava os jogos da PSN por não ser algo que eu jogaria, mas agora estou baixando e jogando.\nPor fim, jogos gratuitos no Google Play e App Store - se você já jogou os mais baixados, tente procurar por sugestões ou lançamentos.\nEsta lista acima para mais com \u0026quot;onde baixar jogos gratuitos\u0026quot; do que uma lista de estudo, mas tudo depende de como você encara isto. Minha recomendação é jogar algo novo toda semana, ou mesmo todo dia se possível, por pelo menos 1 hora e fazer anotações sobre o jogo: o que é legal, o que não é legal, quais são as mecânicas utilizadas, o que poderia ser diferente. Isto é um ótimo exercício de game design, e vai te ajudar na hora de fazer jogos. Isto é algo que eu fazia com frequência, mas aos poucos fui deixando de lado, e meus últimos jogos no Ludum Dare me mostraram as consequências de jogar sempre as mesmas coisas.\nJogar é muito importante para um desenvolvedor de jogos, assim como um cineasta assiste diversos filmes. Jogos também são uma forma artística de expressão, por isso é essencial sempre conhecer jogos novos (de indies a AAA) e jogá-los para se manter criativo. Espero que eu consiga mostrar estas mudanças no desenvolvimento do Final Frontier e no próximo Ludum Dare em Dezembro.\nImagem da capa: Vector Flat Game Illustration do Shutterstock.\n","date":"14 de setembro de 2016","externalUrl":null,"permalink":"/por-que-jogar-jogos-diferentes/","section":"Blog","summary":"Isto é algo que já escrevi aqui no blog, mas recentemente percebi que eu não estava fazendo. Ultimamente tenho jogado sempre os mesmos jogos, e isto ficou refletido nos últimos jogos que fiz participando do Ludum Dare.\n","title":"Por que temos que jogar jogos diferentes","type":"posts"},{"content":"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.\nDesta 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.\nSubstituindo colisão do tiro por Raycast\nNo ú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.\nPor 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.\nO 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.\nSpawner de objetos com prototype\nAgora 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).\nO 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.\nReaproveitar 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.\nMétodo MoSCoW\nAntes 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.\nMais 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:\nMust 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 \u0026quot;Won't have\u0026quot; é 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.\nAbaixo 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. \u0026quot;Nice to have\u0026quot; e \u0026quot;Good to have\u0026quot; equivalem a \u0026quot;Should have\u0026quot; e \u0026quot;Could have\u0026quot;, respectivamente, e não tem o \u0026quot;Won't have\u0026quot;. 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).\nNo verso desta folha adicionei uma lista chamada \u0026quot;Backlog\u0026quot; para listar ideias que tive durante o desenvolvimento das tarefas, assim posso planejar a próxima lista considerando estas ideas como possíveis tarefas.\nPróximos Passos\nAgora 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.\nO 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!\n","date":"8 de setembro de 2016","externalUrl":null,"permalink":"/final-frontier-raycast-e-spawn/","section":"Blog","summary":"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.\n","title":"Final Frontier: Raycast, Spawn e MoSCoW","type":"posts"},{"content":"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.\nAntes 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.\nGame Design\nDesta 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.\nA 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.\nO 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.\nInfelizmente 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.\nO 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.\nProgramação\nRepeti 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.\nAtualmente 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).\nDesta 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.\nNos ú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.\nEste 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.\nArte\nNã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.\nInfelizmente 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.\nConclusão\nNa 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.\nEsta 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).\nAinda 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.\nO 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.\n","date":"30 de agosto de 2016","externalUrl":null,"permalink":"/ludum-dare-36/","section":"Blog","summary":"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.\n","title":"Minha participação no Ludum Dare #36","type":"posts"},{"content":"Sexta-feira às 22h (horário de Brasilia) começa o Ludum Dare #36, e será minha quinta participação nesta game jam.\nSemana passada realizei uma palestra na USP sobre game jams e dei muitas dicas importantes para participar deste tipo de competição, principalmente no Ludum Dare que tempo mais experiência. Confira os slides da apresentação aqui, tem muito conteúdo útil se você também pretende participar.\nAbaixo estão algumas coisas que vou fazer nesta edição do Ludum Dare, separando pelas que eu recomendo e as que eu não recomendo (a não se que tenha experiência).\nNão recomendo, mas vou fazer # Em 3 edições do Ludum Dare usei a Unity, e na última a Defold (que foi um grande desafio por não conhecer). Desta fez quero usar algo que conheço mas não uso há um bom tempo, a Cocos2d-x, um framework para desenvolver jogos em C/C++.\nFocar em game design. Na minha apresentação é possível ver o gráfico abaixo que mostra que a qualidade dos meus jogos aumentou, porém o game design diminuiu. Desta vez este será o principal foco.\nTentar fazer arte e som para o jogo. Na última edição consegui fazer uma arte bem legal, vou tentar repetir o feito nesta.\nPara aproveitar melhor o tempo vou tentar não dormir no primeiro ou no segundo dia. Sempre tento, mas acabo dormindo, vamos ver se desta vez consigo.\nSempre fiz os jogos do Ludum Dare pensando na plataforma Web, pois é mais fácil para colocar o jogo lá e testar. Desta vez quero que o foco seja mobile, então minha prioridade será Android.\nDicas importantes # Escolha a linguagem de programação, framework ou game engine antes de começar e tenha certeza de que tudo está atualizado para não perder tempo esperando downloads.\nVai ser necessário criar arte e som, então já se prepare antecipadamente para isso (mesmo que você ache que não vai dar tempo, se prepare pois vai que dá).\nSe você tem dificuldade em se concentrar, não deixe a TV ligada e evite YouTube, tente ouvir trilha sonoras ou músicas que você gosta.\nParece bobo mas planeja como serão suas refeições, e tente não sair pra comer pois isso pode te custar um tempo precioso.\nPlaneje o que fazer em caso de falta de internet e/ou falta de energia elétrica, é sempre bom ter um plano B e um lugar pra ir (algo tipo Starbucks, por exemplo).\nLinks interessantes:\nMinha participação no Ludum Dare #32\nMinha participação no Ludum Dare #33\nMinha participação no Ludum Dare #34\nMinha participação no Ludum Dare #35\n","date":"23 de agosto de 2016","externalUrl":null,"permalink":"/esta-semana-comeca-o-ludum-dare-36/","section":"Blog","summary":"Sexta-feira às 22h (horário de Brasilia) começa o Ludum Dare #36, e será minha quinta participação nesta game jam.\n","title":"Esta semana começa o Ludum Dare #36","type":"posts"},{"content":"Este foi o tema da minha palestra apresentada apresentada na 6ª Semana de Sistemas de Informação da USP hoje. Nesta palestra falei sobre game jams, dei dicas para aproveitar melhor o tempo de um game jam e focar no desenvolvimento do jogo, e contei como foram minhas participações no Ludum Dare.\nMuito obrigado ao pessoal da organização do evento pelo convite e parabéns pelo evento!\n","date":"17 de agosto de 2016","externalUrl":null,"permalink":"/game-jams-como-fazer-um-jogo-em-48h/","section":"Blog","summary":"Este foi o tema da minha palestra apresentada apresentada na 6ª Semana de Sistemas de Informação da USP hoje. Nesta palestra falei sobre game jams, dei dicas para aproveitar melhor o tempo de um game jam e focar no desenvolvimento do jogo, e contei como foram minhas participações no Ludum Dare.\n","title":"Game Jams - Como fazer um jogo em 48h","type":"posts"},{"content":"Eu sempre recebo e-mails pedindo para divulgar jogos, porém isto é algo que decidi desde o início do blog não fazer. Eu acho importante divulgar, mas fazer um post falando de um jogo não é o tipo de conteúdo que eu quero para o blog, por isso sempre respondo falando que não faço reviews ou divulgação de jogos, mas sempre ofereço uma oportunidade para divulgação do jogo através de um postmortem. Desta forma o desenvolver ganha sua divulgação, e os leitores deste blog ganham uma história sobre o desenvolvimento de um jogo.\nIsto é importante por que é possível aprender muito apenas lendo o que outras pessoas fizeram e deu certo, e também o que deu errado. Já vi muita gente falando que aprendeu com os postmortems publicados aqui, por isso fico feliz em sempre ter este espaço para todo desenvolver que tem seu jogo publicado (esta é a única regra). Não importa se o texto é longo e detalhado, ou curto e objetivo, sempre podemos aprender a partir da experiência dos outros.\nDesta vez vamos ver como foi o desenvolvimento do jogo Geometry World do Eder Gabriel. Muito obrigado por enviar o texto abaixo e parabéns pelo jogo publicado!\nGeometry World\nOlá! Sou o Eder, designer do Geometry World. Abaixo a descrição dele, compartilhando alguns pontos que percebi durante a criação do game.\nDescrição do game\nGeometry World é um puzzle em que o jogador tem como objetivo colocar a caixa em um determinado lugar do cenário. O jogo tem cinquenta níveis divididos em cinco mundos com características particulares, por exemplo, o segundo mundo tem as colunas deslizantes. Apenas posicionando a caixa na posição determinada, o jogador desbloqueia os primeiros quarenta níveis do jogo. O último mundo é desbloqueável coletando as medalhas de conquista disponível de acordo com o objetivo dos 40 níveis anteriores.\nPara controlar a caixa, o jogador deve segurar na tela e direcioná-la para a direção em que ele queira. Os principais desafios são conseguir todas as conquistas dos cinquenta níveis e se acostumar com a física do jogo.\nPor eu estar mais preocupado com os aspectos funcionais do jogo, criei o design dele mais minimalista para diminuir o tempo de criação do jogo. Essa foi uma dúvida que eu fiquei por um tempo, de como alinhar uma arte funcional para o game, sem gastar muito tempo. Um requisito meu nesse projeto foi o de não usar palavras nas ações do jogo, apenas ícones.\nConforme fui mostrando para os amigos mais próximos, reparei em alguns pontos que não ficaram claros o suficiente e provavelmente, eu crie em novas formas de apresentar isso nas futuras versões. Esses mesmos testes também me fizeram a dar um maior valor a como ensinar as pessoas a jogar nas telas iniciais.\nPontos Negativos\nTive um atraso para concluir o game porque num teste com o iPod Touch, alguns cenários não estavam com a resolução ideal, porque o jogador não conseguia fazer o movimento correto para alcançar um determinado lugar.\nPor se tratar de um jogo mais longo, pude aplicar alguns conceitos de level design. Mas sempre tem alguns pontos que ficam pendentes, por eu não ter ninguém para testar e discutir quando eu estava definindo como seriam os níveis.\nTem um erro que não descobri o que faz com que ele não reconheça a posição do jogador quando ele posiciona no lugar correto. Ele é bem inconstante, nas próximas versões, vou ter que inventar uma outra forma de validação, porque quando é reiniciado o app e concluindo a mesma fase, o erro desaparece.\nUma outra dificuldade foi colocar e testar o aplicativo na AppStore, por ser bem rígido o controle deles são necessários diversos certificados no iMac e no iTunes Connect que fui descobrindo e sempre acabava atrasando a publicação.\nTenho pesquisado algumas formas de propaganda, mas o mais difícil é convencer alguém que não me conhece a pagar pelo jogo e criei um flyer para divulgar por aí.\nPontos Positivos\nDescobri o Corona SDK em uma pesquisa na faculdade, por ter uma curva de aprendizado menor em relação aos outros, acabei utilizando ele. Depois de alguns testes e a criação do meu primeiro game mobile, o Moving Kart, percebi que era possível criar algo mais complexo, que a comunidade do Corona é bem ativa e as minhas dúvidas sempre foram explicadas de algum jeito. Fiquei surpreso com o tamanho final do meu app para um jogo de 50 níveis (menos de 9MB).\nSempre tive o interesse em criar um aplicativo na AppStore para tentar deixar o meu portfolio mais interessante e consegui depois de 10 meses de produção e alguns meses que ficou congelado o projeto.\nE o aprendizado que ganho com isso é enorme, principalmente, por ter que planejar todas as possibilidades do game, já que fiz sozinho, esse projeto me ajudou a ser mais analítico com qualquer sistema que eu crie no futuro.\nLinks\nDownload pela App Store\nPágina no Facebook\n","date":"16 de agosto de 2016","externalUrl":null,"permalink":"/postmortem-geometry-world/","section":"Blog","summary":"Eu sempre recebo e-mails pedindo para divulgar jogos, porém isto é algo que decidi desde o início do blog não fazer. Eu acho importante divulgar, mas fazer um post falando de um jogo não é o tipo de conteúdo que eu quero para o blog, por isso sempre respondo falando que não faço reviews ou divulgação de jogos, mas sempre ofereço uma oportunidade para divulgação do jogo através de um postmortem. Desta forma o desenvolver ganha sua divulgação, e os leitores deste blog ganham uma história sobre o desenvolvimento de um jogo.\n","title":"Postmortem: Geometry World","type":"posts"},{"content":"Na parte 1 falei sobre dicas para reduzir o tamanho das imagens e melhores resoluções para dispositivos móveis, e na parte 2 o foco foi o plugin NGUI (mas as dicas também se aplicam ao UI da Unity) e ao uso de sprite sheets. Desta vez o foco serão melhores práticas de programação para jogos 2D na Unity.\nApesar de ter o foco em 2D, boa parte do conteúdo deste post abrange jogos em 3D na Unity também. No site da Unity existe uma categoria de Melhores Práticas excelente, falando de física, assets e UI.\nO Update\nQuando criamos um novo script na Unity, por padrão os métodos Start() e Update() são adicionados ao código. O maior problema é não dar atenção a este detalhe, pois muitos programadores deixam estes métodos mesmo vazios no script, e isto pode fazer diferença no desempenho do jogo dependendo da quantidade de scripts sendo usados.\nInternamente a Unity executa todos os Update() que encontra nos scripts ativos na cena do jogo, mesmo eles estando vazios. Este artigo publicado no blog da Unity explica este problema em maiores detalhes. Se você não for utilizar o método, simplesmente remova do seu código. O Start() não faz muita diferença, mas o Update() pode reduzir o seu frame rate significativamente, principalmente em dispositivos móveis.\nImagens e sprite sheets de jogos 2D podem ocupar mais espaço em disco e memória do que modelos 3D com textura, o que pode exigir um processamento extra do hardware que pode ser adquirido seguindo boas práticas como esta mencionada acima.\nA Física\nA Unity possui uma versão 2D para praticamente todo componente disponível no 3D, e mesmo sendo otimizado pode exigir bastante processamento do hardware se existirem muitos objetos na cena. Se eu não me engano, mesmo que o objeto não esteja sendo desenhado na tela, sua física continua ativa para verificações de colisão fora da tela. Se no seu jogo existem muitos objetos colidindo ao mesmo tempo em uma cena podemos desabilitar a física (ou mesmo o objeto inteiro) quando ele estiver fora da tela.\nPor exemplo, em um jogo de estratégia como StarCraft podemos \u0026quot;ligar\u0026quot; a física dos objetos quando as unidades do jogador estiverem em uma área próxima das unidades do imigo. Para evitar verificações em cada update (e poder ter o problema do tópico anterior), você pode deixar a física habilitada no líder do grupo, e fazer ele habilitar a física nos depois com um callback quando chegar na área do inimigo. É apenas uma ideia, provavelmente existe maneiras ainda melhores pra isso, mas o ponto é que muitos objetos com física ativada podem causar problemas de desempenho.\nA Defold, uma game engine desenvolvida pela King para jogos 2D, limita o número de objetos com colisão por nível. Tive este problema quando estava desenvolvendo o jogo Metaforce para o Ludum Dare #35, montei o mapa inteiro com colisão para o personagem não atravessar as paredes, mas o limite da engine (que eu não sabia) me fez mudar a maneira de verificar a colisão com o cenário.\nO Loading\nIsto depende muito do jogo, mas geralmente temos duas maneiras de carregar as imagens do cenário: tudo de uma vez ou aos poucos. A vantagem de carregar tudo de uma vez é que o jogo flui sem a necessidade de fazer o load de imagens do disco para a memória durante o jogo, mas a desvantagem é que em alguns hardwares isto pode fazer o jogo usar toda memória disponível e quebrar, ou pode ser que o loading seja muito longo em aparelhos com hardware fraco.\nCarregar aos poucos, ou Lazy Loading como é conhecido, é você carregar as imagens apenas quando for necessário. Por exemplo, você não precisa carregar a arte do chefão sem saber se o jogador vai chegar no final da fase para enfrentá-lo, ou carregar todas as imagens de achievements do jogo, mesmo sendo difícil de conseguir todos na mesma fase. A vantagem disso é que você usa apenas a memória necessária para carregar as imagens que precisa no momento, e assim o loading inicial fica mais rápido e com um risco menor de quebrar o jogo em aparelhos com hardware fraco. A desvantagem é que você vai precisar escrever o código para gerenciar o loading de recursos do jogo para que sejam carregados apenas quando necessários.\nAh, e não se esqueça de ter uma tela de loading ou um feedback para que o jogar saiba o que está acontecendo. Isto é mais Game Design do que Programação, mas vale a pena sempre pensar neste detalhes durante o desenvolvimento.\nEsta foi a terceira e última parte sobre melhores práticas para fazer um jogo em 2D na Unity. A ideia inicial era ter publicar estes posts em sequencia, porém demorei mais de 1 ano para publicá-los. Se você quiser saber mais sobre desenvolvimento de jogos com Unity acompanhe o desenvolvimento do meu jogo Final Frontier, estou escrevendo um post sobre o progresso do jogo a cada 2 semanas.\n","date":"10 de agosto de 2016","externalUrl":null,"permalink":"/melhores-praticas-2d-unity-parte-3/","section":"Blog","summary":"Na parte 1 falei sobre dicas para reduzir o tamanho das imagens e melhores resoluções para dispositivos móveis, e na parte 2 o foco foi o plugin NGUI (mas as dicas também se aplicam ao UI da Unity) e ao uso de sprite sheets. Desta vez o foco serão melhores práticas de programação para jogos 2D na Unity.\n","title":"Melhores práticas para 2D na Unity - Parte 3","type":"posts"},{"content":"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.\nUm planeta na galáxia\nUm 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.\nEu 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.\nPilotando a nave\nAté 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.\nEu 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.\nO 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 \u0026gt; Project Settings \u0026gt; Input).\nCâmera\nNa 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.\nMeu 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).\nPróximos passos\nAgora 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.\nO 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!\n","date":"3 de agosto de 2016","externalUrl":null,"permalink":"/final-frontier-camera-e-controle/","section":"Blog","summary":"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.\n","title":"Final Frontier: Câmera e controle","type":"posts"},{"content":"Este post foi uma sugestão do leitor Felipe, que inclusive me enviou boa parte do conteúdo abaixo. Ser um desenvolvedor independente não é fácil, principalmente quando se tem pouco ou nenhum recurso para investir.\nAté pouco tempo atrás a maneira mais comum para nós brasileiros conseguir investimento era ir atrás de publishers de fora e apresentar um jogo quase pronto, nada de idéias ou protótipos inacabados. E mesmo sendo possível conseguir investidores fora do país, ainda assim era necessário tirar dinheiro do próprio bolso para construir o jogo antes de ser apresentado, além dos custos de viajar para eventos e apresentar o jogo.\nFelizmente aos poucos isso tem mudado no Brasil, e agora temos algumas opções para ter o jogo financiado por programas do governo. Alguns estúdios brasileiros já se beneficiaram ou estão se beneficiando dos programados que vou comentar abaixo. Não sou especialista neste assunto, portanto o conteúdo abaixo foi escrito baseado nos links que recebi e mais o que pesquisei. A ideia deste post é mostrar as alternativas que temos no Brasil, e não entrar em discussões políticas.\nLei Rouanet\nAcredito que o primeiro programa do governo que passou a aceitar jogos foi a Lei Rouanet do Ministério da Cultura, que depois de muito custo começou a ver jogos como uma expressão artística e não como um brinquedo ou jogo de azar. O jogo Toren, da Swordtales, conseguiu investimento através desta lei e foi lançado ano passado para PC e PS4. O vídeo abaixo explica como funciona este programa.\nEditais da Prefeitura de São Paulo\nA prefeitura de São Paulo tem editais voltado para investimento em produções audiovisuais, e jogos são aceitos. My Night Job, da Webcore Games, foi lançado este ano com investimento obtido através de um edital. Ninjin: Clash of Carrots, da Pocket Trap, também conseguiu investimento pelo edital da prefeitura.\nApós o Big Festival, o edital Batalha Animada foi aberto e conta com R$100 mil para o desenvolvimento de games para dispositivos móveis. Mais R$100 mil são oferecidos por uma parceria com o Canadá. É claro que não é fácil conseguir o investimento através de um edital, mas existem algumas opções e vale a pena ficar de olho no site da Spcine.\nINOVApps\nO INOVApps é um concurso do Ministério das Comunicações que tem como objetivo apoiar o desenvolvimento de aplicativos para dispositivos móveis. É um pouco difícil encaixar um jogo neste concurso, pois ele requer que o projeto se encaixe em algumas categorias específicas, e a mais segura para jogos é Educação/Ensino. Não é um concurso difícil de participar e ganhar, pois não há apenas um projeto selecionado, mas precisa ter um bom material para ser submetido e se adequar ao edital do concurso.\nParece que alguns jogos que ganharam este concurso ano passado tiveram seu financiamento suspenso devido a uma decisão judicial, mas este é o único link sobre o assunto.\nBNDES\nA Aquiris, desenvolvedora do Horizon Chase que venceu o prêmio de melhor jogo no Big Festival, foi a primeira empresa brasileira do setor de games a conseguir investimento do BNDES. Foram R$ 1,5 milhão financiados para o plano de negócios da empresa. Eu acredito que este deve ser o financiamento mais difícil de conseguir, mas também é o que deve investir o maior valor em uma empresa.\nOutras formas de investimento\nApesar de ser um concurso, o Big Festival possui um bom prêmio para os vencedores e, o que é mais importante na minha opinião, visibilidade internacional. Os vencedores saíram em portais de games no Brasil e no exterior, o que pode ajudar bastante a divulgar o jogo e talvez abrir novos investimentos para a empresa.\nNão tenho certeza, mas acho que para a maioria dos programas acima é necessário ter uma empresa aberta, por isso concursos são uma boa forma de conseguir dinheiro para investir em projetos.\nSe você conheço outros incentivos financeiros para desenvolver jogos no Brasil deixe um comentário abaixo que eu adiciono nesta lista.\nImagem da capa: Young man using a laptop do Shutterstock.\n","date":"27 de julho de 2016","externalUrl":null,"permalink":"/incentivos-financeiros-gamedev/","section":"Blog","summary":"Este post foi uma sugestão do leitor Felipe, que inclusive me enviou boa parte do conteúdo abaixo. Ser um desenvolvedor independente não é fácil, principalmente quando se tem pouco ou nenhum recurso para investir.\n","title":"Incentivos financeiros para desenvolver jogos no Brasil","type":"posts"},{"content":"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.\nAo infinito e além\nSkybox é o nome da textura que fica no \u0026quot;fundo\u0026quot; do cenário renderizado pela câmera principal. O skybox padrão da Unity é um céu azul e um \u0026quot;chão\u0026quot; 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)!\nEsta 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.\nAdicionando mais destruição\nNo post anterior eu tinha colocado apenas uma caixa que, quando o tiro colide com ela, o modelo 3D é substituído pela versão \u0026quot;destruída\u0026quot; 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.\nMuitos 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.\nO 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.\nOrganizando a casa\nUma 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.\nOutra 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.\nPróximos passos\nEu 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).\nO 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!\n","date":"20 de julho de 2016","externalUrl":null,"permalink":"/final-frontier-skybox-e-mais-destruicao/","section":"Blog","summary":"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.\n","title":"Final Frontier: Skybox e mais destruição","type":"posts"},{"content":"Minecraft conseguiu criar uma cultura e se tornou muito mais do que apenas um jogo, hoje é usado até na educação de crianças, como pode ser visto no documentário Minecraft: The Story of Mojang. Hoje é possível até aprender a programar usando o jogo, e é isso que o livro Aprenda a Programar com Minecraft do Craig Richardson faz de uma maneira incrivelmente didática.\nEste livro, lançado no Brasil pela editora Novatec, ensina lógica de programação utilizando a linguagem Python e usado o jogo Minecraft como ferramenta para exibir os resultados. Ou seja, após cada lição, é possível modificar e testar o que foi ensinado no jogo Minecraft para criar estruturas, blocos, itens, entre outras coisas.\nTodas as lições no livro possuem imagens do jogo para mostrar como é o resultado esperado, o que ajuda bastante. Ao invés de aprender a programar em Python utilizando o terminal ou prompt de comando, tudo que é programado pode ser visto no jogo, seja em formato visual (blocos, por exemplo) ou em mensagens de texto na tela do jogo.\nO autor já trabalhou na Fundação Raspberry Pi, por isso além de Windows e Mac também é possível seguir o livro utilizando Raspberry Pi. O capítulo inicial do livro ensina a configurar o ambiente de desenvolvimento, inclusive com o Minecraft API e Minecraft Server.\nO livro cobre todo básico de programação com Python: variáveis, strings, condicionais, loops, funções, operações básicas de matemática e lógica, estruturas de dados como lista e dicionário, e como salvar o progresso ou estado do jogo em arquivos de texto. Por fim um ótimo capítulo, porém básico, sobre orientação a objetivos com Python, tudo para deixar o leitor com uma vontade de continuar aprendendo a programar e testar seus programas no Minecraft.\nEste livro é incrível para quem quer aprender a programar, e o uso do Minecraft é um grande diferencial para incentivar até mesmo crianças e adolescentes a entrarem para o lado negro da força e se tornarem programadores. Dependendo da idade provavelmente é necessário o acompanhamento de um adulto, pelo menos para configurar o computador e fazer os primeiros exercícios, mas depois acho que é possível continuar sozinho.\nApós terminar este livro se você quiser continuar estudando desenvolvimento de jogos com Python, com certeza o próximo livro que eu indico é o Introdução ao Desenvolvimento de Jogos em Python com PyGame. Assim você terá toda base necessária para programar jogos em Python, ou pelo menos criar mods mais complexos para Minecraft. É claro que existem diversos livros sobre Python, mas acredito que estes dois são suficientes para iniciar tanto na programação em Python quanto desenvolvimento de jogos.\nMuito obrigado a editora Novatec por me enviar este livro. Este livro pode ser adquirido pelo site da Novatec ou em praticamente qualquer livraria. Recomendo também dar uma olhada no site do autor, Craig Richardson, pois tem bastante conteúdo adicional para o livro disponível lá (em Inglês).\n","date":"13 de julho de 2016","externalUrl":null,"permalink":"/programar-com-minecraft/","section":"Blog","summary":"Minecraft conseguiu criar uma cultura e se tornou muito mais do que apenas um jogo, hoje é usado até na educação de crianças, como pode ser visto no documentário Minecraft: The Story of Mojang. Hoje é possível até aprender a programar usando o jogo, e é isso que o livro Aprenda a Programar com Minecraft do Craig Richardson faz de uma maneira incrivelmente didática.\n","title":"Aprenda a Programar com Minecraft","type":"posts"},{"content":"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.\nO 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.\nComo brincar no playground\nComo 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.\nA 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 \u0026quot;Playground\u0026quot;.\nOs scripts estão dentro de um namespace chamado \u0026quot;Playground\u0026quot;, 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.\nÉ 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 \u0026quot;dura\u0026quot;. Isso vai fazer mais sentido quando implementar o controle completo da nave.\nDestruindo objetos 3D\nDestruiçã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 \u0026quot;destruído\u0026quot;, e quando o objeto é destruído você substitui pelo modelo destruído e aplica alguma física nos destroços se necessário.\nComo 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.\nPróximos passos\nVou 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.\nFique 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.\n","date":"6 de julho de 2016","externalUrl":null,"permalink":"/final-frontier-playground-e-destruicao/","section":"Blog","summary":"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.\n","title":"Final Frontier: Playground e destruição","type":"posts"},{"content":"Fazem quase 7 anos que escrevi este post com uma lista de livros para desenvolvimento de jogos. Naquela época a lista foi baseada em duas coisas: o conteúdo da pós-graduação que eu estava cursando e o que estava disponível no momento. Felizmente, 7 anos depois, muitos livros novos surgiram e alguns foram traduzidos e lançados no Brasil, inclusive fiz review de grande parte deles.\nNão foi só isso que mudou. 7 anos atrás eu ainda não trabalhava com jogos e este blog estava começando, tinha apenas 4 meses de existência e uns 5 posts. Estava na hora de escrever um novo post atualizado com sugestões de livros. Sempre que me perguntam por e-mail ou realizo palestras costumo sugerir a lista abaixo, que na minha opinião muitos são leituras obrigatórias para todo desenvolvedor de jogos. Clique nas imagens para conferir mais detalhes dos livros.\nApesar de serem muitos livros, foi difícil deixar alguns de fora desta lista. Provavelmente irei fazer outro lista em um post futuro com mais livros. Comparada com a lista do meu post de 7 anos atrás apenas dois livros permanecera: Game Design Workshop, que ganhou uma nova edição, e Desenvolvimento de Jogos Eletrônicos, que está novamente esgotado. Os últimos quatro livros da lista são em português e estão disponíveis no Brasil, confira as reviews do livro Level Up! e do livro Produção de Jogos Digitais, os demais estão disponíveis apenas em inglês.\nNeste post existem mais sugestões de livros em português lançados no Brasil, porém eu recomendo dar uma olhada nos livros em inglês também. Nesta lista selecionei 10 livros que são bem abrangentes em seus assuntos, porém na próxima lista os livros serão mais específicos para um determinado assunto, como matemática para jogos, game design de jogos de tabuleiro, efeitos sonoros, entre outros.\n","date":"29 de junho de 2016","externalUrl":null,"permalink":"/livros-gamedev/","section":"Blog","summary":"Fazem quase 7 anos que escrevi este post com uma lista de livros para desenvolvimento de jogos. Naquela época a lista foi baseada em duas coisas: o conteúdo da pós-graduação que eu estava cursando e o que estava disponível no momento. Felizmente, 7 anos depois, muitos livros novos surgiram e alguns foram traduzidos e lançados no Brasil, inclusive fiz review de grande parte deles.\n","title":"Livros para desenvolver jogos - atualizado!","type":"posts"},{"content":"Decidi começar um novo projeto no meu tempo livre e colocar em um repositório público no GitHub para quem quiser acompanhar o desenvolvimento do jogo em Unity. Este é o primeiro de uma série de posts que vão contar detalhes sobre o desenvolvimento deste projeto, fazendo referências aos posts da série como ser um programador de jogos. Neste post, quero contar um pouco sobre como surgiu a ideia para este projeto e onde quero chegar com ele.\nEu sempre fui um fã de jogos com tema de ficção científica, e entre meus favoritos estão as séries Metroid, Starcraft, Halo, Mass Effect, Endless Space, Star Wars: Knighs of the Old Republic e Destiny. Até nos jogos de tabuleiro tenho essa preferência pelo tema e gosto muito dos jogos Race for the Galaxy, Roll for the Galaxy, Star Trek Catan, Star Realms, e muitos outros que ainda não tenho. E nem preciso falar que sou fã de Star Wars, Star Trek, Doctor Who, Battlestar Galactica e Firefly. Muitos dos meus livros favoritos são dos autores Isaac Asimov e Douglas Adams.\nPor causa de todas estas referências acima decidi iniciar o desenvolvimento de um jogo de ficção científica. Ainda não defini como o jogo será, por isso iniciei o desenvolvimento de um playground para explorar ideias. O playground é um pouco diferente de um protótipo por que nele o objetivo é a exploração, e não a validação de uma mecânica ou ideia.\nUma coisa eu já defini: quero que tenha uma nave para o jogador pilotar e que exista combates e exploração no espaço. Por isso, iniciei o projeto com um modelo 3D de nave gratuita que baixei na Asset Store da Unity e fiz ela atirar \u0026quot;bolas de ping-pong\u0026quot; em um cubo, enquanto se move. Como estou explorando a mecânica, os scripts utilizados até agora não foram escritos pensando em serem reutilizados no jogo. Outro detalhe definido é o nome do jogo: Final Frontier; uma referência a Star Trek e minha homenagem ao Leonard Nimoy.\nO meu objetivo é desenvolver todo o protótipo do jogo utilizando a Unity e deixando o projeto público no GitHub, por isso todos recursos e plugins utilizados serão sempre gratuitos e com os devidos créditos adicionados. Se eu decidir que vale a pena investir neste projeto provavelmente irei terminar o desenvolvimento do protótipo e iniciar o desenvolvimento do jogo em um repositório particular, mas isto é algo pra se pensar quando o jogo estiver definido e testado. Durante o desenvolvimento do protótipo pretendo também criar e disponibilizar documentos, como o Game Design Document.\nQualquer feedback é sempre bem-vindo! E se você não conhece algumas das minhas referências, recomendo dar uma olhada pois vale muito a pena! Ah, a imagem da capa foi tirada em uma partida de Star Trek Catan, tão bom quanto o jogo original.\n","date":"22 de junho de 2016","externalUrl":null,"permalink":"/inicio-do-projeto-final-frontier/","section":"Blog","summary":"Decidi começar um novo projeto no meu tempo livre e colocar em um repositório público no GitHub para quem quiser acompanhar o desenvolvimento do jogo em Unity. Este é o primeiro de uma série de posts que vão contar detalhes sobre o desenvolvimento deste projeto, fazendo referências aos posts da série como ser um programador de jogos. Neste post, quero contar um pouco sobre como surgiu a ideia para este projeto e onde quero chegar com ele.\n","title":"Inicio do projeto Final Frontier","type":"posts"},{"content":"Eu já fiz jogos com mecânicas de FPS, porém eu sempre procuro tutoriais sobre o que eu quero fazer para aprender maneiras diferentes de fazer as mesmas coisas.\nEstá é uma boa dica que gostaria de deixar neste post: mesmo que você saiba fazer algo existe sempre outras maneiras de fazer, que podem ser melhores, iguais ou piores do que a maneira que você costuma fazer. Por isso é muito importante sempre pesquisar na internet, ler livros e assistir videos sobre o assunto, com certeza pelo menos um detalhe novo deve surgir e vai te ajudar.\nVoltando ao assunto do post, eu encontrei este canal (em Inglês) chamado quill18creates com muitos videos sobre desenvolvimento de jogos para Unity e Blender. O autor do canal, Martin \u0026quot;quill18\u0026quot; Glaude, possui um outro canal com foco jogos chamado quill18.\nVou colocar alguns videos que gostei abaixo, porém recomendo dar uma olhada em nos outros videos e playlists do canal. As playlists abaixo contém videos sobre geração procedural, algoritmo pathfind para movimentação e objetos destrutíveis, respectivamente.\nSe você conhece outros canais no YouTube sobre desenvolvimento de jogos deixe nos comentários!\n","date":"15 de junho de 2016","externalUrl":null,"permalink":"/tutoriais-jogos-unity/","section":"Blog","summary":"Eu já fiz jogos com mecânicas de FPS, porém eu sempre procuro tutoriais sobre o que eu quero fazer para aprender maneiras diferentes de fazer as mesmas coisas.\n","title":"Tutoriais de desenvolvimento de jogos com Unity e Blender","type":"posts"},{"content":"Eu não tenho um Xbox One (ainda), mas após a Microsoft anunciar uma atualização que transformou qualquer Xbox One em um kit de desenvolvimento eu comecei achar interessante a ideia de ter o console para jogar e desenvolver jogos.\nEstes são os pré-requisitos para transformar seu console em uma ferramenta para desenvolvimento de jogos:\nParticipar do programa Windows Insider Ter Windows 10 atualizado no seu computador Conectar o computador no Xbox One através de um cabo Instalar a última versão do Visual Studio 2015 Ter pelo menos 30GB de espaço disponível no Xbox One Ainda não tive a oportunidade de testar o Xbox One no modo desenvolvedor, mas assim que eu conseguir pretendo postar mais informações e sobre como funciona a integração com a Unity.\n","date":"8 de junho de 2016","externalUrl":null,"permalink":"/xbox-one-modo-dev/","section":"Blog","summary":"Eu não tenho um Xbox One (ainda), mas após a Microsoft anunciar uma atualização que transformou qualquer Xbox One em um kit de desenvolvimento eu comecei achar interessante a ideia de ter o console para jogar e desenvolver jogos.\n","title":"Como desbloquear o Xbox One para o modo desenvolvedor","type":"posts"},{"content":"A CryEngine já tinha seu código aberto porém, por não ter um instalador, era necessário baixar todo código sempre que algum update era realizado. E o projeto não é pequeno para ser baixado a cada alteração, por isso muitas vezes é comum o desenvolvedor trabalhar com uma versão fixa da engine sem atualizar durante todo o projeto.\nAgora que seu código está no GitHub, e não é mais um ZIP no site, desenvolvedores podem manter o código sempre atualizado, baixando apenas as atualizações do repositório.\nSeria bom a Amazon fazer algo semelhante para a sua engine Lumberyard, que foi construída em cima da CryEngine. Embora exista uma ferramenta de update, não é muito claro o que foi alterado. Em projetos de código aberto isto é muito importante.\nA Unreal Engine também está disponível no GitHub, e possui a mesma vantagem para os desenvolvedores terem seu código atualizado.\nNa minha opinião isto é algo que Unity deve fazer logo, não abrir seu código necessariamente, mas ter um update melhor do que fazer o desenvolvedor baixar quase 10GB todo mês pra manter a engine atualizada para todas plataformas.\n","date":"25 de maio de 2016","externalUrl":null,"permalink":"/crytek-lanca-codigo-da-cryengine-no-github/","section":"Blog","summary":"A CryEngine já tinha seu código aberto porém, por não ter um instalador, era necessário baixar todo código sempre que algum update era realizado. E o projeto não é pequeno para ser baixado a cada alteração, por isso muitas vezes é comum o desenvolvedor trabalhar com uma versão fixa da engine sem atualizar durante todo o projeto.\n","title":"Crytek lança código da CryEngine no GitHub","type":"posts"},{"content":"O site Polygon publicou uma notícia sobre um canal do YouTube onde o autor cria videos ensinando técnicas de game design enquanto joga Super Mario 64.\nO jogo lançado para o Nintendo 64 e criado pela lenda vida Shigeru Miyamoto possui tantos detalhes que normalmente passam despercebidos, mas se retirarmos eles o jogo perde um pouco do seu brilho. São estes detalhes que o canal pannenkoek2012 busca exemplificar e ensinar.\nEu selecionei dois videos que eu gostei, mas eu recomendo dar uma olhada nos demais videos do canal.\nSe você quiser ler mais sobre o quão incrível o Super Mario 64 é, dê uma lida nesta matéria do IGN.\n","date":"18 de maio de 2016","externalUrl":null,"permalink":"/aprenda-game-design-jogando-super-mario-64/","section":"Blog","summary":"O site Polygon publicou uma notícia sobre um canal do YouTube onde o autor cria videos ensinando técnicas de game design enquanto joga Super Mario 64.\n","title":"Aprenda game design jogando Super Mario 64","type":"posts"},{"content":"John Romero, co-fundador da Id Software e criador dos jogos DOOM e Quake, entre muitos outros, deu uma palestra em um evento da revista britânica Develop e falou sobre algumas técnicas para desenvolvimento que ele sempre usou, muitas indo contra ao que encontramos nos livros. Abaixo estão algumas frases que retirei do texto, a notícia completa pode ser lida aqui.\n“No prototypes,” he said. “Just make the game. Polish as you go. Don’t depend on polish happening later. Always maintain constantly shippable code.\nTradução:\n\u0026quot;Sem protótipos\u0026quot;, ele disse. \u0026quot;Apenas crie o jogo. Faça polimento durante o projeto. Não conte com o polimento acontecendo mais tarde. Sempre tenha código pronto para ser lançado.\u0026quot;\nNa continuação do texto ele fala que se existe muito dinheiro e pessoas envolvidas, que provavelmente haverá um protótipo, mas quando se é pequeno e independente (como ele era). Segundo Romero, o melhor é sempre desenvolver algo final ao invés do ciclo que normalmente inicia com um protótipo, que então é descartado para desenvolver o jogo, e após o desenvolvimento estar completo entra na fase de polimento.\nIsso faz muito sentido quando pensamos em empresas pequenas e independentes, mas é claro que existe um risco da equipe desenvolver um jogo se que muitas perguntas importantes tenham sido respondidas na fase de protótipo. Acho que se o game designer tem experiência, e o jogo está bem claro para a equipe, este é um risco que pode ser tomado. Muitas vezes não há tempo suficiente para fazer um protótipo, por isso é comum mesmo as empresas partirem para o jogo final desde o começo.\n“As soon as you see a bug, you fix it. Do not continue on. If you don’t fix your bugs, your new code will be built on a buggy codebase and ensure an unstable foundation.”\nTradução:\n\u0026quot;Ao encontrar um bug, corrija-o. Não continue o desenvolvimento. Se você não corrigir seus bugs, you novo código será escrito em cima de um projeto com problemas e resultando em uma base instável para o jogo\u0026quot;\nRomero diz que não devemos perder o tempo de outras pessoas, se você encontrou um bug ele deve ser corrigido antes de prosseguir. É comum o programador saber que existem bugs mas envia o jogo para a equipe de testes sem falar nada, esperando que eles encontrem para ele corrigir após o bug ser \u0026quot;oficial\u0026quot; e estar anotado em algum lugar.\nNovamente, esta é uma dica para pequenas empresas, pois não possuem processos burocráticos. Mas, independente do tamanho da empresa e do projeto, todo bug deve ser sempre corrigido, especialmente se for seu. Ou, se não houver tempo, pelo menos informe a equipe de testes (ou a pessoa que vai testar).\n“Write your code for this game only – not for a future game. You’re going to be writing a new code later because you’ll be smarter.”\nTradução:\n\u0026quot;Escreve seu código para este jogo apenas - não para jogos futuros. Você irá escrever um código novo depois pois você terá aprendido mais\u0026quot;\nMuitos programadores, não só da área de games, se preocupam em fazer um código que poderá ser utilizado por vários projetos depois. Isto é uma preocupação válida, mas quando não se tem muito tempo não devemos nos preocupar em criar um framework antes de criar o jogo em si. E a segunda parte que ele disse é verdade, provavelmente você irá escrever um código melhor na segunda vez.\nEm empresas grandes existem até equipes desenvolve ferramentas e frameworks para que as equipes que desenvolvem os jogos consigam focar em fazer o jogo.\nO texto contém mais detalhes e dicas, e vale muito a pena ler. John Romero é um grande game designer, e sempre podemos aprender muito com desenvolvedores experientes como ele.\n","date":"11 de maio de 2016","externalUrl":null,"permalink":"/dicas-de-john-romero/","section":"Blog","summary":"John Romero, co-fundador da Id Software e criador dos jogos DOOM e Quake, entre muitos outros, deu uma palestra em um evento da revista britânica Develop e falou sobre algumas técnicas para desenvolvimento que ele sempre usou, muitas indo contra ao que encontramos nos livros. Abaixo estão algumas frases que retirei do texto, a notícia completa pode ser lida aqui.\n","title":"Dicas de John Romero para desenvolver jogos","type":"posts"},{"content":"Esta foi minha quarta participação na game jam Ludum Dare, e pela quarta vez consegui terminar o jogo em 48 horas, o Metaforce. Porém, isto não quer dize que o jogo saiu do jeito que planejei ou que tenha ficado bom, apenas terminei o que comecei.\nEm cada edição eu consigo acertar e errar em muitos detalhes, e desta vez não foi diferente. Vou contar um pouco sobre cada parte do projeto aqui, e o que deu certo e errado.\nProgramação # O que tinha grandes chances de ser meu maior erro acabou dando muito certo. Nas edições anteriores escolhi utilizar a Unity, pois é uma engine que estou acostumado e tenho mais experiência. Desta vez decidi utilizar algo diferente, e escolhi a Defold, uma engine que nunca nem sequer fiz um tutorial. Mais arriscado ainda foi que esta engine foi lançada publicamente mês passado, e apesar de estar em desenvolvimento há anos internamente na King, é algo novo. Tão novo que se não fosse a excelente documentação e exemplos, não seria possível utilizar pois não há muita coisa no Google além do forum deles.\nMas o que pareceu arriscado acabou dando muito certo. A Defold é uma engine incrível, com tudo que você precisa para desenvolver um jogo. É claro que ela possui defeitos e muita coisa para melhorar, principalmente a IDE interna para programar em Lua, mas não deixou a desejar durante o Ludum Dare.\nMinha primeiro contato com esta engine foi duas horas antes de anunciarem o tema e começar o Ludum Dare, e achei tão simples que mesmo sem experiência decidi utilizar a Defold. Acho que por eu ter experiência com outras tecnologias, eu mais ou menos sabia onde estava ou como usar o que eu queria, o que me provou que a Defold é realmente uma excelente ferramenta de desenvolvimento e me lembrou de algumas ferramentas que utilizei quando trabalhava na EA.\nArte # Apesar da Defold ter sido uma boa surpresa durante meu fim de semana, acho que nada vai se comparar com a arte que fiz para jogo. Por que? Por que foi a primeira vez na minha vida que eu desenhei algo no PC e foi a primeira vez que tentei fazer pixel art. Só tive tempo de desenhar os personagens, mas isso já foi mais do que jamais fiz.\nQuando o tema Shapeshit foi anunciado logo pensei em fazer um jogo onde o jogador controla um personagem que quando ataca um monstro ele se divide, ou quando dois monstros se colidem eles se juntam em um. Então logo percebi que eu iria precisar de um personagem e um monstros, sendo que o monstro teria que ter duas formas (grande e pequeno) e cores diferentes (azul, vermelho e roxo para quando se juntarem com cores diferentes).\nPesquisei algumas artes de jogos de Atari para usar como referência, e no final o desenho do meu personagem me lembrou um pouco Castle Crashers. Para fazer os monstros eu não usei referencias, mas no final lembrou um pouco um Creeper com cores diferentes. Até consegui fazer posições diferentes do personagem para o personagem atacar, ficar parado e tomar dano (andar fica pra próxima).\nGame Design # Percebeu a minha empolgação em usar a Defold e ter conseguido desenhar meus primeiros personagens? Então, isso me fez praticamente esquecer algo muito importante: o game design do jogo. Na tarde de domingo, poucas horas antes do final do Ludum Dare, eu já tinha tudo que queria pronto: mapa criado com tiles, colisões funcionando (precisam de ajustes ainda, mas funcionam), personagem andando, atacando e tomando dano, contador de vida no personagem, contador de vida nos monstros, 2 cores de monstros que se juntavam em uma terceira cor, 2 tamanhos de monstro que se combinavam.\nO problema foi que eu estava tão preocupado em terminar estas coisas listadas acima que não pensei em como juntar. Foi como se eu tivesse criado diferentes peças de Lego mas no final não sabia bem o que fazer com elas. Com pouco tempo e ainda alguns ajustes pra fazer acabei apenas adicionando um contador de pontos, sendo que monstros básicos davam 1 ponto e monstros transformados davam 2 pontos, e uma saída no final do mapa. Além disso, gravei uma música curta no violão usando meu celular e coloquei pra repetir. Por ter pouco tempo a música não ficou boa, mas pelo menos o jogo não ficou sem silêncio.\nO resultado foi o jogo mais \u0026quot;complexo\u0026quot; que já desenvolvi no Ludum Dare, com muitas coisas legais, porém não ficou divertido por falta de pensar no game design. Nas edições anteriores eu sempre comecei com um papel e lápis pensando no game design, mas desta vez fiquei tão empolgado em usar a engine pela primeira vez e por ter conseguido desenhar que deixei isso de lado, e o jogo não ficou divertido.\nOutra mudança foi que não exportei o jogo para mobile, embora esteja rodando muito bem no Android. Mas adicionei suporte a teclado e controle, inclusive com duas opções: controle do Xbox 360 e Steam Controller (um pouco bugado, mas funciona). Também não tive tempo de fazer uma tela de menu com o nome do jogo, mas isso eu sempre deixo por último por não influenciar a mecânica do jogo.\nConclusão # Para conseguir fazer um jogo legal em game jams como o Ludum Dare é preciso ter um bom balanceamento entre Programação, Arte (incluindo Som) e Game Design. Claro que fazer um jogo sozinho em 48 horas baseado em um tema que é revelado no início da contagem é desafiador o bastante para causa um desequilíbrio em todas as áreas. Nas edições anteriores sempre a arte ficou de lado, e dessa vez foi o game design. Espero que na próxima edição em Agosto eu consigo encontrar um equilíbrio melhor.\nO código do jogo está no GitHub e jogo para Web, Windows, Mac OS X e Linux está na página do Ludum Dare. Baixem, joguem, e me digam o que mais posso melhorar!\n","date":"20 de abril de 2016","externalUrl":null,"permalink":"/ludum-dare-35/","section":"Blog","summary":"Esta foi minha quarta participação na game jam Ludum Dare, e pela quarta vez consegui terminar o jogo em 48 horas, o Metaforce. Porém, isto não quer dize que o jogo saiu do jeito que planejei ou que tenha ficado bom, apenas terminei o que comecei.\n","title":"Minha participação no Ludum Dare #35","type":"posts"},{"content":"Sexta-feira às 22h (horário de Brasilia) começa o Ludum Dare #35, e eu admito que depois de participar das 3 últimas edições acabei ficando \u0026quot;viciado\u0026quot; em no LD, e sempre fico ansioso quando uma nova edição se aproxima.\nNeste post sobre o Ludum Dare #33 eu dei algumas dicas, e eu mesmo segui elas nas 3 últimas edições. Desta vez eu vou fazer algumas coisas bem diferentes, e espero que eu consiga terminar o jogo em 48 horas.\nNão recomendo, mas vou fazer # Utilizar uma game engine que nunca usei: desta vez vou desenvolver o jogo utilizando a Defold, uma game engine nova e que minha experiência foi um tutorial durante esta semana.\nPensar grande: nas edições passadas pensei em jogos que eram possíveis em 48 horas, e isso me limitou bastante. Desta vez vou pensar em algo maior do que 48 horas, e me forçar a terminar no prazo.\nMais pressão: como quero fazer algo maior e com uma game engine que praticamente não tenho experiência, esta pressão de fazer tudo em 48 horas vai ser maior, e espero que me motive mais.\nVou tentar não dormir: escolher jogos que eram possíveis me deram tempo até pra dormir, desta vez acho que não vou ter este luxo ou se tiver será bem curto.\nDicas importantes # Escolha a linguagem de programação, framework ou game engine antes de começar e tenha certeza de que tudo está atualizado para não perder tempo esperando downloads.\nVai ser necessário criar arte e som, então já se prepare antecipadamente para isso (mesmo que você ache que não vai dar tempo, se prepare pois vai que dá).\nSe você tem dificuldade em se concentrar, não deixe a TV ligada e evite YouTube, tente ouvir trilha sonoras ou músicas que você gosta.\nParece bobo mas planeje como serão suas refeições, e tente não sair pra comer pois isso pode te custar um tempo precioso. No meu caso, já estoquei café.\nPlaneje o que fazer em caso de falta de internet e/ou falta de energia elétrica, é sempre bom ter um plano B e um lugar pra ir (algo tipo Starbucks, por exemplo).\nLinks interessantes:\nMinha participação no Ludum Dare #32\nMinha participação no Ludum Dare #33\nMinha participação no Ludum Dare #34\n","date":"13 de abril de 2016","externalUrl":null,"permalink":"/comeca-o-ludum-dare-35/","section":"Blog","summary":"Sexta-feira às 22h (horário de Brasilia) começa o Ludum Dare #35, e eu admito que depois de participar das 3 últimas edições acabei ficando \"viciado\" em no LD, e sempre fico ansioso quando uma nova edição se aproxima.\n","title":"Esta semana começa o Ludum Dare #35","type":"posts"},{"content":"O livro \u0026quot;A Lógica do Jogo - Recriando clássicos da história dos videogames\u0026quot;, escrito por Marcus Becker e publicado pela editora Casa do Código, é um ótimo guia para aprender a programar jogos clássicos como Tetris, Space Invaders, Asteroids, Pong, Pac-Man, entre outros, utilizando Java.\nNeste livro o autor apresenta como programar a mecânica de cada um destes jogos clássicos, o que pode ser usado como base para desenvolver muitos outros jogos. Eu gostei da maneira que o Marcus abordou o tema, pois é muito legal aprender a programar jogos clássicos.\nPraticamente qualquer curso ou tutorial para iniciantes começa apresentando alguns desses jogos antes de começar a fazer algo mais avançado. Além disso, é um ótimo exercícios tentar recriar algum jogo clássico, pois a arte é fácil de encontrar (quando necessária) e você sempre acaba aprendendo algo novo.\nOs capítulos inicial do livro são uma introdução de como fazer algumas coisas básicas como Java. Nos demais capítulos, e até o final do livro, os jogos clássicos mencionados aqui são apresentados. Em cada capítulo algo é adicionado à um exercício que é construir um jogo chamado Nave Quebrada durante o livro.\nO livro é uma ótima leitura para aprender sobre a mecânica destes jogos clássicos, mas vai exigir um conhecimento prévio de Java para aproveitar ao máximo cada código apresentado. Os projetos do livro estão disponíveis no GitHub.\nMinha única crítica ao livro é o uso da linguagem Java. Apesar de Java ser uma ótima linguagem para aprender a programar (eu aprendi com Java), atualmente ela não é uma das mais utilizadas para se desenvolver jogos. Na minha opinião teria sido melhor escolher uma linguagem ou até mesmo uma game engine que fosse mais adequada a realidade da indústria.\nO livro está disponível em versão física e digital pelo site da Casa do Código. Gostei da opção de enviar o livro digital direto para o meu Kindle, onde li o livro inteiro. Apesar de ficar um pouco ruim para ver código nele, o livro estava muito bem formatado para ele. Obrigado ao Marcus Becker por me enviar uma cópia digital da sua obra!\n","date":"6 de abril de 2016","externalUrl":null,"permalink":"/a-logica-do-jogo/","section":"Blog","summary":"O livro \"A Lógica do Jogo - Recriando clássicos da história dos videogames\", escrito por Marcus Becker e publicado pela editora Casa do Código, é um ótimo guia para aprender a programar jogos clássicos como Tetris, Space Invaders, Asteroids, Pong, Pac-Man, entre outros, utilizando Java.\n","title":"A Lógica do Jogo","type":"posts"},{"content":"Esta semana começou o evento Build da Microsoft em San Francisco, e muitas novidades para desenvolvedores foram apresentadas, inclusive para desenvolvedores de jogos.\nA maior notícia de todas é que não será mais necessário ter um kit de desenvolvimento do Xbox One para desenvolver jogos para esta plataforma, qualquer console pode se tornar um kit de desenvolvimento. Ou seja, se você tem um Xbox One, pode desenvolver jogos pra ele!\nÉ claro que o processo de aprovação para publicar um jogo na Xbox Live ainda é bem criterioso, porém só de permitir que qualquer console seja usada pra desenvolvimento muita coisa muda. Isto deve incentivar mais desenvolvedores a criarem jogos para a plataforma da Microsoft, ou até dar uma vantagem ao Xbox One em relação ao Playstation 4, que é o console mais vendido da geração atual.\nInfelizmente eu não tenho um Xbox One, mas esta notícia me fez pensar em adquirir um este ano. Talvez esse seja o empurrão que muita gente (como eu) estava esperando para não ficar \u0026quot;preso\u0026quot; em mobile. Já fazem 6 anos que trabalho com jogos mobile, acho que chegou a hora de diversificar.\nMesmo que você não seja um desenvolvedor independente e nem quer publicar um jogo sozinho, poder desenvolver em seu Xbox One pode ser uma maneira de estudar desenvolvimento para consoles e até te ajudar a conseguir um emprego pra trabalhar com jogos AAA, já que muitos exigem conhecimento de console, o que era bem restrito até então.\nEspero que a Sony também faça algo assim com o Playstation 4 no futuro. Acho que pra Microsoft isto foi uma decisão natural, pois eles querem unificar todas suas plataformas rodando em uma única versão de Windows.\nAlém disso, a Microsoft também anunciou que vai aumentar a compatibilidade dos jogos de Xbox para rodar no Windows 10, tornando a plataforma da Microsoft ainda mais atraente aos desenvolvedores.\nAlgo que pegou todos de surpresa, e é uma ótima notícia para desenvolvedores em geral, é que o bash está indo para o Windows 10, e se você está curioso de como vai funcionar leia este post. O Xamarin, framework para desenvolver Apps em C# que foi comprado pela Microsoft, será integrado ao Visual Studio nos próximos updates. Se você gostar de brincar com Inteligência Artificial, a Microsoft também lançou durante o evento seu Bot Framework para criar Chat Bots. Neste link tem um resumo de como foi a conferência, parabéns a Microsoft por trazer tantas coisas legais este ano para os desenvolvedores.\n","date":"30 de março de 2016","externalUrl":null,"permalink":"/microsoft-build-16/","section":"Blog","summary":"Esta semana começou o evento Build da Microsoft em San Francisco, e muitas novidades para desenvolvedores foram apresentadas, inclusive para desenvolvedores de jogos.\n","title":"Novidades da Microsoft no Build 16","type":"posts"},{"content":"A King, famosa pelo seu jogo Candy Crush Saga e outros similares, lançou esta semana sua game engine chamada Defold para desenvolvimento de jogos em 2D. Ela é gratuita, conta com editor visual, controle de versão, editor de nível, e editor para programação em Lua.\nAlém de tudo isso, Defold exporta seu jogo para seis plataformas: iOS, Android, HTML5, Mac OS X, Windows e Linux. Para baixar e usar a Defold é necessário utilizar uma conta Google para logar no site e criar os projetos. A Defold funciona com uma integração entre o site e a engine, o que permite gerenciar o projeto, acesso para equipe e até dados de uso do jogo (analytics) pelo site.\nA Defold é uma engine gratuita para jogos 2D, porém não é open source. O objetivo da King é fornecer uma ferramenta profissional para desenvolvimento de jogos gratuitamente, mas também receber ajudar dos desenvolvedores para identificar bugs e sugerir melhorias. Isto também deve ajudar a King a contratar desenvolvedores que já tenham experiência com esta engine, antes usada apenas internamente.\nEu fiquei impressionado pelo simplicidade e, ao mesmo tempo, a riqueza de detalhes que esta game engine tem. A King também disponibilizou tutoriais e documentação bem completa, com uma qualidade esperada de uma empresa do porte deles, além de um forum para os desenvolvedores.\nMês que vem, dia 15 de Abril, teremos uma nova edição do Ludum Dare e eu pretendo participar utilizando a Defold. Veja aqui alguns jogos já publicados.\n","date":"23 de março de 2016","externalUrl":null,"permalink":"/king-defold-engine-2d/","section":"Blog","summary":"A King, famosa pelo seu jogo Candy Crush Saga e outros similares, lançou esta semana sua game engine chamada Defold para desenvolvimento de jogos em 2D. Ela é gratuita, conta com editor visual, controle de versão, editor de nível, e editor para programação em Lua.\n","title":"King lança sua engine 2D Defold de graça","type":"posts"},{"content":"Durante o evento GDC (Game Developer Conference) em San Francisco uma das novidades anunciadas pela Unity foi sua certificação para desenvolvedores de jogos que utilizam a game engine.\nA certificação é dividida em três categorias: Professional Programmer, Professional Artist e Expert. A prova custa $130 dólares (se não me engano), e é necessário acompanhar o calendário de eventos de certificação pra saber quando e onde a prova será aplicada.\nUma notícia bem legal pela parte da Unity é que o Brasil já tem dois centros para aplicar a prova de certificação, um em São Paulo e outro em Curitiba. E mais legal ainda é que o Brasil foi o primeiro lugar a receber o evento de certificação, e ontem já tivemos brasileiros recebendo a certificação da Unity. Neste link é possível ver os detalhes do último evento de certificação.\nLembro que no primeiro evento Unite em São Paulo foi dito que o Brasil era o terceiro país que mais utilizava Unity, isso há uns 3 anos atrás. É muito bom ver este bom relacionamento da Unity com os desenvolvedores brasileiros, só espero que parem de fazer o Unite junto com a SBGames e continuem com um evento grande separado.\nNeste PDF estão todos os tópicos que são cobrados no exame. A prova não parece difícil para quem utilizar Unity no dia-a-dia, mas recomendo dar uma olhada no PDF e estudar os tópicos que você não conhece ou não lembra antes de fazer a prova. Vale lembrar que o certificado é válido por 2 anos e você precisa acertar pelo menos 70 das 100 perguntas.\n","date":"16 de março de 2016","externalUrl":null,"permalink":"/certificacao-unity/","section":"Blog","summary":"Durante o evento GDC (Game Developer Conference) em San Francisco uma das novidades anunciadas pela Unity foi sua certificação para desenvolvedores de jogos que utilizam a game engine.\n","title":"Certificação para Unity","type":"posts"},{"content":"Não esperava demorar praticamente 9 meses para escrever esta segunda parte, mas acabou ficando de lado por ser um conteúdo mais longo que o normal para o blog. Eu até prefiro escrever mais posts assim, e acredito que deve ajudar bastante, por isso vou tentar fazer algo assim pelo menos uma vez por mês (não só sobre a Unity). Se você ainda não viu, recomendo ler a parte 1 antes de continuar neste post.\nBoas práticas usando NGUI\nQuando desenvolvi o jogo que mencionei na parte 1 a GUI da Unity estava em beta, por isso acabamos comprando e usando o plugin NGUI: Next-Gen UI. Este plugin ficou muito famoso pois tornou possível a criação de interface e até jogos 2D utilizando a Unity, que até então não tinha suporte para ambos nativamente.\nHoje o cenário é bem diferente, porém quase tudo que era feito na NGUI também se aplica aos recursos da Unity. A palavra \u0026quot;quase\u0026quot; é devido aos recursos disponíveis na classe NGUITools, que muitas vezes te ajudam demais no desenvolvimento. Eu particularmente utilizei muito os métodos SetActive e AddChild, junto com os componentes da NGUI.\nUm dos grandes recursos da NGUI é fazer toda UI ter apenas um draw call, ou seja, ser desenhada em uma única chamada. Eu recomendo assistir aos videos desta playlist do criador da NGUI (em Inglês), ele fez tutoriais cobrindo todo básico necessário para utilizar o plugin seguindo as boas práticas e otimizando seu jogo. O vídeo abaixo é o número 2 de 5, e cobre o básico.\nEu tive um grande problema com este plugin: era praticamente impossível migrar o projeto da Unity 4 para Unity 5 sem ter que refazer boa parte da interface. Por este motivo decidimos continuar utilizando a Unity 4. Eu sei que outros desenvolvedores passaram pela mesma situação, e muitos utilizam Unity 4 até hoje por que não tiveram tempo de migrar a NGUI. Mas, ao mesmo tempo, conheço gente que não teve problemas em migrar para Unity 5. Mesmo com estes problemas eu acho que vale a pena utilizar NGUI, pois é um plugin incrível com muito conteúdo disponível.\nSe você está se perguntando se deveria comprar o plugin NGUI por $95 dólares ou utilizar os recursos da Unity minha sugestão é a seguinte: se você já comprou a NGUI, e tem experiência com ela, continue utilizando mas não deixe de estudar os recursos da Unity. Se você ainda não comprou, primeiro estude os recursos da Unity antes de tomar a decisão de comprar, pois isso pode te economizar $95 dólares.\nSeu melhor amigo, o sprite sheet\nUm sprite é image imagem solitária, e seu jogo pode ter várias imagens assim. Quando você combina vários sprites em uma única imagem, isto é chamado sprite sheet. Existem tantos benefícios por utilizar isto que é praticamente uma boa prática obrigatória para jogos 2D.\nNo primeiro video abaixo (em Inglês) podemos ver as vantagens relacionadas ao tamanho e redução de cores para deixar seus assets mais leves e reduzir o consumo de memória. O segundo video explica a importância de usar sprite sheets para otimizar o tempo do OpenGL para carregar e desenhar imagens na tela.\nSem dúvidas é um ganho enorme se preocupar em organizar os assets do seu jogo em um único sprite sheet. Porém, devemos levar em conta as limitações de hardware das plataformas que estamos desenvolvendo. Em muitos aparelhos Android e iOS antigos o sprite sheet não deve ter mais do que 1024. O 2048 é um tamanho mais recomendado para que funcione na maioria dos aparelhos, mas 4096 funciona bem em praticamente todos hardwares mais recentes. Lembre-se que o sprite sheet deve sempre ter o tamanho em POT (power of two, ou potência de dois), pois se não for o OpenGL vai fazer sua imagem ser na hora que carregar na memória, o que consome mais espaço e recurso do processador.\nOs dois videos foram feitos pelo autor do TexturePacker, um excelente software para gerar sprite sheets e que é compatível com qualquer game engine ou framework com suporte 2D. O site também possui excelentes tutoriais para as principais tecnologias, tudo em Inglês.\nNo caso da Unity é necessário utilizar o plugin gratuito chamado TexturePacker Importer. Eu utilizei o TexturePacker e o plugin junto com a NGUI no projeto que mencionei na parte 1, e os ganhos de consumo de memória e tamanho da build foram boa partes graças ao uso de sprite sheets, junto com as outras coisas mencionadas.\nInternamente a Unity agrupa suas imagens em uma sprite sheet na hora que seu jogo compilado, então mesmo se você não quiser ter este trabalho de preparar tudo antes a Unity faz pra você. Porém, é bom ter o controle disso, pois muitas otimizações mencionadas aqui devem ser feitas manualmente para se ter um ganho de memória na Unity.\nEsta foi a parte 2! Na próxima e, provavelmente, última parte vou comentar sobre melhores práticas relacionadas à programação na Unity em C#. O foco não será a linguagem de programação, mas sim sobre a utilização dos recursos de script engine. Qualquer dúvida ou sugestão deixe seu comentário abaixo!\n","date":"9 de março de 2016","externalUrl":null,"permalink":"/melhores-praticas-2d-unity-parte-2/","section":"Blog","summary":"Não esperava demorar praticamente 9 meses para escrever esta segunda parte, mas acabou ficando de lado por ser um conteúdo mais longo que o normal para o blog. Eu até prefiro escrever mais posts assim, e acredito que deve ajudar bastante, por isso vou tentar fazer algo assim pelo menos uma vez por mês (não só sobre a Unity). Se você ainda não viu, recomendo ler a parte 1 antes de continuar neste post.\n","title":"Melhores práticas para 2D na Unity - Parte 2","type":"posts"},{"content":"Este é o décimo postmortem publicado aqui no blog. Fiquei muito feliz com este projeto em especial pois, diferente dos demais que entraram em contato depois do projeto estar pronto, o João Paulo comentou sobre este jogo em alguns posts do blog. É muito legal ver um leitor do blog (e sua equipe) desenvolvendo e publicando um jogo, e ainda mais contando a história do desenvolvimento aqui para encorajar outros desenvolvedores a publicar seus jogos.\nOlá, meu nome é João Paulo Santos e sou um dos programadores do jogo HueShark que está 100% gratuito e pronto para download na GooglePlay no link acima. Abaixo irei especificar tudo que ocorreu durante todo o desenvolvimento, as nuances e mostrar o que realmente é positivo e negativo no desenvolvimento de um jogo de pequeno porte como HueShark.\nDescrição do Game\nHueShark conta a história de 2 casais (Pai, Mãe, Filho e Nora) que ganham uma viagem da empresa a qual prestam serviços por serem excelentes funcionários. Todos são especializados em engenharia e conhecem muito de mecânica e tecnologia. Ao irem com um Iate para o mar (Iate locado pela empresa) eles sofrem com as intemperanças do mar, em meio a viagem uma forte tempestade atinge o Iate que eles estão e eles são levados pela correnteza forte. O navio acaba parando em uma ilha deserta, tendo seu motor e parte elétrica destruídos.\nO grupo pensa em como sobreviver e como voltarem para casa e a saída para isto era colocar um navio pesqueiro que também estava na ilha ancorado bem próximo a ilha e tentar consertar o motor/rádio deste barco novo que acharam na ilha para funcionar e assim serem recuperados ou irem para casa. Misteriosamente o barco pesqueiro tinha alguns esqueletos e marcas de \u0026quot;chifradas\u0026quot; no casco. Apesar de ainda estar em bom estado gerou curiosidade aos tripulantes que com esforço conseguiram levar o barco para bem próximo da ilha e ancora-lo ali mesmo. A ideia deles era ir a ilha sempre que possível em um bote para pegar alimento e procurar suprimentos para ajudar o grupo a sobreviver.\nAbaixo segue uma descrição InGame:\nUm jogo desafiador que faz com que o player tenha total atenção com o status de cada player e com a bag com recursos do navio. Cuide da Nutrição, Humor e Cansaço de cada personagem para evitar que eles trabalhem com penalidades na movimentação e tempo de cumprimento de tarefas.\nPesque, crie armadilha para o HueShark, mantenha o tanque de peixe sempre cheio para evitar danos ao navio. Chuvas ocorrem continuamente para renovar a reserva de água do barco.\nTente \u0026quot;fisgar\u0026quot; gaivotas para criar armadilhas para o tubarão (sim, gaivotas + vidro + putrefação = dor de barriga no HueShark).\nExistem 3 formas de vencer:\n1 - Gaste o máximo de suprimentos (supplies) no motor e você vencerá o game indo para casa com o motor novo;\n2 - Gaste o máximo de suprimentos (supplies) no rádio e você vencerá o game sendo resgatado por um helicóptero da marinha;\n3 - Vá o máximo de vezes possíveis para ilha e use o sinalizador para atrair a guarda costeira e você será salvo por um helicóptero da marinha.\nObrigado por apreciar nosso jogo, ele é FREE e é uma honra para nós compartilharmos o nosso esforço com vocês.\nInício\nO game antes mesmo de ser desenvolvido foi pensado no público de smartphones Android. Pensamos no Gdd entre o final de junho de 2015 e o começo de julho 2015 e juntamos 4 pessoas neste projeto inicialmente (tinha por data final de entrega 7 de dezembro de 2015), ressaltando que era um projeto de Universidade (Projeto Integrador). O Gdd foi idealizado em 1 dia, tendo quase tudo o que o projeto final tinha em seu documento original (poucas coisas mudaram). Abaixo irei especificar coisas técnicas, pontos positivos e pontos negativos.\nEspecificações Técnicas do Projeto\nEngine: Nenhuma, usamos AS3 + Flash Builder + Starling + GreenSock (AS3). Plataforma: Android Estilo de Jogo: Survivor Comic Jogabilidade: Point and Click Ferramenta para Gráficos: Photoshop CC 2015 Animação: Photoshop CC 2015 (frames animados via código) Estilo: PixelArt Controle de Versão: Git (BitBucket) + Sourcetree + DropBox Técnica para Gestão: Scrum + Trello\nPontos Negativos\nAqui é aonde moram os perigos de qualquer projeto. Vamos dividir por partes:\n1 – Procure pessoas que realmente estão motivadas\nÉ muito fácil ouvir “estou contigo”, “contigo comigo para o que der e vier” e coisas do gênero quando se está em um mercado tão variável e tão lucrativo como o de game design. Porém, quando é hora de arregaçar às mangas e trabalhar de verdade pouco percebe-se de tal entrega por parte de alguns. Provavelmente o principal motivo disto foi a não identificação com o projeto ou com a área do projeto. É como pensar na Blizzard, imagine que eu como programador fosse trabalhar na área de rigging ou modelagem, além de ser um desastre para companhia provavelmente seria um ponto de desmotivação para mim. Certifique-se de que quem vai entrar no projeto com você realmente quer fazer e está disposto a quase tudo para ver o release do game oficial acontecer. 1 Erro na conta do projeto!\n2 – Certifique-se que todos estão na área correta\nNo final do semestre 2 membros do grupo (éramos 4) saíram do projeto, mas apenas no final foi deixado claro que ambos não estavam na área que queriam, a saber desenho (pixel art).\nLembro-me bem do primeiro dia quando sentamos juntos e estabelecemos o que cada um faria, ou seja, 2 programadores e 2 designers, todavia recebemos bastante elogio na parte de código (não por sermos revolucionários, mas por termos produzido muito em pouco tempo), mas na parte visual não recebemos honrarias. Antes de começar qualquer projeto estripe todos os componentes para saber se realmente é aquela área que ele atuará que será sua “paixão no projeto”. Mais 1 Erro na conta do projeto!\n3 – Motive o tempo todo, mas tenha parcimônia em poupar exclusões\nEsse é um ponto grave de qualquer projeto que se não houver cautela ou falta de pulso seu projeto afunda! Veja bem, imagine o caso aonde uma pessoa não está produzindo (produzir != volume de coisas entregues, na verdade é qualidade) o proposto por ela mesma na semana/dia, se a resposta é NÃO avalie TODAS as coisas do ambiente ao qual ela faz parte (saúde dela/de familiares, emprego ameaçado, relacionamento acabado e etc), se realmente há algo grave ocorrendo respeite-a, mas se não há nada grave/desmotivador fora do projeto ocorrendo e o integrante não cumpre os backlogs propostos por ele mesmo está na hora de reavaliar o componente e se através de reuniões/diálogos privados e outras coisas não houver desprendimento mande um kick e assuma a função, é melhor fazer o seu melhor a não fazer NADA (mesmo que você não seja bom naquela área). Por causa desta falha de tolerar demais tivemos severos problemas com o cronograma assim como resultado negativo, 2 kicks. +1 Erro na conta do projeto!\n4 – Tenha todos componentes com capacidade ou motivação extrema em sua área\nEsse ponto é importante, pense comigo, você não vai achar o programador do Diablo 3 disponível para um projeto indie, vai? Claro que não, mas também não é aceitável um cara que ainda está estudando como se comenta múltiplas linhas em C# na Unity fazer parte de um projeto como programador (pelo menos com tempo de entrega cravado e não mutável). A coisa gira em torno disto, procure pessoas que conhecem do assunto (não precisa ser expert) e se tal pessoa não puder cumprir algo complexo na área dela dê tempo, uma pessoa motivada produz muito (e o bom é que ocorre um aprendizado forte). Colocar pessoas porque são “amigos, chegados, parceirões” é FURADA, corra! +1 Erro na conta do projeto!\nPontos bem positivos\n1 - O verdadeiro líder\nComo um mero aprendiz de liderança fui colocado como cabeça do projeto e isto me colocou uma responsabilidade de 1 tonelada nas costas. Como programador do projeto (também) decidi que a melhor forma de cobrar era fazer, ou seja, programar o máximo de linhas possíveis no menor tempo possível para poder mostrar um “olha caras, minha parte fiz bacana por isso estou pedindo que façam as suas partes” com cabeça fria e tranquila. Isso se mostrou mais que positivo, percebi que gera frutos (para componentes interessados no projeto), todos se sentem devedores de “entregar coisas” no projeto ao verem 1 componente fazendo isto. Lembro-me de “competir” com o outro programador quando fazíamos algoritmos bem legais para sanar problemas e ficávamos zoando um do outro no projeto para ver que fazia algo mais bem elaborado e isso gerou mais qualidade no projeto (perdi na maior parte das vezes kkkkkkk)...\n2 – Redescobrindo seus limites\nUma das coisas mais legais que ocorreram foi chegar além do meu limite físico. Lembro-me que para cumprir um backlog precisei varar 3 dias e meu corpo já não aguentava mais e o new metal + cafeína + energético sustentaram juntamente com a motivação de maneira louvável os meus sentimentos e persistência. Uma das coisas mais legais que você descobre em um projeto com cronograma a ser seguido é que seus limites podem ser rompidos e positivamente ampliados. Cheguei a adoecer em detrimento disto, mas valeu a pena, ganhei o respeito de alguns da sala e da universidade que tomaram conhecimento do esforço dos programadores envolvidos no projeto.\n3 – Achar motivação aonde não tem\nSe não há dinheiro em jogo (projeto acadêmico), como fazer algo dando o melhor de si? Aí foi o bacana da história, pensar em superar a si mesmo e competir consigo mesmo tornam esse ponto uma resposta clara, Ultrapasse VOCÊ MESMO! Pise em você mesmo! Humilhe você mesmo por resultados melhores e você mesmo terá um crescimento forte!\n4 – Quem está na chuva é para se molhar!\nQuando houveram os kicks em detrimento do desinteresse/descumprimento de “Brothers” pensamos (os 2 devs): O que iremos fazer sem designers? Como vamos codar e desenhar? E a resposta foi: Vamos romper nossos limites, se for necessário não dormiremos mais! Temos data certa para encerrar este sofrimento ← Esse ponto é o legal porque aqui abre o leque para se romper limites, tenho até o momento os psds com históricos de edições pixel a pixel assim como o outro programador, aonde superamos a nós mesmos! Supere a si mesmo e se houver algum acomodado tome a frente, não deixe o barco afundar porque não há gente que leva a sério seu trabalho ou simplesmente pulou do barco, META A MÃO E FAÇA!\nConsiderações finais\nIntegrantes no início: 4 (2 devs/2 designers), Integrantes no fim: 2 (2 devs), Cronograma e Conclusão estimada: 5 meses, Conclusão do projeto: 8 meses, Rendimento estimado da matéria: 100%, Rendimento alcançado na matéria: 100%.\nAgradecimentos\nQuero agradecer ao portal gamedeveloper.com.br por ceder este espaço, é uma honra estar aqui postando meu primeiro game oficial e espero repetir este processo de post-mortem mais vezes, será mais que uma honra para mim. Obrigado, Bruno, você é Show!\nQuero também agradecer a Deus que em 10 dias me possibilitou o aprendizado de um framework tão formidável como o Starling.\n","date":"2 de março de 2016","externalUrl":null,"permalink":"/postmortem-hueshark/","section":"Blog","summary":"Este é o décimo postmortem publicado aqui no blog. Fiquei muito feliz com este projeto em especial pois, diferente dos demais que entraram em contato depois do projeto estar pronto, o João Paulo comentou sobre este jogo em alguns posts do blog. É muito legal ver um leitor do blog (e sua equipe) desenvolvendo e publicando um jogo, e ainda mais contando a história do desenvolvimento aqui para encorajar outros desenvolvedores a publicar seus jogos.\n","title":"Postmortem: HueShark","type":"posts"},{"content":"Há muito tempo queria sair do Wordpress, não por estar insatisfeito, mas sim por querer utilizar alguma tecnologia mais nova que com um foco mais \u0026quot;blog\u0026quot; do que \u0026quot;site\u0026quot;.\nEste mês o meu blog fez 7 anos. Eu nem acredito que há 7 anos estava começando minha pós-graduação, e provavelmente não imaginaria que continuaria o blog por tanto tempo. Ainda vou fazer um post sobre minha carreira, por isso aqui quero focar no blog em si.\nComecei hospedando o blog no side do Wordpress e depois de 1 ano quis instalar no meu próprio servidor. Na época eu tinha um hospedagem no UOL Host com meu projeto de TCC da graduação, que acabei tirando do ar para colocar meu blog. Não conhecia muito sobre hospedagem, mas em pouco tem percebi como esta era ruim. Por diversas vezes meu blog ficou fora do ar por problemas na infraestrutura deles, e mesmo não sendo algo famoso eu estava pagando por um serviço que não era bom.\nLogo migrei para a Bluehost, e até fiquei feliz por um tempo. Depois descobri a Digital Ocean, e vi que poderia configurar meu próprio servidor ao invés de ter uma hospedagem e acabei migrando o blog pra lá. Pouco tempo depois migrei para a Amazon Web Services, e estava muito feliz em ter meu servidor lá.\nEm todo esse tempo sempre tive curiosidade de mudar do Wordpress, mas acabava ficando nele por ter muito conteúdo publicado. Uma das coisas que mais me fez querer mudar do Wordpress era a velocidade dele, a dependência de um banco de dados sempre iria adicionar uma camada de lentidão no carregamento da página.\nHá 2 anos conheci o Jekyll e fiquei impressionado, pois era exatamente o que eu queria! Algo que fizesse meu blog ser ter um foco maior em ser um blog, além do conteúdo publicado ser estático e sem banco de dados. A única coisa que me impediu de migrar na época foi mover o conteúdo do Wordpress para o formato do Jekyll, pois a ferramenta de migração na época não funcionava muito bem e acabei desistindo.\nHá alguns dias encontrei uma nova tecnologia parecida com Jekyll, porém baseada no NodeJS, o Ghost. De cara já gostei da sua simplicidade e interface para administrar o blog: simples e direto ao ponto. Fiquei tão empolgado e que decidi tentar sua ferramenta de migração, e para minha supresa funcionou muito bem! Todo conteúdo do blog foi gerado, e a partir dai comecei a migrar o blog.\nO único problema que tive foi que a ferramenta de migração não faz download das imagens, então tive que copiar todas para o diretório do Ghost (que tem a mesma estrutura do Wordpress) e depois editei o arquivo de banco de dados (SQLite3) usando sqlitebrowser e algum código SQL para mudar todas URLs para carregar as imagens locais. Em cerca de 2 horas tudo estava pronto, porém comecei a pensar em outra coisa.\nFiz um teste utilizando o Elastic Beanstalk do AWS e publiquei meu blog como uma aplicação NodeJS. Ficou rápido, porém eu queria resolver outro problema: baixar o custo da hospedagem. Deixar meu blog lá custaria cerca de $10 dólares por mês, e com o valor do dólar atualmente qualquer ajuda é bem vinda para diminuir os custos. Neste ponto entrou o GitHub Pages.\nMeu portfólio já estava hospedado no GitHub Pages, por ser um conteúdo estático, porém meu novo blog era uma aplicação NodeJS. Com um pouco de pesquisa encontrei o Buster que converte todo conteúdo do Ghost em arquivos estáticos, para que possa ser publicado no GitHub Pages.\nDepois de um longo caminho estou muito feliz com o resultado. Atualmente estou trabalhando com dois repositórios, um privado com a aplicação do Ghost e um público no GitHub. Quando quero publicar algo, abro a linha de comando e rodo o Ghost localmente como uma aplicação NodeJS. E quando termino de mexer, uso o buster para converter meu blog em arquivos estáticos e publicar no repositório público do GitHub, e assim deixá-lo disponível no GitHub Pages. Parece muito trabalho, mas já automatizei tudo utilizando um script Ruby. Assim que termino de escrever, basta rodar o script e tudo que escrevi neste parágrafo acontece bem rápido.\nFaz 7 anos que pago cerca de $10 dólares por mês para manter este blog, e o máximo que consegui foi $100 dólares depois de uns 5 anos usando Google Ads. Esta mudança para o Ghost não é apenas boa por deixar de lado o Wordpress e seu conteúdo dinâmico lento. É muito boa por que agora minha hospedagem é gratuita e o conteúdo está muito rápido.\nAinda existem coisas que preciso ajustar, como alguns posts com texto mal formatado ou imagens e links quebrados. Aos poucos estou editando cada um dos 256 posts do blog para que todo conteúdo fique corrigido. Muito obrigado a todos leitores, todo esse tempo que dedico ao blog é para tentar te ajudar com um pouco do meu conhecimento na área. E lembre, estou sempre aberto a sugestões aqui ou por e-mail.\nRecomendação da semana\nEsta semana comecei a ler o livro Armada publicado no Brasil pela editora Leya, o segundo do autor Ernest Cline que escreveu o incrível Jogador Número 1. Ambos os livro são excelentes, com muito conteúdo relacionado a jogos antigos. Vale muito a pena ler!\n","date":"17 de fevereiro de 2016","externalUrl":null,"permalink":"/ola-ghost/","section":"Blog","summary":"Há muito tempo queria sair do Wordpress, não por estar insatisfeito, mas sim por querer utilizar alguma tecnologia mais nova que com um foco mais \"blog\" do que \"site\".\n","title":"Adeus Wordpress, olá Ghost","type":"posts"},{"content":"A Amazon Web Services (AWS) foi algo ao mesmo tempo inesperado e brilhante. Ninguém esperava que uma empresa que tinha \u0026quot;apenas\u0026quot; uma site para vender livros poderia oferecer um serviço para desenvolvedores e empresas. E foi brilhante por que além de ser muito bom, é muito barato, e fez com que praticamente todo mundo migrasse para a cloud da Amazon.\nEu trabalho com AWS há algum tempo, tanto para meus projetos pessoais quanto para os profissionais. Este blog mesmo já ficou um tempo hospedado no AWS, e eu utilizo muitos dos seus serviços em meus projetos de jogos, apps e até backend. Se você não conheço os serviços e produtos do AWS, recomendo dar uma olhada logo!\nHá algum tempo a Amazon criou um estúdio para desenvolvimento de jogos, o Amazon Game Studios, e inclusive contratou a game designer responsável pelo jogo Portal. Até agora lançaram 5 jogos para dispositivos móveis, porém nenhum conseguiu fazer um grande barulho na indústria. Ainda.\nCom tanta tecnologia, conhecimento e dinheiro infinito, criar sua própria game engine como um produto parecia algo claro para a Amazon. Porém, sendo ainda mais esperta, criou toda engine em cima do código da CRYENGINE, sem precisar criar toda base necessária para uma engine, que geralmente levam-se anos para se estabilizar.\nAmazon Lumberyard é uma game engine gratuita e open source, que se integra com todos serviços da AWS. Ou seja, tem tudo para ser um grande produto. Atualmente roda apenas em Windows, mas acredito que logo devem expandir para Mac, iOS, Android e até Windows Phone.\nHá um tempo achei que o Project Anarchy, uma game engine gratuita da Havok, seria uma ameaça para a Unity. Estava errado, pois eles não tiveram popularidade e dinheiro para investir neste produto. Inclusive esta semana vi a notícia de que o Project Anarchy foi cancelado.\nNão sei dizer se dessa vez temos um concorrente a altura da Unity, mas uma coisa eu sei: a Amazon já tem muitos desenvolvedores que utilizam suas tecnologias para games e eles tem dinheiro infinito para investir nesta game engine. Ainda não tive a oportunidade de testar, mas com certeza vale a pena, como tudo que a AWS faz.\nRecomendação da semana\nEsta semana queria recomendar um livro muito bom, que ainda preciso terminar de ler, chamado Clean Code. O objetivo deste livro é ajudar a escrever um código bom e fácil de manter, assim como identificar quando um código não é bom e pensar na melhor maneira de arrumar.\n","date":"10 de fevereiro de 2016","externalUrl":null,"permalink":"/amazon-lumberyard/","section":"Blog","summary":"A Amazon Web Services (AWS) foi algo ao mesmo tempo inesperado e brilhante. Ninguém esperava que uma empresa que tinha \"apenas\" uma site para vender livros poderia oferecer um serviço para desenvolvedores e empresas. E foi brilhante por que além de ser muito bom, é muito barato, e fez com que praticamente todo mundo migrasse para a cloud da Amazon.\n","title":"Amazon entra na briga com Lumberyard","type":"posts"},{"content":"Há pouco mais de 2 anos comecei uma série de posts sobre como ser um programador de jogos, e cada semana tratei um assunto relacionado a como começar uma carreira como programador na indústria de games. Fiz 32 posts nesta série e acabei não escrevendo mais posts há quase 1 ano nesta categoria por que os assuntos para iniciantes foram diminuindo e eu acabei ficando sem tempo para posts semanais.\nDecidi fazer este post para reunir a lista com os 32 posts em apenas um lugar. Muitas vezes recebo emails de pessoas que estão querendo começar na área, e um dos links que sempre envio é o da categoria Como Começar. Porém, acredito que todos links em um único post devem ser mais úteis e fáceis de consultar.\n#01 Pré-requisitos\n#02 Hello World\n#03 Engine vs Framework\n#04 Primeiro jogo\n#05 Cursos\n#06 Livros\n#07 Concursos e Game Jams\n#08 Playground\n#09 Protótipos\n#10 Códigos Open Source\n#11 Programar sem ter a Arte Final\n#12 Para que serve um Maker\n#13 Delta Time\n#14 Dados analíticos do jogo\n#15 Teste com jogadores\n#16 Game Design Document\n#17 Parallax\n#18 Você já fez um jogo?\n#19 Gerenciamento do seu tempo\n#20 Jogue bastante, mas jogos diferentes\n#21 Pixel Perfect\n#22 Boas práticas para animações 2D\n#23 Feedback de ações para o jogador\n#24 200 mecânicas de gameplay\n#25 Definição de prioridade de tarefas\n#26 Transformando jogo em produto\n#27 Por onde começar a programar\n#28 Mantenha tudo simples\n#29 Avaliando um Framework\n#30 Programando com estilo\n#31 Design Patterns\nOlhando os 32 posts aqui até parecem capítulos de um livro, e a ideia inicial dessa série era ser um pequeno guia com informações úteis para quem estiver começando na área. Diferente dos últimos posts desta série, não vou prometer que vou voltar a postar nesta categoria toda semana, mas prometo que vou tentar continuar ou pelo menos atualizar os assuntos tratados anteriormente com novos posts e novas informações.\nRecomendação da semana\nEsta semana finalmente assisti uma série de ficção científica incrível chamada Firefly. Nesta série a civilização humana desenvolveu uma tecnologia que transforma outros planetas e luas em lugares similares a Terra, permitindo a expansão pelo espaço. O interessante desta série é que não existem máquinas com inteligência artificial avançada e muito menos alienígenas, apenas humanos e naves. É possível aplicar essa mesma ideia em games, usando jogabilidades comuns porém com diferentes abordagens.\n","date":"27 de janeiro de 2016","externalUrl":null,"permalink":"/como-ser-um-programador-de-jogos/","section":"Blog","summary":"Há pouco mais de 2 anos comecei uma série de posts sobre como ser um programador de jogos, e cada semana tratei um assunto relacionado a como começar uma carreira como programador na indústria de games. Fiz 32 posts nesta série e acabei não escrevendo mais posts há quase 1 ano nesta categoria por que os assuntos para iniciantes foram diminuindo e eu acabei ficando sem tempo para posts semanais.\n","title":"Como ser um programador de jogos","type":"posts"},{"content":"Há quase 3 anos atrás li um post muito bom do game designer Dan Taylor no gamasutra sobre dez princípios para um bom level design. Salvei o link para publicar aqui e acabei esquecendo, mas aqui está uma tradução/interpretação minha do resumo feito pelo autor.\nÉ divertido de explorar – Usa uma linguagem visual clara para orientar o jogador pelo caminho principal, e cria interesse através da verticalidade, caminhos secundários, áreas escondidas e elementos de labirintos.\nNão depende de palavras para contar uma história – Além da narrativa explicita através da história e objetivos, um bom level design apresenta uma narrativa implícita através do ambiente, e dá aos jogadores uma mecânica de escolhas para que eles possam criar sua própria narrativa emergente.\nDiz ao jogador o que fazer, mas não como fazer – Garante que os objetivos da missão estão claros, mas permite aos jogadores completá-los do jeito que eles preferirem, e, sempre que possível, em qualquer ordem.\nEnsina constantemente algo novo ao jogador – Mantêm o jogador engajado introduzindo novas mecânicas através do jogo, e impede que mecânicas já aprendidas sejam descartadas aplicando modificadores ou reutilizando-as de maneiras inusitadas.\nÉ surpreendente – Um bom level design não tem medo de arriscar o ritmo, estética, localidade e outros elementos para criar uma experiência nova.\nCapacita o jogador – Video games são escapistas e, como tal, devem abster-se do mundano. Além disso, um bom level design reforça a capacidade do jogador permitindo que eles experimentem as consequências das suas ações, de maneira imediata ou a longo prazo através do design dos de todos os níveis.\nPermite ao jogador controlar a dificuldade – Prepara o caminho principal para jogadores iniciantes, apresentando à jogadores avançados desafios opcionais comunicando claramente o risco e a recompensa.\nÉ eficiente – Recursos são limitados. Um bom design de nível cria eficiência através da modularidade, jogabilidade bidirecional, objetivos integrados e bônus exploráveis que fazem uso de todo espaço jogável.\nCria emoção – Começa pelo fim, com a resposta emocional desejada, e trabalha no sentido contrário, selecionando as mecânicas apropriadas, métricas espaciais e dispositivos de narrativa para alcançar aquela resposta.\nÉ movido pela mecânica do jogo – Acima de tudo, demonstra a mecânica do jogo através dos níveis, para reforçar a natureza interativa única dos video games.\nConfira o texto completo na parte 1 e na parte 2 deste artigo no gamasutra, lá cada um destes princípios é explicado com mais detalhes e exemplos. O level design é tão importante que muitos game designers e até artistas se especializam nesta área. Este é um bom resumo das preocupações que um level designer deve ter, mas existe muito mais do que isso para se estudar!\nImagem da capa: Game world computer game screen do Shutterstock.\nRecomendação da semana\nComo estou tentando fazer um post por semana, quero aproveitar para começar algo novo e deixar no final do texto uma sugestão de algo que me chamou a atenção durante a semana, sempre tentando relacionar isto com desenvolvimento de jogos.\nEsta semana quero apresentar um card game chamado Star Realms, que possui versão física e digital (gratuita) para várias plataformas. A versão digital veio depois e é incrivelmente fiel a versão física do jogo, e acredito que tenha sido desenvolvido utilizando Unity. Apesar da mecânica do jogo ter sido muito bem implementada, a interface fica um pouco pequena em dispositivos móveis. O que me chamou mais a atenção neste jogo é a sua mecânica chamada deck building, que dá uma dinâmica incrível ao jogo.\n","date":"20 de janeiro de 2016","externalUrl":null,"permalink":"/10-principios-level-design/","section":"Blog","summary":"Há quase 3 anos atrás li um post muito bom do game designer Dan Taylor no gamasutra sobre dez princípios para um bom level design. Salvei o link para publicar aqui e acabei esquecendo, mas aqui está uma tradução/interpretação minha do resumo feito pelo autor.\n","title":"10 princípios para um bom level design","type":"posts"},{"content":"Recebi um email de um leitor do blog chamado Alexandre que, como muita gente que está começando, estava com dúvida em relação a indústria de games. Suas 5 perguntas foram tão bem formuladas que eu pedi sua permissão para postá-las aqui no blog, confira abaixo!\nNo mercado de programadores para games uma certificação conta muito na hora de uma contratação?\nNão. É claro que é importante ter pelo menos uma formação sólida como Ciência da Computação ou Engenharia, mas o que realmente conta na contratação é experiência. E o bom é que esta experiência não é necessariamente profissional, conta tudo que você fizer no seu tempo livre e publicar em um portfólio. Meu primeiro emprego com games foi assim, mostrei o que eu já tinha feito e respondi todas perguntas dos entrevistadores.\nQuais as qualificação mais desejadas pelas empresas , tanto no brasil como no exterior?\nNo Brasil: ter portfolio. No exterior: ser formado e ter portfolio. Ai depende do que vc estiver procurando. Se for trabalhar com mobile, por exemplo, muito provavelmente vão cobrar experiência com Unity (aqui e fora). No caso de programadores, os jogos do portfolio não precisam ser bonitos, mas você pode usar arte da internet e fazer o jogo para mostrar que sabe programar.\nEm relação e linguagens de programação, devo conhecer a fundo uma linguagem ou ser generalista?\nSaber bem uma linguagem de programação é bom, mas lembre-se que ser o melhor em C# não quer dizer que vc seja o melhor em usar C# para fazer jogos com uma engine ou framework. É preciso estudar linguagem de programação sim, mas no caso de jogos também é necessário estudar engines e frameworks. No começo parece que existem milhares de opções, mas depois de um tempo você se acostuma com tudo e a mudar de tecnologia com frequencia e não ficar preso em uma. Minha sugestão para começar é estudar C# e Unity, pois além de ser uma engine muito boa, também é o que as empresas aqui e fora estão mais usando atualmente.\nO que você considera decisivo, imprescindível para alcançar o sucesso nesse ramo?\nTer um portfolio (para provar que sabe fazer jogos, como disse anteriormente) e saber Inglês. Quando comecei a minha pós logo percebi que também era necessário saber Inglês e comecei um curso. Isso foi decisivo para minha carreira, pois muitas entrevistas e até mesmo no meu dia a dia nas empresas que trabalhei eu tinha que usar Inglês. E além disso, a maioria dos livros bons estão em Inglês.\nAlgum outro conselho que queira contar?\nAproveite que você está começando na faculdade e tente encontrar na sua sala pessoas que tenham os mesmos interesses que você, isso pode te ajudar a focar os projetos do curso em games e até fazer um TCC sobre o assunto. E, quem sabe, não sai algo legal de um grupo assim. Outra dica importante: jogue jogos diferentes, não apenas os quevocê gosta. Arrisque baixar jogos que você normalmente não jogaria e tente aprender a fazer uma analise dele. Sempre que você achar que um jogo é ruim tente responder estas duas pergunta: ‘eu conseguiria fazer algo assim?’ e ‘o que eu faria para melhorar este jogo?’. Ah, além de programação, recomendo dar uma lida em game design também para abrir mais sua mente em relação ao processo de criação de jogos.\nMuito obrigado ao Alexandre e a todos os outros leitores que acompanham o meu blog e me enviam emails. Tenho atualizado pouco aqui nos últimos meses, e até os emails estou demorando para responder. Mas (como já disse muitas vezes antes) vou tentar me organizar melhor para sempre postar um conteúdo legal aqui e responder emails o mais breve possível.\nImagem da capa: Computer programming source code do Shutterstock.\n","date":"13 de janeiro de 2016","externalUrl":null,"permalink":"/5-duvidas-programacao-jogos/","section":"Blog","summary":"Recebi um email de um leitor do blog chamado Alexandre que, como muita gente que está começando, estava com dúvida em relação a indústria de games. Suas 5 perguntas foram tão bem formuladas que eu pedi sua permissão para postá-las aqui no blog, confira abaixo!\n","title":"5 dúvidas sobre programação de jogos","type":"posts"},{"content":"A Editora Novatec trouxe para o Brasil um excelente livro de Harrison Kinsley e Will McGugan: Introdução ao Desenvolvimento de Jogos em Python com PyGame. Este é um livro recheado de surpresas até mesmo para desenvolvedores que já conhecem Python.\nCom pouco mais do que 350 páginas, este livro consegue ser uma introdução perfeita ao assunto, rápido e fácil de ler. Se você não sabe Python não tem problemas, os dois primeiros capítulos tem o objetivo de ensinar a programar e configurar tudo que é necessário para os exemplos do livro. No terceiro capítulo há uma pequena introdução ao PyGame, explicando diversas funcionalidades básicas deste framework. E a partir do capítulo 4 a diversão começa!\nTudo que é necessário para se criar um jogo utilizando o PyGame é apresentado: como desenhar na tela, pegar input do jogador, mover objetos, efeitos sonoros, e até um pouco de inteligência artificial. Mas o que realmente chama a atenção para este livro são os capítulos finais.\nDe uma maneira muito didática, os autores apresentam como criar jogos utilizando OpenGL dentro do PyGame. Por ser algo relativamente avançado para iniciantes, boa parte do livro é dedicada a este assunto. Iluminação, câmera, modelos 3D, skyboxes, fog, texturas, entre muitas outras coisas são apresentadas, e até uma pequena introdução ao OpenGL. Acredito que das coisas mais comuns ficou de fora apenas um pouco sobre animação e shaders, mas o conteúdo é tanto que não da para reclamar disso em um livro introdutório.\nPor fim os autores ensinam como empacotar o seu jogo para publicá-lo ou pelo menos enviar para seus amigos jogarem. Pode parecer simples, mas é algo não trivial para iniciantes e muitos autores esquecem deste detalhe.\nAté antes de ler este livro meu único contato com Python foi criar scripts para automatizar build de jogos, porém o PyGame abriu minha mente para tentar fazer mais coisas com Python. É uma linguagem de programação incrível e que vale a pena estudar.\nMuito obrigado a Editora Novatec por me enviar este livro para fazer esta review. Você pode comprar este livro e outros no site da Novatec, e utilize o código GAMEDEVELOPER para ter desconto na compra!\n","date":"6 de janeiro de 2016","externalUrl":null,"permalink":"/introducao-jogos-python-pygame/","section":"Blog","summary":"A Editora Novatec trouxe para o Brasil um excelente livro de Harrison Kinsley e Will McGugan: Introdução ao Desenvolvimento de Jogos em Python com PyGame. Este é um livro recheado de surpresas até mesmo para desenvolvedores que já conhecem Python.\n","title":"Introdução ao Desenvolvimento de Jogos em Python com PyGame","type":"posts"},{"content":"Este é o primeiro postmortem de um jogo de RPG publicado aqui no blog. Teharth Prologue – The Resources Dissolution é o terceiro jogo do Maurílio Eudes Okamoto, que já publicou os jogos Sou Sustentável e Manual do Skate, e o primeiro do Teharth Studios. Confira aqui um resumo de como foi o desenvolvimento deste projeto as dificuldades que a equipe encontrou para terminar e publicar o jogo e clique aqui para fazer o download do jogo.\nDescrição do jogo O jogo tem como gênero um RPG de ação 2D, com bastante uso de metaficção (quebra da quarta parede), um pouco de humor com paródias e non-sense. E trata-se de apenas um Prólogo do que está por vir futuramente, possui cerca de 1 hora de jogo.\nA história se passa em Baghdah, um país localizado no extremo leste do continente. Gray um aventureiro iniciante, decide explorar todo o mundo de Teharth. Sua primeira parada foi nas Misteriosas Ruínas de Abyadh, onde ele encontra um ser lendário chamado Azazil. Esse ser tem o poder de dissolver os recursos do jogo, como a aparência física, os sons e os mecanismos de seres e objetos de Teharth.\nO jogador possui o poder de evoluir de volta os recursos do jogo, auxiliando assim o Gray a conseguir atingir seus objetos e a resolver os quebra-cabeças. Pois Gray não consegue fazer muita coisa sem os recursos dele e o jogador não pode interagir diretamente com os elementos de Teharth. O jogador está participando do jogo como entidade jogador e não personificando o protagonista.\nPostmortem Dessa vez fiz o postmortem um pouco diferente, em vez de separar em pontos positivos e negativos, vou citar pontos “importantes” que acreditamos que podem ser interessantes. O motivo de não fazer essa separação é porque nesse projeto tivemos muitos pontos que são tanto positivos quanto negativos.\nO Projeto Nasceu de Um Problema No Teharth Studios, até poucas semanas atrás, nosso maior problema era falta de artistas, para fazer a parte gráfica/arte dos jogos. Na época, em março, pensamos em tentar fazer um projeto um pouco mais simples e que pesasse menos em arte.\nFoi então que nasceu a ideia de evoluir o jogo de protótipo para final durante a jogada. Como gostamos de tentar inovar e colocar metaficção, colocamos o poder de evoluir o jogo no jogador, sendo um co-protagonista do jogo.\nDesse modo, conseguimos dar um tempo maior para os artistas, pois as artes mesmo só seriam usadas na segunda metade do projeto. E também tivemos mais tempo para recrutar novos artistas.\nEntão de um problema, conseguimos um projeto e novos membros. Porém isso também gerou um outro problema. No começo do ano estávamos desenvolvendo outro projeto e tivemos que pausar ele, pois manter dois projetos seria um pouco complicado.\nInexperiência da Equipe Gerou Experiência Começamos projetar algumas coisas em 2014, porém só conseguimos começar algo efetivamente em janeiro de 2015. Ao longo de 2015 começamos estabilizar a equipe. Porém o grande problema era que a maioria não havia criado nenhum outro jogo completo anteriormente, por mais simples e curto que seja. Então decidimos fazer 1 ou outro prólogo, seriam projetos não necessariamente simples, mas curtos para a equipe começar ganhar mais experiência prática.\nO problema de alguns era falta de conhecimento em áreas específicas, outros tinham conhecimento, mas não sabiam direito como aplicar em jogos. Então vimos que um prólogo poderia ser perfeito para iniciar as coisas, mesmo porque a maioria dos membros não se conheciam entre si, seria um bom jeito de aumentar o engajamento e o trabalho em equipe.\nComo é geralmente comum em equipes pequenas, muitas pessoas acabam tendo que participar de várias áreas diferentes. Por um lado ruim isso diminui o foco, por outro lado melhora a comunicação entre os membros. Ao aprender e entender mesmo que bem pouco uma outra área de desenvolvimento. Faz você entender melhor o que os outros membros passam, que não é tão fácil ou não é tão difícil fazer tal tarefa daquela área.\nEntão a inexperiência gera experiência, de certa forma isso é meio óbvio, porém somente é verdade quando a pessoa corre atrás para evoluir.\nObjetivo do Projeto: Velocidade X Qualidade Colocamos em mente que nosso objetivo principal seria o ganho de experiência e o projeto deveria ser algo breve. Como citado no item 1, existe outro prólogo que estava em desenvolvimento. Então a ideia era terminar logo esse projeto para continuar o “prólogo de verdade”.\nO lado ruim disso é que o jogo não foi lapidado até o final, poderíamos ter melhorado muitas coisas, como deixar a mecânica ainda mais divertida, melhorar o roteiro que foi feito as pressas, criar animações melhores, algumas delas estão meio estranhas. Muitos desses problemas são consequências de a gente não ter sentado para fazer o GDD do projeto direito, já saímos desenvolvendo sem uma planejamento bem definido.\nPorém de forma positiva esse objetivo manteve melhor o nosso foco e conseguimos concluir o projeto e o objetivo dele. Com uma qualidade final razoável e uma ideia de jogo bacana, com potencial a ser explorado.\nBasicamente o desenvolvimento desse jogo foi um treino para fazer o próximo. Absorver os feedbacks positivos e negativos para fazer melhor futuramente.\nMudanças Este item é consequência dos outros três anteriores. Começamos o projeto “do nada”, nós acreditávamos que a ideia era boa, mas precisávamos ver como aplicar isso. Sabemos que muitas mudanças geram diversos problemas, como retrabalho, frustração, conflitos, entre outros. Porém pode deixar o projeto ainda melhor. Abaixo segue um breve histórico do projeto.\nAbril de 2015: Pelo nosso foco em velocidade, decidimos fazer um jogo 2D do gênero plataforma. Arte 100% minimalista, com evolução do jogo apenas em mecânicas. Chegamos a criar um GDD simplificado as pressas e um protótipo. Porém pensamos depois, que poderíamos evoluir arte e áudio também, temos artistas (mesmo que pouco) e músicos. O gênero plataforma é um dos mais usados em jogos indies, tanto brasileiro quanto de fora. O feedback que mais recebemos na época foi que parece muito com Evoland ou DLC Quest. Mas a gente não achava isso, não estávamos apresentando a ideia de jeito certo. Como gostamos de tentar fazer diferente, cancelamos o projeto.\nMaio de 2015: Mas como a gente achou a ideia da evolução muito bacana e queríamos testar como o público iria reagir. Então pensamos em outro projeto usando essa ideia. Aqui o jogo passou a ser um RPG de ação 2D, com evolução de arte e áudio além da mecânica, deixando o projeto 5 vezes mais complexo que o anterior, indo contra o objetivo inicial. Porém o foco do grupo Teharth Studios é fazer RPG ou pelo menos híbridos com RPG, mais especificamente JRPGs. Após criar um novo GDD simplificado e um protótipo dele, vimos que o jogo não ficaria muito bom, com o tempo e equipe que temos. Aí cancelamos o projeto novamente. Pois, só o fato de ter RPG na descrição do projeto já fazia tudo ficar mais complexo.\n(Em junho e julho o responsável da equipe e projeto, teve que mudar de casa, que demorou muito para terminar e teve a perda de um irmão. Com isso o projeto acabou ficando de lado, sem ele a equipe não se sustenta direito.)\nAgosto de 2015: Decidimos então fazer algo ainda usando a ideia da evolução, mas seria um jogo de puzzles (quebra-cabeças), sem batalha e roteiro.. Algo por fases em vez de contínuo, algo bem mais casual e possivelmente para mobile. Ficamos o mês todo rabiscando algo, mas o projeto não dava aquela motivação de querer desenvolver ele.\nSetembro de 2015: Ficamos na dúvida e basicamente não fizemos nada em setembro. Somente no final do mês, decidimos voltar na ideia de maio, era ela que a gente achava gostava, decidimos tentar mesmo sabendo que poderia dar errado. Podemos dizer que o projeto começou efetivamente no final desse mês.\nOutubro de 2015: O velho problema da falta de artistas pesou novamente. Porém decidimos fazer o projeto mesmo assim, qualquer coisa ficaria com menos evoluções de arte. Porém no final do mês conseguimos ajuda de 3 novos artistas e conseguimos fazer tudo que estava dentro do planejado. Nessa época um dos músicos teve que sair, ele que faria a orquestração das músicas, com isso as músicas ficaram um pouco menos lapidadas, mas ainda ficaram bacanas. Depois disso o projeto finalmente fluiu bem.\nDezembro de 2015: Tivemos alguns atrasos aqui, pois a maioria dos membros fazem faculdade e estavam em final de semestre com provas e tudo mais. Aí a fase final do projeto que era testar e lapidar o projeto, durou bem menos tempo que o previsto. Mas conseguimos corrigir os problemas que encontramos e melhorar algumas coisas.\nConclusão Apesar de o projeto não ter ficado tão bom quanto queríamos, cumprimos os objetivos com ele. Observamos que temos conhecimento para fazer algo bem melhor, se fizermos com calma e um melhor planejamento. Até agora já recebemos bastante feedback e em sua grande maioria foram positivos, então foi bastante gratificante desenvolver esse jogo.\nPara terminar, agradeço novamente ao Bruno Cicanci, pelo espaço e oportunidade de postagem de um postmortem por aqui, no Game Developer. E obrigado a todos que leram, aguardem que em 2016 quando atingirmos nossa meta iremos dobrá-la. Hahaha.\nAcompanhe-nos:\n– Site: http://teharthstudios.wix.com/home\n– Facebook: https://www.facebook.com/teharth.studios\n– Twitter: https://twitter.com/teharthstudios\n","date":"30 de dezembro de 2015","externalUrl":null,"permalink":"/postmortem-teharth-prologue/","section":"Blog","summary":"Este é o primeiro postmortem de um jogo de RPG publicado aqui no blog. Teharth Prologue – The Resources Dissolution é o terceiro jogo do Maurílio Eudes Okamoto, que já publicou os jogos Sou Sustentável e Manual do Skate, e o primeiro do Teharth Studios. Confira aqui um resumo de como foi o desenvolvimento deste projeto as dificuldades que a equipe encontrou para terminar e publicar o jogo e clique aqui para fazer o download do jogo.\n","title":"Postmortem: Teharth Prologue - The Resources Dissolution","type":"posts"},{"content":"Existem alguns livros que são tão únicos na abordagem de seus assuntos que se tornam referência e sempre são recomendados para quem tem interesse de estudar seu assunto específico. Isto acontece com este livro que, como o próprio título diz, é um manual para produção de jogos digitais.\nA autora Heather Maxwell Chandler trabalha com produção de jogos desde 1996 e já passou por empresas como Ubisoft, Activision e Electronic Arts. Embora o livro tenha sido escrito visando projetos de jogos em equipes, muita coisa nele vai ser bem útil para desenvolvedores independente.\nO primeiro capítulo é um belo resumo das 4 principais fases da criação de um jogo: Pré-Produção, Produção, Testes e Pós-Produção. Todos os demais capítulos vão detalhar bem cada uma dessas fases do ciclo de produção, explicar tudo que é recomendável ter ou fazer em cada uma elas, mas isso não significa que tudo deve ser seguido a risca. No capítulo 2 são apresentados praticamente todos papéis possíveis na produção de um jogo, e o capítulo 3 fala rapidamente sobre métodos para gerenciar um projeto.\nA parte II e III do livro eu tenho quase certeza de que este é o único livro que deve abordar este assunto na indústria de jogos. Detalhes sobre a parte legal de um projeto, como licenças e contratos, são apresentados para deixar claro como proteger seu projeto. Além disso, existe um capítulo inteiro sobre como deve ser o relacionamento entre o desenvolvedor e uma publisher de jogos, algo bem raro de se encontrar por ai, principalmente do ponto de vista de uma produtora de jogos. Na parte III o foco é a gestão das pessoas, desde como contratar e manter talentos na equipe, até como ter uma comunicação eficaz com o time.\nNa parte IV o foco é a produção técnica, e assuntos como música, voiceover, captura de movimentos, jogos online, marketing e relações públicas são abordados. É interessante que grande parte destes assunto possuem poucos livros sobre eles. Imagino que de maneira proposital assuntos como física e inteligência artificial foram deixados de lado aqui porque existem muitos livros sobre eles.\nO restante do livro tem um foco maior no papel do produtor e são apresentados em detalhes os assuntos Pré-Produção, Produção, Testes e Pós-Produção. São tantas coisas legais como testes com usuários, postmortem, localização, classificação de jogos, análise SWOT, entre muitos outros tópicos, que este texto ficaria do tamanho do livro para falar de tanto conteúdo de qualidade apresentado.\nEm resumo, este é um livro obrigatório para qualquer pessoa que quer trabalhar com jogos, não importante se é um desenvolvedor independente ou não. Este livro serve para programadores, artistas, designers, músicos e, é claro, produtores.\nMuito obrigado a editora Bookman por me enviar está cópia para fazer esta review! Você pode comprar este livro no site da editora ou em outras livrarias virtuais.\n","date":"29 de dezembro de 2015","externalUrl":null,"permalink":"/manual-de-producao-de-jogos-digitais/","section":"Blog","summary":"Existem alguns livros que são tão únicos na abordagem de seus assuntos que se tornam referência e sempre são recomendados para quem tem interesse de estudar seu assunto específico. Isto acontece com este livro que, como o próprio título diz, é um manual para produção de jogos digitais.\n","title":"Manual de Produção de Jogos Digitais","type":"posts"},{"content":"Participei do Ludum Dare pela terceira vez mas sempre parece ser a primeira pela quantidade de coisas que aprendo. Mudei algumas coisas desta fez, tentei ficar mais organizado, mas como sempre o tempo é o maior vilão.\nDesta vez houve um empate na votação do tema, e dois ficaram disponíveis. Cada participante poderia escolher um deles ou os dois, e eu acabei escolhendo fazer um jogo com ambos. Os temas eram Growing (crescimento) e Two button controls (controle com dois botões). Diferente da edição #33 onde demorei para pensar no jogo, desta vez foi bem fácil e rápido.\nMinha ideia foi fazer um jogo com meu cachorro, um pug chamado Spock. Neste jogo ele se movimentaria para esquerda e direita coletando itens que cairiam do céu. O brocolis é um item saudável, que dá pontos. Já a pizza não dá pontos, e faz ele ficar maior e lento. Com seu crescimento, ao invés de se movimentar ele iria rolar pela pela. E quando atingisse um tamanho máximo, iria explodir em confetti e o jogo terminaria.\nNovamente escolhi utilizar a Unity, principalmente pela facilidade de exportar para diversas plataformas e facilitar o teste do jogo. Existem muitos casos onde os desenvolvedores publicam apenas para uma plataforma e isso pode limitar um pouco o publico. Hoje por exemplo estou trabalhando usando um Mac, então jogos que não tem versão para Mac ou Web eu estou deixando pra testar depois quando ligar meu desktop Windows, mas há uma chance de eu não jogá-los também. Por isso escolhi usar a Unity e publicar para Mac, Windows, Linux e Android.\nEu cheguei a mencionar que estava planejando exportar para Web utilizando o WebGL da Unity que saiu do beta na versão 5.3, porém decidi não utilizá-lo neste momento. Provavelmente vou fazer upload do jogo na página do jogo no Ludum Dare depois, para ter mais uma opção disponível.\nDesta vez tentei brincar de artista e desenhei a pizza, o brocolis e o céu utilizando GIMP. Não sou artista, mas o resultado ficou até que aceitável e engraçado. Para o personagem utilizei a foto do Spock.\nAo invés de utilizar um pedaço de papel com as tarefas decidi me organizar utilizando o Trello, e criei um board com todas tarefas. A grande vantagem disso foi que caso eu queria continuar o jogo já deixei algumas coisas listadas lá como ideias futuras ou melhorias. Nos outros dois jogos pensei em várias coisas para melhorar, mas por não anotar deixei pra lá. Esta com certeza foi uma boa decisão para eu poder continuar o projeto.\nNovamente a parte mais difícil foi a falta de tempo, e isso me prejudicou muito neste projeto. Planejei muitas coisas que não tive tempo de fazer, e esta foi a primeira vez que não coloquei música e efeitos sonoros em um jogo do Ludum Dare. As fotos do Spock eram algo temporário, pois eu iria desenhar de algum jeito ele, mas também não tive tempo para isto. Como o uso de fotos são permitidas, eu deixei elas na versão final do jogo. Também não tive tempo de fazer a explosão em confetti no final do jogo.\nAlguns fatores que me prejudicaram:\nPublicar para várias plataformas: lembra que eu mencionei lá em cima no texto que isso era algo bom para testar? Realmente é, mas durante um game jam pensar em várias plataformas requer compilar e testar, e sempre é necessário fazer algum ajuste (principalmente no caso de mobile). Por isso da próxima vez vou focar em apenas uma plataforma; Criar a arte: diferente dos outros dois jogos que fiz nas edições passadas, este exigiu um pouco mais de “arte”, e por não ser artista acabei fazendo apenas os itens e o background; Fim de ano: Geralmente no fim de semana no final do ano temos muitas coisas para fazer por causa do Natal e viagens, e isto me deixou com pouco menos de 10 horas disponíveis para trabalhar no projeto. Outro problema é que nestas 10 horas disponíveis eu não estava descansado para me concentrar, então não renderam tanto quando eu gostaria. Por conta disso, acabei cortando coisas legais do jogo. O próximo Ludum Dare #35 será em Abril de 2016 e provavelmente irei tentar utilizar um framework diferente para fazer o jogo, além de focar em apenas uma plataforma. Vou tentar estar mais preparado para improvisar arte e fazer o possível para ter mais tempo disponível. Também quero tentar fazer um jogo melhor e maior, geralmente faço esses jogos simples por medo de não terminar a tempo.\nNeste link você pode conferir a página do jogo no Ludum Dare os links para download do jogo. O código do jogo está disponível no meu GitHub.\nUPDATE: Adicionei uma build web lá na página do jogo no Ludum Dare, realmente está muito melhor essa versão nova da Unity 5.3 para exportar WebGL. Ainda quero fazer testes com um jogo mais pesado, mas fiquei realmente surpreso pela melhora.\n","date":"14 de dezembro de 2015","externalUrl":null,"permalink":"/ludum-dare-34/","section":"Blog","summary":"Participei do Ludum Dare pela terceira vez mas sempre parece ser a primeira pela quantidade de coisas que aprendo. Mudei algumas coisas desta fez, tentei ficar mais organizado, mas como sempre o tempo é o maior vilão.\n","title":"Minha participação no Ludum Dare #34","type":"posts"},{"content":"Meia noite, no horário de Brasilia, começa mais uma edição do Ludum Dare, uma game jam internacional online onde desenvolvedores de jogos profissionais e amadores tem 48 horas para criar um jogo baseado em um tema (ou 72 horas no caso de equipes).\nNeste post sobre o Ludum Dare #33 dei algumas dicas para quem tem interesse de participar. Este vai ser o meu terceiro Ludum Dare, e estou bastante animado para colocar em prática muitas coisas que não tive tempo de fazer na edição passada.\nAcesse o site o oficial e se inscreva! Desta vez vou utilizar novamente a Unity para desenvolver o jogo, e vou dar mais uma chance para o exportador do WebGL que finalmente saiu do beta versão 5.3 lançada recentemente. Depois da Ludum Dare vou fazer um post contando minha experiência em uma uma game jam, e o jogo que consegui fazer.\nLinks interessantes:\nMinha participação no Ludum Dare #32 Minha participação no Ludum Dare #33 ","date":"10 de dezembro de 2015","externalUrl":null,"permalink":"/hoje-comeca-o-ludum-dare-34/","section":"Blog","summary":"Meia noite, no horário de Brasilia, começa mais uma edição do Ludum Dare, uma game jam internacional online onde desenvolvedores de jogos profissionais e amadores tem 48 horas para criar um jogo baseado em um tema (ou 72 horas no caso de equipes).\n","title":"Hoje começa o Ludum Dare #34","type":"posts"},{"content":"Ontem apresentei minha palestra sobre uso de design patterns na programação de jogos no evento GameDays 2015 na Universidade Cruzeiro do Sul em São Paulo. Confira aqui os slides apresentados.\nMuito obrigado a coordenação do evento por me convidar para realizar esta palestra, e também a todos que estiveram lá e assistiram minha apresentação. Abaixo esta o video que foi gravado durante a palestra, peço desculpas pela qualidade da imagem e do audio. ","date":"23 de outubro de 2015","externalUrl":null,"permalink":"/palestra-design-patterns-gamedays-2015/","section":"Blog","summary":"Ontem apresentei minha palestra sobre uso de design patterns na programação de jogos no evento GameDays 2015 na Universidade Cruzeiro do Sul em São Paulo. Confira aqui os slides apresentados.\n","title":"Minha palestra sobre Design Patterns no GameDays 2015","type":"posts"},{"content":"Nos dias 21, 22 e 23 de outubro acontece o GameDays 2015 na Universidade Cruzeiro do Sul em São Paulo no campus Liberdade, e eu serei um dos palestrantes do evento para falar sobre Design Patterns e técnicas de programação de jogos.\nO evento é gratuito e para se inscrever basta seguir as instruções deste link. Abaixo está um texto sobre o evento, que contará com outros palestrantes muito bons também. Não deixe de ir!\nO GameDays15 é um Evento Regional na área de Jogos Digitais Interativos, promovido pela Coordenação de Informática e ocorrerá nos dias 21, 22 e 23 de outubro no campus Liberdade da Universidade Cruzeiro do Sul. O evento já está em sua 11ª edição e pretende, ao longo dos anos, se tornar um referencial em São Paulo e região, em termos de jogos de computadores.\nObjetivos: Atingir a comunidade interna da Universidade Cruzeiro do Sul, envolvendo todos os alunos de computação e informática e mais especificamente os alunos do curso de Jogos Digitais. Além disso, o foco é contar com a participação de pessoas do meio empresarial e de outras instituições de ensino (faculdades, colégios, cursos técnicos). O objetivo é projetar o evento para o mercado e buscar parcerias.\n","date":"15 de outubro de 2015","externalUrl":null,"permalink":"/gamedays-2015/","section":"Blog","summary":"Nos dias 21, 22 e 23 de outubro acontece o GameDays 2015 na Universidade Cruzeiro do Sul em São Paulo no campus Liberdade, e eu serei um dos palestrantes do evento para falar sobre Design Patterns e técnicas de programação de jogos.\n","title":"GameDays 2015 na Unicsul em São Paulo","type":"posts"},{"content":"Fazem pouco mais de 5 anos que trabalho profissionalmente na indústria de jogos e, com cada vez mais tecnologias disponíveis para se fazer jogos, ainda é comum encontrar pessoas que ficam no “quero fazer jogos” e não fazem nem um PONG no tempo livre.\nMesmo quando eu comecei a trabalhar com jogos já existiam ferramentas bem legais para desenvolver, algo que era bem diferente há 10 anos atrás. Infelizmente, é bem fácil encontrar pessoas que falam que conhecem a Unity há anos, por exemplo, mas nunca fizeram um jogo. Lembrando que, como já escrevi neste post, fazer um jogo é desenvolver e publicar em algum lugar, não fazer algo e esconder no seu HD.\nDecidi escrever este post agora por que é algo que está acontecendo comigo, e que encontrei uma solução que está funcionando. Se olharem meu portfólio, vão ver que tem muitos jogos que eu trabalhei, porém nenhum deles é meu. Este ano percebi que eu preciso de jogos meus no meu portfólio, e fiquei pensando no que fazer.\nQuando se é novo na indústria de games é fácil ter muitas ideias, pois no começo não é muito claro se é realmente possível criar um jogo exatamente do jeito que foi pensado, pelo menos não sozinho. E quando se está há algum tempo na indústria, muitas ideias são ignoradas por saber que não é algo fácil de fazer ou que será algo muito demorado para desenvolver sozinho.\nEntão me surgiu uma ideia, participar do Ludum Dare, que é um concurso de desenvolvimento de jogos que acontece a cada 4 meses. Este ano participei de duas edições, o LD#32 e o LD#33, cada um com um tema bem diferente que me forçou a criar um jogo em menos de 48 horas e sozinho. Como escrevi no post sobre meus jogos do Ludum Dare, foi uma experiência incrível e agora quero participar sempre que tiver uma oportunidade dessas.\nE agora começa a próxima fase deste processo, que é pegar estas ideias já desenvolvidas e com um feedback legal de quem jogou e começar a desenvolver um jogo mais completo e polido em cima destes conceitos. Não que isso seja tão fácil como parece, mas é um caminho mais seguro.\nEsta foi a minha maneira de me forçar a criar jogos para meu portfólio, e espero que funcione. Nos próximos meses postarei aqui os resultados, e talvez até farei alguns posts sobre o desenvolvimento destes jogos.\nPor isso, chega! É hora de fazer jogos! Não fique meses escolhendo a ferramenta perfeita para desenvolver seu jogo (isso não existe), não espere encontrar um artista (use arte temporária ou compre), não espere encontrar um programador (aprenda a programar ou use uma engine mais visual). Simplesmente faça um jogo.\nImagem da capa: Programming Concept do Shutterstock.\n","date":"6 de outubro de 2015","externalUrl":null,"permalink":"/hora-de-fazer-jogos/","section":"Blog","summary":"Fazem pouco mais de 5 anos que trabalho profissionalmente na indústria de jogos e, com cada vez mais tecnologias disponíveis para se fazer jogos, ainda é comum encontrar pessoas que ficam no “quero fazer jogos” e não fazem nem um PONG no tempo livre.\n","title":"Chega, é hora de fazer jogos!","type":"posts"},{"content":"Eu fico muito feliz quando outros desenvolvedores independentes e até estudantes tem o interesse de publicar um postmortem sobre o projeto aqui no blog. Neste post, o desenvolvedor Aleksiam de 17 anos do Rio de Janeiro conta como foi criar e publicar seu primeiro game no Google Play usando Unity.\nEsta é mais uma história que mostra que o único impedimento para criar um jogo é você mesmo. Tente criar um jogo em seu tempo livre e publicá-lo, ou participe de game jams para se forçar a desenvolver um projeto. Gostaria muito de ver mais jogos publicados pelos leitores do blog e suas histórias contadas aqui.\nDescrição # Insect é um jogo casual, onde seu objetivo é sobreviver com um dos insects. Com a mecânica simples, onde seu dedo controla a personagem, desviando dos obstáculos mais rápido possível.\nSendo muito desafiador, o torna muito divertido. Você deve acumular estrelas para poder comprar Power-ups, ou então os personagens na loja.\nNo shop você vai encontrar uma variedade de itens, como o +5, que acrescenta 5 segundos no seu tempo atual, ou o raio, que destrói rapidamente os obstáculos. Nele, você também pode achar personagens carismáticos, como, a abelha rockeira, ou a libélula do reggae. Ganhando mais estrelas é possível dar upgrade nos seus personagens, e deixá-los mais legais.\nNo modo Zen você pode usar os Power-ups, como o míssil, causando grande estrago, ou a bolha que lhe deixar imune aos obstáculos. A velocidade dos obstáculos é alternada, então ele pode estar indo muito devagar e de repente aumenta sua velocidade, é um grande desafio.\nNo World você entra numa aventura fantástica, passando por fases até completar esse mundo e sendo muito bem recompensado. Para passar as fases você deve sobreviver 30 segundos, assim vai conseguir fechar o mundo dos insects.\nO modo Run tem níveis diferentes, como, easy, medium, hard, extreme, que você escolhe, e ao passar o tempo a velocidade vai aumentando. É quase impossível ficar 30 segundos no extreme, é o modo mais difícil do jogo, sem dúvida você tem que ter muita habilidade.\nAbra um presente e fique muito surpreso, podendo ganhar Power-ups ou até 85 estrelas de uma vez só, mas também pode ter azar e não ganhar nada, vai depender apenas da sua sorte!\nDificuldades e Problemas # Inexperiência # A minha falta de experiência com a Unity foi um grande problema, já tinha feito um jogo antes que ficou pela metade o Round, era de plataforma e bem legal, também fiz outros em outras engines como Construct 2, Game Maker, Game Salad, mas não quis dar continuidade nos jogos feitos nessas plataformas, talvez porque não gostasse tanto do jogo, fazendo assim minha desistência, era amar eles um dia e no outro o odiar.\nResoluções # Já no termino do jogo veio esse grande problema, adaptar o jogo em diferentes telas, tive pelo menos uns 3 dias de dor de cabeça para resolver essa questão, já que usava sprites, demorei um tempo para resolver, li mais sobre telas de celulares aprendi bastante, crie um algoritmo para os sprites se adaptarem e assim resolvi esse problema.\nTempo # Tive que fazer o Insect em um tempo limitado, já que estudo de manhã e à noite, então nesse tempo tirava para estudar sobre a engine, e confesso que perdi várias vezes para a preguiça, quando chega no PC assistia várias series, ou então estudava mais sobre redes, pentest, vulnerabilidades, física teórica entre outros assuntos diversos que não é necessário informar.\nSozinho # Quando estava fazendo o Insect tive algumas ajudas para testar e avaliar o jogo, infelizmente foi apenas esse tipo de ajuda que tive, não pode contar com outro programador ou um game designer, então isso me deixou limitado, a falta de outra pessoa também traz o desânimo.\nTestes em celulares # Eu não tenho um celular bom, e para testar os arquivos apk era muito complicado, isso trouxe uma dependência de um grande amigo, que fez vários testes para mim, mas a passagem do arquivo e sempre demorada e quando você quer saber o resultado rapidamente isso é um grande problema.\nTamanho # O Insect é consideravelmente grande para um jogo casual e ocupa muita memória, isso realmente não consegui solucionar, o que deixa meu app com uma desvantagem enorme.\nPontos Positivos # Um grande aprendizado # O Insect é foi um imenso aprendizado. Para trabalhar com a Unity tive que aprender uma nova linguagem o C#, já conhecia muito bem a linguagem Java, então o aprendizado de C# foi bem rápido, com todo conhecimento que tenho hoje sobre a Unity irei fazer mais jogos, que em breve estará neste ótimo blog.\nCusto baixo # O Insect teve um custo muito baixo os únicos gastos que tive foi com a pen tablet, e a taxa da Play Store, usei todas as ferramentas grátis o que deixou o jogo com pouco custo.\nConclusão # Insect um jogo muito divertido de se jogar e de fazer, me trouxe um pouco de dor de cabeça mas valeu muito a pena, a experiência que tive foi ótima por passar todas as partes de um desenvolvedor.\nCréditos # Sou muito grato a minha família que sempre apoia tudo que eu faço, aos amigos Luís Felipe Nunes, Ivan da Silva Junior e Yan Cavalcanti Santos, que me motivaram a continuar ou ajudando a testar meu jogo, também quando não estava muito confiante com meu jogo, a todos eles meu agradecimento.\nAleksiam Gutenberg Ferreira Junior\n","date":"24 de setembro de 2015","externalUrl":null,"permalink":"/postmortem-insect/","section":"Blog","summary":"Eu fico muito feliz quando outros desenvolvedores independentes e até estudantes tem o interesse de publicar um postmortem sobre o projeto aqui no blog. Neste post, o desenvolvedor Aleksiam de 17 anos do Rio de Janeiro conta como foi criar e publicar seu primeiro game no Google Play usando Unity.\n","title":"Postmortem: Insect","type":"posts"},{"content":"Há alguns meses atrás tive a oportunidade de fazer a review de um livro muito bom de desenvolvimento para Android. Muitos me perguntaram qual seria o livro equivalente de desenvolvimento para iOS, e a resposta está neste post.\nDesenvolvimento para iPhone e iPad do Ricardo Lacheta, publicado pela editora Novatec, está na sua terceira edição e foi atualizado para o iOS 8. Com 21 capítulos e mais de 600 páginas, este livro é uma ótima referência para quem já conhece desenvolvimento para iOS e um recurso ainda melhor para quem quer aprender.\nUm dos capítulos mais legais do livro é sobre a linguagem Swift, que foi lançada pela Apple há 2 anos e possui um SDK próprio para desenvolvimento de jogos. Apesar de ser um livro que foca na programação em Objective-C, este capítulo é suficiente para te fazer querer aprender mais sobre Swift. Existe um capítulo que fala do SpriteKit, porém é bem curto por não ser o foco do livro.\nAlém dos capítulos que são normais em livros que ensinam a desenvolver aplicativos para iOS, como criação de views, layout, utilizar recursos do aparelho, configuração de projeto, entre muitos outros, alguns me chamam a atenção por serem diferentes. Existe um capítulo dedicado ao iPad, e poucos livros dão esta importância a diferença entre ele e o iPhone. Não é apenas uma tela maior, existem muitos conceitos de layout para apps que são diferentes, e muitas destas coisas são explicadas neste capítulo.\nApesar de boa parte do livro ser visual, existe um capítulo em especial que deveria ser obrigatório para todo desenvolvedor que programa em Objective-C, como usar o seu gerenciamento de memória. Além de ter várias dicas legais de como evitar problemas comuns e boas práticas de programação, ele ensina como desligar o ARC para fazer seu próprio gerenciamento da memória (muito usado em aplicativos que exigem boas performances, como jogos).\nPara finalizar, queria também mencionar outro capítulo muito útil, que também me chamou a atenção do livro de Android, que é sobre integração com back-end usando XML e JSON. Isto é algo bem comum, e fico feliz de ver livros explicando como fazer de forma bem direta e prática.\nSe você já desenvolve para iOS, ou quer aprender, este é o livro ideal para você. Junto com o livro de Android que mencionei no início do post, eles formam uma dupla essencial para desenvolvimento mobile.\nMuito obrigado a Editora Novatec por me enviar este livro para fazer esta review. Você pode comprar este livro e outros no site da Novatec, utilize o código GAMEDEVELOPER para ter desconto na compra!\n","date":"16 de setembro de 2015","externalUrl":null,"permalink":"/desenvolvimento-para-iphone-e-ipad/","section":"Blog","summary":"Há alguns meses atrás tive a oportunidade de fazer a review de um livro muito bom de desenvolvimento para Android. Muitos me perguntaram qual seria o livro equivalente de desenvolvimento para iOS, e a resposta está neste post.\n","title":"Desenvolvimento para iPhone e iPad","type":"posts"},{"content":"Acredito que muitos desenvolvedores de jogos (e jogadores) têm uma paixão especial por jogos de tabuleiro, principalmente jogos diferentes e desafiadores. Neste post quero falar sobre a relação deles com jogos digitais, e como funciona a conversão de um para o outro.\nQuando comecei minha pós-graduação em Produção e Programação de Games não imaginava que existia uma conexão especial entre jogos digitais e analógicos (como os de tabuleiro ou card games), e foi após uma aula de Game Design que tudo isso mudou.\nInfelizmente não lembro de qual livro o professor fez a citação, mas ele disse que “todos jogos digitais podem ser analógicos, e vice-ver”. Isso significa que, qualquer jogo digital pode ser convertido para um board game ou card game, e que qualquer jogo analógico pode se tornar um jogo digital. É claro que a adaptação nem sempre é trivial e pode exigir muito trabalho.\nVou dar um exemplo: League of Legends é um jogo digital, que poderia facilmente se tornar um jogo de tabuleiro. Tudo nele pode ser convertido:\nO mapa do jogo seria um tabuleiro Os personagens teriam suas miniaturas e cartas com respectivos atributos Seria necessário algo para marcar a experiência e nível As moedas e a “lojinha” estariam disponíveis para os jogadores Cada jogador teria um número limitado de ações por turno O combate seria utilizando dados e os atributos do personagem Provavelmente features como marcar experiência e nível poderiam ser simplificadas, para deixar a jogabilidade mais fácil. Um bom exemplo de como ficaria este jogo em um board game é o Krosmaster Arena, que inclusive tem personagens vendidos separadamente (como se fossem “DLCs”):\nExistem muitos exemplos de jogos digitais que foram convertidos para analógicos, como Word of Warcraft e Starcraft.\nAgora vamos ao exemplo inverso, transformar um jogo de tabuleiro em digital. Aqui entra um detalhe curioso, pode ser bem complicado adaptar todas informações do jogo na interface digital e um multiplayer na mesma tela teria algumas desvantagens como poder ver cartas na mão de todos jogadores. Vamos analisar o board game Ticket To Ride, pois ele possui também uma versão digital chamada Ticket To Ride Pocket.\nAs cartas que cada jogador tem na mão devem permanecer secretas para ele apenas, pois são recursos para construir ferrovias e objetivos. Desta forma, não seria possível ter uma versão multiplayer no mesmo device, ou seria necessário pedir para todos fecharem os olhos quando você quisesse ver sua mão (mesmo durante o turno de outro jogador).\nPensando nisso, a versão digital só permite multiplayer local se cada jogador estiver com seu aparelho na mesma rede, assim cada um só vê a sua própria mão e quando quiser. Ou você pode jogar online com seus amigos em turnos, como o Words With Friends. Este jogo de tabuleiro possui poucas regras e poucos elementos para ser colocados em uma interface, o que deixou o jogo bem simples de se adaptar.\nOutros jogos podem ser um pouco mais complicados de se adaptar, e exigir muitas regras e itens, como é o caso do XCOM: Enemy Unknown e o XCOM: Board game. Outros exemplos são card games famosos como Magic: The Gathering e Pokémon Trading Card Game que também tiveram suas versões digitais lançadas.\nComecei a jogar card games com Pokemon há muito tempo, depois conheci Magic e muitos outros. Recentemente comecei a me interessar mais por board games, e provavelmente vou fazer mais posts sobre este assunto no futuro.\n","date":"2 de setembro de 2015","externalUrl":null,"permalink":"/board-games-e-jogos-digitais/","section":"Blog","summary":"Acredito que muitos desenvolvedores de jogos (e jogadores) têm uma paixão especial por jogos de tabuleiro, principalmente jogos diferentes e desafiadores. Neste post quero falar sobre a relação deles com jogos digitais, e como funciona a conversão de um para o outro.\n","title":"Jogos de tabuleiro e sua relação com jogos digitais","type":"posts"},{"content":"Esta foi minha segunda participação no game jam Ludum Dare, e isto me fez entender uma coisa: não é apenas o tema que muda, mas tudo é diferente em cada edição.\nVou fazer um resumo de como foi minha participação neste Ludum Dare e o jogo Sea Monster que eu desenvolvi para categoria chamada compo. Nesta categoria, o desenvolvedor tem que criar tudo do zero em 48 horas: código, arte, efeitos sonoros e música.\nNo evento anterior o tema foi “An Unconventional Weapon” (uma arma não-convencional), e foi ótimo por que permitiu explorar diversas mecânicas diferentes. Porém, o tema desta vez foi “You are the monster” (você é o monstro), e se levarmos ao pé da letra não existem tantas opções: seu jogo deve ter um monstro que será representado pelo jogador. Existem discussões sobre este tema, e muita gente fez coisas diferentes, mas muitos também pensando da mesma maneira que eu e fizeram um jogo onde o jogador é o monstro.\nEsta foi uma das primeiras dificuldades que tive: pensar em que jogo fazer. Na edição anterior a minha ideia veio em poucos minutos após ver qual era o tema, e então comecei a desenvolver na sexta-feira a noite e só terminei domingo a tarde, algumas horas antes do prazo.\nDesta vez só consegui ter uma ideia de jogo interessante no sábado (isso que fiquei pensando em opções desde sexta-feira a noite), o que me fez perder um bom tempo de desenvolvimento. Só comecei a desenvolver no sábado a noite, e mesmo assim foram poucas horas. No domingo só tive a parte da tarde disponível para programar, então meu jogo foi desenvolvido em mais ou menos 8 horas, sendo que perdi pelo menos umas 8 horas pensando no que fazer.\nCom pouco tempo para fazer o jogo, foquei em desenvolver todo gameplay antes de pensar em arte e efeitos sonoros. Novamente utilizei a Unity, porém não foquei em desenvolver o jogo para Web. Fiz uma lista de features que queria desenvolver e segui ela, porém por falta de atenção deixei de fora uma feature que faria uma grande diferença no jogo. A falta de ideias iniciais me custou o valioso tempo e também tirou minha atenção para detalhes que deveriam estar no jogo.\nCom a mecânica do jogo definia, comecei a pensar na “arte” do jogo. Não sou artista, então pensei em fazer algo que fosse visualmente simples mas aceitável, e então pensei em deixar o jogo com uma cara de tabuleiro e meeples. Para uma arte de programador feita em poucos minutos para uma game jam de 48 horas, ficou até que bom.\nO próximo passo foram os efeitos sonoros e a música. Na edição anterior eu gravei vários barulhos na minha casa e usei no jogo, e fiz a mesma coisa desta vez. Como eu precisava de uma barulho envolvendo água, enchi uma vasilha de água e gravei alguns sons com meu celular. O som mais legal foi de mergulhar um copo com a boca pra cima, e também de jogar um copo dentro da vasilha. A combinação desses efeitos é o som do monstro afundando o barco ou apenas batendo na água. Novamente, pra quem tinha pouco tempo, ficou aceitável.\nUma coisa que eu não fiz na versão anterior foi música, e dessa vez quis arriscar colocar algo. Peguei meu violão e gravei algumas coisas simples com o celular, e no final selecionei músicas para o menu, o jogo e game over. Por ter gravado tudo usando meu celular e apenas ter usado um software para converter de m4a para ogg, o resultado ficou bom e com poucos ruídos.\nDesta vez meu foco foi criar um jogo com mecânicas mobile, então decidi não exportar para web. Na edição anterior este foi um dos meus maiores problemas, a versão WebGL que a Unity exporta é muito ruim, pesada e demora para compilar. Desta vez exportei para Windows, Mac, Linux e Android, e funcionou em todas plataformas sem problemas.\nNo final, eu queria ter feito isso: “Um jogo onde o jogador controla um monstro marinho que precisa impedir os barcos de atracarem no porto e sem ser visto pelo farol da ilha. Diferentes barcos iriam exigir mais de um ataque ou estratégias diferentes para serem afundados”. E isto foi o que consegui fazer: “Um jogo onde o jogador controla um monstro marinho que precisa impedir os barcos de atracarem no porto”.\nO código-fonte do jogo está disponível no meu GitHub e o jogo pode ser baixado aqui. Este Ludum Dare foi mais difícil pra mim do que o anterior, mas ainda é o meu segundo e muitas outras experiências virão nas próximas edições. Aprendi muitas coisas novas, e também cometi muitos erros novos, e tudo isso será lembrado na próxima edição em dezembro.\nUPDATE: Mais um item pra lista de falta de atenção, não esperava que um jogador pudesse ficar embaixo da ilha destruindo barcos sem parar. Deveria ter impedido o monstro de ficar debaixo da ilha ou colocado um delay em seu ataque.\n","date":"24 de agosto de 2015","externalUrl":null,"permalink":"/ludum-dare-33/","section":"Blog","summary":"Esta foi minha segunda participação no game jam Ludum Dare, e isto me fez entender uma coisa: não é apenas o tema que muda, mas tudo é diferente em cada edição.\n","title":"Minha participação no Ludum Dare #33","type":"posts"},{"content":"Logo desenvolvedores do mundo todo começarão a incrível tarefa de desenvolver um jogo sozinhos em 48 horas (ou em grupo com prazo de 72 horas), aproveite esta oportunidade para participar de um dos maiores game jams do mundo, o Ludum Dare!\nEste ano participei pela primeira vez de um Ludum Dare, o #32 que ocorreu em abril. Fiquei tão empolgado por ter consegui terminar o jogo antes do prazo de 24 horas e sozinho que pretendo participar sempre que tiver, e hoje será minha segunda participação.\nAlgumas dicas que aprendi com minha participação no último Ludum Dare:\nUtilize frameworks, engines e linguagens de programação que você já conhece, por ser muito curto não é o momento ideal para aprender coisas novas Não se preocupe com a arte, música e efeitos sonoros até ter o gameplay funcionando Preste atenção para que seu jogo se encaixe no tema do Ludum Dare e seja divertido (existem algumas categorias que as pessoas vão julgar seu jogo) No meu último jogo gravei os efeitos sonoros utilizando meu celular e fazendo barulhos com objetos, depois editei com Audacity A arte inicial eu fiz no Photoshop (se é que aqueles quadrados brancos com texto podem ser chamados de arte rs), mas desisti de fazer algo “menos pior” por que não sou artista Um lembrete sobre os dois modos de participar:\nCompo: você deve fazer um jogo do zero e sozinho em 48 horas, incluindo código, arte e som Jam: você pode fazer um jogo sozinho ou em grupo em 72 horas, a arte e o som podem ser reaproveitados ","date":"21 de agosto de 2015","externalUrl":null,"permalink":"/hoje-comeca-o-ludum-dare-33/","section":"Blog","summary":"Logo desenvolvedores do mundo todo começarão a incrível tarefa de desenvolver um jogo sozinhos em 48 horas (ou em grupo com prazo de 72 horas), aproveite esta oportunidade para participar de um dos maiores game jams do mundo, o Ludum Dare!\n","title":"Hoje começa o Ludum Dare #33","type":"posts"},{"content":"No último sábado apresentei a palestra Programação de Jogos no evento The Developers Conference 2015 que aconteceu em São Paulo. O foco da palestra foi a utilização de design patterns no desenvolvimento de jogos, confira os slides abaixo.\nMuito obrigado a organização do evento por ter selecionado a minha palestra para a trilha de games e um obrigado especial para todos que compareceram em uma manhã de sábado chuvosa no TDC e por terem assistido minha palestra.\nPretendo fazer um post sobre o conteúdo da palestra, pois gostei muito de apresentar sobre utilização de design patterns.\n","date":"27 de julho de 2015","externalUrl":null,"permalink":"/palestra-design-patterns-tdc-sp-2015/","section":"Blog","summary":"No último sábado apresentei a palestra Programação de Jogos no evento The Developers Conference 2015 que aconteceu em São Paulo. O foco da palestra foi a utilização de design patterns no desenvolvimento de jogos, confira os slides abaixo.\n","title":"Minha palestra sobre Programação de Jogos na TDC","type":"posts"},{"content":"Este post é um pouco diferente do normal, pois eu quero recomendar alguns filmes e documentários sobre a indústria de games que vale muito a pena assistir!\n1) Indie Game: The Movie # Este filme dispensa apresentações, acredito que muitos leitores já conheçam. Quando foi lançado eu fiz este post sobre o filme, e hoje está disponível no Netflix e a venda neste site.\nPor que vale a pena: Este filme mostra um pouco da realidade e da pressão de desenvolvedores que se dedicam a fazer seus próprios jogos. O filme mostra dois casos de sucesso, Super Meat Boy e FEZ, mas mesmo assim não deixa de deixar claro o quão difícil é alcançar o sucesso (e como isso pode deixar uma pessoa maluca).\n2) History of Mojang # Quando vi pela primeira vez este documentário fiquei surpreso por que começaram a filmar no momento em que o Minecraft começou a crescer e a Mojang mudou-se para seu pequeno escritório na Suécia. Ele ficou disponível por um tempo no YouTube, mas está a venda neste site.\nPor que vale a pena: Minecraft ainda vai ser lembrado como um jogo que marcou a indústria dos games, e o fez em diversas maneiras. Uma delas é retratada neste documentário, que é o uso deste jogo para ensinar crianças. É um bom documentário, e mostra a melhor fase da Mojang.\n3) Free To Play: The Movie # Este documentário feito pela Valve conta a jornada de alguns jogadores que chegaram a final do campeonato de Dota 2, e está disponível gratuitamente no YouTube da empresa:\nPor que vale a pena: Este não é um documentário sobre desenvolvedores de jogos, mas sim sobre o poder que temos de influenciar a vida das pessoas e até criar novos esportes e campeonatos milionários.\n4) Critical Path: Dynamic Interview Archive # Também fiz um post quando este documentário foi lançado e, diferente do Indie Game: The Movie, este filme possui diversos vídeos de veteranos da indústria de games compartilhando um pouco da sua experiência sobre determinado assunto. Todos os vídeos estão disponíveis gratuitamente no site do projeto.\nPor que vale a pena: Se o trailer acima não te fez querer assistir ainda, dá uma olhada em alguns nomes que participaram deste projeto: Ckiff Blesinski (Gears of War), Will Wright (The Sims, Spore), Nolan Bushnell (Fundador da Atari), Ken Levine (Bioshock), Sid Meier (Civilization), Warren Spector (Deus Ex, Epic Mickey), John Carmack (Quake, Doom) e Hideo Kojima (Metal Gear).\n5) Atari: Game Over # Toda indústria tem suas lendas urbanas, e a de games não poderia ficar de fora mesmo sendo relativamente jovem. Uma das maiores lendas é a história de que a Atari enterrou diversas cópias do seu “pior jogo” E.T. em algum lugar “secreto”. Este filme, disponível no Netflix, mostra a saga de um cara atrás da verdade e conta com a participação do escritor Ernest Cline e alguns dos primeiros funcionários da empresa.\nPor que vale a pena: Além da busca pela verdade mostrada no documentário, outra parte muito interessante são as entrevistas com os programadores da Atari mostrando como era difícil desenvolver um jogo naquela época e por que muitos eram considerados rock stars.\nBônus: The Social Network (A Rede Social) # Provavelmente todo mundo já assistiu ou pelo menos ouvir falar sobre o filme que conta a história do Facebook baseada no livro Bilionários por Acaso. Este filme está disponível no Netflix e em mídia física.\nPor que vale a pena: Embora não seja um filme sobre a indústria de games é sobre algo que está muito relacionado a ela hoje: redes sociais. A empolgação mostrada no começo do filme é algo que muitos desenvolvedores independentes devem ter para correr atrás dos seus sonhos.\nEu estava sentindo falta de compartilhar aqui estes filmes e documentários que são muito importantes para um desenvolvedor de jogos conhecer. É claro que existem muitos outros relacionados a indústria de games que não estão listados aqui, e fiquem a vontade para dar sugestões de outros documentários e filmes nos comentários.\nImagem da capa: Atari retro console at Games Week 2013 do Shutterstock.\nUPDATE: # 6) GameLoading: Rise of the Indie # Sugestão do leitor João Paulo Santos Carvalho, pode ser comprado pelo site do documentário ou pelo Steam.\n","date":"11 de julho de 2015","externalUrl":null,"permalink":"/5-filmes-que-voce-precisa-assistir/","section":"Blog","summary":"Este post é um pouco diferente do normal, pois eu quero recomendar alguns filmes e documentários sobre a indústria de games que vale muito a pena assistir!\n","title":"5 filmes que você precisa assistir","type":"posts"},{"content":"Dependendo do que você usar como exemplo, 15 anos pode não parecer muito. Mas, quando levamos em consideração qualquer coisa relacionada a tecnologia, este tempo parece ser muito maior.\nEu confesso que joguei pouco Diablo II, na época gostava mais de Warcraft. Mesmo quem não jogou já ouviu falar alguma vez deste jogo, principalmente depois do lançamento do esperado Diablo III (que muitos fãs dos primeiros jogos não gostaram). Esta semana o gamasutra publicou o postmortem do Diablo II, e muitas coisas me deixaram surpreso.\nNaquela época a Blizzard estava crescendo e, como toda empresa que têm projetos grandes, uma das suas preocupações é o controle de versão do código. Quando li que eles utilizaram o Microsoft SourceSafe achei curioso (eu mesmo usei muito isso quando era analista de sistemas), pois fiquei pensando no que poderia ter levado eles a escolherem esta solução. Sabe em qual conclusão cheguei? Provavelmente esta era a única alternativa estável e confiável para a época, pois o SVN foi lançado em 2000 e o nosso querido GIT em 2005, enquanto que o SourceSafe existia desde 1994.\nViu como anos parecem ser mais longos quando falamos de tecnologia? Além do SourceSafe, os programadores usaram o Visual Studio (melhor IDE na minha opinião) e programaram em C/C++. Enquanto que os artistas usaram Photoshop para as texturas e 3D Studio Max para modelar e animar. E só isso. Acho que hoje em dia até um desenvolvedor indie em seu quarto deve usar mais tools do que foram utilizadas para fazer o Diablo II. Quer ver outra coisa curiosa? Olha as máquinas usadas por programadores e artistas:\nTypical programmer workstation: 500 MHz Pentium II running Windows NT with 128MB RAM and 9GB hard drive.\nTypical artist workstation: dual 500 MHz Pentium IIs running Windows NT with 256MB RAM and 14GB hard drive.\nEu acho incrível que nesta época os desenvolvedores levavam ao limite os poucos recursos que tinham para fazer jogos incríveis, sendo que hoje com toda tecnologia que temos disponível poucos jogos conseguem se tornar memoráveis.\nNão vou dar mais spoilers, recomendo você ler o artigo inteiro publicado no gamasutra, vale muito a pena! Vou deixar também um vídeo que encontrei e que combina com o assunto, pois é um cara jogando Diablo II 14 anos depois do lançamento (foi gravado em janeiro deste ano).\nAh, uma dica de jogo para quem gosta de Diablo II, dá uma olhada no Torchlight. Ele foi desenvolvido por um pessoal que trabalhou no Diablo II e saiu da Blizzard durante o projeto do Diablo III por não gostar da direção do projeto, então fizeram seu próprio jogo com tudo que o Diablo II tinha de bom.\n","date":"1 de julho de 2015","externalUrl":null,"permalink":"/postmortem-diablo-ii/","section":"Blog","summary":"Dependendo do que você usar como exemplo, 15 anos pode não parecer muito. Mas, quando levamos em consideração qualquer coisa relacionada a tecnologia, este tempo parece ser muito maior.\n","title":"Postmortem de Diablo II é publicado 15 anos depois","type":"posts"},{"content":"Em julho acontece mais uma edição do evento TDC (The Developer Conference) em São Paulo, e vou apresentar uma palestra na trilha de Games no dia 25/07 (sábado) sobre Programação de Jogos.\nEm 2012 eu realizei uma palestra neste mesmo evento, porém o tema abordado era Desenvolvimento de Jogos Mobile. Este ano me inscrevi novamente, mas desta vez vou focar a apresentação em técnicas de programação de jogos.\nNovamente o evento contará com 40 trilhas e 280 palestras em 5 dias, e será realizado na Universidade Anhembi Morumbi na Vila Olímpia do dia 21 ao dia 27 de julho. O evento tem um valor fixo por trilha, e cada trilha acontece em apenas um dia, ou seja, a trilha de games será apenas no sábado e contará com um dia inteiro de palestras. Clique aqui para se inscrever.\nNa próxima semana vou fazer um post relacionado ao tema da minha palestra, então fique de olho no blog para ver o material que vou apresentar. Ah, você também pode ver todas as palestras que já apresentei clicando aqui ou no SlideShare.\n","date":"26 de junho de 2015","externalUrl":null,"permalink":"/tdc-2015-sao-paulo/","section":"Blog","summary":"Em julho acontece mais uma edição do evento TDC (The Developer Conference) em São Paulo, e vou apresentar uma palestra na trilha de Games no dia 25/07 (sábado) sobre Programação de Jogos.\n","title":"TDC 2015 em São Paulo","type":"posts"},{"content":"Uma das principais preocupações de um programador de games é a performance do seu jogo e qual é o hardware mínimo que ele pode rodar, seja mobile ou desktop. Mas pra isso, primeiro você precisa saber quais são os hardwares mais usados para jogar.\nHá muito tempo atrás empresas de pesquisa cobravam fortunas para fornecerem relatórios sobre o mercado. Quanto mais específico era seu público, mais demorado, caro e limitado era o resultado da sua pesquisa. Muitas vezes empresas reutilizavam pesquisas antigas para não precisar pagar uma nova. Embora isso ainda exista e seja muito utilizado, hoje temos algumas opções muito boas, gratuitas e que estão sempre atualizadas.\nA primeira que vou comentar é provavelmente uma das mais famosas para o público que joga PC, e hoje ela é muito importante para desenvolvedores independentes que querem publicar seu jogo nesta plataforma: o Steam.\nA empresa do nosso querido Gabe fornece estatísticas do hardware de toda sua base de jogadores, sem cobrar nada por isso. Basta clicar aqui e fuçar em tudo que quiser saber sobre o público que está na maior plataforma de jogos de PC do mundo.\nSe você está desenvolvendo um jogo e quer publicar ele no Steam Greelight, este tipo de informação pode te ajudar a definir qual vai ser o requisito mínimo do seu jogo e te deixar livre para explorar os recursos de sua engine ou framework sem ficar na dúvida.\nO segundo que vou comentar provavelmente será ainda mais útil, pois muita gente utiliza esta engine e esta página fornece dados sobre hardware mobile também: a Unity.\nSegundo o que foi apresentado pelo CEO da Unity no evento Unite de 2013 em São Paulo (a primeira edição do evento), o Brasil era o terceiro país que mais utilizava a Unity, e acredito que isso possa ter até aumentado hoje. Esta página da Unity mostra dados de hardware relacionado a jogos publicados para web, desktop e mobile, além de mostrar estatísticas de uso do hardware que os desenvolvedores usam quando trabalham no editor da Unity.\nNem preciso dizer o quanto isto é valioso para desenvolvedores indie, pois combina informação de hardware com o público que joga games feitos com Unity. Ou seja, basta analisar isso para saber quais são os devices que os jogadores mais usam para jogar. E novamente, é gratuito e atualizado mensalmente.\nMesmo se você não estiver desenvolvendo algo neste momento que precise destas informações, é bem interessante ver quais são os hardwares mais utilizados por jogadores (eu geralmente olho as estatísticas da Steam para ver se meu desktop vai precisar de um upgrade ou não).\nImagem da capa: Flat Design Vector Illustration Concept of Game Environemnt do Shutterstock.\n","date":"24 de junho de 2015","externalUrl":null,"permalink":"/estatisticas-de-hardware-desktop-e-mobile/","section":"Blog","summary":"Uma das principais preocupações de um programador de games é a performance do seu jogo e qual é o hardware mínimo que ele pode rodar, seja mobile ou desktop. Mas pra isso, primeiro você precisa saber quais são os hardwares mais usados para jogar.\n","title":"Estatísticas de hardware desktop e mobile","type":"posts"},{"content":"Trabalhei em um projeto grande utilizando a Unity, e aprendi tanta coisa útil sobre otimização para jogos 2D durante o desenvolvimento que vale a pena compartilhar por aqui.\nVou listar alguns tópicos abaixo com o que aprendi para melhorar o desempenho da Unity em jogos 2D. Para ter uma idéia, só o menu principal do jogo estava usando mais de 350MB de memória em um aparelho iOS e a build estava com pouco mais de 100MB. Após fazer as otimizações listadas abaixo, o consumo de memória caiu para 50MB no menu principal e a build ficou com pouco mais de 30MB.\nApenas como referência, neste projeto utilizei a Unity 4.5.5 e o NGUI como plugin para criar toda interface do jogo e menu. Embora eu esteja usando este plugin, muitas dicas abaixo podem ser usadas no 2D da Unity. Esta é a primeira parte de uma série de três.\nReduzindo o peso das imagens\nA primeira coisa que devo avisar aqui é que não importa o quanto você consegue comprimir uma imagem, a Unity vai descomprimir e usar seu tamanho real na importação do editor, e recomprimir quando compilar o projeto.\nEntão por que devemos nos preocupar em reduzir o peso das imagens? Por que isso ajuda a reduzir muito o tamanho da build! Vou recomendar aqui dois programas gratuitos para Mac OS X que ajudam a comprimir imagens e otimizar seus dados.\nImageAlpha: este programa reduz muito o tamanho de imagens PNG, principalmente com transparência. Ele faz um processamento na imagem que remove alguns bytes de cores não usadas e converte para outro formato PNG muito mais eficiente.\nImageOptim: este programa deve ser utilizado após reduzir o tamanho da imagem com o ImageAlpha para ter um resultado melhor. Ele comprimi a imagem reduzindo o tamanho sem perder qualidade. Sua redução é menor do que o ImageAlpha, porém juntos funcionam muito bem. Um aviso: este software é muito lento, então tenha paciência e deixe seu computador processando as imagens enquanto você joga alguma coisa em seu console ou dispositivo móvel.\nEsta dica não é algo exclusivo da Unity, eu já utilizei em projetos com Cocos2d-x e HTML5, funciona muito bem! Infelizmente só rodam em Mac OS X, mas pelo menos são gratuitas, open source e podem ser utilizadas pela linha de comando para processar muitas imagens de uma vez.\nUm aviso: dependendo da imagem, as vezes pode acontecer de perder a qualidade por causa da redução do número de cores. Então fique atento quanto a isto e sempre prefira utilizar este recurso em imagens com pouca variação de cor.\nResolução das imagens para dispositivos móveis\nIsto foi algo que deixei passar despercebido e só depois de alguns testes entendi o que estava fazendo de errado. Os dispositivos utilizam OpenGL ES para lidar com a parte gráfica dos jogos e aplicativos, por isso muitas coisas que a Unity faz internamente tem como objetivo otimizar o jogo para OpenGL quando a build for para dispositivos móveis (Android e iOS).\nToda imagem carregada na memória é convertida em um tamanho POT (Power Of Two, potência de 2) para fins de otimização do OpenGL. Sabendo disso, a Unity junta as imagens para formar POT internamente, porém isso pode deixar tudo mais pesado.\nEu pesquisei bastante sobre qual seria a melhor resolução para fazer um jogo mobile na Unity, e embora muitos digam que o melhor é partir da maior resolução, eu acho que aqui está um item chave para melhorar o jogo. A maior resolução recomendada é do iPad com retina 2048×1536. Porém, quando convertida para POT esta imagem vai ter o tamanho de aproximadamente 2048×2048 e muitos bytes transparentes.\nNa parte 2 vou abordar as melhores práticas usando NGUI (que também servem para o 2D da Unity) e como utilizar sprite sheets no jogo. Na parte 3 vou dar algumas dicas para otimização de código. Se você tem alguma dúvida ou dica relacionada ao assunto é só comentar abaixo!\n","date":"12 de junho de 2015","externalUrl":null,"permalink":"/melhores-praticas-2d-unity-parte-1/","section":"Blog","summary":"Trabalhei em um projeto grande utilizando a Unity, e aprendi tanta coisa útil sobre otimização para jogos 2D durante o desenvolvimento que vale a pena compartilhar por aqui.\n","title":"Melhores práticas para 2D na Unity - Parte 1","type":"posts"},{"content":"Esta semana li um post em um grupo de desenvolvedores de jogos no Facebook que deixou muitas pessoas revoltadas, inclusive eu: um “desenvolvedor” clonou totalmente um jogo famoso e disse que era inovador copiar formulas de sucesso. Isso esta muito errado.\nEu nem vou falar o quanto é errado copiar o trabalho de outra pessoa ou empresa do ponto de vista legal, pois existem vários casos famosos de violação de copyright. Um caso famoso que aconteceu aqui no Brasil foi da empresa Vostu que foi processada pela Zynga por clonar seus jogos, e isto virou notícia no mundo.\nExiste uma grande diferença entre utilizar imagens de jogos famosos para fazer um protótipo ou tech demo e refazer totalmente um jogo famoso esperando ter lucro com isto. Na verdade, é errado mesmo se não esperar lucro com isto, como foi o caso do FullScreenMario, que foi forçado a tirar seu clone de Super Mario em HTML5 do ar por violar o copyright da Nintendo.\nUm dos motivos que fazem a App Store da Apple ter mais credibilidade do que a Play Store do Google é o processo de análise dos jogos publicados na App Store, e um dos itens verificados é se o produto (jogo ou app) infringe algum copyright. Como na Play Store não existe essa análise, existem muitos clones de jogos famosos. Porém, não pense que as grandes empresas não ficam de olho nisso, pois elas monitoram este tipo de coisa e pedem para o Google retirar o app ou jogo do ar.\nO Notch, criador do Minecraft, escreveu o tweet abaixo sobre o novo jogo LEGO. Porém, neste caso, a única cópia foi a mecânica de criar coisas com blocos, pois a história e a arte são diferentes. Inclusive a maneira de criar é um pouco diferente, mas o que você espera de um jogo LEGO?\nThe Lego Infiniminer clone looks neat!\n— Markus Persson (@notch) June 1, 2015\nAgora quero comentar o aspecto moral e ético disso. Copiar totalmente um jogo, desde seu gameplay até sua arte, é a mesma coisa que copiar um livro e lançar com a mesma capa e mudar um pouco o nome, mas não muito para deixar clara a referência ao original. Jogos não são “terra de ninguém”, pelo contrário, é uma indústria bilionária e ao mesmo tempo pequena onde muita gente conhece muita gente. E pode ter certeza: se você tem orgulho e cara-de-pau de fazer clones, muita gente não vai querer te contratar.\nEu (e muitas outras pessoas) não me conformo quando vejo uma pessoa ou um grupo com a capacidade técnica de clonar um jogo desperdiçar seu talento fazendo isso. Desenvolver jogos não é fácil, mas não significa que copiar algo de sucesso seja um atalho. Eu até li o “desenvolvedor” do clone falar que “todo FPS é clone de Quake”, e é claro que não é! Utilizar a mecânica do jogo não é clonar, mas utilizar a mecânica e todo o resto (arte, sons, história, etc), isso é clonar! E eu não conheço nenhuma história de que algo assim se deu bem.\nÉ bem comum acontecer um “ataque dos clones” quando algum jogo independente fica famoso muito rápido. Isto aconteceu com o puzzle 2048 e o viciante Flappy Bird, entre muitos outros. E se você fosse o desenvolvedor de um jogo desses e visse milhares de cópias surgindo, o que você faria? Como se sentiria? Eu ficaria muito triste e irritado pela falta de ética dos meus colegas “desenvolvedores” (eu usei essa palavra com aspas por que realmente não sei como chamar esse pessoal).\nEm resumo, apenas não faça isso. Não clone jogos famosos e publique esperando que esta “formula mágica de sucesso” te deixe rico. E se deixar, você pode perder tudo com belo processo de copyright. Mas, acima de tudo, isto é eticamente errado. Copiar uma mecânica de um jogo não é errado, pois só isso não define um jogo, porém use sua criatividade para deixar seu jogo único.\nEu não vou mencionar neste texto o caso me inspirou em escrevê-lo, mas se você conhecer por favor não comente o jogo nos comentários, este tipo de “desenvolvedor” não merece publicidade, nem negativa.\nImagem da capa: Cloning machine of businessmen do Shutterstock.\n","date":"7 de junho de 2015","externalUrl":null,"permalink":"/nao-faca-clones/","section":"Blog","summary":"Esta semana li um post em um grupo de desenvolvedores de jogos no Facebook que deixou muitas pessoas revoltadas, inclusive eu: um “desenvolvedor” clonou totalmente um jogo famoso e disse que era inovador copiar formulas de sucesso. Isso esta muito errado.\n","title":"Não faça clones","type":"posts"},{"content":"Há alguns meses um amigo conversou comigo e disse que queria começar a desenvolver jogos. Hoje, algum tempo depois, ele e seu amigo formaram um estúdio de jogos independentes e lançaram seu primeiro jogo para dispositivos móveis.\nFico muito feliz por terem publicado o jogo e por contar neste postmortem um pouco sobre o projeto, o que deu errado e o que deu certo durante seu desenvolvimento.\nPOSTMORTEM HUNGRYMONS # por Marcelo Vitoria e João Arthur Navarro\n1) INTRODUÇÃO # Hungrymons é um game casual para iOS e Android. Nele, um robô flutuante (HungryBot) arremessa comidas no ar em diferentes direções, e o jogador precisa mover os monstros (Hungrymons) na tela na direção das comidas para alimentá-los, ganhando pontos por isso. O objetivo é fazer a maior quantidade de pontos possível. O jogador perde quando ele fica sem monstros para alimentar, sendo contabilizada a pontuação final.\nO game foi desenvolvido por mim e por meu amigo e sócio João Arthur Navarro, sob a alcunha de CodeRogue Studio. Este é o nosso primeiro projeto, e o tempo total de desenvolvimento foi de 9 meses, entre Julho de 2014 e Março de 2015, tendo o game sido publicado nas app stores em Abril de 2015.\n2) DETALHES DO GAMEPLAY # O jogador só precisa tocar no monstro e mover horizontalmente na direção das comidas lançadas. Com o tempo, a quantidade de comidas vai aumentando, assim como a velocidade com que elas são arremessadas, além de serem introduzidos elementos que não podem ser ingeridos, como frascos de veneno, que impedem o monstro de comer, e bombas, que eliminam o monstro imediatamente. Além disso, é possível realizar combos que multiplicam a pontuação, e controlar dois monstros ao mesmo tempo.\n3) PROPOSTA # A idéia era fazer um game casual para plataformas mobile, com controles simples, objetivo claro, e que pudesse ser jogado em sessões curtas, de um a três minutos.\n4) O QUE DEU CERTO? # 4.1 Engine # Utilizamos o Corona SDK como plataforma de desenvolvimento, o que aumentou nossa produtividade e possibilitou que testássemos nossas decisões de design de forma rápida e objetiva. Além disso, o fato de podermos utilizar o mesmo código para ambos os SOs facilitou a escolha por esta engine, já que ela lida muito bem com as diferentes resoluções e tamanhos de tela (principalmente no Android).\n4.2 Perfis dos desenvolvedores # No time tínhamos um programador e um designer, e essa divisão clara de responsabilidades e habilidades foi de grande valia durante todo o processo de desenvolvimento, e garantiu que cada um tivesse que se preocupar quase que única e exclusivamente com uma dessas duas tarefas. Isso ajudou a manter o foco, e fez com que o resultado final ficasse um pouco acima das nossas expectativas iniciais.\n4.3 Comunicação # Como todos sabem, a comunicação eficiente, o debate e a rápida resolução de conflitos são pontos importantíssimos em qualquer equipe, de qualquer tamanho. Durante o processo de desenvolvimento, as dúvidas, idéias e problemas eram compartilhados, discutidos, e o consenso era alcançado sem desgaste. O fato de não termos um deadline para entrega, ou comprometimento com terceiros, contribuiu para a harmonia e a fácil comunicação.\n5) O QUE DEU ERRADO? # 5.1 GDD (e a falta dele) # Mesmo sendo um game pequeno, com poucas mecânicas, controles e game design simples, houve momentos em que estávamos em um ponto avançado do desenvolvimento e nos deparamos com dúvidas e dilemas sobre algum aspecto do game que, se devidamente documentados, teria nos poupado tempo e evitado o desvio de foco.\nA falta de um GDD evidenciou que não tínhamos pensado como queríamos que tudo funcionasse, desde o inicio. Nós tínhamos um conceito inicial em mente, basicamente relacionado ao gameplay, e trabalhamos em torno disso para que todo o resto atendesse a ideia principal. Entendo que, mesmo que tivéssemos um documento, ele também seria alterado eventualmente, e evoluiria para o que se tornou o produto final, mas a presença dele serve de direção para o trabalho realizado, e te faz pensar em todos os aspectos do game antecipadamente, definindo um ponto de referência para futuras discussões.\n5.2 Planejamento # O game foi desenvolvido inteiramente em nosso tempo livre, concorrendo com trabalho em tempo integral, relacionamento, família, etc. Nessas situações, é imprescindível que haja um planejamento das atividades de acordo com estimativas (mesmo que superficiais), e um controle rígido do tempo gasto no projeto. Nós não nos planejamos devidamente para o projeto em nenhum dos aspectos mencionados.\nComo não tínhamos um documento que guiasse o desenvolvimento, muitas vezes o trabalho era paralisado até que se pudesse discutir algum ponto importante ou tomar decisões sobre qual caminho seguir. Não tivemos um calendário definido de reuniões iniciais, e essas discussões muitas vezes causava retrabalho.\nO uso de ferramentas de controle de atividades, como Trello, minimizou o impacto na produtividade, mas entendo que, se tivesse havido um melhor planejamento, teríamos feito mais em menos tempo.\n5.3 Poucas features # Sem dúvida, não conseguimos colocar no game tudo o que gostaríamos, como animações mais elaboradas, diferentes cenários, mini games, mais personagens, tutorial interativo, trilha sonora personalizada, e muito mais.\nA verdade é que o projeto demorou bem mais do que imaginávamos, e tivemos que deixar muitas coisas de lado para garantir que tivéssemos no resultado final os conceitos principais, e não estendêssemos ainda mais o tempo de desenvolvimento.\n6) CONCLUSÃO # Por ser nosso primeiro projeto, naturalmente enfrentamos muitas dificuldades durante o processo: falta de planejamento e documentação, curva de aprendizado da engine escolhida, dificuldade de conciliar as atividades do dia-a-dia com o tempo dedicado ao projeto, e diversas outras coisas.\nOlhando para o produto final, podemos dizer que ficamos satisfeitos com o resultado, que condiz com a proposta inicial, com um conceito aderente às plataformas escolhidas, e um nível de “polimento” razoável, que não faz frente à grandes estúdios do mercado, mas nos deixou orgulhosos por termos começado com o pé direito.\nClaro que gostaríamos de ter feito muito mais, mas conseguimos manter o foco no objetivo de fazer nosso primeiro game da melhor forma possível em um tempo aceitável. Muitos desenvolvedores cometem o “erro” de começar com projetos muito grandes, sem passar por experiências intermediarias que lhes dêem confiança e tempo para acumular as habilidades necessárias para criar games cada vez melhores. Felizmente, conseguimos fugir desse estigma e começar bem, com um sentimento de satisfação pessoal, e vontade de fazer muito mais!\n7) DADOS # Desenvolvedor:\nCodeRogue Studio (http://www.coderoguestudio.com/);\nPlataformas:\niOS: https://itun.es/i6Lh3sB Android: http://goo.gl/xX3GFu Time:\nMarcelo Vitoria (@MarcVit [https://twitter.com/marcvit]); João Arthur Navarro (@Litsoh_Navarro [https://twitter.com/litsoh_navarro]); Tempo de desenvolvimento:\n9 meses;\nFerramentas e Linguagens:\nCorona SDK (Lua), utilizando Sublime Text; Git e GitHub, controle de versão e repositório de código; Photoshop; Audacity, PremiumBeat.com, OpenGameArt.org; Trello (task manager); Siga o exemplo do Marcelo e do João e faça um jogo simples e publique. Pela experiência deles (e de outros desenvolvedores publicados aqui) fica claro que mesmo um jogo simples pode ser complexo de fazer por vários motivos. É muito legal comparar a experiência dos desenvolvedores e ver que as vezes algo que um acerta o outro erra, e isso é bem comum mesmo.\nMuito obrigado ao Marcelo e ao João por terem dedicado um tempo em escrever e compartilhar a experiência deles, e parabéns pelo ótimo jogo que desenvolveram e publicaram! Se você já fez um jogo e publicou, e quer compartilhar sua experiência, é só entrar em contato comigo que eu publico seu texto neste seção do blog.\n","date":"6 de junho de 2015","externalUrl":null,"permalink":"/postmortem-hungrymons/","section":"Blog","summary":"Há alguns meses um amigo conversou comigo e disse que queria começar a desenvolver jogos. Hoje, algum tempo depois, ele e seu amigo formaram um estúdio de jogos independentes e lançaram seu primeiro jogo para dispositivos móveis.\n","title":"Postmortem: Hungrymons","type":"posts"},{"content":"Este livro escrito pelo Nelson Glauber tem praticamente tudo que você precisa para desenvolver jogos e apps para Android. Em quase 800 páginas divididas em 26 capítulos, o autor descreve desde conceitos básicos até como desenvolver para Android Wear.\nEu fiquei impressionado pelo tamanho do livro e pela qualidade do seu conteúdo e muito feliz em saber que foi escrito por um brasileiro nomeado o primeiro Developer Expert de Android na América Latina pelo Google. É muito bom ter um material escrito por quem entende do assunto!\nHá um tempo eu fiz uma review do livro Programação de Jogos Android, e por mais que ele seja bom e focado em jogos eu senti que faltou algo. E tudo que faltou naquele livro, tem de sobra neste . Embora o foco não seja jogos, neste livro tem realmente tudo que é necessário para dominar o desenvolvimento para Android.\nNeste livro tem muitas coisas que outros livros abordam, como conceitos básicos, Activity e Intents, Layout, Componentes, Action Bar, Fragments, Notificação, Mapas, Sensores, Multimídia, e muitas outras coisas legais. Mas o que realmente me chamou a atenção foram capítulos difíceis de se encontrar por ai.\nOs primeiros capítulos que me chamaram a atenção fora dois dedicados a Acesso à Web, onde o autor explica como fazer uma integração do Android com um backend através de arquivos JSON e as melhores práticas para se fazer isso. Na segunda parte desde capítulo o autor mostrar como criar uma aplicação REST simples em PHP, e novamente apresenta diversos conceitos importantes para que isto seja feito da melhor maneira.\nSó os dois capítulos que mencionei acima já valem o livro todo, mas existem mais coisas interessantes. Existe um capítulo muito bom explicando como configurar o Gradle no Android Studio (algo que já apanhei muito pra fazer) e quais são os benefícios para o seu projeto em utilizá-lo.\nOutros dois capítulos perto do final são dedicados ao Android Wear, a tecnologia do Google para conectar smartphone e smartwatch. Isto é algo relativamente novo em livros, e neste novamente é apresentado com a mesma qualidade do resto do livro.\nPara terminar o livro com chave de ouro, o autor dedica um capítulo inteiro ao novo Material Design introduzido no Android Lollipop, explicando desde o que mudou em termos de design e até como utilizar as novas transições do Android.\nO Android é um sistema operacional que nunca para de evoluir. Eu lembro de quando comecei a trabalhar com o Android 1.6 na Glu em 2010, e como hoje é praticamente outro sistema. Sem dúvidas foi muito importante na minha carreira aprender mais sobre o Android (assim como sobre o iOS e Windows Phone). Mesmo que meu foco sempre foi jogos, conhecer esses detalhes geralmente mais utilizados em aplicativos fez toda diferença.\nMuito obrigado a Editora Novatec por me enviar este livro para fazer esta review. Você pode comprar este livro e outros no site da Novatec, utilize o código GAMEDEVELOPER para ter desconto na compra!\n","date":"31 de maio de 2015","externalUrl":null,"permalink":"/dominando-o-android-do-basico-ao-avancado/","section":"Blog","summary":"Este livro escrito pelo Nelson Glauber tem praticamente tudo que você precisa para desenvolver jogos e apps para Android. Em quase 800 páginas divididas em 26 capítulos, o autor descreve desde conceitos básicos até como desenvolver para Android Wear.\n","title":"Dominando o Android: do básico ao avançado","type":"posts"},{"content":"A última vez que usei o Marmalade SDK ele nem tinha este nome, era chamado de Airplay SDK até ter o nome alterado devido a uma tecnologia da Apple também chamada AirPlay. Muitos jogos na EA até 2011~2012 eram desenvolvidos utilizando este framework, e hoje ele está bem diferente.\nAntes de começar o post queria deixar claro que o objetivo deste post não é falar que uma tecnologia é melhor do que a outra, mas sim apresentar uma opção de framework e comentar minha experiência com ele.\nNa época em que se chamava Airplay SDK existiam poucas tecnologias com preços acessíveis aos desenvolvedores independentes, e esta não era uma excessão. Mas hoje muitas coisas mudaram e praticamente toda tecnologia para desenvolvimento de jogos tem alguma opção para indies, e foi o que colocou o Marmalade de volta ao jogo.\nEu acredito que um dos motivos que fizeram a EA usar este framework foi por causa da sua flexibilidade em adicionar novos módulos e a possibilidade de publicar para várias plataformas (ou várias versões para a mesma plataforma, como versões localizadas), e pelo desenvolvimento ser em C++. Muitas tecnologias da EA eram integradas neste SDK sem grandes problemas, e provavelmente isso também ajudou no desenvolvimento do seu framework próprio chamado EAMT.\nHoje o Marmalade SDK continua tão flexível quanto antes, podendo até ser utilizando em conjunto com o framework Cocos2d-x e muitas outras tecnologias. Além do Marmalade SDK, que é o framework em C++, também existem outros produtos como o Juice (que converte Objective-C para Android), o Quick (para desenvolvimento usando Lua script, veja o video abaixo) e o Web (que é construído em cima do PhoneGap).\nUma das vantagens do Marmalade que eu gosto bastante é a facilidade na hora de gerar builds. Muitos desenvolvedores hoje não se preocupam com isso, pois basta seleciona uma plataforma que a Unity gera a build pronta, por exemplo. Porém, quando você precisa de mais de uma versão para a mesma plataforma com algumas diferenças, ai as coisas começam a ficar complicadas. No Marmalade é possível automatizar a build para várias plataformas e mesmo versões específicas utilizando um arquivo de configuração chamado MKB.\nAlém disso, este framework permite o desenvolvimento de jogos em 2D ou 3D, e muitas features legais que podem ser utilizadas em ambos os casos. Neste link é explicado como o SDK funciona, deixando clara a sua frase “Native performance. Any Device.“.\nO Marmalade possui 5 tipos de licença, desde a gratuita até uma que custa USD 3.500 por ano, e suporte as seguintes plataformas: iOS, Android, Mac, Windows, Windows Phone, Tizen, BlackBerry e Roku. Vale a pena analisar as features de cada tipo, porém a versão gratuita é suficiente para desenvolver um jogo, pois a diferença entre elas são serviços e customizações.\nConfira aqui alguns jogos desenvolvidos utilizando este framework e baixe a versão gratuita para testar! O video abaixo mostra como começar o desenvolvimento no Marmalade SDK, e muitos outros estão disponíveis no canal do YouTube da empresa.\n","date":"12 de maio de 2015","externalUrl":null,"permalink":"/marmalade-sdk/","section":"Blog","summary":"A última vez que usei o Marmalade SDK ele nem tinha este nome, era chamado de Airplay SDK até ter o nome alterado devido a uma tecnologia da Apple também chamada AirPlay. Muitos jogos na EA até 2011~2012 eram desenvolvidos utilizando este framework, e hoje ele está bem diferente.\n","title":"Conheça o Marmalade SDK","type":"posts"},{"content":"Faz 6 anos que eu trabalho com jogos e nunca tinha participado do game jam chamado Ludum Dare. Por acaso vi que neste fim de semana ia começar a edição #32, então decidi participar.\nLudum Dare é uma game jam dividida em duas categorias: Compo e Jam. Na compo cada desenvolvedor deve criar o jogo sozinho e tudo relacionado a ele (código, arte, efeitos sonoros, etc) em 48 horas. A outra categoria é mais tranquila, pois na Jam é possível trabalhar em equipes, utilizar recursos prontos e os participantes tem 1 dia a mais para enviar seu jogo.\nO que é comum nas duas categorias é que o jogo desenvolvido precisa ter alguma coisa relacionada ao tema, que só é revelado no início da competição. Na edição #32 o tema foi “An Unconventional Weapon” (uma arma não-convencional), e eu decidi participar da categoria Compo.\nComo uma dos itens mais importantes da Ludum Dare é a facilitar o acesso ao seu jogo, decidi que a plataforma principal seria Web e utilizei a nova Unity 5 para o desenvolvimento. Como o plugin da Unity não está mais sendo suportado em alguns navegadores, arrisquei exportar utilizando a opção de HTML5/WebGL da Unity 5.\nMinha ideia inicial era um jogo onde você digitava uma palavra e ela se transformava em um objeto para atacar o inimgo que está indo na sua direção. Como isso iria exigir arte (que eu teria que criar sei lá como, pois sou programador), decidi que as próprias palavras iriam atacar o inimigo, porém estas palavras deveriam ser válidas dentro de um tema. Decidi também colocar um nível de dificuldade para separar a escolha do tema. Infelizmente, devido ao tempo, cada dificuldade tem apenas um tema fixo (que são diferentes entre si). O jogador também não pode utilizar umas das 3 últimas palavras usadas para atacar o inimigo, e cada palavra/inimigo morto contam 1 ponto para o jogador. E assim nasceu o “Word Battle”.\nUma das coisas que deixou o desenvolvimento mais lento foi a nova UI da Unity, que apesar de ter sido lançada há um tempo eu nunca tinha trabalhado com ela. Minha sorte é que lembra muito a NGUI, um plugin de interface que estou acostumado. Não tive muito tempo para estudar as diferenças, então acredito que tudo que eu fiz poderia ser feito melhor.\nComo eu tive dois dias para fazer o jogo sozinho acabei dividindo da seguinte forma: o primeiro dia iria focar no gameplay e no segundo dia no resto (arte, menu, efeitos sonoros). Esta estratégia até deu certo, porém no segundo dia ainda tinha algumas coisas de gameplay para finalizar. Sem muito tempo sobrando decidi que não iria fazer arte e deixei toda arte temporária no jogo, e então me dediquei um pouco aos efeitos sonoros.\nEsta foi uma parte bem divertida, pois fiquei andando pela casa com meu celular na mão gravando vários barulhos diferentes para colocar no jogo, e no final consegui alguns resultados bons, porém não ideais para um jogo. A qualidade da gravação não ficou boa, e por causa do microfone do celular alguns ruídos permaneceram no som. Mas, isso foi o que consegui fazer a tempo de enviar. Na verdade terminei 4 horas antes do prazo, mas não quis arriscar mexer em mais nada já que tudo estava funcionando.\nO meu jogo está publicado nesta página do Ludum Dare #32, e também pode ser jogado através deste link. Como esta foi minha primeira vez em uma game jam de 48 horas, pra mim o resultado até que ficou razoável. O importante é que isto serviu de experiência para as próximas edições, que com certeza vou querer participar.\nO código do jogo está disponível neste link do GitHub. Acabei me arrependendo um pouco de utilizar a Unity, e o principal motivo foi que o jogo exportado ficou muito grande. Todo conteúdo (arte, som e código) ficou com menos de 500KB, porém a build final HTML5/WebGL ficou com mais de 40MB. Com certeza esta não é uma solução aceitável para um jogo, porém foi mais uma lição que aprendi. Ah, sem falar que minha máquina chorou muito pra compilar o projeto e levou uns 10 minutos para exportar a versão release (Intel i5, 8GB de ram, GTX260).\nAgora vem a parte em que os jogadores e outros desenvolvedores começam a jogar os jogos publicados e dar feedback sobre eles. O Ludum Dare não tem uma premiação, mas isso torna a competição bem interessante por que todos estão lá apenas para se divertir. Deixem abaixo comentários e feedbacks sobre meu jogo, e também comentem sobre suas experiências em game jams!\n","date":"19 de abril de 2015","externalUrl":null,"permalink":"/ludum-dare-32/","section":"Blog","summary":"Faz 6 anos que eu trabalho com jogos e nunca tinha participado do game jam chamado Ludum Dare. Por acaso vi que neste fim de semana ia começar a edição #32, então decidi participar.\n","title":"Minha participação no Ludum Dare #32","type":"posts"},{"content":"Quando começamos a desenvolver jogos é mais fácil e prático utilizar soluções prontas para desenvolver jogos, porém grandes empresas da indústria de games criam seus próprios frameworks e engines. Mas, hoje em dia, não são apenas as empresas grandes que estão optando por criar suas próprias soluções.\nAlém das game engines famosas (que inclusive já contam com fanboys para defenderem as tecnologias, muitas vezes sem testarem outras soluções), existem muitas outras que ficam famosas após algum jogo ser lançado e ficar famoso. A mesma coisa acontecem com frameworks. Neste post da revista Develop é possível conhecer 12 game engines e frameworks que são alternativas ao invés de utilizar sempre Unity (ou Unreal) nos projetos de jogos.\nÉ muito comum grandes empresas criarem as próprias tecnologias para ter mais controle sobre tudo. Desta maneira engines como a Frostbite da DICE ficaram famosas e são utilizadas por vários jogos da empresa. Quando trabalhei na EA todos jogos novos estavam sendo desenvolvidos utilizando um framework mobile recém criado internamente, chamado EAMT (Electronic Arts Mobile Technology). Este framework funcionou muito bem, e por ser modular outros frameworks podiam ser facilmente adicionados. A EA tem um departamento só para desenvolver novas tecnologias, chamado EA Tech, o que facilita muito o trabalho dos desenvolvedores.\nPorém, não é necessário ter um departamento inteiro para desenvolver sua própria tecnologia. Apesar de atrasar um pouco o desenvolvimento de um jogo, é possível criar sua própria solução e reutilizar em todos projetos do estúdios. Muitos estúdios estão adotando esta prática, cada um por um motivo próprio porém com o mesmo objetivo: ter sua própria tecnologia que atende as suas necessidades. Neste outro post da revista Develop alguns desenvolvedores comentam por que decidiram seguir este caminho.\nEu acho isto algo incrível, pois muitas vezes não é necessário mais do que juntar alguns frameworks de física e gráfico (entre outros) para criar sua própria solução. É claro que é algo trabalhoso, mas o aprendizado é muito grande durante este processo. Outro detalhe legal é que se utilizar C/C++ para fazer o jogo (e definir bem a arquitetura do jogo), é possível trocar de framework e manter o jogo funcionando. Meu primeiro projeto na EA foi justamente isso, substituir o Marmalade utilizado em um jogo pelo novo framework EAMT, e praticamente nenhuma alteração no código principal do jogo foi necessária.\nSe você está começando um jogo com muito tempo disponível ou sem pressa para lançar, eu recomendo a abordagem de criar o próprio framework para fins de estudo. É claro que não é só juntar frameworks como peças de LEGO e esperar que tudo funcione, mas existem livros muito bons sobre este assunto, com o Game Engine Architecture. Só lembrando que engines e frameworks prontos possuem diversas pessoas trabalhando para que eles sejam bons e estáveis, mas que esta abordagem de criar sua própria tecnologia ensina muito mais do que apenas utiliza-los.\nImagem da capa: Flat Modern Design do Shutterstock.\n","date":"16 de abril de 2015","externalUrl":null,"permalink":"/usar-ou-nao-usar-engines-frameworks/","section":"Blog","summary":"Quando começamos a desenvolver jogos é mais fácil e prático utilizar soluções prontas para desenvolver jogos, porém grandes empresas da indústria de games criam seus próprios frameworks e engines. Mas, hoje em dia, não são apenas as empresas grandes que estão optando por criar suas próprias soluções.\n","title":"Usar ou não usar game engines ou frameworks?","type":"posts"},{"content":"Este é um assunto complicado até para quem decorou todos design patterns possíveis e imagináveis em programação. Por mais que existem muitos por ai, poucos são utilizados no dia-a-dia, e muitas vezes por falta de conhecimento.\nAntes de começar a trabalhar com jogos eu imaginava que muitos design patterns eram utilizados nos jogos, afinal são programas bem complexos e grandes. Porém, o que eu aprendi é que nem sempre é necessário utilizar todas as técnicas possíveis só para dizer que utilizou.\nEm praticamente todos jogos que trabalhei na Glu e na EA o design pattern mais utilizado era sempre o Singleton. Praticamente todas as classes que não eram objectos ou entidades tinham este padrão implementado que tem como objetivo expor uma variável estática para acessar todo conteúdo da classe.\nÉ claro que aqui e ali se via alguns outros design patterns, como Factory e Prototype, mas o mais utilizado sem dúvidas era o Singleton, por que funciona muito bem quando você precisa acessar conteúdos de outras classes. É importante conhecer alguns design patterns mais utilizados, mas também saber onde e quando utilizar.\nNão adianta implementar todos design patterns só para falar que utilizou todos se os demais programadores da equipe (ou futuros programadores) não vão manter tudo funcionando, principalmente por falta de conhecimento. Por isso é muito importante conhecer bem os mais utilizados e pelo menos saber onde utilizar. Para estudar mais sobre design patterns eu recomendo os 3 livros abaixo:\nGame Programming Patterns Design Patterns: Elements of Reusable Object-Oriented Software Code Complete: A Practical Handbook of Software Construction Este livro possui uma Game Programming Patterns (o autor começou o link na internet e depois publico a versão impressa). Obrigado Gabriel Sussumu por lembrar deste link nos comentários! UPDATE 1: Links de mais conteúdo de Design Patterns em jogos enviado pelo leitor Fernando Mondo:\nFSM (Máquina de Estados) em jogos RTS Composite em jogos RPG Site Universidade da Pennsylvania UPDATE 2: Reescrevi algumas partes do texto para tentar expressar melhor minha opinião.\n","date":"23 de março de 2015","externalUrl":null,"permalink":"/design-patterns/","section":"Blog","summary":"Este é um assunto complicado até para quem decorou todos design patterns possíveis e imagináveis em programação. Por mais que existem muitos por ai, poucos são utilizados no dia-a-dia, e muitas vezes por falta de conhecimento.\n","title":"Como ser um programador de jogos: Design Patterns","type":"posts"},{"content":"Faz um bom tempo desde que escrevi o último post desta série, mas agora pretendo voltar com a frequência de 1 post por semana sobre como como ser um programador de jogos. Por mais que o título seja sobre programação, muitas dicas já apresentadas são úteis para todas as áreas.\nProgramar com estilo não é escrever um código enquanto salta de um avião e fazer ele compilar com sucesso antes de abrir o paraquedas, mas sim programar seguindo um estilo ou um padrão que deixe o código mais organizado e fácil de entender para outros programadores.\nA primeira vez que li um documento sobre padronização de código foi enquanto trabalhava na EA. Era um documento bem completo sobre melhores práticas de programação em C/C++ para deixar o código organizado e bem escrito para qualquer desenvolver trabalhar sem problemas.\nMuitas empresas de tecnologia tem este tipo de documento, porém poucas publicam na internet. Neste post reuni alguns muito interessantes para se estudar e que são públicos.\nGoogle C++ Style Guide (dica do Rodrigo Delduca) Id Software Coding Style Conventions (usado no DOOM 3) Airbnb JavaScript Style Guide Mozilla Coding Style Vale a pela ler antes de programar, e se for o caso procure algo voltado para a linguagem de programação que você está utilizando no momento. E você, conhece algum guia que faltou aqui?\nVeja todos os posts desta série clicando aqui!\n","date":"17 de março de 2015","externalUrl":null,"permalink":"/programando-com-estilo/","section":"Blog","summary":"Faz um bom tempo desde que escrevi o último post desta série, mas agora pretendo voltar com a frequência de 1 post por semana sobre como como ser um programador de jogos. Por mais que o título seja sobre programação, muitas dicas já apresentadas são úteis para todas as áreas.\n","title":"Como ser um programador de jogos: Programando com estilo","type":"posts"},{"content":"Eu poderia escrever um texto cheio de figuras para explicar o que é SCRUM e como funciona, mas ao invés disso encontrei um video que ensina em 15 minutos todos os conceitos desta metodologia de desenvolvimento ágil.\nE onde entra a parte de games nisso? O SCRUM é muito bom para softwares, porém para games é necessário alguns ajustes, já que uma mesma sprint pode envolver diversas áreas ao mesmo tempo. Por exemplo, uma tarefa de fazer um jogador pular vai precisar de programação, arte, animação, efeito sonoro, balanceamento, entre outras coisas.\nO livro abaixo, Agile Game Development with SCRUM, foi escrito pela primeira pessoa a introduzir SCRUM no desenvolvimento de jogos AAA. O autor Clinton Keith trabalhou na Rockstar, e utilizou esta metodologia para desenvolver o jogo Midnight Club.\nNeste livro ele conta sua experiência em adaptar a metodologia em projetos de jogos. Deu tão certo que ele saiu da indústria e hoje é instrutor e consultar de SCRUM. O livro pode ser comprado na Amazon através deste link.\nImagem da capa: Marseille France-September 30, 2007 do Shutterstock.\n","date":"13 de março de 2015","externalUrl":null,"permalink":"/aprenda-o-que-e-scrum/","section":"Blog","summary":"Eu poderia escrever um texto cheio de figuras para explicar o que é SCRUM e como funciona, mas ao invés disso encontrei um video que ensina em 15 minutos todos os conceitos desta metodologia de desenvolvimento ágil.\n","title":"Aprenda o que é SCRUM e como usar em projetos de games","type":"posts"},{"content":"O framework de física da NVIDIA, usado em diversos jogos e engines, agora está com o código publicado no GitHub para que os desenvolvedores possam estudá-lo e até melhorá-lo.\nVocê pode não saber, mas este framework está implementado em muitas engines, como Unreal e Unity, e até dentro de engines proprietárias como a AnvilNext (Assassin’s Creed) e Dunia (Far Cry) da Ubisoft. Alguns jogos que utilizam esse framework de física: Batman, Bioshock, Daylight, Borderlands, The Witcher, entre muitos outros.\nPara acessar o código da PhysX no GitHub siga os procedimentos deste link. São bem parecidos com os procedimentos para acessar o código da Unreal Engine.\nObrigado ao Mestre Kishimoto pela dica!\n","date":"12 de março de 2015","externalUrl":null,"permalink":"/nvidia-physx-no-github/","section":"Blog","summary":"O framework de física da NVIDIA, usado em diversos jogos e engines, agora está com o código publicado no GitHub para que os desenvolvedores possam estudá-lo e até melhorá-lo.\n","title":"NVIDIA disponibiliza código da PhysX no GitHub","type":"posts"},{"content":"Depois de pelo menos 2 anos após seu anúncio, finalmente a Unity 5 foi lançada durante a GDC e algumas mudanças na licença da engine vieram junto: Agora ela é free para todas as plataformas (com suas devidas limitações).\nEu lembro de ter ido aos dois últimos eventos do Unite em São Paulo e a mesma dúvida estava no ar: quando a Unity 5 seria lançada. Com seu lançamento, muitos serviços mudaram, como o Cloud Build e o Analytics.\nCom a Unity 5 agora é possível publicar seu projeto em 21 plataformas diferentes, o que é algo realmente incrível. Confira abaixo o video do novo CEO da Unity sobre as novidades das versões Personal e Professional:\nVale lembrar que se você utiliza muitos plugins no seu projeto, pense bem e teste antes de migrar para a versão 5. Com o suporte para iOS 64bits muitos plugins quebraram e precisam ser atualizados. Infelizmente, devido a isso, todos projetos que ainda serão publicados ou atualizados na Apple Store devem ser migrados para a Unity 5 ou para a última versão 4.6.3 (que também tem o suporte para iOS 64bits). Reserve alguns dias para fazer isso com calma.\nOutra dica: utilize o Unity Cloud Build, é uma ferramente incrível e que salva muito tempo do desenvolvedor na hora de gerar builds. É também uma boa alternativa para QAs, após o fim do TestFlight.\n","date":"10 de março de 2015","externalUrl":null,"permalink":"/finalmente-unity-5/","section":"Blog","summary":"Depois de pelo menos 2 anos após seu anúncio, finalmente a Unity 5 foi lançada durante a GDC e algumas mudanças na licença da engine vieram junto: Agora ela é free para todas as plataformas (com suas devidas limitações).\n","title":"Finalmente, Unity 5","type":"posts"},{"content":"A editora Novatec lançou trouxe para o Brasil o livro Introdução ao GitHub: um guia que não é técnico. Os autores Peter Bell e Brent Beer, ambos instrutores da equipe de treinamento do GitHub, dão uma introdução ao serviço e mostram todas as suas features.\nO GitHub é muito mais do que apenas um repositório Git, ele também é uma plataforma criada para desenvolvimento colaborativo, ou seja, tudo nele é voltado para facilitar a vida de quem trabalha em equipes.\nEu conheço o GitHub desde 2011, e já usei por meses em uma empresa que trabalhei, porém mesmo assim este livro me ensinou coisas novas. Eu via o GitHub como um repositório GIT que, ao contrário do seu concorrente BitBucket, precisava pagar para ter repositórios privados, porém após ler este livro eu comecei a entender melhor seu potêncial.\nMuitas coisas no GitHub (muitas mesmo!) são focadas para o desenvolvimento em equipe, por isso se você só usa ele como um repositório para guardar seus projetos (eu faço isso no BitBucket), realmente não existem muitas vantagens. Porém, quando começamos a usar as ferramentas disponíveis nele, e explicadas neste livro, tudo muda.\nO gráficos explicados no capítulo 2 são incríveis para quem é gerente de projeto ou líder de equipe, pois mostram claramente a evolução do projeto baseado nos commits e não em um quadro de tarefas. As vezes ficamos na mesma tarefa a semana a sprint inteira, porém isso não quer dizer que nenhum trabalho é realizado, e estes gráficos ajudam neste ponto.\nO capítulo 4 explica como funciona a colaboração no GitHub, e sem dúvidas foi o capítulo que mais me chamou a atenção e me ensinou coisas novas. Eu ainda prefiro o BitBucket para guardar meus projetos, por ser gratuito para repositórios privados, porém o GitHub sem dúvidas é uma ótima opção para equipes.\nOutra característica bem legal do GitHub, que não está no livro mas eu sou fã, é a facilidade de achar código-fonte de projetos para estudar. Neste post você pode ver alguns links de projetos de jogos open-source para estudar.\nMuito obrigado a Editora Novatec por me enviar este livro para fazer esta review. Você pode comprar este livro e outros no site da Novatec, e utilize o código GAMEDEVELOPER para ter desconto na compra!\n","date":"9 de março de 2015","externalUrl":null,"permalink":"/introducao-ao-github-guia-nao-tecnico/","section":"Blog","summary":"A editora Novatec lançou trouxe para o Brasil o livro Introdução ao GitHub: um guia que não é técnico. Os autores Peter Bell e Brent Beer, ambos instrutores da equipe de treinamento do GitHub, dão uma introdução ao serviço e mostram todas as suas features.\n","title":"Introdução ao GitHub: um guia que não é técnico","type":"posts"},{"content":"O anúncio foi feito esta semana na GDC, e a Unreal Engine 4 já está disponível. Além da UE4, seu código-fonte e do Unreal Tournament também foram disponibilizados gratuitamente no GitHub da Epic Games. Antes este acesso custava $19 dólares por mês, agora está tudo gratuito.\nPara acessar o código-fonte no GitHub é necessário fazer um cadastro no site da UE antes. O modelo da Unreal continua o mesmo, o desenvolvedor paga à Epic 5% do seu lucro após os primeiros 3 mil dólares por jogo a cada trimestre.\nVocê pode estar se perguntando “pra que usar a UE4 sendo que a Unity possui um modelo gratuito?”. A resposta é simples: por que é a Unreal Engine! Existem diversos motivos para utilizar a UE4, na minha opinião:\nA programação é em C++ (nada contra C#, but…); A maioria dos jogos AAA para consoles e desktop utilizam a Unreal Engine; Os 5% que você parará a Epic (caso consiga lucro maior do que 3 mil dólares por trimestre) é bem pouco se comparado ao valor da licença quando era fechada; A Unreal Engine está em desenvolvimento há 17 anos, então ela é muito estável; Ler o código-fonte dela vai te ensinar mais do que ler um livro; Se você um dia sonha em trabalhar fora do país com jogos AAA, comece estudando a UE4 (muitas vagas pedem conhecimento nela) A própria Epic fez este tutorial explicando como usar a UE caso você já esteja acostumando com a Unity (legal né?) Recomendo a todos pelo menos baixar, testar e ver com seus próprios olhos por que esta engine é usada em tantos jogos AAA. Confira abaixo o video do fundador da Epic Games falando sobre a Unreal Engine 4 se tornar gratuita.\n","date":"4 de março de 2015","externalUrl":null,"permalink":"/unreal-engine-4-gratuita/","section":"Blog","summary":"O anúncio foi feito esta semana na GDC, e a Unreal Engine 4 já está disponível. Além da UE4, seu código-fonte e do Unreal Tournament também foram disponibilizados gratuitamente no GitHub da Epic Games. Antes este acesso custava $19 dólares por mês, agora está tudo gratuito.\n","title":"Unreal Engine 4 agora está gratuita","type":"posts"},{"content":"Como praticamente toda indústria, a de games também tem um evento voltado para quem trabalha nela. Eventos como a E3 e Tokyo Game Show tem o foco de mostrar novos jogos, novos consoles, o que está por vir, entre outras coisas. Mas a GDC é algo diferente, lá você conhece quem fez esses jogos e consoles, e muitas vezes aprende como foram feitos.\nA Game Developer Conference (GDC) conta com diversas palestras e workshops apresentados por profissionais bem experientes da indústria. Embora seja voltado para desenvolvedores é comum novidades aparecerem, por isso muitos sites de jogos fazem uma pequena cobertura deste evento.\nIr para a GDC pode ser um pouco caro, principalmente agora que o dólar americano está beirando os R$3 reais, mas sem dúvidas é algo que vale a pena. Eu ainda não fui, mas é o evento de games que mais tenho vontade de ir. Além dasta GDC que acontece na primeira semana de Março em San Francisco, existem outros eventos anuais da GDC na Europa e China (talvez opções mais baratas).\nOutra coisa legal da GDC, e igualmente cara, é o GDC Vault. Um site com praticamente todo conteúdo dos eventos realizados nos últimos anos, disponíveis em vídeo, audio e apresentações. Porém, para ter acesso a isso é necessário pagar $495 dólares por ano ou ir para a GDC e ganhar um voucher que dura um tempo limitado. O GDC Vault também possui conteúdo gratuito, que apesar de limitado conseguimos aprender muito assistindo 1 hora de palestra.\nAbaixo vou colocar alguns videos que achei no YouTube, com eles é possível ver o nível da qualidade do evento e também os grandes nomes que participam e podem ser encontrados em um corredor durante a GDC.\n","date":"22 de fevereiro de 2015","externalUrl":null,"permalink":"/gdc-2015-esta-chegando/","section":"Blog","summary":"Como praticamente toda indústria, a de games também tem um evento voltado para quem trabalha nela. Eventos como a E3 e Tokyo Game Show tem o foco de mostrar novos jogos, novos consoles, o que está por vir, entre outras coisas. Mas a GDC é algo diferente, lá você conhece quem fez esses jogos e consoles, e muitas vezes aprende como foram feitos.\n","title":"GDC está chegando! Você sabe o que é a GDC?","type":"posts"},{"content":"O PodQuest é um podcast onde 3 profissionais da indústria internacional de games falam sobre suas experiências na área. Recentemente eles fizeram um postmortem do novo jogo Dragon Age: Inquisition, e além de um programador da BioWare que faz parte do PodQuest, eles também receberam um produtor e outro programador, todos brasileiros.\nO postmortem do Dragon Age: Inquisition foi bem legal, principalmente por ser um jogo muito bom e que acabou de sair. Muitos detalhes do desenvolvimento foram revelados e discutidos, recomendo para todo mundo ouvir os três episódios abaixo.\nPodQuest #81: Postmortem de Dragon Age, Parte 1 – Teabag no Dragão! # PodQuest #82: Postmortem de Dragon Age, Parte 2 – Rogue de Snowboard # PodQuest #83: Postmortem de Dragon Age, Parte 3 – Stress Test Pra Cardíaco # As equipe do PodQuest é formada por: Gilliard Lopes, Produtor da Electronic Arts e responsável pela série FIFA (publiquei uma entrevista com ele aqui em duas partes); Rafael Kuhnen, Game Designer na Gameloft; e Fernando Secco, Programador na BioWare. Só pelo cargo atual deles da pra ver que possuem muita experiência na área, eu sempre aprendo algo novo apenas ouvindo suas discussões nos podcasts.\n","date":"26 de janeiro de 2015","externalUrl":null,"permalink":"/postmortem-dragon-age-inquisition/","section":"Blog","summary":"O PodQuest é um podcast onde 3 profissionais da indústria internacional de games falam sobre suas experiências na área. Recentemente eles fizeram um postmortem do novo jogo Dragon Age: Inquisition, e além de um programador da BioWare que faz parte do PodQuest, eles também receberam um produtor e outro programador, todos brasileiros.\n","title":"Postmortem do Dragon Age: Inquisition no PodQuest","type":"posts"},{"content":"Descobri o site The Spriters Resource há pouco tempo, e infelizmente não lembro quem compartilhou no Facebook para dar os créditos. Ele é atualizado diariamente com diversas imagens de jogos novos e antigos, o que é perfeito para fazer protótipos de jogos.\nQuando comecei o desenvolvimento do Oniro, o jogo que foi o TCC da minha pós-graduação, utilizei sprites de um site semelhante, o Sprite Database. Na época este site não tinha muitas opções de jogos novos, apenas antigos, mas foi muito útil para começar a programar sem ter a arte final do jogo.\nUPDATE: Confira estes links enviados pelo FL para baixar modelos e texturas para jogos.\nImagem da capa: Pixel Art Set Of Bandit do Shutterstock.\n","date":"31 de dezembro de 2014","externalUrl":null,"permalink":"/site-para-baixar-sprites/","section":"Blog","summary":"Descobri o site The Spriters Resource há pouco tempo, e infelizmente não lembro quem compartilhou no Facebook para dar os créditos. Ele é atualizado diariamente com diversas imagens de jogos novos e antigos, o que é perfeito para fazer protótipos de jogos.\n","title":"Site para baixar sprites de vários jogos","type":"posts"},{"content":"Este livro do Edgard Damiani, com quase 700 páginas, é provavelmente o maior já escrito por um autor brasileiro sobre desenvolvimento de jogos. Ele explica conceitos fundamentais de programação de games ensinando, ao mesmo tempo, a criar sua própria game engine (na verdade um framework) para Android. Porém, usando a linguagem Java.\nUm dos maiores pontos positivos deste livro, que me impressionou desde a primeira página, é sua organização. Tudo está em uma ordem perfeita, explicando desde como usar a IDE do Eclipse, passando pelos conceitos de programação de jogos, game engines (na verdade um framework), e por fim como publicar seu jogo no Google Play. Como o autor é acadêmico, tudo no livro é muito didático.\nAlguns capítulos merecem destaque, como o 20 – Música e efeito sonoros, e o 18 – Sprites. Em ambos muitas dicas legais são apresentadas, além do conceito de cada parte. O capítulo 7 – Loop de jogos e temporização também é interessante, e já falei um pouco sobre isso neste post. Senti falta de um pouco mais sobre física, algo além do que foi apresentado no capítulo 12 – Detecção de colisão, e um pouco mais de coisas específicas do Android.\nMas, o que mais me chamou a atenção é que ele utilizou um jogo como projeto para explicar tudo, da criação do mesmo até a engine (na verdade um framework). E este jogo foi o PONG que, na minha opinião, é um jogo perfeito para ensinar qualquer pessoa a programar games. Eu até fiz este post há um tempo explicando como fazer um PONG com HTML5. Neste ponto, o livro acertou demais.\nPorém, existem alguns problemas no livro. Na minha opinião, o maior erro do autor foi ensinar tudo isso usando Java. Eu até entendo por que ele escolheu esta linguagem: Java é muito bom para ensinar programação e também é a linguagem nativa do Android, porém eu não concordo com esta escolha. Hoje em dia, com tantos devices e plataformas diferentes, devemos sempre aprender algo que pode ser reutilizado. Fazer o jogo em Java permite apenas, e com muito trabalho, compilar para desktop. Enquanto que utilizando C++ você pode compilar seu projeto para praticamente qualquer coisa.\nOutro ponto incorreto é que o livro não ensina a criar sua própria game engine (por isso adicionei o parênteses no texto), mas sim um framework. O framework que o autor ensina a construir usa como base recursos do Android, o que torna extremamente inflexível. No geral é um livro muito bom para aprender conceitos, porém é uma pena ser limitado a ensinar tudo com Java.\nMuito obrigado a Editora Novatec por me enviar este livro para fazer esta review. Você pode comprar este livro e outros no site da Novatec, utilize o código GAMEDEVELOPER para ter desconto na compra!\n","date":"30 de dezembro de 2014","externalUrl":null,"permalink":"/programacao-de-jogos-android/","section":"Blog","summary":"Este livro do Edgard Damiani, com quase 700 páginas, é provavelmente o maior já escrito por um autor brasileiro sobre desenvolvimento de jogos. Ele explica conceitos fundamentais de programação de games ensinando, ao mesmo tempo, a criar sua própria game engine (na verdade um framework) para Android. Porém, usando a linguagem Java.\n","title":"Programação de Jogos Android","type":"posts"},{"content":"Ontem fiz uma palestra sobre a carreira de um desenvolvedor de jogos na USP, no campus da zona leste em São Paulo. Além de falar sobre carreira, também adicionei alguns links interessante de sites, recomendações de livros, código fonte de jogos, principais tecnologias, entre outras coisas.\nA palestra foi bem legal e tive a oportunidade de conhecer alguns alunos que já conhecem e acompanham meu blog, essa com certeza foi a melhor parte!\n**UPDATE: **\nDica do Gilliard Lopes, outro site para procurar empregos fora: CreativeHeads.net\n","date":"11 de novembro de 2014","externalUrl":null,"permalink":"/palestra-carreira-usp/","section":"Blog","summary":"Ontem fiz uma palestra sobre a carreira de um desenvolvedor de jogos na USP, no campus da zona leste em São Paulo. Além de falar sobre carreira, também adicionei alguns links interessante de sites, recomendações de livros, código fonte de jogos, principais tecnologias, entre outras coisas.\n","title":"Minha palestra sobre carreira na USP","type":"posts"},{"content":"Durante minha carreira já usei muitos controles de versão, mas nos últimos anos o que mais tenho usado é o GIT. Além das suas features que vou comentar neste post, a possibilidade de ter seu repositório na nuvem em sites como Github e Bitbucket sem pagar nada está fazendo cada vez mais programadores escolherem o GIT.\nO primeiro controle de versão que utilizei foi o SVN quando era estagiário na Level Up! Games. Naquela época achava que o SVN servia apenas para compartilhar o código e ver o histórico das alterações no arquivo, não sentia muita vontade de usar isso em projetos pessoais.\nQuando comecei a trabalhar como analista de sistemas e com .Net, utilizei muito o SourceSafe da Microsoft. Assim como o SVN, ele tinha o conceito de dar checkout em arquivo para trabalhar, e depois dar checkin para subir as alterações no repositório. Eu achava interessante esse conceito de bloquear um arquivo para edição, mas em equipes com mais de 3 pessoas este tipo de recurso era um problema, pois não permitia mais de um programador trabalhar no mesmo arquivo.\nNa Electronic Arts eu utilizava o Perforce, um controle de versão muito bom e com recursos semelhantes ao do GIT que permitiam mais de uma pessoa trabalhar no mesmo arquivo sem grandes problema e criar branches para os projetos. Mesmo sendo muito bom, ainda assim não era como o GIT.\nCheguei a usar o SourceSafe no meu TCC da graduação, mas só quando comecei a pós-graduação que eu conheci o GIT. No início foi um grande choque sair de um modelo centralizado em arquivos para um outro onde cada um poderia trabalhar em qualquer arquivo e juntar tudo na hora de publicar no repositório. O uso de branches era bem interessante, mas como não conseguia ver para que poderia usar, sempre mantive as alterações no “master”. Aos poucos fui perdendo o medo de fazer branches e entendendo suas vantagens, mas só agora estou realmente usando tudo que o GIT oferece para os programadores.\nUm programador russo que trabalhou em um projeto comigo há algum tempo me mandou este link, que falava sobre um modelo de uso do GIT com branches e me disse que era muito bom. Li o texto e comecei a trabalhar assim, e em pouco tempo comecei a ver as vantagens desse modelo (e realmente usar as features do GIT).\nA ideia desse modelo é bem simples: use um branch “develop” para o desenvolvimento e faça as releases no “master”. O grande diferencial do modelo está no desenvolvimento das features, pois cada feature deve ser desenvolvida no seu próprio branch. Este branch, por sua vez, deverá ser aplicado no brach “develop” usando o comando “git merge”. Pode parecer um pouco confuso, mas depois de começar a usar este modelo tudo fica mais claro. Além das features, podemos também ter branches separados para bug fixes, sempre sendo criados a partir do branch “develop”.\nExistem muitas vantagens em utilizar um branch por feature, como por exemplo pode voltar a trabalhar em algo ou verificar alguma feature a qualquer hora. Como o merge é feito apenas no final da feature, o risco de ter vários conflitos é bem reduzido, pois você só precisará lidar com isso uma vez ao invés de lidar a cada commit quando utilizamos o mesmo branch “master” para tudo.\nO código do projeto fica muito bem organizado, e fica mais fácil de associar uma feature a uma parte do código. Eu, pessoalmente, acho muito mais organizado do que usar tags (apesar de serem úteis para marcar commits). Eu expliquei bem por cima por que eu acho mais interessante ler a explicação completa no site do Vincent clicando aqui.\nE você, usa o qual repositório em seus projetos? Lembrando que dropbox não conta! rs\nFonte: A successful Git branching model\n","date":"27 de outubro de 2014","externalUrl":null,"permalink":"/git-usando-branches/","section":"Blog","summary":"Durante minha carreira já usei muitos controles de versão, mas nos últimos anos o que mais tenho usado é o GIT. Além das suas features que vou comentar neste post, a possibilidade de ter seu repositório na nuvem em sites como Github e Bitbucket sem pagar nada está fazendo cada vez mais programadores escolherem o GIT.\n","title":"Modelo de desenvolvimento com GIT usando branches","type":"posts"},{"content":"Não tenho palavras para descrever como fiquei feliz por uma coisa tão simples como esta: um cara fez um video do gameplay de um jogo que fiz usando Unity 2009, e ele gostou!\nEm 2009, no meu primeiro ano da pós-graduação em games, comecei a estudar Unity. Fiz um tutorial e um jogo bem simples, o Jenga Explosion. Publiquei o jogo em um site chamado Gamejolt em 2011, onde muitos jogos indies para são publicados, principalmente web.\nHoje recebi um email avisando sobre um comentário na página do jogo, e quando li quase cai da cadeira. Fizeram um video mostrando o gameplay do jogo, e o mais legal é que o cara se divertiu muito jogando e fazendo o video.\nÉ um jogo simples, meu primeiro após fazer apenas um tutorial da Unity em 2009. Só coloquei no Gamejolt por que precisava ter ele hospedado em algum lugar para mostrar para as pessoas, e depois de 3 anos um comentário falando que gostou do jogo e um video mostrando o gameplay me deixou muito feliz. É como ter um objetivo concluído: uma pessoa jogou e gostou do meu jogo, isso é o suficiente.\nEste é o tipo de coisa que me faz lembrar por que comecei a fazer jogos, me motiva a não desistir não importa as dificuldades do caminho, me faz querer virar noites programando algo para que pelo menos uma pessoa goste. É por isso que faço jogos! =D\n","date":"17 de setembro de 2014","externalUrl":null,"permalink":"/por-isso-que-faco-jogos/","section":"Blog","summary":"Não tenho palavras para descrever como fiquei feliz por uma coisa tão simples como esta: um cara fez um video do gameplay de um jogo que fiz usando Unity 2009, e ele gostou!\n","title":"É por isso que faço jogos!","type":"posts"},{"content":"Raphael Dias, fundador do blog Produção de Jogos, lançou seu primeiro ebook chamado GAMEDEV – Fazendo carreira no mundo dos jogos digitais.\nO ebook contém informações e descrições de áreas para fazer carreira com jogos e até informações de salários, porém baseados no mercado norte americano. É uma leitura bem rápida, e ajuda a entender dúvidas iniciais sobre o que cada área faz para produzir um jogo.\nO livro é uma boa introdução ao assunto, porém senti falta de explorar mais, como outros livros fazem. Também faltaram as referências para confirmar muitos dados levantados pelo autor.\nO livro acompanha uma lista de cursos de desenvolvimentos de jogos no Brasil e no exterior, e também uma lista de empresas brasileiras que desenvolvem jogos. Infelizmente, a lista está um pouco desatualizado, pois algumas empresas que estão lá fecharam, embora seus sites continuem ativos.\nConheça mais sobre o livro clicando aqui, e também veja como comprá-lo.\n","date":"2 de setembro de 2014","externalUrl":null,"permalink":"/livro-sobre-como-fazer-carreira-em-games/","section":"Blog","summary":"Raphael Dias, fundador do blog Produção de Jogos, lançou seu primeiro ebook chamado GAMEDEV – Fazendo carreira no mundo dos jogos digitais.\n","title":"Livro sobre como fazer carreira em games","type":"posts"},{"content":"O site Indie Game Jams tem uma lista de todos os jams que estão acontecendo atualmente no mundo todo, além das datas dos próximos e muitas outras informações.\nGame jams são concursos onde você tem que desenvolver um jogo em um curto tempo (pode variar de horas a dias), as vezes seguindo um tema específico ou usando uma tecnologia específica. Alguns jams são em lugares específicos, enquanto outros como o famoso Ludum Dare são realizados online.\nExistem muitos game jams pelo mundo, inclusive logo começará o SP Jam, que é um jam realizado em São Paulo onde desenvolvedores tem 2 dias (sábado e domingo) para criar um jogo com um tema revelado na hora de começar.\nEu recomendo muito para todos que trabalham e querem trabalhar com games a participar destes jams, é uma ótima maneira de treinar, fazer um bom portfólio e conhecer pessoas. Muitos jogos indies começaram com uma demo em um game jam ou concurso, e muitas empresas foram formadas desta mesma maneira.\n","date":"22 de agosto de 2014","externalUrl":null,"permalink":"/site-game-jams/","section":"Blog","summary":"O site Indie Game Jams tem uma lista de todos os jams que estão acontecendo atualmente no mundo todo, além das datas dos próximos e muitas outras informações.\n","title":"Site com game jams independentes","type":"posts"},{"content":"Há um tempo me enviaram este post do Reddit chamado “Pocketknives for Game Developers“, que é um conjunto de ferramentas gratuitas úteis em várias partes do processo de desenvolver um jogo.\nSegundo o post, todos os links que estão lá são muito bons para sua função específica, são gratuitos e “portables”, ou seja, são flexíveis a ponto de exportar os dados para serem usados em outras ferramentas.\nEu copiar a lista de lá colei aqui para facilitar, mas não deixem de acessar o post original clicando aqui, pois lá existem mais sugestões nos comentários e explicações de por que usar cada uma dessas ferramentas.\nArte\nSpritesheet Cutter: http://spritecutie.com/ (created by /u/Rezoner) Turn photos to 8bit: http://superpixeltime.com/ (created by /u/FamousAspect) Simple 3D Modeller: http://www.3dtin.com/ (Thanks /u/TannerNetwork!) SVG Vector Art: http://svg-edit.googlecode.com/svn/branches/2.6/editor/svg-editor.html Photoshop-like Webapp: http://pixlr.com/editor/ (Thanks /u/2Fort!) Pixel Art: http://makepixelart.com/free/ Pixel Art Analyzer: http://hivemind.in/pj/specs/ (Thanks /u/MoarThenFeeling!) Pixel Animation: http://www.pickleeditor.com/ (Thanks /u/LoveDuckie!) Adobe Air app Pixel Tileset: http://pyxeledit.com/ (created by /u/Danik112, suggested by /u/InlineVoid) Adobe Air app Compressor de Imagens: https://www.websiteplanet.com/pt-br/webtools/imagecompressor/ Som\nMake Music #1: http://soundation.com/studio (Feels like GarageBand. Thanks /u/optimality!) Make Music #2: http://www.audiotool.com/app (If you like sliders and knobs) Make Music #3: http://www.beepbox.co/ (Super-simple chiptune loop creator. Thanks /u/Spajder!) Sound FX #1: http://www.superflashbros.net/as3sfxr/ Sound FX #2: http://www.bfxr.net/ (Newer revision of sfxr. Thanks /u/ethicszen!) Sound FX #3: http://www.leshylabs.com/apps/sfMaker/ (An HTML5 version of sfxr by /u/LeshyLabs) Convert OGG/MP3/WAV: http://media.io (Thanks /u/Bionsuba!) Convert WAV to MP3: http://audioformat.com/wav-to-mp3 (Thanks /u/RyeBread761!) Procedural Tunes: https://github.com/wibblymat/ld24/blob/master/autotracker.py (Thanks/u/Cosmologicon!) Python script Wolfram Tones: http://tones.wolfram.com/generate/ (MATHEMUSICAL. Thanks /u/BluShine!) Turns out Wolfram has a non-permissive license for the tunes it procedurally generates, so you can’t use them in your games. Uncool. Thanks to /u/ethicszen for the correction! Dados\nPlaceholder Kittens: http://placekitten.com/ (To test loading external images / image manipulation.) JSON Prettifier: http://jsonsh.com/ JSON Lint: http://jsonlint.com/ (Thanks /u/Skjalg!) Design\nTile Maps: http://elias-schuett.de/git/Online-Tile-Map-Editor UI Wireframing: https://moqups.com Flowcharting game flow: https://www.lucidchart.com (Thanks /u/MX-Chronos!) HTML5 Level Editor: http://www.craftyy.com (Full disclosure: /u/CosmicJC \u0026amp; I made this.) Game Mechanics: http://www.jorisdormans.nl/machinations/ (Thanks /u/Quantanamo!) Grid Map Editor: http://www.arraypainter.com (Thanks /u/oldsecondhand!) Standalone Java app Tiled Map Editor: http://www.mapeditor.org (Thanks /u/KillaW0lf04!) not web app Canva: https://www.canva.com/pt_br (Veja o canal no YouTube para conhecer mais sobre esta ferramenta) Produção\nOrganization: http://corkboard.me/ (Automatically creates your organization “corkboard”, no login needed!) Collaboration: https://trello.com/ (Thanks /u/MatticusRex \u0026amp; /u/Reaner!) Screenrecording*: http://www.screenr.com/ (Screencast without downloading anything) Warning: It uses the Java web applet, which hasn’t had a great track record with security issues. Programação\nRegex: http://regexpal.com/ (Thanks /u/Noctune!) Collaborative Coding: http://collabedit.com/ (Like Google Docs for programming. Thanks /u/BluShine!) Gist: https://gist.github.com/ (Good for sharing snippets of code) Pastie: http://pastie.org/ (Pastebin with plugins available for Sublime \u0026amp; TextMate. Thanks /u/agmcleod!) Making JS+CSS+HTML #1: http://jsfiddle.net/ (Thanks /u/MurderOfCrows!) Making JS+CSS+HTML #2: http://codepen.io/ (Thanks /u/Azeirah!) Making JS+CSS+HTML #3: http://cssdeck.com/ (Thanks /u/Rezoner!) Recursos\nOpen Game Art: http://opengameart.org/ (of course) Pocketknives for Javascript: http://microjs.com/ Game-specific UI Icons: http://game-icons.net/ (Thanks /u/AutumnGecko!) General UI Icons: http://thenounproject.com/ Fonts #1: http://www.google.com/webfonts (Free, open-source, and you can simply embed them) Fonts #2: http://www.dafont.com/ (Licenses vary, mostly free for personal use) 3D Textures: http://www.cgtextures.com/ (Thanks /u/Brother_Clovis!) Sound effects: http://www.freesound.org/ (Thanks /u/Connerses!) ","date":"18 de julho de 2014","externalUrl":null,"permalink":"/ferramentas-uteis-gamedev/","section":"Blog","summary":"Há um tempo me enviaram este post do Reddit chamado “Pocketknives for Game Developers“, que é um conjunto de ferramentas gratuitas úteis em várias partes do processo de desenvolver um jogo.\n","title":"Várias ferramentas úteis para desenvolver jogos","type":"posts"},{"content":"Desde o seu surgimento, muita gente diz que o HTML5 seria o substituto do Flash para jogos, principalmente por ter um canvas 2D. Antes eu apoiava esta ideia, mas hoje já não acredito mais nisso em plataformas móveis.\nAntes de começar a falar sobre o assunto do post, quero esclarecer algo que muitos se confundem: o HTML5 é apenas um padrão para marcações de HTML, e você não usa tudo desse padrão para fazer jogos, apenas a tag canvas. A programação do jogo é feita com Javascript, portanto, o jogo não é “desenvolvido com HTML5”, mas sim com Javascript.\nO HTML5 é muitas vezes vendido como uma solução “perfeita” para o desenvolvimento de jogos e apps, pois você pode tornar o produto acessível através de um navegador (desktop, mobile e até consoles). Além disso, em plataformas móveis, existe a possibilidade de colocar o projeto dentro de um wrapper (como PhoneGap ou Titanium) e lançar o jogo ou app nas stores.\nParece um mundo perfeito, sem Flash (nada contra rs) e com uma solução que “funciona” em qualquer plataforma, certo? Bom, por mais que vendam isso, esta utopia não existe.\nNa empresa que trabalho atualmente tive a oportunidade de participar do desenvolvimento de um jogo muito parecido com o SongPop, do seu início ao fim. Ele possui perguntas, interação social, partidas por turno e muitas outras coisas, então existe uma integração de front-end e back-end.\nFoi possível desenvolver o jogo sem grandes problemas, e ele funciona bem nas plataformas desktop e mobile, porém o uso de HTML5 deixou o que deveria ser simples mais complicado de fazer: a interface. A integração com redes sociais e com o próprio servidor do jogo foi muito fácil se comparado com o trabalho de montar a interface do jogo, que é apenas telas com botões de ação.\nO que era mais simples no Flash se torna a maior dificuldade em utilizar HTML5 para jogos, não existe uma solução visual boa para auxiliar o desenvolvimento. Mesmo soluções como o Construct 2 são fracas e limitadas, pois facilitam a parte visual mas atrapalham a programação forçando o programador a utilizar tudo no padrão deles.\nOutro fator que me fez não gostar do HTML5 para jogos mobile é o desempenho. O navegador do smartphone e tablets é um aplicativo que roda no sistema operacional, e o jogo roda dentro desse aplicativo. Por isso, muitas coisas são extremamente limitadas, como a memória disponível e o controle do contexto do jogo.\nO carregamento de algumas músicas pode fazer aparelhos bons, como o iPhone 4S, não aguentarem e fecham o navegador. Pelos testes que fiz, estes navegadores aguentam no máximo algo perto de 10MB de imagens e sons na memória, mais do que isso faz o desempenho do jogo cair muito e o navegador fechar.\nPara o desenvolvimento do jogo em questão, utilizei a suite de frameworks CreateJS, um conjunto de bibliotecas Javascript muito bom para desenvolvimento de aplicações web interativas, como jogos ou aplicativos. Utilizei o EaselJS, para o canvas, PreloadJS, para fazer o carregamento dos recursos, e SoundJS, para gerenciamento do som.\nEste framework é muito bom para desenvolvimento web com Javascript, um dos melhores e mais estáveis do mercado. Porém, HTML5 não foi feito para jogos em navegadores. Enquanto que para desktop não há problemas, para mobile o navegador dos aparelhos coloca um limite sem sentido para jogos.\nMesmo utilizando wrappers, como os dois citados no começo do post, isso não quer dizer que os problemas foram resolvidos. Embora dentro de um wrapper o jogo possa usar mais memória, pois roda como um aplicativo, ainda assim existem limites. Quem já desenvolveu utilizando wrappers para conteúdo com HTML5 sabe o quanto é complicado fazer muitas coisas que depende do hardware funcionarem, isso sem falar em problemas de layout que sempre acontecem devido a limitação também presente nestes wrappers.\nEnquanto não existir uma solução visual boa para o desenvolvimento de jogos com HTML5, mesmo seu uso em desktop será sempre limitado e de difícil utilização. Existem muitas outras opções melhores hoje, com a Unity. É estranho ter tantos frameworks e tanta gente incentivando o uso de HTML5, porém não existem ferramentas de qualidade para auxiliar o desenvolvimento.\nPara desktop, eu acredito que o uso de HTML5 para jogos só vai crescer quando houver mais ferramentas que auxiliem o desenvolvimento, e não estou falando de frameworks, e sim de softwares. Grandes jogos não são feitos apenas de frameworks, mas sim diversas ferramentas que auxiliam o desenvolvimento.\nPara mobile, o melhor é não usar. Mesmo para o desenvolvimento de apps, o HTML5 é extremamente fraco. Nada é melhor do que fazer um aplicativo utilizando os recursos presentes no Android SDK e iOS SDK. Acredite: o trabalho de fazer dois apps com códigos diferentes é menor do que fazer um app com HTML5 e esperar que funcionem em ambos, e você ainda ganha mais desempenho no app.\nApps grandes como Facebook, Twitter, WhatsApp, entre muitos outros, são feitos em projetos separados para cada sistema operacional mobile, pois eles precisam de performance e flexibilidade, coisas que o HTML5 está muito longe de oferecer. Se os grandes fazem assim, por que insistir em um padrão fraco? Muitas vezes os programadores preferem utilizar o HTML5 por preguiça de fazer mais de um projeto, e no fim acabam com uma solução mobile ruim ou tendo que fazer projetos para cada wrapper (que também é ruim).\nCom tantas opções hoje para desenvolvimento de jogos (e apps) mobile, não há razão para utilizar o HTML5. Eu tive todo tipo de experiência em jogos e aplicativos, ambos utilizando engines e frameworks bons e ruins, e tenho muito certeza quando digo que o momento é de abandonar o uso de HTML5 para jogos e aplicativos mobile. Ah, não confunda aplicativo com site, existe uma grande diferença entre prestar um serviço e mostrar informações.\nDesculpe o texto longo em forma de desabafo, seu objetivo é deixar claro que o HTML5 não é a solução de todos os problemas, não tem ferramentas boas para desenvolvimento, e não tem bons motivos para ser usado em jogos e aplicativos mobile. Deixe seu comentário abaixo para continuarmos esta discussão.\nUPDATE\nSe você quiser ver uma longa explicação técnica de por que HTML5 não serve pra mobile, leia estes dois excelentes artigos (em Inglês):\nMobile web apps are slow\nWhy mobile web apps are slow\n","date":"30 de junho de 2014","externalUrl":null,"permalink":"/html5-nao-serve-para-fazer-jogos-mobile/","section":"Blog","summary":"Desde o seu surgimento, muita gente diz que o HTML5 seria o substituto do Flash para jogos, principalmente por ter um canvas 2D. Antes eu apoiava esta ideia, mas hoje já não acredito mais nisso em plataformas móveis.\n","title":"HTML5 não serve para fazer jogos mobile","type":"posts"},{"content":"Jonathan Blow, criador de um dos jogos independentes de maior sucesso, o Braid, fez uma palestra sobre como programar jogos independentes na CSUA (Computer Science Undergraduate Association) de Berkeley.\nMesmo sendo um pouco antigo, pois a palestra foi apresentada em 2011, o conteúdo é aquele tipo de material tão valioso que nunca perde seu valor ou envelhece. Para preparar esta palestra, Jonathan Blow pensou em que ele falaria para ele mesmo quando era um estudante na escola.\nO resultado pode ser acompanhando no arquivo PPT abaixo e também através do audio gravado. É uma palestra de 40 minutos, com mais uns 40 minutos de perguntas e respostas. Muitos dados técnicos sobre o desenvolvimento do Braid e do The Witness são revelados, dando mais importância ao conteúdo. Um detalhe: leia também as anotações dele nos slides.\nEste conteúdo foi postado pelo próprio Jonathan Blow em seu blog. Também hospedei os arquivos no meu site, caso exista algum problema para baixá-los (links abaixo). Todo conteúdo está em inglês.\nDownload da apresentação (PDF).\n","date":"27 de junho de 2014","externalUrl":null,"permalink":"/como-programar-jogos-indie-jonathan-blow/","section":"Blog","summary":"Jonathan Blow, criador de um dos jogos independentes de maior sucesso, o Braid, fez uma palestra sobre como programar jogos independentes na CSUA (Computer Science Undergraduate Association) de Berkeley.\n","title":"Como programar jogos independentes, por Jonathan Blow","type":"posts"},{"content":"Existem muitos frameworks para jogos na internet, e cada vez mais estão sendo lançados para diversas plataformas. Por isso, é importante saber o que um framework deve ter e o que deve ser testado, antes de escolher a tecnologia errada e descobrir isso tarde demais para mudar.\nOs itens abaixo foram baseados em necessidades que tive (e não foram atendidas) quando desenvolvi o TCC da minha pós-graduação. O framework que eu usei foi uma escolha tão errada que ele falha em quase todos os itens abaixo, mas era tarde demais para mudar.\nPor isso, vale a pena perder um tempo no começo do projeto avaliando se o framework escolhido realmente serve para o que você quer fazer, e também se funciona bem, para não te deixar na mão.\nPossui alguma biblioteca de física? Se não, existe alguma recomendada pelos criadores do framework que funciona bem em conjunto? Consegue trabalhar com sprite sheets ou apenas imagens separadas? É necessário muitas linhas de código para carregar e desenhar algo na tela? Possui suporte para eventos de entrada (teclado, mouse, touch, etc)? No caso de 3D, quais são as compressões de textura que tem suporte? Existe um site/forum para tirar dúvidas? Algo feito para a comunidade de desenvolvedores que usa a tecnologia? O framework é atualizado constantemente? Possui um roadmap de futuras atualizações? Eles são abertos a sugestões? Pode ser utilizado em mais de uma plataforma? Se for pago, existe uma versão trial para testes? Possui suporte a redes sociais, publicidade e pagamento (para comprar itens no jogo com dinheiro de verdade)? Se não, aceita algum framework externo? Em quais sistemas operacionais e IDEs (visual studio, xcode, eclipse, etc) funciona? O framework é famoso e já foi utilizado em jogos publicados? É fácil de debugar e entender os problemas? Isso tudo é bem genérico, e é claro que depende do tipo de jogo que você está desenvolvendo. Mas, mesmo se não usar algo no início do projeto, é bom saber se o framework tem suporte a uma determinada funcionalidade, ou seu jogo não será flexível. Existe mais algum ponto que vale a pena ser verificado antes de escolher um framework? Comente abaixo!\n","date":"26 de junho de 2014","externalUrl":null,"permalink":"/avaliando-um-framework/","section":"Blog","summary":"Existem muitos frameworks para jogos na internet, e cada vez mais estão sendo lançados para diversas plataformas. Por isso, é importante saber o que um framework deve ter e o que deve ser testado, antes de escolher a tecnologia errada e descobrir isso tarde demais para mudar.\n","title":"Como ser um programador de jogos: Avaliando um framework","type":"posts"},{"content":"As vezes queremos usar imagens de botões de controles nos jogos para algum tutorial ou mesmo em interfaces touch como botões de ação, e este pack com vários botões de controles de consoles pode ajudar bastante.\nO Kenny é um artista que disponibiliza muito conteúdo gratuito em seu site, e vale um destaque para as suas artes de interface, principalmente botões para usar em jogos.\nRecomendo dar uma olhada em todo conteúdo disponível, já usei muito dos seus assets para protótipos ou testar algo em um jogo.\n","date":"27 de maio de 2014","externalUrl":null,"permalink":"/imagens-botoes-jogos/","section":"Blog","summary":"As vezes queremos usar imagens de botões de controles nos jogos para algum tutorial ou mesmo em interfaces touch como botões de ação, e este pack com vários botões de controles de consoles pode ajudar bastante.\n","title":"Imagens de botões para usar em jogos","type":"posts"},{"content":"Esta é a segunda parte minha entrevista com o Gilliard Lopes, o brasileiro produtor dos jogos da série FIFA.\nA primeira parte da entrevista está disponível aqui, e foca no começo da carreira do Gilliard e seu caminho até se tornar produtor da série FIFA. Nesta segunda parte conheça um pouco do trabalho dele na Electronic Arts, suas responsabilidades na série FIFA e dicas de onde procurar emprego fora do país e o que estudar.\nBruno Cicanci: Como é trabalhar em uma empresa gigante como a EA e em um título AAA tão famoso quanto FIFA?\nGilliard Lopes: A grande diferença que senti, comparando com a experiência que tive no Brasil, é que na época tínhamos que justificar tudo que a gente fazia. Muito do que eu fazia era conversar com as pessoas sobre o que são games, por que são importantes, por que fazem dinheiro, por que deveriam se importar com eles. Aqui fora a indústria é bem desenvolvida, a EA é a gigante que ela é por causa dos games. Todo mundo aqui leva muito a sério aquilo que a gente faz, entende como um negócio que movimenta muito dinheiro e dá emprego para muitas pessoas. Até na minha promoção de programador para produtor eu senti muito essa valorização do trabalho do game designer e do produtor. Sempre no Brasil quando era necessário descartar algo do jogo, sempre existia resistência e comentários como “ninguém vai perceber, isso é só um jogo”. Isto não existe aqui, o fato de ser um jogo é o que faz a gente existir, e tudo mundo é muito respeitado com seriedade pelo que faz. No lado mais técnico, é obvio que a estrutura é uma diferença enorme. Quando você recebe seu PC novo para trabalhar ele já vem com tudo que você precisa funcionando e basta apenas ler uma página da Wiki interna para saber como começar a trabalhar e compilar o jogo pela premira vez. E termos de processo, mesmo a EA sendo ma empresa muito bem estabelecida, nesses 5 anos que estou aqui vi muitas coisas mudarem, e eu contribuí um pouco para algumas coisas mudarem. As empresas grandes não tem todas as respostas prontas, mesmo por que é uma indústria que não deixa você estagnado. Por exemplo, na época que eu entrei o uso do Scrum não era tão disseminado como é hoje, e eu participei da implantação do Scum no FIFA, fui um dos evangelizadores desse processo. Quando cheguei as pessoas não entendiam que o papel do produtor e do game designer era ser o product owner, e não parte do time. Eles devem cuidar do backlog enquanto os desenvolvedores estão trabalhando no sprint. No Brasil é comum o cara que fazer o game designer e produção gerenciar a equipe, mas aqui esse papel é muito bem definido e o gerente de projeto é o scrum master, o cara que tira os problemas da frente e acompanha o resultado das sprints e cuida das reuniões.\nBC: Depois de trabalhar como programador por alguns anos, você tornou-se produtor do FIFA. Como foi encarar esse desafio para garantir a qualidade da série?\nGL: Esta era uma das coisas que me deixava acordado a noite (risos). Na verdade, nenhuma decisão é tomada sem uma preparação, de modo que um produtor novato não é jogado aos lobos. Temos uma estrutura hierárquica não muito profunda mas com tamanho suficiente para dar este tipo de apoio. No FIFA 12, que foi o primeiro jogo que eu fui produtor, havia este entendimento de que eu estava aprendendo no trabalho, então tinha um acompanhamento muito mais próximo de cada uma das decisões e das perguntas que eu tinha que responder. Durante toda pré-produção eu tive um produtor do meu lado que já tinha trabalhado na minha área de produção até o FIFA 11, e estava deixando a área para trabalhar em outra coisa, mas ele passou toda pré-produção comigo me treinando. Esta é a parte mais intensa da responsabilidade, pois na pré-produção que é definido o que vai fazer o próximo FIFA ser diferente do anterior e convencer as pessoas a querer jogá-lo. É um momento crucial, e tive muito apoio, nada disso foi feito nas coxas. Pelo contrário, é difícil alguém entrar como produtor em um jogo, por isso existe este processo para garantir que o produtor novato seja treinado para assumir certas responsabilidades. Eu tive a felicidade de ser muito bem treinado e tive ótimos mentores que hoje são diretores da série.\nBC: Por ser brasileiro, sua experiência com futebol te ajuda na produção do FIFA?\nGL: Desde que eu era programador eu pedia para me deixarem participar das reuniões de produção, e aos poucos começaram a respeitar minha opinião e experiência com futebol. Hoje eu sou uma pessoa muito procurada para questionar autenticidade, como regras específicas de algum campeonato, e eu conheço por que eu realmente gosto de assistir e acompanhar o esporte. Isto é um trabalho de casa que eu sempre fiz por gostar de futebol, e isto foi algo que me ajudou muito na minha transição para produtor da série. Mesmo quando eu era programador as pessoas vinham perguntar para mim coisas sobre futebol que muitas vezes os produtores e game designers não sabiam por ser coisas muito específicas do esporte ou em algum país, como o futebol sul-americano. Parte do que fez eu ganhar esta confiança do pessoal foi meu interesse e conhecimento pelo esporte, e também por conhecer o mercado brasileiro que é um grande consumidor do jogo. É muito mais fácil trabalhar em um jogo como o FIFA quando se conhece o futebol, e isso sempre foi um diferencial para mim, pois acompanhar campeonatos é algo que sempre fiz e faria mesmo se não trabalhasse com jogos. É muito importante internamente ter pessoas de diferentes partes do mundo que conheçam o esporte na sua região para garantir a autenticidade destes fatores no jogo. É primordial conhecer futebol para fazer um bom jogo como o FIFA.\nBC: Você é um dos criadores do PodQuest, o que o motivou a criar o podcast e qual o objetivo dele?\nGL: O PodQuest é um podcast sobre a indústria de games que eu criei com dois amigos que também tiveram a oportunidade de trabalhar com jogos fora do Brasil, e nós fazemos em português por que o público-alvo são realmente os brasileiros.\nBC: Como você vê a indústria de desenvolvimento de games no Brasil? Você acha que só fora do país é possível seguir carreira?\nGL: Acho que tudo depende dos empreendedores e da capacidade deles de viabilizarem um negócio. Hoje, mais do que nunca, os caminhos estão abertos para ganhar uma experiência através do mercado indie, você tem condições de um time pequeno e focado desenvolver um game que você consiga publicar, e também existem canais hoje que não existiam antes. Acho que a dificuldade está sempre em dar o próximo passo, como um profissional consegue fazer carreira e ter um bom retorno. A dificuldade é muito grande para estúdios que começam a crescer e necessitam de mais investimentos para manter uma equipe desenvolvendo jogos. Talvez com mais iniciativas de investimentos estas empresas consigam crescer, mas também os empreendedores precisam estarem lá com seu projeto debaixo do braço para apresentar e chamar a atenção dos investidores. Como profissional, é importante ter esta experiência no Brasil, mas em um momento quando quiser ter um crescimento na carreira será necessário deixar o país em busca disso, pelo menos esta é a realidade de hoje. Ou, como empreendedor, criar estas oportunidades para que esta realidade mude, este é o grande desafio. Isto é algo que tenho dentro de mim, um espírito empreendedor e quero um dia colocar isto em prática e abrir um estúdio, talvez por aqui ou no Brasil, não sei. Por enquanto estou feliz com a minha carreira e tenho o emprego dos sonhos, não tenho nada a reclamar daqui, mas sei que esta parte de criar oportunidades e ter meu próprio negócio na área de games é uma coisa que vou voltar a tender fazer no futuro, e acho que a gente precisa de gente que esteja disposta a fazer isso no Brasil.\nBC: Qual é a melhor maneira de procurar uma vaga em outro pais?\nGL: É muito importante você aprender por fora daquilo que você oportunidade de fazer no dia-a-dia. Além de você construir um portfólio de jogos, trabalhar em uma empresa brasileira ou ter sua própria empresa, até um TCC da faculdade por ser uma oportunidade para fazer alguma, mas o importante é levar isso até o final. Chegar em uma versão jogável, uma demo, uma fase, um protótipo, alguma coisa jogável. Muitos problemas você vai encontrar quando desenvolver um jogo, e eu conheço muita gente que escreve projetos mas não conhecem os percalços do caminho por não fazer um jogo de verdade. Acho muito importante o profissional brasileiro ganhar esta experiência, mesmo com as oportunidades limitadas que existem no Brasil. Hoje em dia não tem como falar que existe dificuldade em acesso a informação, existem livros, artigos, recursos na internet, engines gratuitas. As pessoas tem que ser autodidatas para se prepararem para o momento em que forem procurar uma oportunidade fora. O processo de ser entrevista e ser levado para fora é muito difícil, por isso você precisa estar bem preparado para concorrer no mercado internacional. Uma dica é tentar evitar lugares onde é mais difícil para um brasileiro conseguir entrar sem ter passaporte de outro país, os Estados Unidos é um exemplo. Um visto de trabalho lá é bastante difícil de conseguir, então muitos entrevistadores vão perguntar se você tem este visto, e não ter pode acabar com muitas oportunidades. O Canadá é um país muito mais tranquilo para se obter um visto de trabalho e é um país que precisa de gente de fora, pois existem mais oportunidades do que pessoas. A Europa também é mais fácil, exceto Inglaterra que ainda é difícil conseguir um visto de trabalho. Mesmo que muitas empresas de jogos estejam nos Estados Unidos, ainda existem muitas oportunidades em outros países, principalmente no Canadá.\nBC: Dicas para quem está começando a desenvolver jogos.\nGL: Faça seu jogo até o fim, coloque-se no lugar do jogador e faça um review do seu jogo bem imparcial e veja onde você precisa melhorar. Vai fundo e não se dê por satisfeito, não ache que por que você está no Brasil e é mais difícil você não tem oportunidade para desenvolver jogos legais. Quando você for conversar com alguém de fora, não vão querer saber de onde você é, e sim sua experiência. Então corra atrás, a informação necessária está por ai em livros, artigos. Faça seu jogo até o fim.\n","date":"15 de maio de 2014","externalUrl":null,"permalink":"/entrevista-gilliard-lopes-produtor-fifa-ea-parte2/","section":"Blog","summary":"Esta é a segunda parte minha entrevista com o Gilliard Lopes, o brasileiro produtor dos jogos da série FIFA.\n","title":"Entrevista: Gilliard Lopes, produtor do FIFA na Electronic Arts Canada – Part 2","type":"posts"},{"content":"","date":"15 de maio de 2014","externalUrl":null,"permalink":"/categories/entrevistas/","section":"Categorias","summary":"","title":"Entrevistas","type":"categories"},{"content":"Esta semana li este comentário que me inspirou a escrever este post, que é a frase famosa “Keep it simple, stupid”, algo como “Mantenha simples, idiota” em tradução literal.\nMuitas vezes buscamos programar a melhor solução possível para um problema, mas muitas vezes o problema não requer uma solução complicada. Por exemplo, não é necessário programar um algoritmo de ordenação complexo para ordenar uma lista que sempre será pequena, neste caso vale a pena usar algo mais simples.\nO Brian Kernighan, explicou a frase “Keep it simples, stupid” da seguinte forma: debugar um código é duas vezes mais complexo do que escrevê-lo. Sendo assim, se você escrever o melhor código possível, você mesmo não será capaz de debugá-lo. Faz sentindo, não?\n“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”\nBrian Kernighan\nQuanto maior for a complexidade, mais difícil será entender algum bug no código. Por isso, mantenha seu código com baixa complexidade e sempre pense em como debugar enquanto programa, isso ajuda a identificar problemas e prevenir código complexos.\nUma dica para simplificar um código é quebra-lo em métodos e funções, pois assim você deixa o código reusável e mais simples de entender e debugar. Existem outras formas de simplificar um código, está é uma das mais básicas e usadas.\nOutra dica é ler livros que ensinam programar e também boas práticas, como Code Complete e Effective C++.\nUPDATE\nDicas do leitor Lucas Oliveira:\nPractical Object-Oriented Design in Ruby by Sandi Metz\n","date":"12 de maio de 2014","externalUrl":null,"permalink":"/mantenha-tudo-simples/","section":"Blog","summary":"Esta semana li este comentário que me inspirou a escrever este post, que é a frase famosa “Keep it simple, stupid”, algo como “Mantenha simples, idiota” em tradução literal.\n","title":"Como ser um programador de jogos: Mantenha tudo simples","type":"posts"},{"content":"Muita gente se perde na hora de começar a programar um jogo, e independente do tamanho do projeto pode ser realmente uma tarefa difícil saber por onde começar.\nA melhor alternativa é sempre começar pela mecânica principal do jogo, quebrando ela em tarefas menores. Por exemplo, em um jogo onde um personagem movimenta-se pela tela, a primeira coisa que deve ser programada é este personagem. Antes mesmo de pensar em atacar, sistema de níveis, inimigos, e qualquer outra coisa, o jogador deve poder movimentar o personagem.\nA partir disso, você pode criar um nível de playground para poder testar o comportamento do personagem com diversas opções no cenário do jogo. Isso é apenas um exemplo, pois esta abordagem pode variar de acordo com o tipo do jogo, mas no geral é sempre bom começar pela mecânica principal, e trabalhar nela até ficar bem polida.\nEm jogos de puzzle, por exemplo, a primeira coisa a ser programada são os movimentos que o jogador pode fazer para resolver um puzzle, antes mesmo de programar o puzzle. Com os movimentos bem definidos e testados, programar os diferentes puzzles ficará mais fácil.\nAlgumas coisas que escrevi neste post já foram apresentadas nesta série Como ser um programador de jogos, vale a pena conferir os posts anteriores por que tem muita coisa legal e útil para começar.\n","date":"2 de maio de 2014","externalUrl":null,"permalink":"/por-onde-comecar-programar/","section":"Blog","summary":"Muita gente se perde na hora de começar a programar um jogo, e independente do tamanho do projeto pode ser realmente uma tarefa difícil saber por onde começar.\n","title":"Como ser um programador de jogos: Por onde começar a programar um jogo","type":"posts"},{"content":"Um game nasce de uma idéia ou um conceito, que então é validado com um protótipo, para depois tornar-se em algo jogável. Porém, esse “algo jogável” pode ser tecnicamente perfeito e, mesmo assim, não agradar aos jogadores. Nesse caso, a culpa não é da equipe de desenvolvimento, e sim de quem pensou na sua idéia sem tratá-la como um produto.\nPara um jogo tornar-se um produto é necessário pensar em alguns detalhes antes (ou enquanto) o protótipo é desenvolvido, pois não basta o jogo ser bem feito e divertido se existe muita concorrência de jogos similares. Para transformar o jogo em um produto, deve-se montar um tipo de plano de negócio com foco em lançamento de produtos, e para isso deve-se levar em conta os seguintes itens:\nPúblico-Alvo: Quem vai jogar o seu jogo? Onde você vai encontrar o seu público-alvo? Como você vai fazê-lo jogador? Plataforma: Em qual plataforma você quer lançar o seu jogo? A ideia é viável na plataforma escolhida? Como funciona a publicação de um jogo nessa plataforma? Mercado: As pessoas vão querer jogar o seu jogo? A plataforma escolhida é viável? O mercado está saturado para o tipo de jogo que você quer fazer? **Concorrência **Quais empresas e quais jogos são seus concorrentes diretos e indiretos? Quais jogos são similares em algumas funcionalidades? Diferenciais: Por que as pessoas vão querer jogar o eu jogo ao invés dos jogos concorrentes? Por que um investidor colocaria dinheiro em seu projeto? Basicamente, esses são os pontos iniciais para transformar um jogo em produto. Apenas com esse tipo de análise de negócio será possível descobrir se o seu jogo terá chances de ser um sucesso ou não. É algo simples de fazer, não demora muito, e pode te deixar rico ou frustrado (para então tentar de novo!).\nUPDATE\nDica do leitor Lucas Oliveira:\nModelo Canvas para plano de negócio\nSite para montar um Canvas\nDica do Martin Luenendonk, do site STARTUP FUNDRAISING:\nInvestment Readiness Level Guide: How to Boost Your Startup’s Attractiveness to Venture Capital Investors using the Business Model Canvas\n","date":"23 de abril de 2014","externalUrl":null,"permalink":"/transformando-jogo-em-produto/","section":"Blog","summary":"Um game nasce de uma idéia ou um conceito, que então é validado com um protótipo, para depois tornar-se em algo jogável. Porém, esse “algo jogável” pode ser tecnicamente perfeito e, mesmo assim, não agradar aos jogadores. Nesse caso, a culpa não é da equipe de desenvolvimento, e sim de quem pensou na sua idéia sem tratá-la como um produto.\n","title":"Como ser um programador de jogos: Transformando jogo em produto","type":"posts"},{"content":"O projeto do Code.org, chamado Hour of Code, ensina conceitos básicos de lógica de programação através de jogos simples baseados em Plants vs Zombies e Angry Birds.\nO aluno deve chegar ao objetivo da fase através de linhas de código que são ensinadas em cada capítulo. O objetivo pode ser desde chegar em um personagem do Angry Birds ou impedir que zumbis ataquem sua casa. É bem simples e divertido, e no final você ganha um certificado de participação.\nMesmo se você for um programador experiente, não deixe de jogar, é realmente bem legal! E se você não é um programador e quer aprender um pouco de lógica de programação, este site é mais do que recomendado para você começar.\nVeja o vídeo abaixo com as pessoas que apoiam este projeto, e acesse aqui para jogar.\n","date":"22 de abril de 2014","externalUrl":null,"permalink":"/basico-logica-programacao-jogando/","section":"Blog","summary":"O projeto do Code.org, chamado Hour of Code, ensina conceitos básicos de lógica de programação através de jogos simples baseados em Plants vs Zombies e Angry Birds.\n","title":"Aprenda o básico de lógica de programação jogando","type":"posts"},{"content":"Assim como em qualquer projeto, existem tarefas e elas necessitam de prioridade para você saber quais são mais importantes e urgentes. No desenvolvimento de um jogo, muitas vezes as tarefas podem ter dependência com outras áreas, como arte ou som, porém mesmo com dependências podemos definir prioridades nas tarefas.\nPodemos olhar para elas pensando exclusivamente na programação, assim você saberá o que deve ser programado primeiro. Por exemplo, não adianta fazer a programação do movimento de um personagem sem antes ter um personagem na tela. Algumas tarefas podem ser difíceis de priorizar, pois muitas podem ter a mesma dependência básica. Por exemplo, com o personagem na tela você pode fazer ele andar, atacar, pular, correr, etc, mas essas tarefas podem não dizer claramente quais são as mais importantes.\nPara saber o que é mais importante na hora de programar, devemos olhar para o nosso objetivo. Se queremos fazer o personagem lutar, fazer ele se movimentar é mais importante do que fazer ele interagir com portas, por exemplo. Por isso, muitas vezes as tarefas são derivadas de uma tarefa maior, que na verdade é um requisito do jogo, uma mecânica, uma jogabilidade, uma feature, entre outras coisas. É importante também manter o foco, pois se o objetivo é ver o personagem lutar, não é necessário criar todo o nível nestas tarefa, pois o foco dela é jogabilidade.\nA seguir está um exemplo de uma tarefa quebrada em outras menores, e (ordenado por prioridade sempre que possível). Através do exemplo abaixo, podemos ter uma idéia de por que uma tarefa tem mais prioridade do que a outra. Se ajudar, você podem também adicionar números nas tarefas e marcar o nome de qual tarefa é dependente dela, mas isso não é necessário se um objetivo tiver mais ou menos o mesmo tamanho que o exemplo. Se for muito maior do que isso, ele precisa ser quebrado em menores antes de definir as tarefas.\nObjetivo\nMovimentar o personagem através de um controle de touch na tela\nTarefas\nDesenhar jogador na tela (apenas uma imagem) Desenhar botões na tela (cima, baixo, esquerda e direita) Capturar o input do jogador nos botões Mover o personagem de acordo com o input Definir uma velocidade de movimento Substituir a imagem do jogador por animações para todas direções Alterar a imagem dos botões quando ele for pressionado Testar a jogabilidade e refinar até ficar boa e constante Uma boa dica é utilizar ferramentas como o Trello para organizar as tarefas. Este post é legal para saber mais sobre o Trello e outras ferramentas e técnicas para organização do tempo, que podem ser úteis na organização das tarefas do projeto.\n","date":"9 de abril de 2014","externalUrl":null,"permalink":"/definicao-de-prioridade-de-tarefas/","section":"Blog","summary":"Assim como em qualquer projeto, existem tarefas e elas necessitam de prioridade para você saber quais são mais importantes e urgentes. No desenvolvimento de um jogo, muitas vezes as tarefas podem ter dependência com outras áreas, como arte ou som, porém mesmo com dependências podemos definir prioridades nas tarefas.\n","title":"Como ser um programador de jogos: Definição de prioridade de tarefas","type":"posts"},{"content":"O quarto e último livro da série americana Introdução ao Desenvolvimento de Games, publicado em português no Brasil pela editora Cengage Learning, trata a parte final da produção de um jogo, que envolve marketing, comercialização e direitos autorais.\nO editor do livro, Steve Rabin, reuniu seu time de profissionais da indústria de jogos AAA para tratar de um assunto que muita gente não lida, mas que faz toda a diferença no sucesso de um jogo, que é a comercialização e a parte legal burocrática da propriedade intelectual. Confira a review do volume 1, volume 2 e do volume 3 que fiz no blog também.\nEnquanto os demais livros da série focam no game design, programação e arte, este último apresenta resumidamente diversos tópicos interessantes e essenciais que buscam viabilizar o jogo, tratando-o como um produto que deve ser comercializado para gerar lucro e também deve ter sua propriedade intelectual protegida.\nA primeira parte do livro é obrigatória para todo desenvolvedor antes de começar a fazer um jogo, que é a organização da produção e o gerenciamento do projeto do game. Existe uma fase chamada pré-produção, e nela muitas coisas são documentadas, produzidas e testadas, como o documento de game design (GDD), o cronograma do projeto e a organização da equipe. Depois disso começamos a fase de produção, que é onde o jogo é criado de fato. Por fim, a fase de pós-produção, onde muitos detalhes são acertados antes e durante o lançamento do game.\nEstas fases de produção são incrivelmente detalhadas no livro, e acredite que são muitas. Vale ressaltar dois detalhes: nem tudo que está no livro é válido para o Brasil; e pode parecer muita coisa mas lembre-se de que este livro foi escrito por veteranos da indústria que criaram jogos AAA, e não indies.\nEu conhecia um pouco dessa parte de produção, mas após este capítulo o livro me surpreendeu com um conteúdo inesperado. Existem capítulos que falam sobre o relacionamento do desenvolvedor com a publisher (ou editora, como foi traduzido), e até sobre a economia da indústria de games. São coisas muito interessantes para ler e conhecer, mesmo que você não use isto agora ajuda a entender que não basta fazer um jogo, para ele ser um sucesso existem diversos fatores e tarefas.\nO capítulo sobre marketing é outro destaque do livro, uma vez que nunca vi um livro focando em marketing para games. Se pra mim que sou programador foi bem legal de ler, tenho certeza de que alguém desta área que tem interesse em jogos vai gostar e aproveitar muito esta parte do livro.\nPor fim, dois capítulos respondem as dúvidas mais comuns de um desenvolver sobre regulação de conteúdo no mundo e a lei e prática sobre conteúdo de propriedade intelectual (IP, em inglês). Eu sempre tive interesse em ler sobre isso, mas nunca fui atrás de um livro sobre o assunto, não sei dizer se existe um para games também. Porém, estes capítulos são um ótimo ponto de partida para entender o que você deve fazer para proteger a IP do seu jogo e também a importância da regulação do conteúdo do jogo para poder publicá-lo em outros países.\nNovamente, lembre-se de que todo o conteúdo do livro foi escrito para o mercado norte americano e para jogos AAA. Claro que tudo pode ser usado em mercado brasileiro e em jogos indies, mas muitos detalhes devem ser pesquisados por que são diferentes.\nFechando com chave de ouro a série, este volume 4 é quase tão essencial quanto a parte técnica de se desenvolver um jogo. Por mais que você desenvolva por paixão, se o jogo virar um negócio lucrativo é bom estar preparado e informado sobre o que fazer para ter sua propriedade intelectual protegida, como fazer o marketing do jogo e também como funcionam as fases da produção de um game.\nMuito obrigado novamente a editora Cengage Learning por tem enviado o livro! Este volume, assim como toda coleção, esta disponível em várias livrarias e no site da editora. Siga a Cengage Learning no Facebook e no Twitter para ficar por dentro dos lançamentos da editora.\n","date":"8 de abril de 2014","externalUrl":null,"permalink":"/introducao-ao-desenvolvimento-de-games-4/","section":"Blog","summary":"O quarto e último livro da série americana Introdução ao Desenvolvimento de Games, publicado em português no Brasil pela editora Cengage Learning, trata a parte final da produção de um jogo, que envolve marketing, comercialização e direitos autorais.\n","title":"Introdução ao desenvolvimento de games, volume 4","type":"posts"},{"content":"Há pouco tempo o estúdio brasileiro Fire Horse levou o prêmio de melhor jogo no evento GDWC 2013. Entrei em contato com eles e toparam fazer está entrevista contando um pouco sobre a história do estúdio.\nMesmo em uma semana corrida participando de eventos, ainda conseguiram tempo para responder esta entrevista e compartilhar sua experiência com os leitores do blog. Muito obrigado pessoal, o sucesso de vocês é mais do que merecido! Acompanhem abaixo um pouco sobre um estúdio brasileiro que não deixou a paixão por fazer jogos de lado ao desenvolver seus projetos.\nBruno Cicanci: Como nasceu o estúdio Fire Horse e por que este nome?\nFire Horse: Apesar de a Fire Horse oficialmente estar em operação a pouco mais de dois anos, desde fevereiro de 2012, ela já existe informalmente desde 2008, e tudo começou como um grupo na faculdade de Design de Games que apesar de mudar muito de sua formação original até agora, veio sempre com o mesmo nome. O porque do nome é uma pergunta mais difícil… hahah nós poderíamos inventar algo como “é Horse porque é um animal rápido, resistente e leal, e Fire porque representa a chama em nossos corações, a paixão por fazer games…” mas infelizmente não é nada tão profundo… acho que a resposta mais honesta é… “porque sim” =P.\n**BC: Qual é o tamanho da equipe e o que cada um faz?** FH: A equipe atual é composta por 3 pessoas, Allan Smith responsável pela programação, Danilo Franco pela Arte 2D (texturas, interfaces, etc) e Fernando Colombo pela Arte 3D (modelagem, rigging, animação, etc). Nós 3 nos formamos juntos no curso de Design de Games no final de 2011 e logo depois formamos a empresa. A equipe cresce e diminui dependendo da necessidade, mas temos alguns parceiros pra fazer toda a parte de efeitos sonoros e músicas, mas nós 3 que ficamos responsáveis basicamente por tudo que acontece por aqui.\nBC: Quais foram as primeiras dificuldades que vocês enfrentaram para desenvolver jogos no Brasil?\nFH: A primeira dificuldade com certeza foi a falta de experiência. Nos formamos, e 2 meses depois largamos nossos empregos pra correr atrás do sonho. Apesar de formados em Design de Games que é um curso muito interessante e que com certeza ajudou muito, não tínhamos experiência em desenvolvimento para mobile (nosso foco atual), nem um portfólio que prestasse (pegamos nosso TCC e alguns outros trabalhinhos meio fracos só pra dizer que tinha alguma coisa). Sabíamos desde o começo que tínhamos (e ainda temos) um longo caminho pela frente e que até ter um retorno financeiro levaria um bom tempo, mas estávamos prontos para isso. Apesar de acharmos o Brasil um país extremamente hardmode para desenvolvimento de jogos, nossas dificuldades iniciais não estavam ligadas com a condição do país nesse sentido.\nBC: Você acha importante a formação acadêmica para o desenvolvimento de jogos? Quais são os cursos mais indicados?\nFH: Como mencionei nas outras perguntas, nós 3 somos formados em Design de Games, pela Universidade Anhembi Morumbi, e posso dizer que é um curso muito legal mesmo, que vai te dar um geral sobre tudo que envolve criar um jogo. Desde aulas de Sound Design até 3D até Programação, tudo está contemplado na grade. Além disso, todo semestre tem um trabalho que é chamado Interdisciplinar, que em geral é desenvolver um jogo em grupo, primeiro de tabuleiro, depois em Flash, depois em Unity e por ai vai. Acho que é um curso MUITO legal pra quem quer entrar em contato com a área e ter noção da bronca que é fazer um jogo, e ainda não está decidido com o que quer trabalhar no ramo (programação, arte, etc), mas, por ser tão abrangente o curso não se aprofunda em nada, então é bom estar preparado pra se dedicar por fora da faculdade naquilo que mais gosta da área. Digamos assim, nós 3 sabemos o que sabemos hoje por nossa conta, e não por conta da faculdade, mas ao mesmo tempo, se não tivéssemos cursado Design de Games, com certeza a Fire Horse não existiria hoje, nós nem nos conheceríamos.\n**BC: Quais são os softwares e frameworks que vocês utilizam para desenvolver? **\nFH: Todos nossos jogos são feitos em Unity 3D, utilizando C# como linguagem de programação, e para a criação dos assets de arte usamos Photoshop e 3DS Max e é basicamente isso. Eventualmente para criar vídeos/cutscenes, utilizamos After Effects.\nBC: Como você vê a indústria de desenvolvimento de jogos no Brasil?\nFH: No começo, quando as pessoas começam a desenvolver jogos, eu acho que qualquer país acaba sendo igual, é difícil simplesmente porque fazer jogos é difícil, não importa se você vive na Finlândia com uma baita infraestrutura animal ou no Zimbábue, você está competindo com o mundo todo. Todo mundo quer entrar na Steam, quer estar no top da App Store, enfim, não é fácil pra ninguém. No entanto, quando se fala em “abrir uma empresa” e crescer o negócio, é ai que o bicho pega no Brasil. Quando é só um grupo fazendo um jogo, tudo bem, mas quando é uma empresa, os encargos absurdamente altos do país, a completa falta de incentivo, o custo de vida absurdamente caro e tudo o mais podem matar a empresa rapidamente. Só para dar uma ideia, aqui no Brasil contratar um funcionário, vamos supor que o salário seja de 1000 reais? O gasto desse funcionário pra empresa é de (em torno de) R$1800,00-R$2000,00 por mês, só de encargos trabalhistas. Na Alemanha, o custo seria de R$1200,00, no Canada, dependendo de como sua empresa se enquadra e de que incentivos do governo você pode fazer parte, o custo seria de R$400,00. Isso mesmo, o governo PAGA pra você uma parte do salário do fulano (de até 60%). Então existe sim um problema gigante no Brasil, não só pra games mas pra qualquer empresa.\n**BC: Como são vistos os jogos brasileiros fora do país? **\nFH: Sendo bem sincero, muito bem vistos. Sempre que a gente comenta com alguém de fora “Somos um estúdio brasileiro de desenvolvimento” todo mundo acha super legal e se interessa por saber mais, inclusive existem algumas iniciativas que são exclusivas para o Brasil ou América Latina, por exemplo um incentivo da Sony para ajudar desenvolvedores dessa região a entrarem em seus consoles. Não acredito que exista um preconceito quanto a isso, na verdade acho que o maior problema é realmente a qualidade dos jogos. Ao mesmo tempo que existem jogos fantásticos como Knight’s of Pen and Paper, Toren, Ninjin entre uma porrada de outros, existe uma porrada ainda maior de jogos que não estão prontos para competir com o resto do mundo. Nós mesmos ainda não criamos nenhum jogo que tenha se tornado um hit e com certeza não é por sermos brasileiros, mas porque nossos jogos ainda não estão bons o suficiente.\nBC: Como foi ganhar o GDWC 2013?\nFH: Completamente inesperado! Foi fantástico, uma baita injeção de ânimo! Nós nos inscrevemos no último dia num clima meio de “é… o jogo ainda tá simples e curtinho mas não custa nada tentar…” tanto é que a gente nem ficou sabendo que a gente ganhou direto, nem fomos ver os vencedores, um amigo nosso que chegou “Parabéns falei que tava da hora o jogo” e a gente ficou sem entender… ai ele explicou e foi aquela baita felicidade na hora =). É mais do que pelos prêmios (que são bem legais) sabe, é pelo feedback positivo, pela certeza de que estamos trabalhando em algo legal e que o projeto está indo no caminho certo. Foi genial.\nBC: Como foi participar da GDC 2014?\nFH: Infelizmente nós não estivemos na GDC mas estivemos na Game Connection, que é um outro evento que acontece ao mesmo tempo mas é totalmente voltado para negócios. São 3 dias de “speed dating” entre publishers, desenvolvedores, provedores de serviço e qualquer um envolvido na indústria de jogos. Nesses 3 dias nós realizamos quase 50 reuniões com empresas que variam desde Microsoft, Nintendo, GameVil até empresas de anúncios e serviços de hospedagem. Mostramos nosso projeto atual, o Like a Boss pra muita gente, não só recebemos muito feedback como estamos atualmente conversando com uma baita galera interessada em trabalhar junto com a gente, e estamos bem confiantes de que graças à viagem vamos fechar negócio, provavelmente com publishing e funding envolvido, as duas coisas que estávamos procurando ao ir para o evento. Em outras palavras, é um dinheiro bem gasto. Queria só aproveitar o tópico pra agradecer a Eliana Russi, do BGD, um programa organizado pela Abragames, pois sem o apoio deles, nós não teríamos condições de participar.\nBC: Uma dica para quem está começando na área e quer fazer jogos.\nFH: Dica é o que não falta. Mas como já escrevemos uma baita muralha de texto, vamos citar as que consideramos mais importantes. Em primeiro lugar, pode parecer óbvio mas é sempre bom citar, é preciso ter MUITA dedicação e auto crítica. Fazer jogo é difícil e muito trabalhoso, e é importante sempre estar aberto a críticas e a enxergar o problema do seu produto. Nunca se de por satisfeito e sempre tente ser sincero consigo mesmo em relação à qualidade e divertimento que o game proporciona. É difícil, mas não tome as críticas que receber como algo pessoal e tente aprender com elas, porque nenhum jogo é perfeito (nem AAA) e SEMPRE vão haver pessoas que vão odiar seu jogo, assim como vão ter pessoas que vão AMAR seu jogo mais do que você mesmo. E acho que pra finalizar, minha dica é participe de eventos… esteja presente no SBGames, se você é de São Paulo tente participar do SPIN, BIG, conheça pessoas… e participe de todas as competições possíveis, pois qualquer visibilidade e prêmio são sempre muito bem vindos.\nAgora para finalizar de vez gostaríamos de agradecer a oportunidade de dar esta entrevista e espero que seja útil para alguém saber um pouco mais do caminho que trilhamos até agora, e queríamos reafirmar que seu sonho é fazer jogos, persista, insista, e se dedique porque é muito difícil, mas é possível e pra quem conseguir o prêmio é muito mais do que dinheiro, é a satisfação de saber que conseguiu, que realmente trabalha com o que ama. Abraços!\nPor fim, alguns links interessantes para você conhecer mais sobre o trabalho da Fire Horse. Eu recomendo fortemente a leitura do blog deles!\nFacebook: http://www.facebook.com/FireHorseStudio\nTwitter: https://twitter.com/firehorsegames\nYoutube: https://www.youtube.com/channel/UCjBW9MZagcQSrFUNI_QE_Ew\nBlog: http://firehorsedev.blogspot.com.br/\nSite: http://www.firehorse.com.br\n","date":"3 de abril de 2014","externalUrl":null,"permalink":"/entrevista-fire-horse/","section":"Blog","summary":"Há pouco tempo o estúdio brasileiro Fire Horse levou o prêmio de melhor jogo no evento GDWC 2013. Entrei em contato com eles e toparam fazer está entrevista contando um pouco sobre a história do estúdio.\n","title":"Entrevista: Estúdio brasileiro Fire Horse","type":"posts"},{"content":"Esta é a primeira parte de uma conversa que tive com o Gilliard Lopes, que hoje é produtor da série FIFA na Electronic Arts Canada. Conheça como ele iniciou sua carreira no Brasil, sua passagem pela Hoplon, e sua saída do país para trabalhar em uma das séries de jogos mais famosas do mundo.\nA entrevista será publicada em duas partes, sendo que esta primeira tem o foco no início da carreira do Gilliard na sua empresa Paralelo Computação e posteriormente na Hoplon, e como ele conseguiu entrar como programador na EA e depois se tornar produtor do FIFA, além de falar quais são as diferenças em se produzir jogos AAA.\nBruno Cicanci: Quando você decidiu que queria trabalhar com games e por que?\nGilliard Lopes: Fiz meu bacharelado em Ciência da Computação na Universidade Federal Fluminense em Niterói/RJ, e lá conheci outros dois engenheiros de software que tinham uma pequena empresa que estavam começando a mexer com 3D e renderização em tempo real, e eu me interessei muito sobre esse assunto. Nos juntamos e abrimos um estúdio chamado Paralelo Computação, no Rio de Janeiro, em Niterói. Durante vários anos, 1998 a 2006, vivemos de desenvolver e licenciar engines para computação gráfica em tempo real, e nosso produto mais famoso era o Fly 3D. Sempre fomos muito autodidata em games, lendo muito material de fora, pois no Brasil não havia quase nada sobre o assunto. Nesta época também fiz meu mestrado e doutorado na PUC RJ em Inteligência Artificial para Games. Participamos de todos eventos que haviam na época relacionados a games, como o WGames, que hoje se tornou a SBGames. Sempre fui gamer, mas não tinha uma ideia de que poderia me tornar desenvolver até eu e meus sócios começamos a tentar quebrar alguns mitos, estudamos muito e final a parte mais difícil foi a viabilização do negócio e fazer dinheiro com isso. Começamos a descobrir que era difícil, mas não impossível, era realmente uma questão de falta de oportunidade, pois ninguém no Brasil teve a oportunidade de estar nesse meio. Isso abriu minha cabeça, e depois da Paralelo foi trabalhar na Hoplon, por 2 anos e meio. Na Paralelo tentamos criar um estúdio de jogos para criar produções de maior porte, mas pela dificuldade de encontrar investimento acabamos indo cada um para um lado, mas sempre continuando na área de desenvolvimento de jogos.\nBC: Como foi sua experiência na Hoplon com o Taikodon?\nGL: Apesar de eu ter uma formação muito forte em programação, sempre tive interesse pela área de design de games. Na Paralelo eu já fazia este trabalho, e quando entrei na Hoplon comecei como programar e em apenas duas semanas me tornei game designer devido a uma necessidade de alguém para liderar o time de game designers. Lá foi minha primeira experiência profissional exclusivamente como game designer, e depois como produtor. Lá tive a oportunidade de trabalhar com um profissional que foi uma grande inspiração pra mim, o Marcelo Carvalho da Devworks, e aprendi muita coisa com ele. Foi uma época muito interessante, pois participei da primeira versão do jogo que foi lançada em 2008 no Brasil. Como o jogo teve seu design reinventado 3 vezes, eu tive a oportunidade de trabalhar na produção da segunda versão do jogo, que foi a primeira lançada oficialmente. Depois de ter trabalhado na maior empresa do Brasil, a Hoplon, e ter tentado meu próprio negócio, eu vi que tinha que tentar outras coisas por que aqui estavam acabando as opções, e o próximo passo foi tentar ir pra fora.\nBC: Você tinha planejado seu próximo passo fora do país?\nGL: Na verdade não. Eu não saí do Brasil por que queria, e isso é algo que me faz falta, pois estava sempre participando da indústria nacional. Eu pensei que ficaria mais tempo na Hoplon e desenvolver outros jogos, mas eu senti que já tinha esgotado o que eu podia aprender e me desenvolver, não só na empresa mas na indústria nacional. Minhas opções eram sair do Brasil e continuar trabalhando com games ou talvez usar meu conhecimento de programação em outro tipo de emprego, mas eu não estava pronto para tomar essa decisão e deixar a carreira que eu amo pra fazer outra coisa. Foi quando comecei a mandar meu currículo pra fora, fiz um lista de 108 empresas e pouco mais de 10% respondeu. Dessas, fiz entrevistas com 3 e recebi duas propostas, pra trabalhar na Ubisoft de Montreal e na Electronic Arts em Vancouver. Quando soube que a vaga na EA era pra trabalhar na franquia do FIFA, e a proposta deles era um pouco melhor, não tive dúvidas e fui pra lá, pois sempre fui muito fã de futebol. Nunca imaginei que isso poderia acontecer, mas consegui unir minhas duas paixões: fazer jogos e futebol.\nBC: Como foi deixar o país e continuar a carreira na EA?\nGL: Minha experiência na Hoplon me possibilitou sair do país e ir para a EA, desde 2008. Fiquei um tempo trabalhando como programador e depois de dois anos me tornei produtor. Minha porta de entrada na EA foi ser um programador de games, pois é muito difícil uma empresa como a EA trazer alguém de outro país para trabalhar com produção e verificar se a pessoa é certa para este trabalho apenas através de entrevistas, foi necessário um convívio e a demonstração de interesse sempre ajudando e participando do game design para mostrar que eu tinha condições de trabalhar com produção também, que foi sempre meu objetivo maior. E desde 2011 tive a oportunidade de ser produtor do FIFA na parte que eu entendo mais que é Presentation, como é chamado aqui, que envolve a computação gráfica do jogo e outros detalhes como câmera e interface com o jogador, e aos poucos cada ano eu venho ganhando um pouco mais de responsabilidade. Já no FIFA 14 fui produtor de Presentation, Rendering e Audio. Uma coisa que sempre conto é como foi minha entrevista aqui na EA. Na época estava em Florianópolis, e todas entrevistas foram por telefone. Como estava concorrendo a uma vaga de programador, eu conversei com pessoas técnicas. No dia quinta entrevista eu estava tranquilo por que já conhecia o pessoal, mas eu tive uma surpresa pois a última entrevista foi com o produtor do FIFA. Na hora eu gelei, e não imaginava que tipo de pergunta ele faria, e sua primeira pergunta foi sobre o que eu estava achando da seleção brasileira com o Dunga! Ficamos 40 minutos só conversando sobre futebol, e nada sobre desenvolvimento de games, ele só queria conversar sobre isso. Foi um momento engraçado e inesperado, e no dia seguinte recebi o contrato para trabalhar na EA. Este produtor, o Simon, foi meu mentor aqui e me apoiou nessa mudança de carreira que consegui fazer aqui dentro.\nBC: O que, na sua formação, te ajudou a trabalhar em jogos AAA?\nGL: Muito do que me ajudou foi saber que algo era possível e fazer. Desde a Paralelo eu meu sócio não buscávamos implementar o que era mais fácil, mas sim o que era mais difícil para aprender coisas mais avançadas. Muitas vezes não conseguíamos, mas a gente tentava. Na época que estava no Brasil fiz sempre projetos pessoais e estava sempre estudando coisas que fossem mais avançadas e para o lado de jogos AAA. Por exemplo, assim que saiu o UDK eu comecei a aprender tudo para ver como muitas coisas eram feitas. Muito antes disso até já conseguíamos carregar os níveis do Quake III Arena na nossa engine gráfica da Paralelo, e mesmo sendo uns dois anos depois que o jogo saiu, isso não era algo que existia no Brasil. Sempre fui muito estudioso nas áreas de computação gráfica e inteligência artificial, e isso contou muito por que na hora das entrevistas eu conseguia responder as perguntas e também tinha exemplos de código para enviar, e muitas dessas perguntas eram problemas de jogos AAA, como, por exemplo, perguntas sobre técnicas de multi-threading, que eu sabia não por ter experiência, mas por ter estudado isso. Todo esse esforço que fiz por fora de aprender valeu muito a pena para conseguir ir bem nas entrevistas, pois mesmo sem um portfolio de jogos AAA, ainda assim eu tinha muita coisa que fiz por conta própria que eram avançadas e no nível de jogos AAA. Minha experiência no Brasil foi muito boa, e me possibilitou contribuir desde o primeiro dia na EA, mesmo tendo uma experiência limitada pelas oportunidades daqui. Isso foi crucial para eu estar na EA hoje e ter subido de maneira bem rápida de programador para produtor do FIFA, comparado com outras pessoas da mesma época que eu.\nBC: Tecnicamente falando, quais são as diferenças entre um jogo AAA e um jogo indie?\nGL: Acho que independente de ser indie ou não, em projetos mais curtos e de menor investimento você geralmente não faz soluções para todo tipo de problemas. Por exemplo, vale a pena fazer um editor de níveis para um jogo que vai ter apenas 5 níveis? Acho que esta é a principal diferença, pois aqui tudo que a gente faz para o FIFA, não é para o FIFA 14, por exemplo, e sim para todos jogos da franquia que ainda virão nos próximos anos. Se você considerar que temos que lançar um novo FIFA a cada ano, temos sempre que pensar em soluções que sejam escaláveis para os próximos projetos e que não vão criar dor de cabeça depois e deixar a ferramenta inútil para outros jogos. Em jogos AAA temos uma visão de longo prazo muito maior, e também temos que ter muito cuidai com tudo. Uma linha de código que parece inofensiva pode quebrar o jogo para toda equipe, pois o jogo é muito grande, e só aqui no Canada temos 150 pessoas trabalhando exclusivamente no FIFA o ano inteiro. Hoje temos muitas ferramentas desenvolvidas durante anos para impedir que este tipo de coisa aconteça, e isso é o tipo de coisa que não se desenvolve para jogos curtos e com pouco investimento. Aqui as soluções precisam ser robustas, e funcionar bem em tudo, sempre com a visão de longo prazo. Um exemplo disso é um sistema no FIFA chamado Skill Games, que foi criado pensando em ser usado no futuro e hoje podemos reconstruir lances de jogos reais utilizando este sistema, que inicialmente foi projetado para ser apenas mini-games e testar as habilidades do jogador.\nA segunda parte trará mais detalhes sobre como é trabalhar na EA, o que estudar para trabalhar em jogos AAA, dicas para que está começando, e muito mais! Confira também o PodQuest, o podcast criado pelo Gilliard e outros dois amigos que também são brasileiros e trabalham fora do país desenvolvendo jogos.\n","date":"1 de abril de 2014","externalUrl":null,"permalink":"/entrevista-gilliard-lopes-produtor-fifa-ea-parte1/","section":"Blog","summary":"Esta é a primeira parte de uma conversa que tive com o Gilliard Lopes, que hoje é produtor da série FIFA na Electronic Arts Canada. Conheça como ele iniciou sua carreira no Brasil, sua passagem pela Hoplon, e sua saída do país para trabalhar em uma das séries de jogos mais famosas do mundo.\n","title":"Entrevista: Gilliard Lopes, produtor do FIFA na Electronic Arts Canada - Parte 1","type":"posts"},{"content":"Você consegue pensar em várias mecânicas de gameplay diferentes? Conseguiria definir o conceito de mais de 200 diferentes? No site Squidi.net atualmente estão listadas 200 exemplos de mecânica de gameplay diferentes, que podem ser utilizadas livremente por qualquer pessoa. Seu objetivo é chegar em 300 conceitos diferentes.\nPra que serve isso? O trabalho de um Game Designer é criar mecânicas e validá-las com protótipos de gameplay, pra garantir que o jogo seja divertido. Nesse site existem diversos exemplo muito bons e bem explicados de mecânicas diferentes, que podem ser misturadas ou até gerar novas idéias. É como se fosse um repositório de idéias genéricas de gameplay.\nIsso também é útil para programadores e artistas, pois ao ler sobre como uma mecânica funciona, você também entenderá o trabalho necessário para implementá-la, tanto na parte de código quando na parte de arte. Está sem idéias? Dê uma olhada no site, e novos jogos irão surgir na sua cabeça!\nSite: http://www.squidi.net/three/index.php\n","date":"26 de março de 2014","externalUrl":null,"permalink":"/200-mecanicas-de-gameplay/","section":"Blog","summary":"Você consegue pensar em várias mecânicas de gameplay diferentes? Conseguiria definir o conceito de mais de 200 diferentes? No site Squidi.net atualmente estão listadas 200 exemplos de mecânica de gameplay diferentes, que podem ser utilizadas livremente por qualquer pessoa. Seu objetivo é chegar em 300 conceitos diferentes.\n","title":"Como ser um programador de jogos: 200 mecânicas de gameplay","type":"posts"},{"content":"Este vídeo mostra a vida de um QA (Quality Assurance, também chamado de Game Tester), o cara responsável por testar o jogo e garantir sua qualidade durante a produção do game.\nJá trabalhei com muitos QAs na Glu Mobile e na Electronic Arts, e com certeza esse tipo de coisa acontece. No vídeo abaixo (audio e legenda em inglês) algumas coisas são exageradas, como o bug que aparece no vídeo com o status NMI (Need More Information), mas outras são bem realistas.\nMuita gente não dá valor ao trabalho de um QA, pois alguns pensam que eles só ficam jogando e muitos começam a trabalhar na área com este mesmo pensamento. O QA tem que jogar o jogo sim, mas em busca de problemas para que o jogo seja lançado e agrade o jogador.\nQAs também sempre devem documentar da melhor maneira possível os passos para reproduzir um bug. No vídeo aparece isso também, e em alguns casos exagerados, mas em outros não. Desenvolvedores não devem subestimar o trabalho de um QA, e um QA não deve pensar que vai ficar o dia inteiro só jogando.\nEm muitas empresas o cargo de QA é a porta de entrada para começar a trabalhar na área, por isso contratam gente sem experiência mas que tem interesse em fazer carreira na área de games. O importante é sempre ter um foco e saber para onde direcionar a carreira, mesmo que seja se tornar um QA Lead Badass. Caso tenha uma oportunidade como esta, aproveite pare aprender o máximo que puder com os desenvolvedores e logo você será um deles.\n","date":"20 de março de 2014","externalUrl":null,"permalink":"/vida-de-qa-game-tester/","section":"Blog","summary":"Este vídeo mostra a vida de um QA (Quality Assurance, também chamado de Game Tester), o cara responsável por testar o jogo e garantir sua qualidade durante a produção do game.\n","title":"Vida de QA (Game Tester)","type":"posts"},{"content":"Uma das coisas mais frustrantes para um jogador é fazer uma ação no jogo e não ter um feedback do próprio jogo informando se a ação foi realizada, ou se ele fez algo errado.\nÉ importante para um bom gameplay fornecer ao jogador um feedback para cada ação, para deixar claro se ação foi realizada com sucesso ou não.\nO feedback pode ser uma mensagem de texto, um ícone na tela ou simplesmente um som. Fornecer um feedback das ações é um detalhe que deixa o jogo mais profissional, e evita o jogador de se sentir perdido ou irritado.\nEste tipo de recurso faz parte do design de interface do jogo, pois deve ser prevista uma área para exibir o feedback para o jogador (caso seja um aviso gráfico). Um exemplo de feedback é a mensagem do windows quando você tenta apagar algo, ele pergunta se você realmente quer apagar:\nNo caso de jogos, pode ser exibido uma outra mensagem informando que a ação foi realizada com sucesso (ou não). Pode parecer chato sempre querer confirmar ações, mas isso é menos chato para o jogador do que perder algo importante no jogo por falta deste recurso.\n","date":"19 de março de 2014","externalUrl":null,"permalink":"/feedback-de-acoes-para-o-jogador/","section":"Blog","summary":"Uma das coisas mais frustrantes para um jogador é fazer uma ação no jogo e não ter um feedback do próprio jogo informando se a ação foi realizada, ou se ele fez algo errado.\n","title":"Como ser um programador de jogos: Feedback de ações para o jogador","type":"posts"},{"content":"A EPIC anunciou a que a sua game engine de ponta, a Unreal Engine 4, está disponível para todo mundo e por um preço muito justo por mês.\nAntes com acesso limitado apenas empresas grandes, agora a Unreal Engine 4 vem com tudo para ganhar o mercado da Unity. Muitos jogos AAA usam esta tecnilogia, que agora está disponível para todo mundo por $19 por mês + %5 do lucro do jogo.\nLembrando que a versão gratuita da Unity é bem limitada em comparação com a Unity Pro, que custa $1500 ou $75 por mês, ambos valores por plataforma. Já a Unreal Engine 4 tem tudo que jogos AAA usam, para Windows, Mac, Android e iOS por $19 dólares por mês + %5 do lucro do seu jogo.\nEu não sei como funciona essa história dos %5 ainda, mas assim que testar esta nova versão vou ler mais sobre isso e fazer um post. A Unity é muito boa, mas agora concorrentes grandes querem os indies também, como a CryEngine 3 da CryTech, e a Unreal Engine 4 da Epic.\nOutro detalhe interessante é que estes $19 dólares por mês também dá acesso ao código fonte em c++ da Unreal Engine 4, entre várias outros materiais legais. Uma notícia não muito boa é que a UDK (Unreal Dev Kit) não existe mais, mas a boa é que agora a Unreal Engine 4 funciona em Mac (antes era só windows) e também exporta para Android (antes era só iOS).\n","date":"18 de março de 2014","externalUrl":null,"permalink":"/unreal-engine-4/","section":"Blog","summary":"A EPIC anunciou a que a sua game engine de ponta, a Unreal Engine 4, está disponível para todo mundo e por um preço muito justo por mês.\n","title":"Unreal Engine 4 agora com preço acessível","type":"posts"},{"content":"Um artista costuma fazer a animação completa de um determinado sprite, porém nem sempre será necessário utilizar todos os frames da animação para causar o mesmo efeito.\nMesmo com sprites detalhados, nem sempre a animação precisa ter muitos frames. Por exemplo, se você reparar em um jogo de luta 2D, a animação dos golpes normais (chute e soco) é muito rápida, praticamente um frame de antecipação e um do golpe. Muitos frames mostrando o golpe em detalhes vai pesar na memória, não será percebido no jogo e vai precisar de mais trabalho do artista.\nNa imagem abaixo do jogo Street Fighter II, do Super Nintendo, podemos ver o que foi dito acima. Os dois primeiros frames são a antecipação, o frame do meio é o golpe, e os dois últimos frames é o feedback para o jogador após o golpe. Você pode conferir a spritesheet completa do Ken clicando aqui.\nEm jogos que possuem animações rápidas, quanto menos detalhes tiver é melhor. O importante é focar no que a animação deve passar, como a sensação de um golpe rápido em um jogo de luta. Vale mais a pena investir em detalhes do que em mais frames, assim o jogo fica mais bonito, menos pesado e será possível ver toda animação sem desperdiçar frames.\n","date":"5 de março de 2014","externalUrl":null,"permalink":"/boas-praticas-para-animacoes-2d/","section":"Blog","summary":"Um artista costuma fazer a animação completa de um determinado sprite, porém nem sempre será necessário utilizar todos os frames da animação para causar o mesmo efeito.\n","title":"Como ser um programador de jogos: Boas práticas para animações 2D","type":"posts"},{"content":"Uma das dúvidas mais comuns no desenvolvimento de jogos para dispositivos móveis é qual a melhor maneira para que o jogo se adapte em várias resoluções, e uma das técnicas mais usadas é a chamada Pixel Perfect, que consiste em utilizar a PPI do aparelho como base para isto.\nNeste post vou explicar como está técnica funciona usando como base os aparelhos da Apple com iOS. No Android e Windows Phone é a mesma coisa, porém eles possuem mais variações de PPI, por isso dá um pouco mais de trabalho. Aqui não vou explicar como identificar a DPI de um aparelho, e sim o uso da técnica. Lembrando que isto funciona apenas para jogos em 2D, pois em 3D é outra história.\nPPI significa Pixels Per Inch, ou seja, é o número de pixels por polegada. Isto é literalmente o número de pixels que são exibidos em uma polegada da tela, quanto maior mais detalhes se o tamanho da tela for grande também. Algumas pessoas chama isso também de DPI, que significa Dots Per Inch, ou seja, pontos por polegada. Esta atribuição é incorreta quando falamos de aparelhos digitais, pois esta medida é usada em impressões. Porém, é bem comum chamar PPI de DPI, o próprio Google chama esta medida de DPI no Android, então acostume-se a ouvir ambos.\nPrimeiro, vamos analizar a resolução e o PPI dos aparelhos da Apple. No Android a DPI é classificada como MDPI, HDPI, XHDPI, entre outros. Não vou entrar nos detalhes de classificação, pois o importante neste técnica é o valor da PPI/DPI. No caso do Android, você pode encontrar mais detalhes aqui.\niPhone 3G/3GS 320x480 163 ppi\niPhone 4/4S 640×960 326 ppi\niPhone 5/5C/5S 640×1136 326 ppi\nA PPI do iPhone 3, assim como a resolução da sua tela, é exatamente a metade da PPI do iPhone 4 e de sua tela também. Por ser exatamente metade, isto significa que se você usar uma imagem do tamanho do iPhone 4 com resize no iPhone 3, ela ficará “perfeita”, e dai vem o termo Pixel Perfect. Isto só funciona quando a PPI (ou DPI) possui esta proporção de ser metade, então nestes casos você pode usar uma imagem maior com resize para um tamanho menor sem perder a qualidade e definição.\nNo caso do iPhone 5 temos um problema, embora sua PPI seja a mesma do iPhone 4, o tamanho da sua tela é diferente e não é proporcional, pois a largura é a mesma e a altura é diferente. Uma imagem no tamanho do iPhone 5 ficará cortada no iPhone 4, pois apesar da mesma DPI não é possível fazer o resize sem perder qualidade. Isto se aplica ao iPhone 3 também, que também tem a metade da PPI do iPhone 5, mas não tem a metade da resolução. Assim, a imagem ficará distorcida.\nEstes são dois exemplos levando em conta apenas imagens com o tamanho da tela do aparelho, sendo que funciona do iPhone 4 para o iPhone 3, mas não funciona do iPhone 5 para os demais. Neste caso, muitos desenvolvedores criam uma imagem para o iPhone 5 e uma para o iPhone 4, que é usada também no iPhone 3.\nPorém, para imagens que não ocupam a tela inteira como botões ou sprites, a mesma imagem usada no iPhone 5 pode ser usada no iPhone 4 sem resize, e usada no iPhone 3 com resize mas sem perder a qualidade e definição graças a PPI. Basicamente, a regra geral é esta:\nPara imagens com o tamanho da tela:\n– Resize só funciona sem perder a qualidade se os aparelhos tiverem a PPI/DPI e o tamanho da tela proporcionais.\nPara imagens menores:\n– Resize funciona baseado apenas na PPI/DPI, o tamanho da tela pode influenciar apenas o posicionamento dos itens na tela.\nJá utilizei esta técnica algumas vezes quando trabalhei na Glu Mobile e na Electronic Arts. O jogo que mais usei isto foi o Scrabble, para Android e iOS. Todo seu layout é baseado na PPI/DPI do aparelho, e as imagens são usadas de acordo com esta classificação. Neste jogo o layout do tablet é diferente do smartphone, então não tivemos problemas com a PPI/DPI e resolução destes aparelhos, o que ajudou bastante no resultado final.\nEspero ter conseguido explicar direito esta técnica, ela é bem simples de usar e um pouco complicada de explicar. Lembre-se que este exemplo foi feito para os modelos de iPhone, que é o mais simples de todos. Aparelhos Android geralmente dão mais problemas por causa da fragmentação e falta de padrões por parte dos fabricantes, mas não é impossível fazer uso do Pixel Perfect da mesma maneira. Qualquer dúvida, fique a vontade para perguntar nos comentários abaixo!\n","date":"26 de fevereiro de 2014","externalUrl":null,"permalink":"/pixel-perfect/","section":"Blog","summary":"Uma das dúvidas mais comuns no desenvolvimento de jogos para dispositivos móveis é qual a melhor maneira para que o jogo se adapte em várias resoluções, e uma das técnicas mais usadas é a chamada Pixel Perfect, que consiste em utilizar a PPI do aparelho como base para isto.\n","title":"Como ser um programador de jogos: Pixel Perfect","type":"posts"},{"content":"The Last of Us é um jogo incrível, um marco da indústria que será lembrando como um dos melhores jogos desenvolvidos para o Playstation 3. Agora conheça como a Naughty Dog criou este game em seu documentário oficial.\nA Sony disponibilizou o documentário gratuitamente no YouTube. De entrevistas com os desenvolvedores até concepts do jogo, o vídeo de 1 hora e meia mostra como este incrível game saiu do papel e ganhou vários merecidos prêmios. Conheça as dificuldades e pressões que mesmo uma empresa grande têm para criar um jogo novo, e a responsabilidade de manter o nível de qualidade alto pela expectativa dos jogadores.\nUm alerta: se você não jogo ou ainda não terminou o jogo, verá possíveis spoilers no vídeo. Recomendo você terminar logo o jogo para assistir depois. Se o video abaixo não funcionar, clique aqui para assistir no YouTube.\n","date":"24 de fevereiro de 2014","externalUrl":null,"permalink":"/making-of-the-last-of-us/","section":"Blog","summary":"The Last of Us é um jogo incrível, um marco da indústria que será lembrando como um dos melhores jogos desenvolvidos para o Playstation 3. Agora conheça como a Naughty Dog criou este game em seu documentário oficial.\n","title":"Documentário: The Making of The Last of Us","type":"posts"},{"content":"Este ano aconteceu o primeiro Steam Dev Days, o evento fechado organizado pela Valve para desenvolvedores de jogos. Durante 2 dias muitas tecnologias novas foram apresentadas, como a Steam Machine e o controle novo.\nTodo conteúdo apresentado no evento, como as palestras e material de apoio, foram divulgados após o evento na página oficial do Steam Dev Days. Existem materiais incríveis, que vão desde o desenvolvimento de jogos para Linux até o estudo da economia de alguns jogos da Valve. Existe muito material sobre o Oculus Rift também e coisas de business.\nVale a pena conferir todo material e as palestras! O video abaixo mostra um pouco como foram estes dois dias, tomara que a Valve continue com este e evento e que ele fique tão grande quanto uma GDC.\n","date":"21 de fevereiro de 2014","externalUrl":null,"permalink":"/steam-dev-days-2014/","section":"Blog","summary":"Este ano aconteceu o primeiro Steam Dev Days, o evento fechado organizado pela Valve para desenvolvedores de jogos. Durante 2 dias muitas tecnologias novas foram apresentadas, como a Steam Machine e o controle novo.\n","title":"Steam Dev Days 2014","type":"posts"},{"content":"Com prêmios de até R$ 10.000 e algumas categorias, o BIG é um festival para jogos independentes desenvolvidos na américa latina, principalmente no Brasil.\nVocê pode participar mesmo com o jogo não terminado, pelo que entendi no site. A data para enviar o projeto é até 31 de março deste ano.\nLeia atentamente o regulamento e participe. Confira abaixo o texto sobre o evento, retirado do site deles.\nBIG é o primeiro e único festival de jogos independentes da América Latina. A cada edição, o BIG expõe os melhores jogos independentes do ano do mundo inteiro. Aspectos visuais, sonoros, narrativos e de gameplay serão levados em consideração para a seleção dos títulos expostos.\nAlém dos prêmios que serão dados aos melhores jogos, todos os jogos finalistas estarão disponíveis para serem jogados durante o festival. Alguns deles também estarão disponíveis online. Não perca a oportunidade de participar do BIG Festival.\nQuanto mais eventos seus jogos participarem, melhor será para ele ficar conhecido e você ganhar experiência e feedback\n","date":"18 de fevereiro de 2014","externalUrl":null,"permalink":"/big-festival-jogos-indie/","section":"Blog","summary":"Com prêmios de até R$ 10.000 e algumas categorias, o BIG é um festival para jogos independentes desenvolvidos na américa latina, principalmente no Brasil.\n","title":"Participe do BIG, o festival de jogos independentes da américa latina","type":"posts"},{"content":"Muita gente acha quem trabalha com games fica jogando o dia inteiro. Isto é verdade, jogamos muito o projeto em que trabalhamos, mas também precisamos jogar outras coisas para ter novas ideias.\nÉ incrível como, com o passar o tempo, quanto mais você desenvolve games, mais seu olhar fica atento a detalhes em um jogo. Não estou falando disso no sentido de falar mal de um jogo ou ficar achando defeitos, mas sim no sentido de aprender observando o jogo.\nPor exemplo, você pode estar desenvolvendo um jogo em que uma determinada mecânica da jogabilidade não está muito boa. Neste caso, você pode jogar jogos que tenham a mecânica parecida e tentar entender como o seu problema foi resolvido neste jogo. Este é um dos benefícios de jogar tentando entender como o jogo foi feito, mas existem outras formas de aprender com games.\nJogar tipos diferentes de jogos, que você normalmente não está acostumado, pode te ajudar muito a aprender novas mecânicas de jogabilidade e até ter novas ideias para interface e HUD. É possível aprender e ter ideias para seus próprios projetos jogando desde games AAA hardcore para consoles até jogos sociais de Facebook e mobile. Mesmo que você não goste do jogo, ou não seja o seia tipo de jogo, jogue para extrair novas experiências que você pode proporcionar aos seus jogadores.\nSe você quer aprender mesmo observando outros jogos, tente fazer isto: pegue um jogo que você não gosta e acha que tem muitos defeitos e tente melhorá-lo. Você irá, pelo menos, analisar o jogo, escrever um GDD para definir o game design e programar um protótipo para validar a jogabilidade. Se realmente você conseguiu melhorar o jogo seu aprendizado foi muito grande durante o processo. Basicamente, não critique se você não puder fazer melhor.\nNão esqueça também de aprender com os famosos glitches, como no vídeo abaixo. Tentar entender uma mecânica para aproveitar em uma ideia é algo simples comparado com tentar entender como um determinado glitch acontece e por que.\n","date":"12 de fevereiro de 2014","externalUrl":null,"permalink":"/jogue-bastante-mas-jogos-diferentes/","section":"Blog","summary":"Muita gente acha quem trabalha com games fica jogando o dia inteiro. Isto é verdade, jogamos muito o projeto em que trabalhamos, mas também precisamos jogar outras coisas para ter novas ideias.\n","title":"Como ser um programador de jogos: Jogue bastante, mas jogos diferentes","type":"posts"},{"content":"O terceiro livro da série americana Introdução ao Desenvolvimento de Games, publicado em português no Brasil pela editora Cengage Learning, trata a criação e produção audiovisual em jogos.\nSteve Rabin, o editor do livro, reuniu outro grande time de profissionais da indústria de jogos AAA para tratar de um assunto que interessa muito aos artistas, mas que também é essencial aos programadores de jogos, que é a parte visual e sonora do jogo. Confira a review do volume 1 e do volume 2 que fiz no blog também.\nEste livro não vai te ensinar a modelar, desenhar, animar, criar efeitos especiais e compor trilhas sonoras para jogos, mas vai te dar uma base muito importante para entender como estas coisas são feitas em jogos. Assim como os dois volumes anteriores, este livro é a base e o ponta pé inicial para se aprofundar no assunto que você quiser trabalhar com games.\nUm dos capítulos mais legais para mim, que sou programador, é o primeiro que explica conceitos básicos de design visual e ensina alguns truques para montagem de interface, como linhas guia para simetria e sugestões de interface. Por ser programador, eu não preciso me aprofundar neste assunto, mas é muito útil conhecer e ter esta base, isso faz muito diferença na hora de desenvolver um jogo e conversar com um artista.\nOs capítulos seguintes tratam de modelarem 3D, ambientes, mapeamento de textura, efeitos especiais e animação. Novamente, são aparentados conceitos básicos mas que ajudam muito. Eu, por exemplo, me senti nas minhas aulas da pós-graduação que fiz em games, pois também tive este conteúdo lá e desta mesma forma, apenas o necessário para trabalhar com games.\nMuita gente acha que programar jogos em 3D são difíceis ou mais pesados do que jogos 2D, e em muitos casos não tem diferença ou é até mais fácil dependendo do jogo. Entender como a parte artista disso funciona ajuda a perder o medo de programar, além de saber exatamente o que esperar de um artista para colocar no jogo, e também como pedir alterações quando algo estiver errado no modelo ou animação 3D.\nPor fim, temos um capítulo que trata um assunto que eu gosto bastante, a produção musical de uma jogo. Uma música no fundo é importante para a imersão no jogo, mas efeitos sonoros são igualmente importantes para o feedback da mecânica do jogo. O game designer deve pensar neste tipo de feedback sonoro no jogo, porém o músico que deve criar o som mais adequado.\nAlguns conceitos básicos de design de áudio e até mesmo dublagem em jogos são apresentados, e no final existem capítulos com dicas mais profissionais, até mesmo discutindo a diferença entre usar um PC ou um Mac para a produção musical em jogos.\nEstá tem se tornado a minha série de livros favorita lançada no Brasil, principalmente por ter sido desenvolvida por um tipo de profissionais da indústria que trabalham com jogos AAA. Muito obrigado novamente a editora Cengage Learning por tem enviado o livro! Este volume, assim como toda coleção, esta disponível em várias livrarias e no site da editora.\nSiga a Cengage Learning no Facebook e no Twitter para ficar por dentro dos lançamentos da editora.\n","date":"11 de fevereiro de 2014","externalUrl":null,"permalink":"/introducao-ao-desenvolvimento-de-games-volume-3/","section":"Blog","summary":"O terceiro livro da série americana Introdução ao Desenvolvimento de Games, publicado em português no Brasil pela editora Cengage Learning, trata a criação e produção audiovisual em jogos.\n","title":"Introdução ao desenvolvimento de games, volume 3","type":"posts"},{"content":"O novo filme Frozen, da Disney, utiliza uma nova tecnologia criada pela Disney para simulação de neve, e o resultado é impressionante! Agora, imagine este tipo de tecnologia em jogos da nova geração?\nO video neste link contém uma apresentaçõa e algumas explicações técnicas de como a neve foi recriada, e mostra todas as possibilidades para tipos diferentes de neve. Efeitos assim são pesados para calcular em tempo real, por isso geralmente são usados apenas em cut-scenes pré-renderedizados.\nPorém, com o poder de processamento dos novos consoles Playstation 4 e Xbox One, esta realidade pode estar cada vez mais perto. Um exemplo disso são os detalhes do jogo Shadow of Mordor (video abaixo), que possui diversos detalhes antes não possíveis nos video games, como o movimento da capa mais realista.\nImagine só um jogo como Lost Planet ou Dead Space usando esta tecnologia da Disney em tempo real? Na verdade, nem precisa ser um jogo com neve, pois esta técnica pode ser aplicada em qualquer tipo de partícula, o problema é saber o quanto um console vai aguentar renderizar em tempo real.\n","date":"6 de fevereiro de 2014","externalUrl":null,"permalink":"/tecnologia-disney-neve-frozen/","section":"Blog","summary":"O novo filme Frozen, da Disney, utiliza uma nova tecnologia criada pela Disney para simulação de neve, e o resultado é impressionante! Agora, imagine este tipo de tecnologia em jogos da nova geração?\n","title":"Tecnologia da Disney usada para fazer neve em Frozen","type":"posts"},{"content":"Sem dúvidas um dos principais problemas que a maioria dos desenvolvedores enfrentam é a falta de tempo para se dedicar em um projeto, mas isso o pode ser amenizado com umas dicas para otimizar seu tempo.\nTudo que esta escrito neste post eu aprendi com o tempo e experiência. Algumas coisas deram certo pra mim e algumas para outras pessoas, por isso a melhor dica que posso dar é tentar sempre encontrar alguma forma de melhorar o uso do seu tempo, pois sem isso você já está perdendo um tempo que poderia estar trabalhando no seu jogo.\nUma das primeiras coisas que testei foi a técnica Pomodoro (Pomodoro Technique), que consiste em se concentrar por um tempo e depois descansar alguns minutos. Por exemplo, você pode trabalhar sem parar por 25 minutos e depois faz uma pausa de 5 minutos para fazer o que quiser, e depois continue repetindo este ciclo várias vezes. O tempo de descanso pode variar, mas o de trabalho não.\nExistem várias maneiras de usar esta técnica, a minha preferida é esta extensão para o Chrome chamada Strict Workflow. Ele conta o tempo de trabalho e descanso e também bloqueia seu acesso a sites que você quiser durante os 25 minutos. Eu, pessoalmente, não consegui me adaptar para trabalhar usando esta técnica, pois as vezes estou concentrado e não quero parar meu tempo para descansar. Porém, para estudar funciona muito bem.\nOutra forma de organizar seu tempo é criando uma lista de tarefas e colocando prazos. Esta parte é muito importante, coloque prazos e planeje sua semana. Eu utilizo o Any.Do, que é um aplicativo mobile com uma extensão para Chrome também. Nele listo as tarefas que tenho que fazer e coloco datas e alarmes para me lembrar. Funciona muito bem para tarefas do dia-a-dia que você tem que lembrar e fazer, mas para trabalhar eu prefiro usar outra coisa.\nEu senti uma necessidade de organizar os posts do blog, porém o Any.Do não funcionou na maneira que eu queria para isto. Então, decidi usar o Google Calendar, e até hoje funciona muito bem. Eu planejo os posts todas as semanas, e me cobro para escrever e postar nos dias certos. Se você acompanha o blog há um tempo pode perceber que nos útimos meses eu comecei a postar com muito mais frequência, e foi graças a minha organização no Google Calendar.\nNo trabalho também utilizo o Google Calendar para colocar prazos de cada projeto, mas não das tarefas relacionadas ao projeto em si.Lembre-se que neste post não estou falando em organização de projetos, que utilizo outros recursos como o Trello. Estou falando de como eu organizo meu tempo e minhas tarefas no dia para conseguir fazer tudo que preciso e quero. O foco é muito importante para que todo seu planejamento dê certo, e você precisa estar motivado para conseguir realizar todas as suas terefas.\nPara meus projetos pessoais eu geralmente sou mais produtivo a noite, porém as vezes chego cansado do trabalho e sem vontade de fazer outra coisa. Nessa hora eu busco me distrair um pouco jogando ou assistindo algo, e depois eu começo a trabalhar. Isso funciona muito bem para mim, principalmente com jogos, pois eu perco até o sono. O único problema é que as vezes você pode acabar jogando até tarde e esquece de trabalhar, mas isso não é algo ruim se acontecer as vezes, afinal a gente merece descansar também!\nNo final de semana eu durmo até tarde, vou passear, jogo, assisto séries e filmes e tento trabalhar em meus projetos pessoais, porém sem a cobrança que me faço durante a semana. Por isso, sempre fazemos estas coisas juntos, mesmo que cada um tenha que fazer algo diferente. E funciona muito bem, pois a companhia dela é demais todos os dias =)\nPor mim, nada disso funciona sem um elemento primordial: Música! Eu só consigo me concentrar com música, por isso uso no escritório um fone gigante que isola o som externo (este aqui da Philips), é muito bom e recomendo! Eu geralmente ouvia trilha sonora de filmes e jogos no Youtube (procure por OST), até fiz esta playlist com algumas que mais gostei, mas agora estou ouvindo tudo no rdio, que é fantástico. O vídeo abaixo é uma coletânea de músicas épicas, este é o meu preferido da minha playlist.\nOutra coisa que faço para otimizar meu tempo é tentar fazer coisas em qualquer lugar. Por exemplo, eu leio e respondo emails no caminho para o trabalho. Quando estou em algum lugar esperando uso meu tablet para escrever algum post ou organizar minhas terafas. Quando preciso me concentrar, mas não aguento ficar em casa ou no escritório, vou para um café e levo meu tablet. Também leio bastante notícias da indústria e livros de fantasia para relaxar, quando não estou jogando no celular ou no tablet.\nExistem muitas outras ferramentas para organizar seu tempo, e muitas técnicas para te manter focado. O que escrevi aqui é o que funciona comigo, mas para você pode ser diferente. Se tiver alguma recomendação fique a vontade para postar nos comentários. É importante focar, mas também saiba aproveitar os momentos para relaxar e não deixe de fazer as coisas que você tem vontade.\n","date":"22 de janeiro de 2014","externalUrl":null,"permalink":"/gerenciamento-do-seu-tempo/","section":"Blog","summary":"Sem dúvidas um dos principais problemas que a maioria dos desenvolvedores enfrentam é a falta de tempo para se dedicar em um projeto, mas isso o pode ser amenizado com umas dicas para otimizar seu tempo.\n","title":"Como ser um programador de jogos: Gerenciamento do seu tempo","type":"posts"},{"content":"Neste postmortem conheça o jogo independente brasileiro Cat-Fly para Android e conheça os desafios enfrentados pelo desenvolvedor Cláudio Rainho para publicá-lo.\nComo escrevi neste post, se você não publicou um jogo, você não fez um jogo. Apenas um jogo publicado tem uma história para contar em um postmortem, e só assim um desenvolvedor aprende todo ciclo de vida de um jogo como um produto. Leia abaixo o texto enviado pelo Cláudio e veja mais um exemplo de que não é fácil criar um jogo, e que publicar faz parte do processo.\n1. Descrição do Jogo\nCat-Fly é um game casual desenvolvido para Android, o jogador pode escolher dentre vários gatinhos o seu preferido, a base dos acontecimentos do jogo acontece em volta de uma situação inusitada, o seu gatinho bebeu um leite um tanto quanto ruim e a dor de barriga apertou, ele corre para o banheiro mas algo estranho acontece, o banheiro ” Explode ” e o seu gatinho sai voando pelos ares, voe o mais alto possível com seu gatinho ” até mais alto que a Lua”\nMecanica do jogo.\nA mecânica é simples você movimenta o seu gato de um lado para outro, precisa apenas recolher moedas e desviar de objetos que estão caindo, você possui um arsenal de powerUps que vão ajudar você a ir o mais alto possível. Dentro do jogo é possivel, comprar personagens, poderes e fases.\nO jogo esta disponível gratuitamente na PlayStore para Tablets e Smartphone com Android. Baixe o jogo aqui: https://play.google.com/store/apps/details?id=com.crgamestudio.tut.catflyfree.\n2. Dificuldades e Problemas\nDesempenho Bom, quem desenvolve para dispositivos sabe bem como isso é complicado,em Cat-Flyexistem objetos que se quebram, existem muitas partículas,e eu queria boas texturas com objetos 3D, no começo foi dificil adaptar o jogo para celulares moveis, dive que diminuir muito a qualidade dos objetos, as resoluções das texturas, e tirar objetos do jogo, tive que remodelar objetos das cenas diversas vezes, deus sabe o como isso foi cansativo, mas no final o jogo ficou razoável, porem não como eu esperava.\nDesenvolver sozinho. Eu particularmente gosto de fazer sozinho, mas não posso negar que isso da um trabalhão, eu como desenvolvedor indie não sei tudo e tudo que sei não é 100% mas nesse jogo tive quetrabalhar como tudo, desde desenho,animações,programação até a edição de áudio, o que mais me deu trabalho foi os efeitos sonoros e as musicas, e vou aproveitar o espaço para dar uma dica, porque tive dificuldade de achar bons efeitos sonoros e musicas que de fato fosse gratuitas, mas achei um site que permite a comercialização dos sons disponíveis nele, o nome do site é freesound.com, outros problemas em relação a trabalhar sozinho é o fato de que com o tempo você passa a odiar o seu jogo de tanto que teve que testa ele, mas faz parte.\nResoluções de aparelhos. Eu estou desenvolvendo para Android faz pouco tempo mas, o que mais me deu trabalho foi trabalhar com resoluções,os aparelhos Android possuem uma grande variedade de resoluções e isso atrapalha um pouco,então tive que limitar meu jogo para aparelhos com uma tela maior ou igual a 4″, agora para o próximo projeto eu estou mais preparado para lidar com as resoluções .\nPublicidade Esse sim é um grande problema, eu como desenvolvedor independente sou um tremendo de um durango, não tenho recursos financeiros para investir em propaganda, então a parte de publicidade do jogo foi um grande problema,minha unica solução foi recorrer as redes sociais, entrei em todos os foruns e grupos relacionados a jogos e android, e divulguei neles mas isso me consumiu um bom tempo, e ainda sim não vai dar um retorno satisfatório, é como o meu pai sempre fala “Propaganda é a alma do negocio” eu demorei para entender isso.\n3. Pontos Positivos\nAprendizado O Aprendizado foi sem duvida o maior ponto positivo, aprendi tantas coisas novas nesse jogo que me sinto pronto para fazer outro jogo e melhor, atualmente eu tenho apenas dois jogos lançados oficialmente, mas dezenas espalhados pela internet, mas é possível reparar a evolução que tive de um jogo para outro foi incrível,em Cat-Fly eu me desafiei em algumas mecânicas do jogo,coisas que deram um trabalho danado mas foi incrivelmente proveitoso e o fato de ter ganhando experiência,, agora posso ver claramente os erros que cometi no primeiro e ja vejo outros erros que cometi no Cat-Fly e esses erros serão evitados nos próximos projetos.\nSatisfação Pessoal Sem duvidas a Satisfação Pessoal é grande, eu desenvolvo games desde os meus 13 anos mas nunca fiz nada completo, agora com o segundo jogo lançado na PlayStore me sinto ótimo e pronto para outro.\nNovas Ideias O que Cat-Fly mais rendeu foi novas ideias, o desenvolvimento do jogo me obrigou a pesquisar diversas coisas que me geraram um bom conhecimento e bagagem para um próximo game também relacionado a animais, e a experiencia que eu tivo junto com os conselhos que recebi, estou convencido a investir meu tempo em um projeto mais comercial, seguindo a tendencia, infelizmente não posso falar dele mas quem quiser ficar por dentro é só curtit essa pagina nofacebook: https://www.facebook.com/crgamestudio\nDownload do Cat-Fly FREE\nhttps://play.google.com/store/apps/details?id=com.crgamestudio.tut.catflyfree\nPara finalizar,quero agradecer o ao Bruno Cicanci, muito obrigado pelo espaço e oportunidade e agradeço a todos que leram.\nClaudio Rainho\nEsta é uma sessão do blog dedicada a mostrar exemplos de pessoas que conseguiram tirar sua ideia do papel e fizeram um jogo, o texto é escrito pelo desenvolvedor e publicado aqui da mesma maneira que recebo. Se você já publicou um jogo e tem interesse de contar como foi o processo de desenvolvimento entre em contato para saber mais sobre o postmortem.\n","date":"21 de janeiro de 2014","externalUrl":null,"permalink":"/postmortem-cat-fly/","section":"Blog","summary":"Neste postmortem conheça o jogo independente brasileiro Cat-Fly para Android e conheça os desafios enfrentados pelo desenvolvedor Cláudio Rainho para publicá-lo.\n","title":"Postmortem: Cat-Fly","type":"posts"},{"content":"Em primeiro lugar, peço desculpas por não ter postado nesta série nas últimas semanas. Mas agora eu voltarei a publicar semanalmente, toda quarta-feira, e no primeiro post deste ano começo com a pergunta: você já fez um jogo?\nQuase todo mundo que fala que já fez um jogo, na verdade nunca fez um jogo. Fazer um jogo envolve criar o conceito, desenvolver e publicar para o mundo conhecer seu projeto e jogar. E, infelizmente, muitas pessoas não chegam a publicar seu jogo. Quando eu falo publicar, não é necessariamente vender o jogo em alguma loja virtual. Publicar é apenas tornar público, ou seja, colocar em algum site um link para as pessoas baixarem e compartilhar esta informação com seus amigos.\nGeralmente, o principal objetivo em desenvolver um jogo é divertir as pessoas. Existem diversos livros como o Homo Ludens e Regras do Jogo que falam da importância dos jogos na sociedade, e não há nada mais satisfatório do que ver uma pessoa jogando algo que você desenvolveu. É por isso que entrei nesta área, e é isso que me deixa apaixonado em criar jogos e experiências para as pessoas fugirem da sua realidade e se divertirem.\nNão faz sentido fazer um jogo e não divulgar para todos jogarem. Você pode fazer diversos jogos, mas uma pessoa que fez e publicou um único jogo tem um diferencial maior que o seu para trabalhar em uma empresa de jogos. Publicar um jogo também é tornar seu portifólio público, e se você quer trabalhar com jogos isto é essencial. Não importa se você acha que não vai fazer dinheiro com o seus primeiros jogos, você tem que publicar para começar a receber feedback das pessoas e validar se você está indo para o caminho certo.\nPortanto, se você desenvolveu jogos e não publicou nenhum deles, você NÃO fez um jogo. E isso vale para toda forma de arte, se você não divulgar o que você faz para as pessoas verem e darem seu feedback, você não pode se considerar um artista. Não seja tímido e não tenha vergonha, mostre para o mundo seu trabalho, e então você poderá falar que faz jogos.\nO meu portfólio está desatualizado desde que terminei a minha pós-graduação em 2010, então lá não estão os jogos que desenvolvi na Glu Mobile, Electronic Arts e freelances. Em breve vou montar uma página nova para mostrar todos os jogos que participei do desenvolvimento, mas por enquanto vocês podem ver o meu portfólio aqui.\n","date":"15 de janeiro de 2014","externalUrl":null,"permalink":"/voce-ja-fez-um-jogo/","section":"Blog","summary":"Em primeiro lugar, peço desculpas por não ter postado nesta série nas últimas semanas. Mas agora eu voltarei a publicar semanalmente, toda quarta-feira, e no primeiro post deste ano começo com a pergunta: você já fez um jogo?\n","title":"Como ser um programador de jogos: Você já fez um jogo?","type":"posts"},{"content":"A série Introdução ao desenvolvimento de games da editora Cengage Learning possui 4 volumes traduzidos e publicados no Brasil, e neste post vou falar sobre o Volume 2: Programação: técnica, linguagem e arquitetura.\nEu tive uma feliz surpresa ao ler o primeiro volume desta série sobre game design, que você pode conferir aqui. E neste segundo volume foi diferente, a surpresa foi ainda maior! O livro, organizado pelo Steve Rabin, contou novamente com a colaboração de diversos profissionais da indústria de games AAA.\nPor isso, muitos assuntos abordados no livro são tratados com a visão de desenvolvedores de jogos AAA, bem como suas preocupações e técnicas. Não podemos deixar de lembrar que este livro é uma introdução à programação de jogos, então muitas coisas são bem básicas. Alguns assuntos parecem empolgantes no sumário, mas o conteúdo é bem básico e as vezes tem apenas um parágrafo. Porém, isso não diminui o valor do livro, que deve ser lido como um primeiro passo para trabalhar com jogos profissionalmente.\nO livro é divido em três partes, e a primeira trata linguagens de programação e arquitetura. Embora as demais partes sejam muito importantes, esta primeira é a que faz toda diferença neste livro. Design patterns são explicados com exemplos em jogos, e inclusive com vantagens e desvantagens de cada padrão e a parte de arquitetura é algo que eu busquei em muitos livros e apenas neste encontrei uma forma clara de explicar alguns tipos principais para jogos.\nExiste também um capítulo inteiro sobre gerenciamento de memória, que é importante mas existem muitos livros sobre isso. O mais impressionante pra mim, que é essencial para qualquer programador, é um capítulo dedicado a depuração de código, ou debug. Eu achei incrível por que o livro apresenta diversas técnicas que eu aprendi nos anos que trabalhei na Electronic Arts e na Glu Mobile, e isso tudo aprendo sozinho ou alguém me explicou, nunca tinha lido um livro que tivesse este tipo de informação. Em muitos casos, não basta apenas saber programar, tem que saber resolver problemas no código.\nSobre esta primeira parte tenho dois comentários negativos. Em alguns momentos a tradução e a revisão deixaram passar textos sem sentido, como “reinicializarão a quente”, que não é explicado. Outro ponto é sobre uma parte do conteúdo que fala sobre C++ como sendo algo muito difícil de usar e apresenta o Java como uma solução incrível que a indústria estaria adotando por ser mais fácil. Isso não é verdade, pois por mais que jogos Indie como o Minecraft usem, jogos AAA e de iOS sempre são feitos em C++ (ou Objective-C no caso do iOS) pela vantagem de usar o mesmo código em mais de uma plataforma. Não faz sentido usar Java se você quer publicar seu jogo em mais plataformas, use sempre C++ e não tenha medo de aprender a programar com esta linguagem.\nA segunda parte sobre matemática e física é também uma ótima introdução, pois muitas coisas são apresentadas bem resumidas, porém com explicações de uso em jogos. Por mais que seja básico, vale a pena entender como usar essas coisas em jogos antes de se aprofundar com outros livros mais direcionados. O capítulo sobre detecção de colisão merece um bom destaque, pois está é uma técnica muito usado e sempre da problemas.\nPor fim, na terceira parte, temos assuntos mais avançados como inteligência artificial, gráficos, áudio e rede. Aqui está outra parte diferenciada do livro, o capítulo sobre computação gráfica e principais técnicas. Este capítulo é uma introdução e um resumo de muita coisa essencial, que é o funcionamento da pipeline gráfica e como tudo é renderizado pelo hardware. Ler este capítulo pode te fazer entender muitos problemas que acontecerão na programação do seu jogo, mas não deixe de se aprofundar no assunto com outros livros.\nA inteligência artificial tem dois capítulos, um fala de maneira geral e até resumido demais, porém o outro é dedicado a principal técnica usada em jogos, o path finding. Entendendo como usar esta técnica, você provavelmente mudará muitas coisas no seu código para melhorar a inteligência dos seus NPCs. Existem muitos livros bons sobre este assunto, mas está é uma ótima introdução também.\nO capítulo final é algo que muitos programadores fogem, pois temem até mais do que física e inteligência artificial ou acham que é muito fácil, que é programação em rede. Prever e otimizar um código para um hardware já é algo complexo, agora fazer isso em rede é ainda mais complicado, pois existem coisas impossíveis de prever, mas que necessitam de um código flexível e robusto. Programar em rede é mais do que enviar e receber pacotes com dados, e muitos conceitos e técnicas sobre este assunto são tratados nesta parte final do livro. Fiz um jogo em rede uma vez na pós-graduação, e foi ao mesmo tempo divertido e complicado.\nSe você leu o post inteiro vai perceber que este é um livro essencial para qualquer programador que quer desenvolver jogos. Ele é básico como o primeiro livro da série, mas para começar a entender como é programar jogos é perfeito, e este é o foco do livro. Mesmo quem já trabalha na área pode aproveitar muito do livro, pois todo conteúdo foi produzido por pessoas que trabalham na indústria de jogos lá fora, que é bem diferente daqui. Muito obrigado a editora Cengage Learning por me enviar este volume!\nSiga a Cengage Learning no Facebook e no Twitter para ficar por dentro dos lançamentos da editora.\n","date":"14 de janeiro de 2014","externalUrl":null,"permalink":"/introducao-ao-desenvolvimento-de-games-2/","section":"Blog","summary":"A série Introdução ao desenvolvimento de games da editora Cengage Learning possui 4 volumes traduzidos e publicados no Brasil, e neste post vou falar sobre o Volume 2: Programação: técnica, linguagem e arquitetura.\n","title":"Introdução ao desenvolvimento de games, volume 2","type":"posts"},{"content":"Enfim chegamos a 2014, um ano com eleições, copa do mundo no Brasil, novos consoles e muitas oportunidades para desenvolvedores de jogos!\nAno passado escrevi este post falando sobre como seria 2013 para os desenvolvedores independentes, e muitas das coisas que escrevi lá já passaram e não fizeram muita diferença. O OUYA, por exemplo, não cresceu como todo mundo esperava, e os novos sistemas operacionais para dispositivos móveis também não cresceram, como era esperado da mesma forma.\nNeste post quero falar de oportunidades, pois este ano estamos repletos de coisas para explorar. Por exemplo, vamos ter eleições e provavelmente mais manifestações pelo Brasil. E o que isso tem haver com desenvolvimento de jogos? Oportunidade para fazer jogos criativos! Um ótimo exemplo disso é o jogo “V de Vinagre” que a Flux Game Studios fez na época das manifestações, eles pegaram um detalhe da manifestação (o uso de vinagre para não sentir o efeito de gás lacrimogêneo) e fizeram um jogo em cima disso! No video abaixo você pode conhecer o jogo, que começou como uma brincadeira e acabou fazendo tanto sucesso que eles portaram para OUYA e levaram na Brasil Game Show.\nAcredito que não faltarão inspirações para fazer jogos baseados em casos relacionados a eleições e manifestos. Lembre-se que jogos são uma forma de arte, e como tal podem ser usados para expressar ideias de forma criativa e divertida. O “V de Vinagre” é um bom exemplo de crítica com bom humor!\nA copa do mundo também é uma ótima oportunidade de explorar com jogos e aplicativos temáticos. Muitas empresas estão fazendo aplicativos e jogos com o tema da copa do mundo, mas nem todas estão pensando nas pessoas fora do Brasil. Estes aplicativos e jogos não precisam ser feitos apenas para quem vem assistir os jogos. O mundo vai estar pensando em copa do mundo, então qualquer coisa que ajude esta imersão será bem popular!\nÉ sempre bom estar por dentro das coisas que estão acontecendo no Brasil e no mundo. Todo mundo já deve ter ouvido falar de algo que fez sucesso por aproveitar uma boa oportunidade na hora certa, então fique atento e seja criativo.\nDois novos consoles chegaram ao mercado ano passado, o Xbox One e o Playstation 4, e com eles os desenvolvedores tem duas novas plataformas e os jogadores dois novos objetos de desejo. Ter um código cross-platform já era muito importante, e está cada vez mais indispensável! Hoje uma empresa tem que pensar em dois conjuntos de plataformas: móvel (iOS, Android, Nintendo 3DS, PSVita, Windows Phone) e desktop (Windows, Mac, Linux, Xbox 360, Xbox One, Playstation 3, Playstation 4, Nintendo Wii U, Steam Machine). Com excessão de algumas licenças que não podemos ter no Brasil diretamente ou que exigem uma empresa por trás, temos mais de 10 plataformas distintas para explorar!\nNão faltam oportunidades, tecnologias e plataformas para criar jogos, mas não se esqueça de sempre estudar sobre o assunto, principalmente conteúdo de fora como livros e palestras, geralmente gravadas e colocadas no youtube. Fique atento também aos eventos que acontecerão pelo mundo, pois mesmo que não seja possível ir, muito conteúdo dos eventos são divulgados pela internet, e alguns deles são possíveis acompanhar online.\n","date":"2 de janeiro de 2014","externalUrl":null,"permalink":"/um-ano-de-oportunidades/","section":"Blog","summary":"Enfim chegamos a 2014, um ano com eleições, copa do mundo no Brasil, novos consoles e muitas oportunidades para desenvolvedores de jogos!\n","title":"2014, um ano de oportunidades para os desenvolvedores de jogos","type":"posts"},{"content":"Depois de alguns postmortems de jogos digitais enviados pelos desenvolvedores, este é o primeiro de um jogo de tabuleiro e mostra algumas diferenças na criação de um jogo analógico.\nEste é o segundo postmortem de um jogo desenvolvido pelo Maurílio Eudes Okamoto, que já tinha me enviado o postmortem do seu jogo Sou Sustentável. Confira abaixo o que deu certo e errado na criação deste jogo analógico. No final do texto há o link para download do jogo, é só imprimir e jogar!\n1. Descrição do Jogo\nÉ um jogo de tabuleiro, onde você se torna um skatista profissional e é um participante finalista de uma competição de skate. O jogo consiste em uma fase de treinamento rápido, na qual abrange analisar o skatepark e escolher quais manobras você irá usar na competição. Na segunda fase a de competição propriamente dita. Cada jogador tem o seu turno, onde escolhe-se em qual direção irá tomar dentro do skatepark, qual será o local onde o jogador irá usar as manobras e como irá combiná-las.\n2. Dificuldades e Problemas\nDefinição do Tema\nEsse projeto fez parte de um projeto da faculdade, com isso tínhamos quatro limitações, o projeto deveria ser de tabuleiro/cartas, com o tema esporte, prazos de entrega e o jogo deveria ser útil, tentar passar algo através do jogo para os jogadores.\nO maior dificuldade inicial era a utilidade do jogo. Entre idéias e discussões, chegamos a começar fazer um jogo sobre Tiro Esportivo, onde iríamos mostrar as regras, curiosidades e passar que o esporte não é algo ligado a violência apesar de usar armas.\nPorém um dos responsáveis pela idéia acabou desistindo do curso e a utilidade do jogo na prática estava ficando meio duvidosa. Decidimos voltar para uma idéia que sugeri no começo, na qual era sobre skate usando cartas. A utilidade ficou definida como ensinar algumas regras, manobras, combinações e uma abstração de uma competição.\nEquipe\nManual do Skate não foi uma exceção, assim como muitas equipes recém criadas houve também problema com a equipe. A saída de um dos membros da equipe foi o primeiro, ele era um dos que mais ajudava. Um segundo membro não ajudava em nada. E por fim os outros dois tentavam ajudar, porém a qualidade não estava ficando boa.\nCom isso no fim tive que fazer toda parte gráfica também, na qual era responsabilidade dos outros membros. Minha parte era inicialmente o Game Design.\nPrazo e Conseqüências\nCom o troca troca de tema, acabamos perdendo muito tempo e o prazo ficou apertado. Com isso acabamos não fazendo muitos testes de mecânica e a versão final ficou com alguns ajustes pendentes.\nUm dos ajustes pendentes foi o tamanho do tabuleiro, como o jogo era praticamente só de cartas, decidimos fazer uma caixa pequena, com isso tabuleiro ficou pequeno. É um pouco difícil de ler os escritos dele, porém dava para ter aumentando os escritos sem aumentar o tabuleiro, mas isso acabou ficando de lado para dar prioridade a outros problemas.\nE o outro ajuste pendente é que demora um pouco para chegar o próximo turno de cada jogador. Como o jogo é para um total de 5 pessoas e cada um tem que ficar pensando qual lugar vai ir, quais manobras e combinações vai fazer, isso demora um pouco.\nOutros Problemas\nTempo de jogo, o jogo estava demorando cerca de 2 horas e isso é bastante num jogo voltado a utilidade. Porém conseguimos arrumar isso, descartando metade da mecânica. Ela era inicialmente mostrar toda carreira de um skatista até chegar na primeira competição. No final ficou apenas a competição.\nQualidade da Gráfica, a gráfica que fomos imprimir o jogo para apresentar depois, fez um trabalho bem ruim. Escolhemos ela pois, estávamos sem tempo, a gráfica tinha prazo de entrega rápido e aparentemente não era cara. Porém, as cartas ficaram todas tortas e não só as cartas com o todo resto ficou mal cortado. Com algumas reclamaçõe s o resultado ficou mediano, estava “bom” pelo tempo que eles levaram para fazer tudo, menos de um dia.\n3. Pontos Positivos\nNova Experiência\nDesde que comecei a fazer jogos, a cerca de 2 anos, não tinha pensando em fazer jogos de tabuleiro, acabou sendo uma boa experiência. Apesar de ambos serem jogos tabuleiro e eletrônicos, é um pouco diferente na hora de criar, principalmente pelo fato da interação entre jogo e jogadores e também de jogadores com jogadores é diferenciada. Toda parte de testes é um tanto diferente também.\nE não menos importante foi o primeiro projeto que fui o Graphic Designer, como eu fiz Ciência da Computação antes, meu cargo nos projetos de jogos era sempre programador.\nSatisfação Pessoal\nApesar de todos os problemas foi bastante gratificante por causa do feedback positivo que recebemos. Dentre eles, a mecânica bem projetada, apesar de demorar para chegar a vez de cada jogador jogar. Bom aspecto visual, apesar da qualidade de impressão e trabalho da gráfica. E pontualidade com os prazos, mesmo com todos os problemas, fomos o único grupo a apresentar 100% dentro do prazo.\nDownload do Manual do Skate (imagens e manual de regras para imprimir): http://okamotoprojects.wix.com/site#!manual-do-skate/c101n\nPara terminar, muito obrigado ao Bruno Cicanci, pelo espaço e oportunidade de postagem do meu segundo postmortem e o primeiro de um jogo de tabuleiro. E obrigado a todos que leram o/\nMaurílio Eudes Okamoto\n","date":"20 de dezembro de 2013","externalUrl":null,"permalink":"/postmortem-manual-do-skate/","section":"Blog","summary":"Depois de alguns postmortems de jogos digitais enviados pelos desenvolvedores, este é o primeiro de um jogo de tabuleiro e mostra algumas diferenças na criação de um jogo analógico.\n","title":"Postmortem: Manual do Skate","type":"posts"},{"content":"Assim como a maioria dos livros da série Head First (Use a Cabeça, no Brasil), o HTML5 Programming mostra tudo que é preciso saber sobre o assunto com excelentes metáforas e associações com casos do dia-a-dia, melhorando a aprendizagem.\nDo básico de HTML5, à tópicos mais avançados envolvendo Javascript, Head First HTML5 Programming monstra os conceitos básico e como implementá-los em situações reais, com destaque para as funcionalidades de localização, armazenamento e o canvas, novo recurso gráfico do HTML5.\nA didática deste livro, assim como todos os comentários nas suas seções, são muito bons. Este é o segundo livro que eu li desta série (o primeiro foi o Desenvolvendo para iPhone), e este mesmo padrão de qualidade está presente em todos os livros. Eu recomendo fortemente que os exercícios propostos sejam feitos, ajudam bastante a fixar o conteúdo proposto.\nO principal item do HTML5 apresentado no livro é o canvas, e tudo que pode ser feito nele. Na minha primeira experiência com o HTML5, onde fiz este PONG, tive que estudar e entender como utilizar o canvas, pois ele é responsável por toda parte gráfica. O canvas é o lendário substituto do Flash, por que nele podemos criar animações e jogos, teoricamente tudo que também é possível fazer com o Flash, mas sem a facilidade da interface.\nEste livro pode ajudar muito se você está desenvolvendo um jogo com HTML5, ou pretende apenas aprender sobre o assunto. Existem frameworks para desenvolvimento de jogos mobile como o PhoneGap e o Titianium que usam HTML5 por dentro, e você pode programar em Javascript como faria no browser.\nO ebook que li foi enviado pela editora americana O’Reilly, pois ainda não existe versão em português no Brasil. Você pode comprar este e outros livros da série em sites como a Amazon, que envia livros sobre problemas para o Brasil (comprei muitos livros lá já), ou também comprar a versão digital e ler em qualquer lugar (smartphone, tablet, desktop, laptop e leitores de ebook).\n","date":"19 de dezembro de 2013","externalUrl":null,"permalink":"/head-first-html5-programming/","section":"Blog","summary":"Assim como a maioria dos livros da série Head First (Use a Cabeça, no Brasil), o HTML5 Programming mostra tudo que é preciso saber sobre o assunto com excelentes metáforas e associações com casos do dia-a-dia, melhorando a aprendizagem.\n","title":"Head First HTML5 Programming","type":"posts"},{"content":"Praticamente todo jogo em 2D com visão lateral, seja o Super Mario Bros ou Mortal Kombat, possui um cenário de fundo. Este cenário não é estático, pois precisa dar a impressão de que realmente existe algo “vivo” no fundo do jogo, e que complementa a fase.\nPara que o fundo mude de acordo com a movimentação do personagem, utilizando a técnica chamada de Parallax Scrolling, que consiste em movimentar a imagem do fundo de acordo com a movimentação do personagem, porém mais lento para dar a impressão de profundidade. Um dos detalhes mais interessantes do Parallax Scrolling é que quando mais imagens com velocidade de movimento diferente houverem no fundo da fase, maior será a sensação de profundidade.\nO exemplo abaixo é um pseudo-código baseado na cocos2d-x que mostra como podemos implementar esta técnica, utilizando três imagens diferentes (podem ser várias imagens, depende da profundidade e detalhes que você quer).\nIniciamos as variáveis com cada imagem. Devemos ter atenção na hora de adicionar as imagens, pois na cocos2d essa ordem influência na ordem que a imagem será desenhada na tela. Neste caso queremos o pSky atrás, e as demais imagens na sua frente.\nCCSprite* pSky = CCSprite::create(\u0026#34;sky.webp\u0026#34;); this-\u0026gt;addChild(pSky, 0); CCSprite* pMountain = CCSprite::create(\u0026#34;mountain.webp\u0026#34;); this-\u0026gt;addChild(pMountain, 0); CCSprite* pGround = CCSprite::create(\u0026#34;ground.webp\u0026#34;); this-\u0026gt;addChild(pGround, 0); Depois de inicializar e posicionar as imagens nos lugares corretos (com o setPosition()), vem a parte da movimentação. Vamos imaginar que temos duas variáveis que nos dizem para qual lado o jogador está se movimentando, assim vamos fazer o Parallax ir para o lado correto. Também vamos imaginar que já existe uma variável com o sprite do jogadar inicializada.\nvoid update(float dt) { if (pPlayerMoveRight) { pSky-\u0026gt;setPosition(ccp(pSky-\u0026gt;getPosition().x + (1.0f * dt), pSky-\u0026gt;getPosition().y)); pMountain-\u0026gt;setPosition(ccp(pMountain-\u0026gt;getPosition().x + (10.0f * dt), pMountain-\u0026gt;getPosition().y)); pGround-\u0026gt;setPosition(ccp(pGround-\u0026gt;getPosition().x + (100.0f * dt), pGround-\u0026gt;getPosition().y)); pPlayer-\u0026gt;setPosition(ccp(pPlayer-\u0026gt;getPosition().x + (100.0f * dt), pPlayer-\u0026gt;getPosition().y)); } else if (pPlayerMoveLeft) { pSky-\u0026gt;setPosition(ccp(pSky-\u0026gt;getPosition().x + (-1.0f * dt), pSky-\u0026gt;getPosition().y)); pMountain-\u0026gt;setPosition(ccp(pMountain-\u0026gt;getPosition().x + (-10.0f * dt), pMountain-\u0026gt;getPosition().y)); pGround-\u0026gt;setPosition(ccp(pGround-\u0026gt;getPosition().x + (-100.0f * dt), pGround-\u0026gt;getPosition().y)); pPlayer-\u0026gt;setPosition(ccp(pPlayer-\u0026gt;getPosition().x + (-100.0f * dt), pPlayer-\u0026gt;getPosition().y)); } } Repare que o valor da movimentação do pSky é bem menor do que os demais. Isso influencia na velocidade do movimento, pois o que está mais afastado deve se mover mais lentamente para dar a impressão de profundidade. O resultado é que o céu irá se movimentar bem devagar, pois está mais longe, depois a montanha irá se movimentar um pouco mais rápido, mas ainda lenta por estar longe também, e o chão irá se movimentar na mesma velocidade que o jogador.\nEsta técnica pode ser utilizada em praticamente qualquer jogo 2D com visão lateral, seja de aventura, corrida, luta, ou qualquer outro estilo. Alguns jogos com visão lateral e gráficos 3D (o que chamamos também de 2.5D) utilizam essa técnica com modelos ao invés de imagens, o que aumenta a profundidade. Um exemplo é o Trine, que possui jogabilidade 2D com gráficos 3D, e podemos ver claramente o Parallax feito com modelos 3D no video abaixo.\nMais informações sobre o Parallax Scrolling e fonte das imagens na Wikipedia.\n","date":"18 de dezembro de 2013","externalUrl":null,"permalink":"/parallax/","section":"Blog","summary":"Praticamente todo jogo em 2D com visão lateral, seja o Super Mario Bros ou Mortal Kombat, possui um cenário de fundo. Este cenário não é estático, pois precisa dar a impressão de que realmente existe algo “vivo” no fundo do jogo, e que complementa a fase.\n","title":"Como ser um programador de jogos: Parallax","type":"posts"},{"content":"Conheça o livro de Cesar Brod, publicado pela editora Novatec, que pode ensinar qualquer pessoa os conceitos básicos de programação com exemplos de jogos.\nMuitas vezes a maior barreira para se tornar um programador é o primeiro contato. Pode ser algo simples para quem já trabalha, mas eu lembro que no começo da faculdade um dos problemas mais comuns para mim e os demais alunos era converter a lógica em código.\nNeste livro, Aprenda a Programar, o autor Cesar Brod parte do mesmo princípio que aprendi nas primeiras aulas de lógica de programação: a comparação com uma receita de bolo. Nesta linguagem mais comum fica muito fácil entender o conceito de algoritmo e como a programação funciona.\nNas duas primeiras partes do livro nenhum código é escrito, pois o autor apresenta os conceitos e propõem exercícios de lógica de programação, itens essenciais para formar uma base sólida antes de começar a programar qualquer coisa. É muito interessante a maneira que o livro ensina a lógica a partir de verbos que indicam ações.\nA partir da terceira parte do livro começa a parte mais prática de programação, utilizando a linguagem Python. Está não é a primeira vez que vejo um livro sobre este assunto que utiliza o Python para apresentar os conceitos de programação. Quando trabalhei na Electronic Arts usei muito Python para automatização do processo de compilação, mas não para programar os jogos.\nEmbora seja possível utilizar Python em qualquer sistema operacional, o autor sugere o uso de Linux, e tudo no livro é baseado neste S.O. O Linux é muito usado para programação, principalmente back-end., mas não muito em jogos. Porém, vale a pena aprender a mexer em um ambiente Unix, pois empresas grandes utilizam para diversas coisas, desde simples servidores até aplicações e automação para auxiliar o desenvolvimento dos jogos.\nO maior exemplo de código do livro é como programar o jogo PONG em Python. Embora este livro não seja sobre desenvolvimento de jogos, seu foco é ensinar qualquer pessoa que queira aprender a programar, por isso ele é muito interessante para que quer começar a programar e desenvolver jogos. Nos capítulos finais o livro ensina como compilar o projeto feito em Python para rodar em dispositivos móveis com Android, tudo sempre no ambiente do Linux.\nEste livro não vai te ensinar a ser o melhor programador do mundo, e muito menos ensinar a fazer jogos, mas com certeza é muito indicado para quem quer começar a programar. Vale mais a pena ler um livro como este, que se preocupa em ensinar o básico antes de mostrar código do que pegar um livro de introdução a uma linguagem qualquer, que não vai ensinar a lógica de programação.\nMesmo trabalhando há alguns anos com programação, este livro foi interessante para rever coisas muito básicas que geralmente esquecemos com o tempo, e também para aprender mais sobre Python. Muito obrigado a editora Novatec por me enviar este livro!\nVocês podem adquirir este livro no site da Novatec, e com o código GAMEDEVELOPER ao finalizar a compra você ganha 20% de desconto (válido até 31/12/1014)!\n","date":"17 de dezembro de 2013","externalUrl":null,"permalink":"/aprenda-a-programar/","section":"Blog","summary":"Conheça o livro de Cesar Brod, publicado pela editora Novatec, que pode ensinar qualquer pessoa os conceitos básicos de programação com exemplos de jogos.\n","title":"Aprenda a Programar: A Arte de Ensinar o Computador","type":"posts"},{"content":"Jonathan Blow é um desenvolvedor independente famoso por criar o jogo Braid, um dos jogos indies mais bem sucedidos no Xbox Live Arcade. Nesta palestra, apresentada mês passado no evento CreativeMornings, ele explica muitas coisas interessantes sobre Game Design.\nMuitas pessoas conheceram sua história no excelente documentário Indie Game: The Movie. Apesar de não ser tão polêmico quanto o Phil Fish, criador do FEZ, Blow tinha o costume de buscar e comentar TODAS reviews que eram publicadas sobre seu jogo Braid, geralmente escrevendo que não entenderam a essência do seu jogo.\nAtualmente, Blow está trabalhando no jogo The Witness. Confira abaixo a palestra completa:\n","date":"13 de dezembro de 2013","externalUrl":null,"permalink":"/palestra-jonathan-blow/","section":"Blog","summary":"Jonathan Blow é um desenvolvedor independente famoso por criar o jogo Braid, um dos jogos indies mais bem sucedidos no Xbox Live Arcade. Nesta palestra, apresentada mês passado no evento CreativeMornings, ele explica muitas coisas interessantes sobre Game Design.\n","title":"Palestra sobre Game Design do Jonathan Blow, criador do jogo Braid","type":"posts"},{"content":"Este mês fez 20 anos que o jogo DOOM foi lançando, um game que introduziu muitos conceitos e técnicas usados até hoje em muitos FPS, além de inspirar muita gente a desenvolver jogos.\nJohn Carmack, o cara mais badass em computação gráfica do mundo, e John Romero falaram sobre suas memórias da época em que desenvolveram o DOOM. A entrevista com os dois está disponível no Kotaku. A foto abaixo foi tirada do texto publicado, e coloquei apenas para mostrar como eles eram e o tamanho da equipe que criou um dos jogos mais importantes para a indústria de games.\nSe ficou som saudades de jogador DOOM ou curioso para conhecer este jogo que está fazendo 20 anos este mês, leia este post que contém links para baixar o código-fonte do projeto completo, e mais outros jogos publicados pela Id Software, como Quake e Wolfenstein.\n","date":"12 de dezembro de 2013","externalUrl":null,"permalink":"/20-anos-de-doom/","section":"Blog","summary":"Este mês fez 20 anos que o jogo DOOM foi lançando, um game que introduziu muitos conceitos e técnicas usados até hoje em muitos FPS, além de inspirar muita gente a desenvolver jogos.\n","title":"20 anos de DOOM e lembranças de Carmack e Romero","type":"posts"},{"content":"O Game Design Document (GDD), é um documento escrito pelo Game Designer para os programadores e artistas entenderem sua visão da mecânica do jogo. Este documento é muito importante, mas infelizmente é tão ignorado quanto o próprio Game Designer.\nMuita gente acha que o GDD é praticamente a mesma coisa que a especificação técnica que um analista de sistemas escrever depois antes da equipe começar a fazer o projeto. Ambos são documentos que devem ser escritos antes do desenvolvimento do projeto, porém o GDD não é definitivo e pode ter constantes mudanças, pois algumas coisa no jogo podem não sair como foi esperado, e neste caso mudanças são necessárias.\nNas primeiras fases do desenvolvimento, enquanto a equipe está trabalhando no protótipo junto com o Game Designer, ele está escrevendo o GDD e definindo todas as mecânicas e features do jogo. Pode ser que após o término do protótipo, usado para apenas para validar a mecânica básica do jogo, muita coisa tenha mudado, e o Game Designer deve manter o GDD sempre atualizado, e sempre pedir para a equipe acompanhar as atualizações.\nNa Glu Mobile, todo GDD é uma página na wiki interna, e todo mundo da empresa tem acesso para ler e conhecer mais sobre os jogos. É muito legal este tipo de documento por ser uma página onde todos podem editar e ver as alterações, as vezes mais prático do que compartilhar um o GDD usando o Google Drive ou Dropbox, por exemplo. Eu achava muito legal, e passava horas lendo o GDD de outros projetos!\nCompartilhar um documento funciona bem neste caso, pois geralmente a equipe não vai editá-lo, irão apenas visualizar seu conteúdo, por isso não é normal acontecer problemas de mais de uma pessoa editar ao mesmo tempo. Independente da maneira que você irá fazer o GDD, faça e sempre avise a equipe que nova alterações foram feitas, não espere que todo mundo irá sempre ler este arquivo para ver se algo mudou. Mesmo tendo um documento, é bom conversar sobre seu conteúdo em reuniões, para ter certeza de que todos entenderam a visão do Game Designer.\nA organização do documento é algo que não tem um padrão, mas existem diversas sugestões. Meu modelo favorito é o apresentado pelo Scott Rogers, no livro Level Up: Um guia para o design de grande jogos. Quando fiz meu TCC na pós-graduação em games, o jogo Oniro, usei o modelo do livro Game Design Workshop, da Tracy Fullerton, e você pode baixar o GDD que escrevi clicando aqui.\nExistem diversos modelos de GDD espalhados por ai, porém vale lembrar que nada em um modelo de GDD é obrigatório ou deve ser usado sempre. Você deve analisar estes modelos e ver o que se adapta melhor ao seu jogo, e preencher apenas estes itens. Se algum item do GDD não será usado, ou não faz sentido manter, remova do seu documento para deixar tudo mais organizado e apenas com informações úteis. Não adianta escrever 100 páginas se a equipe não vai ler, por isso existem dicas legais no livro do Scott Rogers para fazer uma versão menor para facilitar a apresentação da ideia do jogo.\nA partir do GDD, também, o produtor ou o próprio Game Designer pode criar a lista de tarefas de cada área, o que facilita muito o processo de desenvolvimento. Em muitas empresas é comum programadores e artistas ajudarem o Game Designer no começo do documento, principalmente apontando as limitações técnicas da ideia antes de começar a fazer ou durante o desenvolvimento do protótipo.\nComo em qualquer equipe, para qualquer projeto, a chave do sucesso é uma boa comunicação entre todos os membros de forma clara e transparente. Não tenha medo de compartilhar o GDD com a equipe, ele não deve ser um segredo guardo apenas para o Game Designer.\n","date":"11 de dezembro de 2013","externalUrl":null,"permalink":"/game-design-document/","section":"Blog","summary":"O Game Design Document (GDD), é um documento escrito pelo Game Designer para os programadores e artistas entenderem sua visão da mecânica do jogo. Este documento é muito importante, mas infelizmente é tão ignorado quanto o próprio Game Designer.\n","title":"Como ser um programador de jogos: Game Design Document","type":"posts"},{"content":"O cocos2d é um framework open source para desenvolvimento de jogos 2D usando Objective-C, que permite a publicação para a plataforma iOS da Apple. Conheça o livro que vai te ensinar tudo sobre este assunto, e veja como ter 40% de desconto na compra de livros físicos no site da editora Ciência Moderna.\nO iOS não é a maior plataforma mobile hoje, porém é a mais rentável para jogos e aplicativos. Enquanto o Android sofre com pirataria, o iOS é mais estável para o desenvolvedor, com mais modelos de negocio que funcionam bem, como a própria venda do jogo ou aplicativo.\nNeste livro, Aprenda a desenvolver jogos para iPhone e iPad com o cocos2d, lançando no Brasil pela editora Ciência Moderna, o autor Steffen Intterheim apresenta de forma clara e objetiva tudo que este framework é capaz de fazer. No início, ele apresenta as vantagens de usar o cocos2d, além de destacar as diferenças e problemas que o desenvolvedor enfrentaria para portar seu jogo para outra plataforma, o que basicamente obrigaria ele a refazer o jogo em outra linguagem. Vale lembrar que este livro é de 2010, e muitas coisas mudaram hoje, pois a área d desenvolvimento de games vive uma constante busca por melhores tecnologias para criar jogos.\nOs capítulos 3, 4, 5 e 6 apresentam, de forma resumida, todo conceito por trás da cocos2d. O uso do Director para gerenciar as Scenes é um conceito muito importante, sem isso não é possível entender realmente como as coisas funcionam dentro deste framework. Leia com atenção este capítulo para endentar como fazer corretamente o uso de todos recursos do cocos2d.\nOutro destaque é a explicação do uso do famoso framework de simulação de física, Box2D, para criar jogos na cocos2d. Embora todo código do livro seja apenas para explicar cada assunto tratado no respectivo capítulo, há um capítulo que ensina a fazer um jogo de pinball utilizando todos conceitos e recursos apresentados no livro. O capítulo 15 é muito interessante para qualquer desenvolvedor, pois da dicas bem legais de como publicar seu jogo, encontrar pessoas para ajudar no projeto, integração com redes sociais e opções de monetização.\nNo capítulo 2 tem uma parte que fala sobre gerenciamento de memória, e o autor diz que não é possível prever o uso da memória no simulador. Eu até li duas vezes pra ver se era isso mesmo, pois a organização do texto ficou confusa parece que ele está falando disso em simuladores e aparelhos reais, mas na verdade ele está falando apenas que o emulador usa os recursos da sua máquina, e por isso não é possível prever o uso de memória e desempenho do jogo.\nInfelizmente, a tradução do livro deixou algumas coisas passarem por não haver uma revisão técnica adequada após este processo. Erros de nomeclaturas são comuns, e algumas vezes o mesmo termo não é traduzido para português, o que gera uma inconsistência que pode prejudicar quem está aprendendo. Uma exemplo disso é o termo Tiledmap, que em alguns lugares foi mantido e em outros traduzido para Mapa de Ladrilhos. Se você procurar por este termo traduzido no Google vai encontrar como colocar ladrilhos no piso e em paredes, ao invés de criar mapas para jogos.\nMesmo não estando atualizado, este livro é bom para ensinar conceitos básicos de desenvolvimento de jogos para dispositivos móveis, aprender detalhes da plataforma iOS, dicas importantes sobre física e eventos de touch, além de um boa referência para aprender cocos2d, que não mudou tanto assim nos últimos anos. Conceitos não envelhecem, você apenas aprende novos. Não deixe de acessar também o site do autor, com muito material adicional para você aprender mais sobre desenvolvimento de jogos com cocos2d.\nO cocos2d é um framework muito usado, e há pouco tempo saiu a preview da versão 3 que permite publicar jogos para Android também. Ainda não olhei isso para ver como funciona, mas é uma boa notícia para quem usa, pois até então a cocos2d-x, que é multiplataforma, estava sendo a principal escolha dos desenvolvedores. Hoje não faz sentido lançar um produto em apenas uma plataforma, principalmente pela facilidade de usar do mesmo código com poucas alterações. Embora o iOS seja mais rentável, o Android não pode ser ignorado, é necessário apenas entender qual é o melhor modelo de negócios para cada plataforma e lançar o projeto da melhor maneira em cada mercado.\nMuito obrigado ao pessoal da editora Ciência Moderna que me enviou este ebook! Eles também tem um presente para o pessoal do blog: 40% de desconto na compra de livros físicos pelo site da editora! Após finalizar a compra, você deve se cadastrar como CONVENIADO e informar a senha V00028, então o desconto será aplicado na sua compra atual e nas futuras pelo site da Ciência Moderna. Só um detalhe, eu não ganho nada com isso, é apenas uma promoção muito legal da editora que consegui para os leitores do blog.\n","date":"10 de dezembro de 2013","externalUrl":null,"permalink":"/aprenda-a-desenvolver-jogos-para-iphone-e-ipad-com-o-cocos2d/","section":"Blog","summary":"O cocos2d é um framework open source para desenvolvimento de jogos 2D usando Objective-C, que permite a publicação para a plataforma iOS da Apple. Conheça o livro que vai te ensinar tudo sobre este assunto, e veja como ter 40% de desconto na compra de livros físicos no site da editora Ciência Moderna.\n","title":"Aprenda a desenvolver jogos para iPhone e iPad com o cocos2d","type":"posts"},{"content":"Fiquei alguns dias sem postar no blog, mas foi por um bom motivo. Aliás, um excelente motivo! Participei do Google Developer Bus, um hackathon de 3 dias, e minha equipe ganhou a competição com um app para fidelização de clientes em academias com conceitos de gameficação, o PowerUp, e vamos conhecer o escritório do Google na Califórnia!\nNão sei em por onde começar a descrever minha felicidade! Vou contar um pouco de como foi o evento, qual foi minha parte nisso e um resumo de cada dia do evento. O texto ficou longo, pois tentei contar quase tudo que lembrei, espero que gostem! Não deixe de acessar o site do PowerUp, e curtir a página no Facebook e Google+, isso vai nos ajudar muito!\nGoogle Developer Bus # O Google Developer Bus é o primeiro Hackathon organizado pelo Google na América Latina, e ocorreu em quatro países: Argentina, México, Colômbia e Brasil. Mais do que uma simples competição, o evento teve como foco criar soluções criativas utilizando serviços do Google para solucionar problemas de pequenas e médias empresas.\nA edição brasileira contou com mais de 2.200 inscritos, e destes foram selecionados apenas 44 participantes, divididos em quatro categorias: Front-end (eu), Back-end, Design e Project Manager. A seleção dos 44 participantes foi através de três etapas que consistiam em um teste online sobre o seu conhecimento em relação a sua categoria, um teste de lógica e um vídeo que cada participante gravou contanto sua experiência e o que esperava do evento.\nAlém do recorde de inscrições, no Brasil teve também o recorde de equipes, pois eram para ser apenas 10, sendo que 4 participantes foram chamados como lista de espera. Felizmente, no dia do evento, todos que foram selecionados compareceram, e a organização do evento permitiu que o pessoal da lista de espera formasse um novo grupo, deixando a competição ainda mais desafiadora com mais concorrentes.\nForam 3 dias de evento, onde nos encontrávamos todo dia as 8h na frente do escritório do Google em São Paulo, e um ônibus nos levava até a Universidade Anhembi-Morumbi da Vila Olímpia, onde ficávamos até as 20h. Porém, mais do que apenas um espaço para o evento, o Google fez questão de colocar a sua cultura nestes 3 dias. Então, além da área de trabalho, havia um espaço para relaxar com bebidas e comidas a vontade, locais para descansar, massagem, PS3, fliperama, além de café da manhã, almoço e café da tarde. Tudo muito bem organizado e a vontade, foi demais!\nEste evento era também um reality show, e durante três vezes por dia o Neto Marin, funcionário do Google e apresentador do evento, entrava ao vivo através do YouTube para conversar com os desenvolvedores e também entrevistar alguns mentores. Na terceira vez, já no começo da noite, era a vez das equipes apresentarem o andamento do projeto em 3 minutos, o que é algo realmente difícil de planejar.\nAlém de tudo isso, ainda existiu uma competição social onde cada equipe tinha que cria ruma página no Google+ e divulgar. Quanto mais +1 a página recebia, mais pontos a equipe ganhava para poder trocar por itens premium, como Redbull, Kitkat e massagem. Nos 3 dias de eventos eu dormi apenas 4 horas e tomei muito Redbull, acho que eles tinham que patrocinar este evento junto com o Google.\nDia 1 # 44 pessoas que nunca se viram tiveram que, em apenas 3 dias, ter um entrosamento muito grande com a sua equipe, e um comprometimento em dar o melhor de si. Isso é tão incrível que nem sei se consegui me expressa nessa frase. Sério. Você consegue imaginer se juntar com pessoas desconhecidas e criar algo criativo em 3 dias, e ainda se preocupar em ganhar uma competição? Com certeza é um sentimento muito bom, e só quem passou pode falar a loucura que isso é.\nNo primeiro dia ninguém sabia ao certo como seria o evento, mas todos estavam muito empolgados. Na chegada ao prédio do Google cada um ganhou duas camisetas do evento com a cor da sua categoria: verde para Front-end, azul para Back-end, amarelo para Design e vermelho para Project Manager, tudo bem colorido e com a cara do Google! Ganhamos também um crachá bem legal, e logo o sentimento de que algo grande estava por vir tomou conta de mim e muitas outras pessoas.\nChegando na universidade, a primeira coisa que fizemos foi deixar nossas coisas na sala principal de trabalho e ir tomar café da manhã. Após o café, o evento começou pra valer! Além do pessoal da organização, também existiam alguns mentores (inicialmente 10, mas depois chegaram mais). A dinâmica das ideias foi a seguinte: 4 pessoas aleatórias sentavam com um mentor por 10 minutos, e cada um falava de uma ideia qualquer. Se o mentor gostava, ele anotava em um papel e este era entregue para a coordenação. Fizemos este procedimento duas vezes, e uma terceira sem os mentores. A ideia era boa, mas infelizmente a falta de controle de tempo fez com que muita gente não tivesse a chance de falar.\nApós isso, os mentores se reuniram para selecionar as melhores ideias e agrupar as parecidas. Eu dei uma ideia de um site para gerenciamento de tarefas com elementos de gameficação para recompensar os desenvolvedores, e esta foi uma das ideias selecionadas para serem escolhidas. Após esta pré-seleção dos mentores, cada um recebeu um número e, em ordem de chamada aleatório, tivemos que colocar um cartão com nosso nome e cor na ideia. A regra era simples: apenas uma cor de cada poderia estar em uma ideia, e isto formaria a equipe. Eu fui um dos últimos a ser chamado, e a minha ideia foi selecionada por outra equipe. Na dúvida, escolhi uma ideia que estava escrito apenas “Healthcare com gamefication”, e nem preciso falar por que isso me chamou a atenção, né?\nNo momento em que coloquei o meu cartão verde na ideia já haviam outros dois, Design e Back-end, e ao mesmo tempo outro cara colocou um vermelho de Project Manager, e assim a equipe foi formada. Neste momento conheci o André, um empreendedor de Belo Horizonte que tornou-se o Project Manager da equipe. Quando estávamos indo para a mesa destinada ao grupo tive uma surpresa curiosa. Eu conversei apenas com duas pessoas, e bem rapidamente, antes de chegar na faculdade, e estas duas pessoas estavam na minha equipe! A Dani, Designer, me perguntou quem estava distribuindo as camisetas quando ela chegou na frente do Google, e o Fábio, Back-end, sentou do meu lado no ônibus e conversamos um pouco sobre o que fazíamos. Incrível, não?\nA ideia inicial era criar um jogo que recebesse ações de sensores no corpo de uma pessoa, e isso seria usado para estimular o paciente a completar um determinado exame. Existiam alguns sensores lá, no caso usaríamos cardíacos, mas a ideia for descartada pela sua complexidade. Então, depois de muita conversa chegamos no conceito do PowerUp, um serviço que academias podem oferecer aos alunos para monitorar seu treino e receber recompensas com o objetivo de fidelizar os clientes e incentivá-los a não desistir. A ideia é ter um aplicativo Android para os alunos gerenciarem o seu treino, sendo que os instrutores cadastram o treino através de uma interface web, e disso tiramos diversas estatísticas e relatórios para a academia. As recompensas para os alunos são bem parecidas com o modelo de gameficação do Foursquare: medalhas (bagdes) e pontos, além de um ranking dos seus amigos e um da academia, tudo integrado através do Google+.\nNosso diferencial partiu da ideia, pois o André também é instrutor de Karate e trabalha em duas academias, então além de ter contatos também conhecia as necessidades de instrutores e alunos por um serviço como o PowerUp. Ele montou um formulário para validar a ideia, e também entrou em contato com instrutores e academias, e na primeira noite já tínhamosalguns dados para apresentar, e todos eles validavam a nossa ideia. Além disso, nossa página começou a ganhar muitos +1, e logo nos destacamos.\nEnquanto o André corria com a parte dele, a Dani criou a identidade visual, o logo e um mockup do aplicativo. O Fábio começou a configurar o App Engine para usarmos no projeto, e eu comecei a desenvolver um protótipo usando Corona SDK para mostrar algo rodando em um Android na nossa primeira apresentação, e isso causou um efeito muito bom, pois todas equipes começaram a nos ver como um forte adversário. Inclusive o Neto disse isso após a nossa primeira apresentação: “Temos um forte candidato”. Ficamos muito satisfeitos com o primeiro dia, mas ainda tinha muita coisa pra fazer, mais do que o tempo disponível. Quando cheguei em casa naquela noite fiquei configurando algumas coisas no meu computador e adiantando os layouts do aplicativo. Neste dia dormi 4 horas.\nDia 2 # O segundo dia começou com todo mundo com muita vontade de desenvolver seu projeto e empolgados com a competição. Existiam muitas pessoas legais e simpáticas no evento, que estavam simplesmente curtindo estar lá, e sinceramente esta era minha ideia também, pois por não conhecer o time e o que as demais pessoas estavam fazendo, não sabia o que esperar. Logo que chegamos, a equipe se reuniu e começamos a conversar sobre o que faríamos no dia. O André deu um update sobre o feedback dos formulários e a página do Google+, todos os números estava crescendo bastante. Descartei o protótipo e comecei o projeto usando o Eclipse e Android SDK apenas.\nCom a ideia do PowerUp já definida, nossa preocupação no segundo dia foi quais features deveríamos priorizar para terminar e apresentar na final. Eu fiquei o dia inteiro apanhando dos layouts de Android, pois este foi o primeiro aplicativo que desenvolvi, minha experiência toda sempre foi voltada para jogos, que são bem diferentes. Neste dia a Dani conseguiu terminar praticamente todo layout do aplicativo e começou a trabalhar no site, enquanto que o Fábio já estava com o back-end pronto para integrar com o aplicativo, e foi o que fizemos.\nEu detalhei mais o primeiro dia do evento por que foi quando mais coisas aconteceram, neste segundo dia estávamos todos muito concentrados no trabalho, por isso que não houveram tantos detalhes para contar. Porém, muitas coisas legais aconteceram, como a nossa página no Google+ ser a mais popular, com mais de 2.000 +1 no segundo dia, e alguns grupos já falaram que éramos um forte concorrente para as câmeras. Ah sim, durante todo o evento existiam pessoas filmando e colhendo depoimentos para um making of, que não sei quando ou onde será publicado. Muitos desses videos foram usados nos videos que estão neste post, esse pessoal trabalhou duro também para editar tanto material durante o evento.\nNossa apresentação no final do segundo dia foi ainda melhor, pois tínhamos muito mais dados para apresentar, o mockup do site e do aplicativo estavam praticamente prontos, e toda nossa tecnologia bem definida. Eu tive alguns problemas com a integração do login através do Google+, mas isso misteriosamente foi resolvido depois que criamos novamente o projeto no Google Cloud. Chegando em casa, virei a noite trabalhando no aplicativo Android, na integração com um leitor de QR code (usado pelo aplicativo para identificar qual treino deve ser feito em um equipamento com seu código) e no login do Google+. Toda equipe virou a noite, estávamos juntos no hangouts do grupo, e foi este tipo de atitude que nos motivou a dar o melhor para apresentar o melhor projeto possível.\nEste foi um momento decisivo pra mim, e acredito que para todos da minha equipe e as demais equipes. Virar a noite fez a diferença, e sem isso não sei como teria sido a nossa apresentação do aplicativo no terceiro dia. Em alguns momentos pensei em ir dormir, estava muito cansado, mas logo me animava e voltada a programar. Não foi fácil, mas valeu muito a pena no final. Neste dia não dormi.\nDia 3 # No último dia do evento, a empolgação virou desespero, e todo estávamos muito pressionados para terminar os respectivos projetos. Na parte da manhã terminei a integração do Google+, o layout da tela principal e detalhe do aplicativo, que foi integrado com o leitor de QR code, e a exibição de uma medalha para o aluno por ter completado o seu treino. O Fábio terminou a parte dele e ajudou no site. A Dani terminou de montar o CSS e HTML das páginas, e o André continuou seu trabalho nas redes sociais. Neste dia chegamos nos quase 4.000 +1 na nossa página, sendo que a segundo equipe com mais +1 tinha 1.200. Nossos amigos e famílias ajudaram demais nisso!\nEnquanto as pessoas técnicas da equipe estavam trabalhando, o André foi atrás de todos os mentores para apresentar o projeto, e fazer disso um treino para a apresentação final. Tivemos também uma pré-apresentação para treinar e pegar feedback, e tudo isso foi essencial para a apresentação final, que focou exatamente no que era importante mostrar para o júri, formando principalmente por empreendedores e pessoas de empresas como o Sebrae.\nAs 14 horas começou a primeira parte da nossa avaliação, onde cada equipe teve que colocar o código em um repositório no GitHub e os mentores técnicos do evento começaram a avaliar tudo que fizemos. Eu fiquei sabendo disso no terceiro dia, então não tinha muito o que fazer, pois a prioridade era implementar as features principais. Não que o meu código estava de qualquer jeito, eu até fiz boa parte bem feito, mas sempre há coisas que podemos melhorar, e eu sou muito perfeccionista.\nPerto do horário limite, 17 horas, terminei as coisas necessárias para a apresentação, e é claro que algumas coisas ficaram de fora. Tentei relaxar um pouco para a apresentação, mas não foi nada fácil. O tempo todo só pensava que o aplicativo poderia dar algum erro, e isso que fiquei meia hora só testando o fluxo básico que seria demonstrado. Por fim, chegou nossa vez e o nervosismo virou empolgação. Na apresentação final, além da demonstração do site com os treinos do aluno, o aplicativo lendo o QR code, abrindo o treino e dando uma medalha para o aluno, e tudo isso integrado pelo login do Google+. O André mostrou mais números interessantes do nosso projeto, e inclusive mencionou que uma academia em Belo Horizonte demonstrou interesse em usar o PowerUp. O que fechou com chave de ouro foi uma foto demonstrando um aluno usando o aplicativo em uma academia, com o QR code no equipamento, e também uma foto de um pessoal em um academia com plaquinhas falando que querem o PowerUp.\nFui uma apresentação rápida, simples e objetiva. Mostramos todo potencial do projeto e as duas interfaces, web e mobile, funcionando e conversando. Tudo isso feito em 3 dias por pessoas que não se conheciam. Alguns grupos mostraram seus projetos funcionando também, e outros apenas a imagens do produto. Após todas as apresentações, o júri se retirou para conversar, e em alguns minutos voltaram com o resultado. Antes de falarem os vencedores, mencionaram dois projetos muito bons que mereceram destaque, o Expense.me e o Vila do Corretor, e então chegou a hora de anunciar o vencedor. O video abaixo mostra a reação da nossa equipe no quando o Neto disse “PowerUp!”.\nDiversos sentimentos tomaram conta de mim, fiquei incrivelmente feliz e me emocionei quando liguei para contar para meus pais. Na hora só deu tempo de escrever “Vou pra Califórnia, minha equipe ganhou o Google Developer Bus” no Facebook, e recebi diversas mensagens de parabéns e mais de 100 likes. Foi tão surreal que é difícil até descrever o que senti, foi tudo muito rápido. Eu sabia que tínhamos um bom projeto e uma excelente equipe, mas os concorrentes também. Devo admitir que depois das menções eu tive certeza que ganhamos, pois aquelas duas equipes eram as mais preocupantes, mas só acreditei quando ouvi o nome da nossa equipe e fomos receber o troféu lá na frente, ao vivo.\nDepois de muitas fotos, conversas, depoimentos, parabéns, fomos para a festa do Google, que aconteceu em um lugar na Augusta. Eu não consegui ficar muito tempo, pois estava muito cansado e ainda iria dirigir de volta pra casa. Neste dia eu finalmente dormi, cerca de 10 horas ou mais, e acordei ainda sem acreditar que tinha ganhado este concurso e que iria para a Califórnia, conhecer o famoso Vale do Silício.\nCalifórnia, here we come! # Depois de muita comemoração, nosso foco agora é o que vamos fazer na sede do Google na Califórnia. Sabemos que todas equipes vencedoras vão se encontrar lá, e que também vamos apresentar novamente o projeto, mas não sabemos mais do que isso. Com certeza, estamos muito empolgados. Foi muito legal também ver a notícia que ganhamos em sites como Info, Blog do Google e iMasters.\nSão tantas pessoas para agradecer, que nem sei por onde começar! Obrigado a todos que apoiaram o projeto na página do blog no Facebook; aos meus amigos e família que apoiaram e ajudaram muito; aos mentores do evento que nos ajudaram a definir o PowerUp; à organização do evento, pessoal do Google e da Globalcode; à Dani, que fez um trabalho incrível no design do projeto em pouco tempo; ao Fábio que desenvolveu todo back-end e facilitou a integração com o aplicativo; ao André que correu atrás das academias, apoio, empreendedores, e todo mundo que pudesse ajudar; a Letícia, que esteve sempre do meu lado me motivando e não me deixando dormir; e a Deus pela oportunidade de viver toda essa experiência incrível e única.\nObrigado a vocês meus leitores pelo apoio e incentivo que me dão para continuar meus projetos, como este blog. O Google Developer Bus é mais uma conquista importante na minha carreira, ao lado de tantas outras que me fazem continuar e nunca desistir. Nada é impossível, e a única pessoa que te impede de realizar seus sonhos é você mesmo! Obrigado por ter lido todo este post até o fim e desculpe o texto logo. É tanta coisa pra contar, e infelizmente deixei muita coisa de fora, mas tentei ao máximo contar como foi esta experiência única. Pra finalizar, uma música que não sai da minha cabeça! hahaha\nNão deixe de acessar o site do PowerUp, e curtir a página no Facebook e Google+, isso vai nos ajudar muito!\n","date":"6 de dezembro de 2013","externalUrl":null,"permalink":"/google-developer-bus-brasil/","section":"Blog","summary":"Fiquei alguns dias sem postar no blog, mas foi por um bom motivo. Aliás, um excelente motivo! Participei do Google Developer Bus, um hackathon de 3 dias, e minha equipe ganhou a competição com um app para fidelização de clientes em academias com conceitos de gameficação, o PowerUp, e vamos conhecer o escritório do Google na Califórnia!\n","title":"Califórnia, aí vou eu: Como minha equipe ganhou o Google Developer Bus","type":"posts"},{"content":"Testar um jogo é algo fácil, não é? Só jogar? Não! Existem maneiras de testar e, o mais importante, coletar dados destes testes para realmente melhorar o jogo. Alguns tipos de testes podem e devem ser feitos com um jogador, mas também existe o momento certo para cada tipo de teste.\nPara ficar mais simples de explicar, vou dividir o texto em fases do processo de desenvolvimento e destacar os tipos de testes que podem ser realizados. Em todas as fases assuma sempre que quem está testando o jogo é um QA da equipe de desenvolvimento, e não artistas, programadores, produtores e game designers. Nas fases finais, além do QA da equipe, falarei também sobre testes com o público-alvo e público geral.\nProtótipo # Durante a elaboração do Documento de Game Design (GDD) é iniciado o desenvolvimento do protótipo do jogo que, como expliquei neste post, é fundamental para a validação da ideia e do gameplay. Neste contexto, o teste deve focar na ideia que o game designer quer transmitir, e não em encontrar problemas técnicos.\nO game designer também vai jogar e testar a jogabilidade, inclusive ele fará isso durante todo desenvolvimento, porém é importante um QA testar, pois o teste do game designer, assim como de todos desenvolvedores, pode ser algo viciado, que não vai ver o que um QA pode encontrar por não estar dentro do desenvolvimento.\nAlpha # Esta fase começa logo depois que o protótipo foi validado e o game designer está com boa parte do GDD pronto, então começamos o desenvolvimento do jogo de acordo com a orientação do produtor e do gerente do projeto. Embora o jogo esteja no começo do desenvolvimento, aqui o QA já pode ficar mais atendo a problemas técnicos.\nÉ muito importante manter uma base de bugs encontrados, que também possua informações de como reproduzir e qual seu status (aberto, corrigido, não é bug, etc). Quando trabalhei na Glu Mobile usávamos o Bugzilla, e na Electronic Arts usávamos o DevTrack. Eu recomendo o Bugzilla por ser uma ferramenta gratuita e opensource que funciona muito bem para o que eu mencionei. Por favor, não use um Excel para isso já que temos opções profissionais e gratuitas.\nAqui ainda não temos testes com jogadores, pois o produto está em um estágio que pode causar uma impressão ruim ao jogador por não estar bem acabado, já que o foco é o gameplay. Por isso, nesta fase o teste é feito apenas pela equipe de QA interna. Vida de QA não é fácil, como mostra este artigo do IGN.\nBeta fechado # Aqui as coisas começam a ficar mais divertidas. Com um jogo com a base bem definida e testada pela equipe de QA na fase Alpha, agora podemos começar a testar com jogadores. A ideia do Beta fechado é selecionar jogadores que fazem parte do seu público-alvo para testar o jogo, e apenas isso. Por isso é fechado, devem ser convidados apenas as pessoas que você acredita que vão dar um bom feedback sobre o jogo. O objetivo é que todos problemas do jogo sejam encontrados e corrigidos para não acontecer problemas como no vídeo abaixo.\nExiste diversas maneiras de recrutar pessoas para testes fechados, e por serem limitados você não precisa de muitas. Aqui o que vale é a qualidade, e não a quantidade de jogadores. Enquanto os programadores e artistas estão trabalhando, o gerente do projeto e o produtor devem conseguir esta lista de jogadores para serem a equipe de testes do beta fechado. A coordenação dos testes deve ser feita pela equipe de QA, e os jogadores devem responder questionários e enviar todo tipo de informação que, depois de filtradas, devem ser entregues a equipe de desenvolvimento.\nOs formulários do Google Documents são uma boa forma de coletar dados, pois é uma ferramenta online e gratuita, onde os resultados são obtidos em tempo real. Por ser uma fase bem limitada, é possível também convidar jogadores para testar dentro do próprio estúdio. Neste caso a equipe de QAs, junto com o game designer, devem fazer apenas uma coisa: observar. Deixe os jogadores explorarem o jogo, e ao final da sessão peça para preencher algum formulário ou até converse com cada um para obter o feedback. Isso é muito importante para que o jogo dê certo.\nBeta aberto # Depois de toda experiência com os jogadores no Beta fechado, o teste aberto e feito para o público em geral é mais simples. É importante lembrar que provavelmente boa parte do público não vai enviar feedback sobre os testes, e talvez jogue apenas uma vez para ver como o jogo é. Por isso, toda informação mais importante é obtida pelo Beta fechado, que geralmente demora mais do que esta fase. Um jogador que está testando deve sempre ser orientado a reportar qualquer tipo de problema que encontrar, mesmo que ele ache que não é um problema.\nPor ser aberto, nesta fase fica difícil de receber jogadores para testar, por isso tudo deve ser feito online através de pesquisas. Muitas empresas oferecem incentivos para os jogadores, como algum item especial ou desconto no jogo em troca do feedback deles, e isso funciona muito bem, como o exemplo da imagem acima. Outro detalhe muito importante é que todo feedback coletado deve ser apresentado a equipe de desenvolvimento resumido e com tudo que é mais importante destacado. O objetivo disso é ajudar a ter um jogo melhor, e não atrapalhar o desenvolvimento, por isso se for feito de qualquer jeito, a equipe de desenvolvimento não vai parar para ver tudo com calma.\nConclusão # Cada fase possui um foco diferente, mas em todas a figura do QA é muito importante para garantir a qualidade do jogo. Nos testes em que deve-se observar o jogador, faça anotações das reações deles em cada parte, se demoraram muito para concluir uma missão, se estão com cara de desanimo ou empolgados. A expressão deles é a mesma que você pode ter quando seu jogo for lançado, por isso é importante entender se o jogo está agradando ou não, e cabe ao game designer mudar isso caso seja necessário.\nEmbora pareça que tudo que eu escrevi aqui serve apenas para empresas grandes, isto não é verdade. O público-alvo pode ser seus amigos que tem os mesmos gostos e os testes podem ser feitos até em um encontro para tomar café, o importante é que estes testes sejam feitos e as informações coletadas. Você não precisar ser uma empresa grande para fazer grande jogos, mas pode e precisar ter o mesmo nível de profissionalismo.\n","date":"5 de dezembro de 2013","externalUrl":null,"permalink":"/teste-com-jogadores/","section":"Blog","summary":"Testar um jogo é algo fácil, não é? Só jogar? Não! Existem maneiras de testar e, o mais importante, coletar dados destes testes para realmente melhorar o jogo. Alguns tipos de testes podem e devem ser feitos com um jogador, mas também existe o momento certo para cada tipo de teste.\n","title":"Como ser um programador de jogos: Teste com jogadores","type":"posts"},{"content":"Hoje em dia existem ferramentas para sabermos exatamente quais partes do jogo que os jogadores estão interagindo mais, como o Game Analytics, que permite que os desenvolvedores corrijam falhas de game design que eles não sabiam que estavam lá.\nMesmo empresas grandes, com grandes equipes de desenvolvimento e testes, não podem prever exatamente tudo que os jogadores irão interagir no jogo. Por isso, ferramentas como o Game Analytics são muito importantes. Sua ideia é simples, o desenvolvedor só precisa colocar nos lugares certos do seu código uma chamada de um método do SDK do Game Analytics, que possui versões para várias tecnologias. Assim, o jogo enviará estatísticas para o site, e irá gerar relatórios indicado tudo que o desenvolvedor precisa saber.\nVocê pode ver quais são os menus mais acessados, os itens mais usados, as opções mais selecionadas, tudo! São infinitas possibilidades que estes dados permitem, mas é necessário adicionar os eventos em locais certos do código, se não os dados podem vir errados. Além de eventos, é possível fazer o mapeamento de dados mais simples, como quantidade de acesso por dia, por exemplo.\nÉ de se surpreender o que este tipo de informação pode fazer. Você pode descobrir que um modo de jogo que acha ser mais divertido é o menos jogado, enquanto um outro é o preferido dos jogadores. E com estas informações você pode fazer updates mais precisos para realmente melhorar o gameplay do jogo, e atrair mais jogadores.\nSe você usa Unity, vai gostar muito de uma funcionalidade do Game Analytics chama heatmap, que destaca as áreas do mapa do jogo através de um mapa de calor por cima do cenário. Assim, você consegue ver claramente os caminhos que os jogadores fazem, e as áreas que eles menos exploram.\nAlém do Game Analytics existem outras empresas que fazem isso, como o Flurry, e ambas são gratuitas. Isto não é algo de outro mundo, todas as empresas grandes fazem isso há anos, e agora existem tecnologias que qualquer pessoa pode adicionar em seu jogo. Porém, algumas empresas incluem em seus jogos alertas informando que estes dados são coletados com objetivo de análise para melhorar o jogo, e que nada pessoal é armazenado. Algumas empresas colocam até uma opção em seus jogos para que o jogador possa desligar o envio de dados estatísticos para a empresa.\nEste é um grande de exemplo do uso da tecnologia para melhorar os jogos, vale a pena usar! Lembre-se: não é preciso uma grande empresa para fazer grandes jogos, você só precisa aprender a usar técnicas e ferramentas mais profissionais.\n","date":"13 de novembro de 2013","externalUrl":null,"permalink":"/game-analytics/","section":"Blog","summary":"Hoje em dia existem ferramentas para sabermos exatamente quais partes do jogo que os jogadores estão interagindo mais, como o Game Analytics, que permite que os desenvolvedores corrijam falhas de game design que eles não sabiam que estavam lá.\n","title":"Como ser um programador de jogos: Dados analíticos do jogo","type":"posts"},{"content":"Finalmente, meses após seu anúncio oficial, foi lançada a nova Unit 4.3, que tem como principal destaque uma nova tecnologia que permite o desenvolvimento de jogos 2D dentro desta poderosa game engine.\nFaça o download gratuito hoje mesmo e conheça a ferramenta de 2D integrada na Unity, com certeza muitos jogos utilizando esta tecnologia serão lançados nos próximos meses. Confira abaixo um vídeo demonstrando este recurso 2D, e confira no site da Unity as outras novidades da versão 4.3.\n","date":"12 de novembro de 2013","externalUrl":null,"permalink":"/unity-com-suporte-nativo-2d/","section":"Blog","summary":"Finalmente, meses após seu anúncio oficial, foi lançada a nova Unit 4.3, que tem como principal destaque uma nova tecnologia que permite o desenvolvimento de jogos 2D dentro desta poderosa game engine.\n","title":"Unity 4.3 foi lançada hoje e trás o tão esperado suporte nativo a 2D","type":"posts"},{"content":"Mais um postmortem de um jogo produzido por desenvolvedores independentes no Brasil, desta vez vamos conhecer o que deu certo e o que deu errado durante a criação do jogo Sou Sustentável, desenvolvido pelo Okamoto Game Productions.\nO jogo, desenvolvido com a game engine Unity 3D, possui três mini-games diferentes, todos com temática de sustentabilidade. O postmortem abaixo, escrito pelo Maurílio Eudes Okamoto, mostra as dificuldades e problemas e os pontos positivos da experiência de criar um jogo do zero até o fim.\nPostmortem: Sou Sustentável\n1. Descrição do Jogo\nSou Sustentável é um jogo para as plataformas Android, WebPlayer e Windows (PC). É um jogo educativo com o tema sobre sustentabilidade. Possui 3 minijogos, com fácil aprendizado e englobam conhecimento e situações que envolvam o tema sustentabilidade. O primeiro minijogo, é para coletar os lixos recicláveis, onde o jogador controla uma lixeira. O segundo é sobre reaproveitamento de água da chuva, onde o jogador precisa ligar os canos para formar a tubulação que irá levar a água da chuva da calha para uma cisterna. E o terceiro minijogo envolve reflexos, o nome de um tipo de lixo reciclável irá aparecer na tela e o jogador precisa apertar o botão referente a aquele tipo de lixo.\n2. Dificuldades e Problemas\nPouco Empenho de Alguns Membros da Equipe\nDos 5 membros da equipe, dois deles eu conheci pela internet e outros dois eram amigos de vários anos. O interessante desse projeto é que deixou bem claro para mim, algo que um grande amigo meu dizia “Trabalho e amizade são coisas diferentes.” depois disso venho passando essa frase para as pessoas. Pois vejo muita gente levando um problema de trabalho/projeto para o lado pessoal e perdendo amizades. E ter mais cuidado em criar a equipe, bons amigos não quer dizer que vão ser bom desenvolvedores.\nArte Gráfica\nO Graphic Designer sabe bem desenhar no papel, mas no computador “dava para o gasto”, mas a arte não ficou ruim. O grande problema da arte era o tamanho em bytes que as imagens ficavam. Outro problema enfrentado por ele foi a falta de conhecimento em ferramentas gráficas, isso fez com que a criação das imagens demorassem muito mais.\nBugs e Problemas de Implementação\nFelizmente (ou infelizmente) houveram poucos problemas no fim do projeto. Os dois maiores problemas foram de desempenho, na qual causa lentidão (lag) em alguns aparelhos Android no primeiro minijogo. Outro problema foi com a chave da versão Android, que fez com que não conseguíssemos colocar o jogo no Google Play. Um outro problema considerável foi a qualidade das imagens no jogo, como elas eram naturalmente pesadas, nós tivemos que comprimir mais piorando bastante a qualidade inicial delas. 3. Pontos Positivos\nArte Sonora\nEm questão de músicas e efeitos sonoros, o Sound Designer do grupo fez um ótimo trabalho. As músicas e efeitos sonoros combinavam bem com o estilo do jogo, com cada minijogo. Foi um ponto positivo bem considerável, mas houve alguns improvisos. Aprendizado de Novas Ferramentas e Tecnologias\nEsse projeto foi focado para o aprendizado da game engine Unity 3D usando Javascript. E foi justamente isso o que eu aprendi nesse projeto, desenvolvimento de jogos no Unity 3D com Javascript. Também aprendi mais sobre a criação de um Game Design Document (GDD), que abrangeu a área de Game Design e Level Design.\nGanho de Experiência em Diversas Áreas\nEsse foi o segundo projeto de jogo que eu desenvolvi, ao contrário do primeiro que eu fui um participante mediano na equipe. Nesse projeto eu fui o que mais participou, apesar da pouca participação de alguns membros, a experiência que adquiri em um único projeto foi bem considerável.\nFoi a primeira vez que fui gerente de projeto e de equipe, foi o primeiro GDD que fiz que saiu do papel. Também foi a primeira vez que fui um Lead Programmer, programação é algo que sempre tive dificuldade.\nSatisfação Pessoal\nAlém dos fatores já citados, foi bem bacana trabalhar com pessoas inicialmente desconhecidas e o projeto fluir bem e terminar. Foi bastante divertido aprender a desenvolver no Unity 3D, antes disso só havia mexido em Android sem game engine. É tudo mais fácil e flui melhor, fora a economia de tempo que isso deu. O projeto demoraria pelo menos 5 vezes mais sem o Unity 3D, ou no pior caso ele nem sairia do papel.\nResumidamente foi muito bom pelo aprendizado e experiência. Não menos importante é o segundo jogo que criei e foi o primeiro que eu projetei e gerenciei sozinho. Afinal uma das melhores sensações para um desenvolvedor de jogos é terminar um jogo, mesmo se for simples e feio.\nDownload do Sou Sustentável: http://okamotoprojects.wix.com/site#!sou-sustentavel/cz1\nE para terminar obrigado ao Bruno Cicanci pela oportunidade de postagem do meu primeiro postmortem. E obrigado a todos que leram o/\nMaurílio Eudes Okamoto\nObrigado por compartilhar sua experiência Maurílio, e parabéns pelo jogo! Lembrando que os postmortems publicados são escritos pelos desenvolvedores do jogo, contando as coisas que deram certo e que deram errado durante a produção do game. Se você também produziu um jogo e quer compartilhar com os leitores, entre em contato comigo pelo email que está na seção contato.\n","date":"11 de novembro de 2013","externalUrl":null,"permalink":"/postmortem-sou-sustentavel/","section":"Blog","summary":"Mais um postmortem de um jogo produzido por desenvolvedores independentes no Brasil, desta vez vamos conhecer o que deu certo e o que deu errado durante a criação do jogo Sou Sustentável, desenvolvido pelo Okamoto Game Productions.\n","title":"Postmortem: Sou Sustentável","type":"posts"},{"content":"Já entrevistei alguns profissionais da área de desenvolvimento de jogos aqui no blog, e sempre desenvolvedores que trabalham ou trabalharam em grandes empresas. Pela primeira vez entrevistei um desenvolvedor independente brasileiro, um dos criadores de Knights of Pen \u0026amp; Paper e Chroma Squad, Saulo Camarotti.\nEu já conhecia o trabalho do Saulo por jogar Knights of Pen \u0026amp; Paper, comprei logo que saiu para iOS e me diverti bastante. Um tempo depois, no mês passado, assisti uma palestra do Saulo no Unite Brasil, e fiquei muito impressionado com seu relato de como a Behold Studios nasceu, e o sucesso do Chroma Squad no Kickstarter. Fique feliz por ele ter aceitado fazer a entrevista, e o resultado ficou muito bom!\nBruno Cicanci: Como e quando você teve interesse em desenvolver jogos?\nSaulo Camarotti: Aprendi a programar em Basic com 12 anos. E para uma criança, com uma ferramenta incrível que é esta de programar, eu quis fazer aquilo que eu gostava. Então comecei a fazer jogos. Também sempre que jogava, sempre entrava numa de “como vou melhorar esse jogo” ou “podia ser assim, que ia ser melhor”. Essas duas coisas juntas me fez caminhar pra onde estou hoje.\nBC: Quais foram seus primeiros contatos com desenvolvimento de jogos?\nSC: Mexia muito com Game Maker, RPG Maker, e 3D Game Studio. Estas ferramentas me ajudavam a fazer protótipos e comecei a aprender como se faziam jogos. Na época da adolescência, eu fazia de tudo, desenhava, programava, mas depois, entrei no curso de Ciência da Computação, e me especializei no que faço melhor.\nBC: Como nasceu a Behold? Quais eram seus objetivos no começo?\nSC: Durante o curso de Ciência da Computação, na Universidade de Brasília, fui desenvolvendo alguns trabalhos de pesquisa com colegas e professores na área de games. Já em 2008 fiz meu primeiro plano de negócios, de como seria a minha empresa, e em 2009 abri na incubadora do CDT/UnB. O objetivo no começo era fazer uma empresa de Advergames e Serious Games, mas depois mudamos o nosso foco, e hoje tem tudo dado muito mais certo.\nBC: Knights of Pen \u0026amp; Paper foi um grande sucesso, principalmente pela sua temática de RPG de mesa. Este jogo abriu muitas portas para a Behold?\nSC: Sim! Hoje temos muitos jornalistas acompanhando nosso trabalho, temos publishers e canais de distribuição atentos nos nossos jogos, como Steam, Sony e Microsoft. Então, o Knights foi fundamental nessa jornada.\nBC: Trabalhar com uma publisher de fora, a Paradox, foi uma boa experiência?\nSC: A Paradox é Sueca. Foi muito bom, aprendemos muito com eles. E ainda estamos trabalhando com eles. Mas no nosso novo jogo Chroma Squad resolvemos atuar de forma mais independente, e lançarmos por conta própria.\nBC: Como nasceu a ideia de colocar o Chroma Squad no kickstarter? Vocês ficaram surpresos com o sucesso?\nSC: Nós queríamos testar o conceito do jogo, antes de mergulhar no projeto. Precisávamos saber se a temática ia agradar o público. Então o Kickstarter foi fundamental pra criar essa comunidade por trás do jogo. Nós achamos sensacional o retorno que deu, tanto financeiro, quanto de ideias e pessoas envolvidas.\nBC: Como você vê o mercado para os desenvolvedores de jogos indies no Brasil?\nSC: A indústria de jogos no Brasil está muito bem. Agora precisamos entender que fazer jogo é ralação e empenho, e muita vontade. Não existe caminho fácil. Se comparado aos internaconais, inclusive alunos e desenvolvedores indies, nosso trabalho aqui ainda é muito ruim. Mas eles já estão há 20 anos na nossa frente, então, fica fácil de entender o que está faltando aqui: é experiência e vivência.\nBC: Do ponto de vista técnico e criativo, você acha que ser um indie no Brasil é muito diferente do que ser um indie fora daqui?\nSC: Nenhuma diferença. Talvez nos EUA os indies tenham mais acesso aos eventos e pessoas, o que facilita um pouco. Mas se o indie aqui participa dos eventos nacionais, como SBGames e BGS, é possível entrar diretamente em contato com grandes publishers e canais de distribuição também, e alavancar um bom jogo. Mas o que falta no brasileiro não são oportunidades de negócio, e sim, ainda falta fazer bons jogos. O Knights é um bom jogo, na nossa opinião, e ele se alavancou como nenhum outro jogo brasileiro, pois tivemos uma viralidade muito boa de divulgação. No fim das contas é só o jogo que importa, não o plano de negócios ou o acesso a dinheiro.\nBC: Qual conselho você daria para quem quer abrir uma empresa de jogos?\nSC: Não abre uma empresa ainda não. Faça jogos, crie ideias, jogue fora ideias, amadureça equipes, descarte membros da equipe, encontre novos membros de equipe, aprenda a desenvolver boas mecânicas, desapegue-se, erre, faça de novo, viva. Quando um jogo ficar pronto e polido, lance-o no mercado, sem mesmo ter CNPJ. E quando algum jogo tiver um retorno consideravel, pelo menos uns R$ 1 mil por mês, aí, sim, abra uma empresa, contrate um contador e oficialize a budega toda.\nBC: E qual dica você daria para quem quer começar a estudar desenvolvimento de jogos, mas ainda não se decidiu por programação, arte ou design?\nSC: Eu comecei fazendo um pouco de tudo, e aprendi a descobrir qual seria o meu talento verdadeiro. Apesar de amar arte, e ficar vislumbrado com animações 2D e 3D, sei que essa admiração não me torna um bom artista. Mas descobri que sou excelente programador, e quando comecei a estudar me encontrei, pois sei que estou usando meu talento nessa tarefa de codificar. Acho que todo mundo tem que descobrir seu verdadeiro talento ou vocação, e não simplesmente ir atrás do que gosta mais. Quando você se encontra, o gostar também aparece. E melhor de tudo, você começa a fazer o que lhe cabe fazer.\nCom relação ao estudo, eu aconselho fazer cursos específicos, e evitar os cursos genéricos. Por exemplo, é melhor fazer Ciência da Computação e aprender verdadeiramente a programa, do que fazer Jogos Digitais, aprender de tudo e sair sem saber fazer nada. Também vale para Arte Digital, Desenho Industrial, Artes Plásticas, etc. Agora, se o talento é desenvolver narrativas, mecânicas, entender balanceamento, e ter a visão do todo, acho que o curso de Design de Jogos pode ser muito bom também. O Aluno faz o Curso.\nObrigado Saulo, muito sucesso para vocês da Behold Studios! Acompanhem a página do Facebook deles para saber mais novidades sobre os seus projetos.\n","date":"8 de novembro de 2013","externalUrl":null,"permalink":"/entrevista-saulo-camarotti-ceo-behold-studios/","section":"Blog","summary":"Já entrevistei alguns profissionais da área de desenvolvimento de jogos aqui no blog, e sempre desenvolvedores que trabalham ou trabalharam em grandes empresas. Pela primeira vez entrevistei um desenvolvedor independente brasileiro, um dos criadores de Knights of Pen \u0026 Paper e Chroma Squad, Saulo Camarotti.\n","title":"Entrevista: Saulo Camarotti, CEO da Behold Studios","type":"posts"},{"content":"Muitas engines e frameworks possuem um controle do tempo de cada game loop internamente, mas expõem esta informação caso você precise. E, acredite, você precisa!\nPrimeiro, vamos falar de algumas definições. Game loop é looping principal do jogo, aquele método update() que é executado a cada frame, e pode ser internamente (Cocos2d-x, Corona, Unity) ou você tem que definir (SDL, DirectX). Cada vez que um frame do jogo é executado, quem executa é o game loop. Assim, se o seu jogo está rodando a 30 frames por segundo, o game loop é executando 30 vezes em um único segundo, por isso é importante que ele seja bem controlado.\nA diferença entre o tempo que o game loop inicia e termina sua execução é o nosso Delta Time! Esta diferença, geralmente em segundos ou mili-segundos, é um tempo inconstante que cada frame do jogo leva para ser feito. Basicamente, durante um frame acontecem coisas como verificar o input do jogador, atualizar a lógica do jogo e desenhar na tela tudo que aconteceu. Tudo isso feito várias vezes por segundo! Já da pra imaginar que quando o jogo está lento ou com lag o problema está por aqui, né?\nE por que é tão importante o Delta Time? Para controlar os frames por segundo do seu jogo. As engines e frameworks possuem um controle bem básico internamente, mas cabe ao programador estendê-lo para se adequar ao seu jogo. Existem algumas técnicas para controlar o tempo do game loop envolvendo o Delta Time, e a mais usada chama-se Fixed Rate, que consiste em garantir que game loop será executado naquele tempo.\nNo caso do Fixed Rate, basicamente, temos um valor fixo para cada game loop. Por exemplo, eu quero que cada game loop seja executado em 0,03 segundos (1 segundo / 30 frames), só que o tempo está rápido demais. Neste caso, após a execução do game loop, verificamos se o Delta Time é menor do que 0,03 segundos, e em caso positivo fazemos o game loop “esperar” 0,03 segundos – Delta Time, utilizando recursos como Thread Sleep (isso depende da tecnologia usada). Abaixo um exemplo implementado em C++ no framework SDL, que possui métodos para pegar o número de “ticks” e aguardar um número específico. Neste caso, o SDL não usa segundos, e sim um valor que corresponde ao número de “ticks” por frame.\nUint32 Scene::Wait(Uint32 t0) { Uint32 t1 = SDL_GetTicks(); if ((t1 - t0) \u0026lt; 75) { SDL_Delay(75 - (t1 - t0)); } return t1; } Isto funciona se o jogo estiver rápido demais, mas se estiver lento demais? Se estiver muito lento, o jeito é reduzir o número de frames por segundo. Quando trabalhei no FIFA 12 para Android, na Electronic Arts, usamos isso para baixar o FPS (frame por segundo) do jogo em aparelhos com hardware mais fraco, e assim reduzir ou eliminar o lag. Lembrando que reduzir o FPS não deixa o seu jogo lento, ele apenas faz menos updates por segundo, e para o olho humano as coisas só ficam perceptivelmente lentas abaixo de 17 FPS.\nPara saber mais detalhes sobre o game loop e fixed rate, dêem uma olhada neste post que fiz faz alguns anos explicando melhor este dois conceitos. Como o objetivo deste post é o Delta Time, vou falar um pouco mais sobre outros usos dele. Por exemplo, as vezes você precisa esperar um tempo determinado para uma ação, como esperar 10 segundos para exibir um banner em um jogo mobile. Neste caso, você usa o Delta Time para acumular o tempo passado até que chegue no seu valor desejado. O exemplo abaixo é uma implementação em C# na game engine Unity, e mostra como pegar o Delta Time, acumular e esperar um tempo determinado.\nprivate float mDelay; void Update () { // se passou 10 segundos... if (mDelay \u0026gt; 10.0f) { // faz alguma coisa e zera o contado mDelay = 0; } else { // se não, vai acumulando mDelay += Time.deltaTime; } } Controlar o game loop e fazer contagem de tempo são duas das principais utilizações do Delta Time em um jogo, e é claro que existem outros. O importante é sempre utilizar este tipo de recurso para estas tarefas, e lembre-se sempre de verificar na tecnologia que você está usando como este controle pode ser feito.\nUPDATE: Tinha esquecido de adicionar o video, obrigado por avisar Thales!\n","date":"6 de novembro de 2013","externalUrl":null,"permalink":"/delta-time/","section":"Blog","summary":"Muitas engines e frameworks possuem um controle do tempo de cada game loop internamente, mas expõem esta informação caso você precise. E, acredite, você precisa!\n","title":"Como ser um programador de jogos: Delta Time","type":"posts"},{"content":"Estamos longe de ter eventos com o mesmo nível que vemos nos EUA, Europa e Japão, mas a BGS tem tudo para se tornar cada vez mais um evento importante para o mercado nacional e também para mostrar que o Brasil é realmente um grande consumidor de jogos.\nEmbora este ano o espaço da BGS foi um pouco maior do que no ano passado, ainda assim ficou pequeno para tantos gamers presentes no evento. Com certeza os grandes destaques foram poder jogar os novos consoles, Xbox One e PlayStation 4, antes do lançamento, além de grandes jogos como Call of Duty: Ghosts, Hearthstone, Assassin’s Creed IV, Watch_Dogs, entre muitos outros.\nTodos stands de empresas grandes estavam muito legais, mas nada se compara ao palco montado pela Riot para as finais do campeonato de League of Legends. Além de empresas grandes internacionais, o evento contou também com empresas brasileiras, como a Flux e Hoplon.\nEu fui apenas no sábado, consegui jogar nos novos consoles, conheci pessoalmente o produtor brasileiro do FIFA, Gilliard Lopes, tive meu jogo Injustice autografado pelo produtor do game, Hector Sanchez, e também vi o Jovem Nerd e Azaghal. Foi um dia muito bom, e nem consegui ver todo evento.\nConsiderando todas dificuldades de produzir um evento deste porte, a organização está de parabéns pela iniciativa e pelas atrações que conseguiram trazer. Eu acredito que a BGS irá crescer cada vez mais, e que cada ano será melhor que o anterior, e um dia poderemos ter um evento realmente grande e de importância mundial.\nPara que eventos como este sejam cada vez maiores e frequentes aqui, temos que fazer nossa parte e apoiar a indústria de games. Todo mundo sabe que aqui é tudo mais caro por caso dos impostos, mas vemos alguns mudanças, como jogos lançados por R$150, que é algo muito próximo dos $60 dólares que são vendidos lá fora. Só para ressaltar, estou falando de jogo, de consoles. Este são caros mesmo por aqui, e nem preciso comentar o preço irreal do PS4K.\nReduzindo a pirataria, as empresas irão olhar para o Brasil cada vez com mais carinho, e podemos ter muitas coisas boa para indústria nacional. Lembre-se também que existem alternativas ainda mais baratas para PC, como o Steam e o Nuuvem, quem fazem promoções muito boas toda semana.\n","date":"4 de novembro de 2013","externalUrl":null,"permalink":"/como-foi-a-bgs-2013/","section":"Blog","summary":"Estamos longe de ter eventos com o mesmo nível que vemos nos EUA, Europa e Japão, mas a BGS tem tudo para se tornar cada vez mais um evento importante para o mercado nacional e também para mostrar que o Brasil é realmente um grande consumidor de jogos.\n","title":"Como foi a Brasil Game Show 2013","type":"posts"},{"content":"Existem muitas ferramentas para desenvolver jogos, como engines e frameworks, mas também existem outras que tem o objetivo de facilitar muito o desenvolvimento, que são os makers.\nUma maker é um software extremamente limitado para criação de jogos. Muita gente teve um primeiro contato com desenvolvimento de games através de makers, como o Game Maker e o RPG Maker. Eu mesmo comecei a brincar com o RPG Maker antes da faculdade. Tive vários problemas por não saber o que fazer e como fazer, pois mesmo sendo simples você ainda precisa aprender a usar a ferramenta.\nEu lembro que o RPG Maker tinha um projeto exemplo baseado nos Cavaleiros do Zodíaco, e como eu não sabia fazer algo do zero, passava horas editando esse jogo, mudando tudo pra o que acontecia. Por todas as suas características, eu acho um maker ideal para começar a fazer jogos e entender como funciona. Além de estudar a ferramenta, também é necessário uma base de lógica para pelo menos ter uma noção do que fazer.\nOutro uso dos makers é a criação de protótipos, pois eles só fáceis e rápidos de usar, pontos fortes para quem buscar prototipar uma ideia rapidamente. Além do uso como ferramenta de ensino e prototipagem, na minha opinião, os makers não servem pra mais nada. Você pode até fazer um jogo nele, mas são tão limitados que chega a ser pouco profissional usá-los para criar games.\nEmbora as empresa divulguem seus makers como software para desenvolver jogos, não se engane. Se você quer realmente aprender a fazer jogos com o mínimo de profissionalismo, utilize frameworks ou engines, e não tenha medo de programar!\n","date":"30 de outubro de 2013","externalUrl":null,"permalink":"/como-ser-um-programador-de-jogos-para-que-serve-um-maker/","section":"Blog","summary":"Existem muitas ferramentas para desenvolver jogos, como engines e frameworks, mas também existem outras que tem o objetivo de facilitar muito o desenvolvimento, que são os makers.\n","title":"Como ser um programador de jogos: Para que serve um Maker","type":"posts"},{"content":"Este ano, o Simpósio Brasileiro de Desenvolvedores de Games foi realizado na Universidade Presbiteriana Mackenzie em São Paulo, e mostrou, principalmente, as pesquisas que os acadêmicos estão realizando na área de games no Brasil.\nEm todas as trilhas muitos artigos foram apresentados, desde pesquisas mais técnicas, como captura de movimentos, até conceitos de game design e imersão. Este é o um dos poucos eventos de jogos que temos no Brasil, e por seu foco ser pesquisas acadêmicas podemos ver como estudantes e pesquisadores de todas as partes do país estão trabalhando para contribuir como esta área.\nO evento teve também o Festival De Jogos Independentes, que premiou jogos brasileiros publicados e em produção. O Combo Nuts, jogo que participei do desenvolvimento, concorreu em duas categorias mas infelizmente não ganhou prêmios.\nTodo conteúdo do evento foi muito interessantes, porém, na minha opinião, deveriam haver mais apresentações técnicas, além das teóricas, pois por termos poucos eventos de jogos eu considero importante conteúdos mais práticos para o dia-a-dia do desenvolvedor, como aconteceu no Unite.\nAbaixo estão alguns vídeos gravados pelo André Kishimoto da apresentação chamada Postmortem, que contou com a participação dos desenvolvedores de Dungeonland, Favela Wars e Amazônia.\n","date":"25 de outubro de 2013","externalUrl":null,"permalink":"/como-foi-a-sbgames/","section":"Blog","summary":"Este ano, o Simpósio Brasileiro de Desenvolvedores de Games foi realizado na Universidade Presbiteriana Mackenzie em São Paulo, e mostrou, principalmente, as pesquisas que os acadêmicos estão realizando na área de games no Brasil.\n","title":"Como foi a SBGames","type":"posts"},{"content":"O maior evento de games da América Latina, o Brasil Game Show, começa neste fim de semana em São Paulo! Além de muitas atrações para os jogadores, o evento também contará com um espaço de business para os desenvolvedores conhecerem empresas que oferecem serviços, além de outros desenvolvedores com stand para divulgar seus jogos.\nAbaixo está o press release do evento, que começa no dia 25 (apenas para imprensa e business nesse dia) e vai até dia 29. Confira os horários e não deixe de ir! Só lembrando que os ingressos para sábado e domingo estão esgotados, e que não será permitido entrar com mochilas e bolsas.\nEu estarei lá no sábado participando como imprensa e representando o blog. Irei conversar com pessoas da indústria do Brasil e de fora, e postarei tudo depois aqui!\nBrasil Game Show apresenta novidades do Mercado de Games de 25 a 29 de outubro em São Paulo A Maior Feira de Games da América Latina será um grande parque de diversões eletrônicas para milhares de crianças, adolescentes e adultos A Brasil Game Show (BGS) promete muita diversão aos visitantes de sua sexta edição. Após o sucesso da edição de 2012, em que recebeu mais de cem mil visitantes, a Feira garante ainda mais novidades para 2013, com o dobro do tamanho da edição anterior. Em cinco dias de Evento, a BGS reunirá 150 empresas e mais de 150 mil visitantes, além de Lançamentos, Campeonatos, Celebridades e muitas Atrações Especiais.\nOs gamers já provaram que são muito solidários. Em sua última edição, a Brasil Game Show, Maior Feira de Games da América Latina, arrecadou mais de 40 toneladas de alimentos, doados pelos visitantes do Evento. Em sua sexta edição, que será realizada entre os dias 25 e 29 de outubro, no Expo Center Norte, em São Paulo, a Brasil Game Show espera receber cerca de 150 mil visitantes. A doação de 1 kg de alimento não perecível garante ao visitante o benefício da meia-entrada, em uma ação para ajudar milhares de crianças atendidas pela Associação Prato Cheio. A entidade, fundada há mais de 10 anos, arrecada e distribui alimentos à instituições assistenciais.\nPara participar desta ação solidária, após garantir o ingresso de meia-entrada no site www.brasilgameshow.com.br/visitantes/ingressos, o visitante deve entregar o quilo de alimento não perecível na entrada do Evento.\nAlém disso, a BGS também estimula a inclusão social. Desde 2011, o Evento conta com cerca de metade de seu staff composto por cadeirantes e outros portadores de necessidades especiais.\nFique por dentro do que vai rolar na BGS 2013:\nLançamentos: A BGS 2013 reunirá as mais recentes novidades, com uma prévia dos sucessos previstos para o final do ano, e até mesmo alguns títulos que chegarão ao mercado somente em 2014.\n– XBOX ONE – O novo console da Microsoft será apresentado na Brasil Game Show antes de seu lançamento mundial;\n– NVIDIA Shield – O portátil da NVIDIA será apresentado pela primeira vez no Brasil durante o Evento;\n– RetroN 5 – Também inédito, este console é o sonho dos fãs de consoles do passado e é considerado um aparelho 10 em 1, pois aceita fitas de NES, Famicom, Super Nintendo, Super Famicom, Mega Drive, Genesis, Game Boy, Game Boy Color, Game Boy Advance e Master System;\n– PlayStation 4 – O grande lançamento da Sony será apresentado ao público brasileiro antes do seu lançamento mundial;\n– Assassin’s Creed 4: Black Flag – Uma das maiores séries de sucesso da atualidade terá a sua sequência apresentada no stand da NC Games e Ubisoft;\n– Battlefield 4 – O game de Guerra será destaque no stand da Warner/EA com 32 estações simultâneas disponíveis para os visitantes;\n– Call of Duty: Ghosts – O novo título da Activision será apresentado pela primeira vez no país;\n– Diablo III – Os fãs da Blizzard poderão jogar este título em sua versão console no stand da empresa;\n– FIFA 14 – O melhor game de futebol da atualidade e que conta com estádios, atletas e performances reais estará presente no stand da Warner/EA;\n– Just Dance 2014 – O game preferido do público feminino traz os hits da nova temporada para o stand da NC Games e Ubisoft;\n– Batman: Arkham Origins – Haverá 16 estações do novo Batman para jogar no stand da Warner, já com a dublagem em português;\n– The Witcher 3 – O novo título da CD Projekt Red, que chegará ao mercado somente em 2014, estará disponível em apresentações para a imprensa no stand de sua produtora;\n– Hearthstone: Heroes of Warcraft – O ainda não lançado e divertido jogo de estratégia de cards estará no stand da Blizzard;\n– Assault Fire – FPS que traz toda sua ação e adrenalina para a Brasil Game Show. Durante a Feira, a Level Up! anunciará diversas novidades do jogo;\n– Razer Edge – o novo tablet super poderoso ideal para games;\n– Razer Blade Pro e Blade 14″ – Os laptops gamers mais finos do mundo;\n– Periféricos Razer Battlefield 4 – Teclado, mouse, mousepad e outros acessórios para o gamer que quer jogar como profissional;\n– Destaques da Hoplon – A empresa brasileira de Santa Catarina apresenta os games: Heavy Metal Machines, Minhokarts, Fallen Earth, Bount Hounds Online, APB: Reloaded e Seer;\nProdutores Internacionais: Os visitantes da Brasil Game Show 2013 terão a oportunidade de conhecer os Produtores de alguns dos jogos mais aclamados do momento.\n– Gilliard Lopes (FIFA 14 – EA/Warner);\n– Hector Sanchez (Injustice – EA/Warner);\n– Eric Holmes (Batman Arkham Origins – EA/Warner);\n– Tyman Smekata (Dying Light – EA/Warner);\n– Designers do League of Legends (Riot Games);\n– Desenvolvedores do Heavy Metal Machines (Hoplon);\nAtrações: Celebridades, Shows, Arcades e muita Música para quem curte Games.\n– Helder Moreira (Escultor Oficial da Marvel – Seven);\n– Marcelo D2 (Cantor e rapper – Warner);\n– Banda Mega Driver (Seven);\n– Banda GameBoys (Seven);\n– Banda Pentakill (Riot Games);\n– Gil Brother “Away Nilzer” (Humorista – Seven);\n– Mundo Canibal (Humoristas – Seven);\n– Arcade Center – Nesta área será possível testar todos os jogos que que a WB Games está lançando para o quarto trimestre do ano, como Need For Speed Rivals, Dying Light, Disney Infinity, LEGO Marvel Super Heroes, Hot Wheels e Mad Max;\n– Autógrafos – Os visitantes poderão levar seus jogos e produtos licenciados da Blizzard para que sejam autografados por membros da equipe no stand da empresa;\nCampeonatos: Torneios com os melhores jogadores do Brasil e do mundo serão destaque na BGS.\n– Desafio Internacional de League of Legends – As melhores equipes do Brasil e da América Latina se enfrentarão neste torneio do game que conta com mais de 32 milhões de jogadores ativos por mês, que marca o primeiro encontro das duas regiões no cenário competitivo;\n– FIFA 14 – O principal simulador de futebol do mundo, contará com estações que vão possibilitar testes e torneios de até 32 jogadores. Os torneios acontecerão nos períodos da manhã e noite e serão abertos ao público;\n– Elsword – O MMORPG, que traz diversas opções de combos e magias, com várias missões e também a opção de PVP, contará com torneios no stand da Level Up! As inscrições acontecem no local;\nCompras: Centenas de Jogos, Consoles, Acessórios e Produtos Oficiais estarão à venda.\n– Pré-venda – No stand da Saraiva, alguns lançamentos estarão disponíveis para venda ou pré-venda. Haverá também colecionáveis, action figures e camisetas voltadas ao universo geek;\n– Loja de produtos oficiais licenciados da franquia Street Fighter – Bonés, camisetas e outros produtos personalizados com a marca de um dos maiores jogos de luta de todos os tempos;\n– Loja Oficial da BGS – Cases para celular, mousepads, bolsas, canecas, camisas e bonés da Maior Feira de Games da América Latina;\n– Lojas Americanas – Um dos maiores varejistas do país contará com centenas de produtos disponíveis para os visitantes da BGS.\nA lista de expositores inclui: XBOX, BoaCompra, Seven, Riot Games, PlayStation, Saraiva, Lojas Americanas, Warner, EA, Activision, Blizzard, NVIDIA, Razer, Level Up!, Hoplon, NC Games, Ubisoft, Nurigo Games, Live TIM, CD Projekt Red, Disney, Kingston, Corsair, Game Insight, InnoGames, ClickJogos, Roccat, Philips, Mad Catz, Hyperkin, Loja de Roupas e Acessórios Oficiais Licenciados da franquia Street Fighter, Grupo Editorial Record, G4BOX, Ratto Games, Aiyra, Playphone, Square Enix, Positivo, Pingo no i, Furfle, Epay, Flux Game Studio, Galápagos Jogos, Atrativa Game House, E-prepag, Insignia Games, Boxware, Insane, InstallCore, Ecogames, CMD, TIMWE, SoMemórias, Music Brokers, Devolver Digital, UBV, Inconm, Rixty, Global Collect, Min!inimo, Tíbia BR, Pixel Federation, EVGA, Qualcomm, Movile, SENAC, Z8 Games, The Game Station, SEBRAE, BC Lanches, Bob’s, Spoleto, Pizza al Taglio, Texas Grill, Casa do Pão de Queijo, Di Nardi Fast-Food, Jhonny Café, Fast Snack, EuQueroAçaí, Joysteak, Minas in Sampa, entre outras.\nSERVIÇO BRASIL GAME SHOW\nData: 25 a 29 de Outubro\nLocal: Expo Center Norte – Rua José Bernardo Pinto, 333 – Vila Guilherme – SP\nHorários:\n25 de Outubro (exclusivo para Imprensa e Business) – 11h às 20h\n26 e 27 de Outubro (público geral) – 11h às 20h\n28 e 29 de Outubro (público geral) – 13 às 22h\nInformações: www.brasilgameshow.com.br\nSobre a Brasil Game Show\nA Brasil Game Show (BGS) é a Maior Feira de Games da América Latina. Realizada em seis edições consecutivas, a BGS é uma empresa 100% focada no crescimento do Mercado de Jogos Eletrônicos e a Feira de games que mais cresce no mundo. Sucesso e recorde de público, o Evento reúne os principais nomes da Indústria de Games. Confira todos os detalhes da última Edição no site oficial www.brasilgameshow.com.br ou acompanhe as últimas novidades do Evento no Facebook emwww.facebook.com/BrasilGameShow .\n","date":"24 de outubro de 2013","externalUrl":null,"permalink":"/brasil-game-show-2013/","section":"Blog","summary":"O maior evento de games da América Latina, o Brasil Game Show, começa neste fim de semana em São Paulo! Além de muitas atrações para os jogadores, o evento também contará com um espaço de business para os desenvolvedores conhecerem empresas que oferecem serviços, além de outros desenvolvedores com stand para divulgar seus jogos.\n","title":"Brasil Game Show começa neste fim de semana","type":"posts"},{"content":"As vezes aguardamos uma arte para programar uma parte do jogo. O grande problema é que o artista pode demorar, ou você pode nem ter um artista ainda. Nesse caso, vale a pena utilizar imagens provisórias para programar o jogo, mas é importante levar e consideração o tamanho da imagem.\nSe você utilizar imagens provisórias, mas com o tamanho correto, quando tiver as artes finais o trabalho será apenas substituir as imagens e acertar pequenos detalhes. Isso ajuda muito a não perder tempo dependendo de outras pessoas, e você pode programar (e testar) todo o game play desta maneira.\nEu fiz isso no meu TCC da pós-graduação, Oniro. Eu ainda não tinha um artista, mas comecei a programar o jogo utilizando imagens provisórios de outros jogos. No final, faltando um mês para entregar o projeto, eu tinha o jogo pronto e consegui um artista. Neste mês final substituí todas as imagens pelas artes finais, e não tive muito trabalha para adaptar as imagens. Mas o melhor disso tudo foi não perder tempo esperando encontrar um artista.\nExiste dois sites muito legais que podem ajudar nisso, o Sprite Database, que tem imagens de vários jogos antigos (eu usei muitas imagens desse site para o protótipo), e o 2D Art for Programmers, que tem imagens e também ensina a criar usando Inkscape.\nSe você quer arte original e gratuita, o melhor lugar para encontrar é no Open Game Art, pois lá muitos artistas publicam artes para outras pessoas usarem, mas sempre leia sobre a forma de distribuição, alguns artistas colocam restrições e pedem créditos pelas imagens. Todas essas opções são para jogos em 2D, para 3D eu conheço apenas o Turbo Squid, que tem modelos e animações pagos e gratuitos.\nNão perca tempo esperando encontrar um artista para começar o projeto, se você é programador comece o quanto antes a escrever código usando imagens temporárias, mas sempre pensando na melhor maneira de substituí-las quando puder. Não se esqueça que pra isso dar certo você deve avisar o artista pra te mandar as imagens do jeito que você precisa!\nUPDATE\nSugestão do leitor Francisco Padro, o site Blendswap com modelos 3D gratuitos.\n","date":"23 de outubro de 2013","externalUrl":null,"permalink":"/programar-sem-ter-a-arte-final/","section":"Blog","summary":"As vezes aguardamos uma arte para programar uma parte do jogo. O grande problema é que o artista pode demorar, ou você pode nem ter um artista ainda. Nesse caso, vale a pena utilizar imagens provisórias para programar o jogo, mas é importante levar e consideração o tamanho da imagem.\n","title":"Como ser um programador de jogos: Programar sem ter a arte final","type":"posts"},{"content":"Incrível é a palavra que pode descrever melhor como foi o Unite Brasil, o primeiro evento da Unity realizado por aqui e que mostrou o nível de eventos para desenvolvedores de jogos que existem fora do país.\nEu esperava menos, mas vou explicar o por que. Existem poucos eventos para desenvolvedores no Brasil, e esses poucos eventos são fracos e com pouco conteúdo interessante pra quem é realmente um desenvolvedor de jogos. Eu estava esperando que o Unity fosse mais um evento assim, e me enganei.\nAs palestras do pessoal da Unity foram incríveis, mostrando como otimizar um jogo para reduzir draw calls, efeitos avançados com partículas, e o tão esperado recurso de 2D. Este recurso 2D era tão esperado que, mesmo sendo a última palestra depois de 10 horas de evento, todo mundo estava animado e rindo a toa das facilidades que a Unity vai proporcionar para o desenvolvimento de jogos 2D.\nO 2D foi, sem dúvidas, um movimento inteligente e necessário da Unity para fazer sua engine ser ainda mais usada. Outro destaque foi a abertura do evento pelo simpático David, um dos fundadores da Unity que revelou estar envergonhado em ter demorado tanto para trazer o evento ao Brasil, sendo que somos o terceiro país que mais usa a Unity.\nÉ claro que tiveram palestras mais sem graça, como da Microsoft e Blackberry, que estavam interessados em convencer os desenvolvedores a publicar seus jogos nas suas plataformas móveis. Não estou criticando as plataformas, que são ótimas opções, mas as demais palestras foram mais legais.\nSem dúvidas, os pontos altos do evento foram as palestras de dois estúdios brasileiros, a Behold, criadores do Knights of Pen and Paper, e Aquiris, que fizeram a demo pra Unity 3.0 chamado Bootcamp, além de outros jogos. Ambos mostraram o caminho difícil que foi chegar ao seu sucesso, e ambos usaram a Unity desde as suas primeiras versões. Na minha opinião, estes são os dois estúdios brasileiros mais promissores e que estão representando muito bem a nossa indústria.\nEu tenho mais coisas que quero falar sobre o evento, mas para não deixar este texto muito grande, vou fazer outros posts. Alguns assuntos merecem mais destaques, e também quero dar a minha opinião sobre tudo que foi apresentado e me chamou a atenção. Foi muito bom também ter visto o Combo Nuts lá como um dos jogos em destaque produzidos com a Unity!\nAlém de ter sido um excelente evento, eu gostei muito de rever pessoas que fizem parte da trajetória da minha carreira, e também conheci outras. Queria agradecer e parabenizar a Unity, principalmente, ao Jay Santos, que ajudou a organizar este evento fantástico e também fez uma apresentação muito boa sobre efeitos gráficos. Um abraço também ao Odair, um cara que conheci no evento e disse que acompanha o meu blog.\n","date":"22 de outubro de 2013","externalUrl":null,"permalink":"/unite-brasil-2013/","section":"Blog","summary":"Incrível é a palavra que pode descrever melhor como foi o Unite Brasil, o primeiro evento da Unity realizado por aqui e que mostrou o nível de eventos para desenvolvedores de jogos que existem fora do país.\n","title":"Como foi o Unite Brasil 2013","type":"posts"},{"content":"A game designer Mariana Boucault apresentou uma palestra sobre os tipos de monetização para jogos mobile, e em sua apresentação cada tipo foi exposto com seus prós e contras.\nA apresentação abaixo pode ajudar bastante quem está em dúvida em qual modelo de monetização usar no seu jogo, pois através dos pontos apresentados podemos ver quais modelos valem mais a pena para cada tipo de jogo. Não basta apenas fazer um jogo, todo desenvolvedor também deve pensar na melhor forma de ganhar dinheiro com seu projeto, mas sem incomodar ou abusar do seu jogador!\nPara saber mais, siga a Mariana no twitter!\n","date":"21 de outubro de 2013","externalUrl":null,"permalink":"/monetizacao-em-jogos/","section":"Blog","summary":"A game designer Mariana Boucault apresentou uma palestra sobre os tipos de monetização para jogos mobile, e em sua apresentação cada tipo foi exposto com seus prós e contras.\n","title":"Modelos de monetização em jogos","type":"posts"},{"content":"Esta é a segunda entrevista com o meu grande amigo Nicholas Souza, que atualmente é game designer na Ubisoft em Montreal. Na primeira entrevista conhecemos o início da sua carreira, passando pela Ubisoft Brasil e Glu Mobile. Confira agora como ele chegou no Canadá e seu trabalho no estúdio brasileiro Insólita.\nComo muita gente por aqui, Nicholas também sonhava em ir pra fora do país trabalhar com jogos AAA. Depois de uma longa caminhada, ele alcançou um grande passo em sua carreira indo para a Ubisoft Montreal.\n1) Desde a sua última entrevista para o blog muita coisa mudou na sua carreira. Depois da Glu Mobile você foi para a empresa brasileira Insólita Studios trabalhar com jogos para redes sociais, foi uma mudança muita grande em relação à sua experiência anterior?\nSim e não. Em sentido de organização da empresa e número de funcionários, foi uma mudança relativa, já que na Glu Mobile tínhamos mais pessoas na equipe, espaço era maior e tínhamos um departamento grande de QA. Em balanceamento, já digo que foi muito similar ao trabalho que já tinha realizado na Glu.\n2) Você trabalhou como Game Designer no jogo do Chico Bento para Facebook, lançado pela Level Up! Games. Quais foram suas responsabilidades nesse projeto?\nNo Chico Bento eu fui o responsável pelo balanceamento do jogo, definindo valores dos itens no jogo, tempo de construção das instalações da fazenda e ajudando nas estratégias de monetização. Durante o projeto também ajudei dando feedbacks no core game loop e processo de desenvolvimento do jogo em si.\n3) Hoje você está trabalhando no Canadá, quando e por quê você decidiu que queria trabalhar fora do Brasil?\nDesde que entrei na indústria de games eu tinha um sonho de trabalhar em jogos AAA (as grandes produções do mercado de jogos mundial), então tracei uma meta de que antes dos 30 anos estaria trabalhando/produzindo um desses jogos.\nQuando entrei na Ubisoft pela primeira vez no final de 2008 achei que rapidamente iria alcançar esse objetivo. Porém quando o estúdio fechou, tive que recomeçar tudo de novo. Alguns membros da equipe começaram a enviar currículos para fora do pais. Decidi ficar mais um tempo me aprimorando e testando meus conhecimentos adquiridos na Ubisoft para poder me arriscar fora novamente. Perto do final da produção de meu primeiro jogo na Glu como Lead Game Designer, o Blood \u0026amp; Glory, recebi a maravilhosa noticia de que um amigo meu, Thiago Klafke (environment artist na Ubisoft São Paulo), estava de malas prontas para o seu novo emprego na Blizzard. Nossa conversa foi a ultima coisa que faltava para eu me arriscar de vez ao projeto de tentar ir para fora do pais. Ao termino do Blood \u0026amp; Glory, estava muito confiante nos meus conhecimentos aplicados no game design e liderança criativa de projeto. Pedi demissão da Glu (até mesmo sem ganhar meu bônus pelo sucesso do projeto) e comecei a focar em enviar currículos para empresas no exterior.\nO processo foi longo e difícil. Tiveram vezes que pensei em ficar no Brasil (como quando fui trabalhar na Insolita) mas quando finalmente deu certo, fiquei muito contente.\n4) Você é Game Designer na Ubisoft em Montréal no Canada, como você foi atrás disso e como você recebeu a notícia de tinha conseguido avançar esse degrau importante na sua carreira indo para fora do país?\nPor já ter uma boa experiência na área, comecei a enviar meu currículo para vagas que tinham o perfil que procurava nos lugares onde gostaria de morar. Surgiram ideias de tentar em outros países, pois as vezes algumas vagas eram atrativas, mas defini para mim o objetivo de que gostaria de trabalhar numa empresa que fizesse jogos que eu gostaria de jogar. No processo, fiz algumas entrevistas e 3 empresas quiseram me contratar. Acabei optando pela Ubisoft, que apareceu depois. Por já conhecer os processos da empresa e por Montreal ser “O” estúdio para se trabalhar em AAA, fiquei muito feliz quando me fizeram a proposta.\n5) Foi muito difícil adaptar-se a um outro país? O dia-a-dia na empresa é muito diferente daqui?\nOlha, a adaptação a cidade não foi difícil. Como vivi em São Paulo a vida toda, estava acostumado a transito, stress, muitas pessoas, alimentação e lazer caríssimos. Ao chegar em Montreal e ver uma cidade menor, organizada, com baixíssimos índices de violência, com custo de vida baixo e qualidade de vida alta, para mim foi como ir para uma cidadezinha no interior de São Paulo tendo o privilégio de poder comprar tudo o que quer.\nSobre a empresa, a adaptação a empresa foi bem rápida. Como já conhecia todos os processos, não precisei me adaptar muito. Aqui as pessoas não fazem amizades tão rapidamente quanto no Brasil. Isso leva mais tempo. Mas hoje em dia estou muito bem integrado com o pessoal.\nO que eu gosto muito do dia-a-dia da empresa é que como eles já estão acostumados a fazer jogos, o ritmo da empresa é mais calmo, tudo é mais organizado e cada developer sabe qual é o seu quadrado e como dar o seu melhor pelo projeto. Dentro da Ubisoft temos academia, locadora de jogos, clinica médica só para funcionários, loja de jogos exclusiva, festas 2 vezes ao ano, baggels 1 vez ao mês e frutas 1 vez por semana, entre outras regalias. A empresa cuida muito bem dos funcionários. Tem seus problemas, como qualquer outra, mas em relação a empresas de jogos no Brasil, é muito melhor.\n6) Existe muita burocracia para trabalhar em outro país? É mais fácil quando se tem um emprego garantido?\nÉ bem complicado ir para outro pais e tentar arranjar emprego lá se você não conhece ninguém, como eu que não conhecia, ou alguém que tem pouca experiência na área. Minha dica é: se torne bom na sua profissão e ai tente ir para fora. Assim que você consegue, é relativamente rápido, mas tem muita burocracia de papelada para preencher.\n7) Em quase 1 ano vivendo em Montreal e trabalhando na Ubisoft, o que mais mudou na sua concepção de desenvolvimento de jogos?\nEu acho que não mudou muito, só esclareceu alguns pontos. Aqui a escala é muito maior, então se você não tem um foco e sabe exatamente o que fazer, você pode dar muitas dores de cabeça aos membros da equipe. Para mim a grande diferença que encontrei em termos de desenvolvimento é como as pessoas aqui aprendem com os erros e feedbacks dados por todos da equipe. Eles não sabem como fazer tudo, sempre. Então rolam muitos feedbacks que no final tornam o jogo melhor. E como boa parte da equipe os entende como algo construtivo, você se sente parte de uma grande equipe em que todos podem contribuir para melhorar. Você cresce junto com todos os outros. No Brasil, isso já é um pouco complicado já que as pessoas não aceitam tão bem feedbacks que elas não entendem, ou criticam algo por simplesmente não gostarem. Acho que isso é um dos motivos que faz com que eles consigam se aprimorar em um ritmo absurdo. Trabalho atualmente numa equipe de 8 designers, todos com perfis bem diferentes. Todos dão feedback no trabalho uns dos outros e os designs só ficam melhores.\n8) Quais são seus próximos degraus na sua carreira?\nMeu próximo passo é ir para o time de game design de um AAA de console, como Assassin’s Creed, Watchdogs ou Far Cry, continuando a aprimorar meus conhecimentos e minhas abilidades de designer. Depois é ganhar mais experiência para me tornar sênior e lead game designer em AAA.\n9) Fale um pouco do jogo “The Mighty Quest For Epic Loot” que você está trabalhando.\nO Mighty Quest for Epic Loot é um F2P AAA hack\u0026amp;slash para PC onde o jogador ataca castelos utilizando um dos heróis disponíveis no jogo (Cavaleiro, Arqueiro e Mago), roubando o “loot” deles e usando dinheiro para aprimorar o seu castelo com armadilhas, labirintos e monstros tentando se defender dos ataques de outros jogadores.\nO jogo tem um estilo visual e humor bem diferenciado de outros jogos e está em constante atualização. No momento o jogo encontra-se no closed beta.\n10) O que você recomenda para as pessoas que querem trabalhar fora do Brasil com jogos?\nA primeira coisa que recomendo é que ganhe experiência com desenvolvimento de games na sua área, e se aprimore. Procure ser o melhor no que faz. Entre em concursos de forums de modelagem (caso artista), crie seus projetos particulares e compartilhe (como programador) e colha o máximo de feedbacks possíveis para estar sempre se aprimorando.\nQuando você achar que estiver pronto, vá a luta e mostre seu trabalho para as empresas.\nSem ter experiência e fazer bem seu trabalho, você dificilmente será chamado por uma empresa de fora, pois trazer alguém envolve altos custos para o empregador (pagar realocação, mobiliário do apartamento, hotel, passagem de avião, etc). Assim, elas vão apostar quando virem que seu trabalho pode contribuir no projeto.\nMuito obrigado ao Nicholas por ter participado novamente de uma entrevista aqui no blog, com certeza sua experiência será uma grande referência para quem quer seguir nesta área!\n","date":"19 de outubro de 2013","externalUrl":null,"permalink":"/entrevista-nicholas-game-designer-ubisoft/","section":"Blog","summary":"Esta é a segunda entrevista com o meu grande amigo Nicholas Souza, que atualmente é game designer na Ubisoft em Montreal. Na primeira entrevista conhecemos o início da sua carreira, passando pela Ubisoft Brasil e Glu Mobile. Confira agora como ele chegou no Canadá e seu trabalho no estúdio brasileiro Insólita.\n","title":"Entrevista: Nicholas Souza, game designer na Ubisoft Montreal","type":"posts"},{"content":"Muita gente tem mais facilidade em aprender vendo como se faz do que através de livros, por exemplo. Ver um código ou um projeto inteiro de exemplo ajuda bastante em alguns casos, e neste post vou mostrar alguns jogos famosos que tem seu código aberto (opensource).\nEu comecei a série Programando PONG com o objetivo de mostrar, através de um exemplo, a programação de um mesmo jogo em plataformas e tecnologias diferentes. Isso ajuda bastante a começar a entender tanto o código do jogo quando a tecnologia usada.\nPor isso, decidi postar aqui alguns jogos muito legais que são opensource, e você pode baixar e revirar seu código a vontade para aprender e até tentar fazer funcionar em outras plataformas se quiser, é um bom desafio e ajuda a aprender detalhes da arquitetura de cada plataforma.\nA empresa mais legal de todas para compartilhar códigos de jogos é a Id Software, eles abriram o código de praticamente todos seus jogos antigos no seu GitHub! Confira abaixo alguns jogos, e aprenda com o mestre da computação gráfica John Carmack. Todos foram desenvolvidos em C/C++, com partes em Objective-C no caso das versões de iOS.\nQuake – https://github.com/id-Software/Quake\nQuake 2 – https://github.com/id-Software/Quake-2\nQuake 3 Arena – https://github.com/id-Software/Quake-III-Arena\nDOOM – https://github.com/id-Software/DOOM\nDOOM (iOS) – https://github.com/id-Software/DOOM-iOS\nDOOM 3 – https://github.com/id-Software/DOOM-3\nWolfenstein 3D – https://github.com/id-Software/wolf3d\nWolfenstein 3D (iOS) – https://github.com/id-Software/Wolf3D-iOS\nA Mojang, empresa que do Notch, o criador de Minecraft, participou de um Jam através do HumbleBundle e compartilhou o código do jogo Catacomb Snatch, desenvolvido em Java. Provavelmente muito código daí veio do Minecraft. Um jogo que o Notch estava desenvolvendo, 0x10c, e que teve sua produção congelada, teve seu código liberado também.\nCatacomb Snatch – https://github.com/Maescool/Catacomb-Snatch\n0x10c – https://github.com/mappum/0x10code\nOutro jogo que vale a pena conhecer seu código é o Browser Quest, um jogo multiplayer online desenvolvido com HTML5 e Javascript. Além da arte ser muito bonita, feita em pixel art, você pode aprender muitas coisas legais relacionada a desenvolvimento web.\nBrowserQuest – https://github.com/mozilla/BrowserQuest\nEu também tenho alguns jogos que coloquei no GitHub. Não são nada comparados com estes outros, mas também podem ajudar a aprender mais de uma determinada tecnologia. Pretendo adicionar mais jogos meus lá em breve!\nSpaceShip 4042 (XNA)\nSpaceShip 4042 (HTML5)\nSpaceShip 4042 (J2ME)\nPONG (HTML5)\nEspero que tenha gostado desta lista, agora não tem desculpa para não aprender com tantos exemplos feitos por profissionais da área! Se tiver sugestões de código aberto para colocar nesta lista, deixe um comentário. Lembrando que é sempre bom procurar no GitHub por código de exemplo entre os vários projetos públicos que existem lá.\n","date":"16 de outubro de 2013","externalUrl":null,"permalink":"/como-ser-um-programador-de-jogos-codigos-opensource/","section":"Blog","summary":"Muita gente tem mais facilidade em aprender vendo como se faz do que através de livros, por exemplo. Ver um código ou um projeto inteiro de exemplo ajuda bastante em alguns casos, e neste post vou mostrar alguns jogos famosos que tem seu código aberto (opensource).\n","title":"Como ser um programador de jogos: Códigos opensource","type":"posts"},{"content":"Vou começar mais uma série de posts aqui no blog para apresentar como é por dentro dos grandes estúdios de desenvolvimento de jogos espalhados pelo mundo, e o primeiro será a Epic Games!\nMuita gente sonha em trabalhar em grandes empresas, participar de projetos de jogos famosos e curtir tudo que estas empresas oferecem para seus funcionários, desde coisas simples como horário bem flexível até comidas, jogos, eventos, festas, e muitas outras coisas.\nNeste série vou mostrar vídeos disponíveis na internet sobre como são os estúdios por dentro. Neste primeiro post vamos conhecer a Epic Games, a empresa que cresceu muito com o Unreal Tournament e reinventou os jogos de tiro em terceira pessoa nos consoles com Gears of War. Eles também possuem a game engine comercial mais utilizada em jogos AAA, a Unreal Engine (que possui uma versão gratuita chamada UDK), e também desenvolveram Infinity Blade para iOS.\nA tour pelo estúdio é apresentada pelo famoso Cliff Bleszinski, também conhecido como CliffB, o game designer da série Unreal e Gears of War. Confiram o vídeo abaixo e reparem no mesinha pouco decorada que o Cliff trabalha!\nVale a pena comentar que o Cliff não está mais na Epic Games, ele saiu ano passado para trabalhar em seus próprios projetos.\n","date":"14 de outubro de 2013","externalUrl":null,"permalink":"/epic-games/","section":"Blog","summary":"Vou começar mais uma série de posts aqui no blog para apresentar como é por dentro dos grandes estúdios de desenvolvimento de jogos espalhados pelo mundo, e o primeiro será a Epic Games!\n","title":"Por dentro dos grandes estúdios: Epic Games","type":"posts"},{"content":"No último post desta série falei sobre a técnica de usar um Playground para testar o jogo durante o desenvolvimento. Desta vez, o assunto será protótipos.\nEm primeiro lugar, o mais importante que devemos sempre ter em mente é que protótipos são descartáveis. Nunca utilize o código do protótipo no seu jogo! Você pode fazer algumas coisas simples para evitar isso, como utilizar uma tecnologia diferente para desenvolver o protótipo, assim você não ficará tentado a continuar o jogo a partir do protótipo ou mesmo pegar pedaços do código e usar novamente.\nAntes de falar por que o código do protótipo é descartável, vamos definir melhor o que é um protótipo. Antes de sentar e programar o jogo, precisamos validar se a jogabilidade definida pelo game designer é possível de ser desenvolvida e se ficará divertida de jogar. Muitas ideias de jogos são deixadas de lados através da realidade que o protótipo trás ao jogo.\nPodemos dizer que é um recurso muito bom para colocar os pés no chão, muito melhor do que perder semanas, meses ou anos tentando fazer algo funcionar sem saber se ficará bom. Abaixo está um video do protótipo do Bioshock Infinite, usado para validar a jogabilidade de movimentar o personagem através de trilhos e atirar em alvos ao mesmo tempo. Sem o protótipo eles não teriam verificado se era possível e se ficaria divertido no jogo.\nMas, por que o código do protótipo é descartável? Isso é simples, pois tudo que você programar no protótipo será apenas código para testar. Neste caso, não é um teste como no Playground, onde usamos uma fase de testes dentro do jogo para verificar algo antes de programar. O protótipo é um código feito as pressas, sem técnicas e padrões, com o único objetivo de validar o quanto antes se aquela ideia é possível de fazer e se ficará divertida. A imagem abaixo é de um protótipo que desenvolvi antes de programar meu primeiro jogo com SDL na pós-graduação.\nPor tanto, no protótipo o programador está liberado para fazer qualquer coisa, contanto que a jogabilidade a ser testada seja implementada, e que o game designer consiga jogar e analisar o resultado. Com a ideia bem definida e testada no protótipo, jogamos tudo fora e partimos para o começar a produção do jogo. E, se for necessário testar algo durante o desenvolvimento, utilizamos o Playground.\nO protótipo não necessáriamente precisa ser programado, podemos usar protótipos de papel ou qualquer outra coisa, como peças de Lego e objetos de jogos de tabuleiro. A foto abaixo é de um protótipo de papel de um jogo de explorar calabouços que desenvolvi com um grupo durante a pós-graduação. Fizemos apenas o protótipo para aprender e demonstrar a técnica com papel.\n","date":"9 de outubro de 2013","externalUrl":null,"permalink":"/como-ser-um-programador-de-jogos-prototipos/","section":"Blog","summary":"No último post desta série falei sobre a técnica de usar um Playground para testar o jogo durante o desenvolvimento. Desta vez, o assunto será protótipos.\n","title":"Como ser um programador de jogos: Protótipos","type":"posts"},{"content":"O livro Manual do Indie Game Developer – Versão Android e iOS foi lançado este ano pela editora Ciência Moderna e trás muitos conceitos de desenvolvimento de jogos explicados pelo autor Cleuton Sampaio.\nEm um primeiro momento fiquei impressionado pela abordagem de alguns temas neste livro, como prototipagem, física e OpenGL ES 2.0. Na parte de prototipagem são apresentados conceitos de como fazer e até mesmo dicas de softwares, como o aplicativo Codea para iPad. É muito interessante a ideia de criar um protótipo diretamente no iPad, por exemplo, pois isto possibilita testar o gameplay no próprio aparelho, o que ajuda bastante.\nSão apresentados frameworks de física como a famosa Bullet, o pouco usado Chipmunk, e o preferido de qualquer framework 2D, a Box2D. O autor se aprofunda nos conceitos da Box2D, o que é muito legal por que eu mesmo já apanhei bastante no começo, e o conteúdo deste livro com certeza ajuda a começar e entender como funciona a física neste framework usado em grandes jogos mobile como Angry Birds.\nO capítulo sobre OpenGLES 2.0 merece destaque também pela explicação dos conceitos de computação gráfica, tudo com foco em 2D para dispositivos móveis. Não temos livros em português bons sobre este assunto, e com certeza este livro da uma boa introdução nesta parte da computação gráfica.\nAlgumas coisas me incomodaram no livro como o autor não deixar claro que devemos jogar o protótipo fora antes de fazer um jogo, pois é um código descartável apenas para testar conceitos, e também o fato dele considerar que a criação de personagens fazer parte de game design, o que não é verdade por que a única função do game designer é criar a jogabilidade e tornar o jogo divertido, seguindo o ciclo desafio-objetivo-recompensa.\nEmbora seja muito legal ver a implementação para Android em Java e para iOS em Objective-C, isto não é prático para o dia-a-dia de um desenvolvedor, pois escrever o mesmo código duas vezes em linguagens diferentes não faz sentido para lançar o mesmo jogo em duas plataformas mobile diferentes. Por isso, frameworks como a Cocos2d-x e Corona SDK, além de game engines como a Unity 3D, são muito usados na indústria, pois permitem escrever apenas um código e publicar para diversas plataformas.\nEste é um livro brasileiro muito bom, porém curto por ter apenas 300 e poucas páginas e não abordar com detalhes outros assuntos importantes, como scale de imagens e spritesheets. Porém, eu recomendo pela base de prototipagem, física e OpenGL que este livro explica muito bem.\nMuito obrigado a editora Ciência Moderna pela versão digital deste livro! Você pode o comprar ambas versões, impressa ou digital, no site da editora.\n","date":"8 de outubro de 2013","externalUrl":null,"permalink":"/manual-do-indie-game-developer/","section":"Blog","summary":"O livro Manual do Indie Game Developer – Versão Android e iOS foi lançado este ano pela editora Ciência Moderna e trás muitos conceitos de desenvolvimento de jogos explicados pelo autor Cleuton Sampaio.\n","title":"Manual do Indie Game Developer - Versão Android e iOS","type":"posts"},{"content":"Hoje aconteceu algo que até então eu não tinha presenciado: vi uma pessoa no metro jogando um jogo que programei quando trabalhei na Electronic Arts, o FIFA 12 para Android. Isso foi tão diferente que tive vontade de compartilhar aqui esta experiência.\nJogos são uma forma interativa de entretenimento, que proporciona para muitas pessoas diversão e um momento de tranquilidade (ou não), uma fuga da realidade do dia-a-dia. Como Huizinga escreveu em seu livro Homo Ludens, o ser humano sempre inventou maneiras de transformar coisas em jogos, e todos gostam e precisam de jogos para se divertir, aprender e desenvolver o raciocínio lógico.\nEnquanto um jogador pensa que encaixar blocos do Tetris é apenas um passa-tempo, por trás disso ele está desenvolvendo seu raciocínio lógico. Quantos casos já não vimos do uso de jogos para aprendizado, e até mesmo em fisioterapia. Quantas vezes já não ouvimos falar de pessoas que se conheceram, ficaram amigos, namorados e até casaram por causa de um jogo? Quantos grupos de amigos não se juntam para jogar? Quantos produtos e indústrias nasceram por causa dos jogos?\nÉ incrível como um jogo pode fazer parte e até mudar a vida de uma pessoa, e é mais incrível ainda ter o “poder” de causar este efeito. Quando fazemos um jogo e algum amigo joga, mesmo que ele diga que está muito bom, não é a mesma coisa que você ver uma pessoa que nem sabe quem é jogando o seu jogo por escolha própria. É um sentimento engraçado imaginar que as horas de trabalho, todo estresse e preocupações, no final, valeu a pena por que você alcançou seu objetivo: estão se divertindo com seu jogo.\nEu já tinha visto pessoas jogando FIFA 12 no iPhone, mas a versão de Android que eu trabalhei saiu um tempo depois. Esta foi a primeira vez que eu vi alguém jogando, e senti uma vontade enorme de ir falar com esse cara, perguntar o que ele achou do jogo e falar que eu participei do desenvolvimento, e que inclusive meu nome está nos créditos. Fui pego tão de surpresa que fiquei sem reação, apenas observando. Acho que em uma próxima oportunidade eu talvez vá conversar.\nHoje temos tantas formas de se distrair no metro, tantos jogos para jogar e livros para ler. Quando alguem escolhe o seu jogo para passar esse tempo até o trabalho ou faculdade, é um sentimento de honra e dever cumprido que só mesmo uma área ligada ao entretenimento pode causar.\nIsso me deixou com saudades também. Tive uma experiência que pouquíssimas pessoas puderam ter, de trabalhar em uma empresa tradicional de games no Brasil, e ainda desenvolver jogos novos. Muita gente acha que empresas vem para o país fazer porting e localização, mas muitas desenvolveram jogos por aqui, como a Electronic Arts, Ubisoft, Glu Mobile e Gameloft.\nO FIFA 12 foi um projeto incrível, com partes de código de versões muito antigas e muita história para contar. Um projeto que levava 1 hora e 30 minutos para compilar (a partir de um clean) e que tinha 40GB de arquivos, um jogo AAA para dispositivos móveis. Ainda vou falar mais sobre este e outros projetos que trabalhei na EA e na Glu quando for postar sobre meu portfolio profissional. No final do FIFA 12 eu era o líder de uma equipe pequena, mas que juntos conseguimos entregar um jogo de qualidade para o Android.\nQuando a EA fechou as portas por aqui, me senti como se o Zangief tivesse dado um soco no meu estômago, esperado eu melhorar, e então feito isso de novo por horas. Em 3 anos deixei de ser apenas um estudando de jogos, passei pela Glu Mobile, e me tornei Lead Programmer na Electronic Arts. Participei de projetos incríveis como Tetris, FIFA 12 e Scrabble, todos para Android e com meu nome nos créditos. Sinto um vazio, como se tivesse voltado alguns degraus para trás na minha carreira em jogos, mas sei que logo voltarei a criar jogos tão incríveis quando os que fiz na EA.\nComo ouvi uma vez, só existe uma coisa que te impede de fazer qualquer coisa: você mesmo.\n","date":"2 de outubro de 2013","externalUrl":null,"permalink":"/vi-uma-pessoa-jogando-um-jogo-que-fiz-na-ea/","section":"Blog","summary":"Hoje aconteceu algo que até então eu não tinha presenciado: vi uma pessoa no metro jogando um jogo que programei quando trabalhei na Electronic Arts, o FIFA 12 para Android. Isso foi tão diferente que tive vontade de compartilhar aqui esta experiência.\n","title":"O dia em que vi uma pessoa jogando um jogo que fiz na Electronic Arts","type":"posts"},{"content":"Playground é uma técnica de teste de funcionalidades durante o desenvolvimento de um jogo que muitas empresas grandes utilizam durante a produção de um projeto. Mesmo sendo usado em empresas grandes, é algo bem simples de fazer e ajuda muito!\nEm primeiro lugar, o playground não é um protótipo. Só para contextualizar, um protótipo é algo que você faz antes de começar o seu projeto para validar as mecânicas do game design, e depois disso deve ser descartado para poder começar o desenvolvimento do jogo.\nCom isso em mente, vamos falar do playground. Isto é, simplesmente, uma fase especial para testar coisas. Esta fase ou tela do jogo é quase como se fosse parte do jogo, porém aqui você pode brincar a vontade para testar funcionalidades ou qualquer outra coisa, antes de implementar na parte principal do jogo.\nEu falei de protótipo primeiro, pois agora vou falar da diferença entre ele e o playground. Tudo que você fizer no seu playground não é um código qualquer, você está desenvolvendo um teste mas utilizando os recursos e classes do seu jogo, e não é por ser teste que deve ser feito de qualquer jeito.\nComo o protótipo parte da premissa de ser descartável, você programa de qualquer jeito, pois o importante nele é validar a mecânica do game design. Já no playground, a mecânica do jogo já está definida, você quer apenas testar implementações e situações diferentes do fluxo normal.\n","date":"1 de outubro de 2013","externalUrl":null,"permalink":"/como-ser-um-programador-de-jogos-playground/","section":"Blog","summary":"Playground é uma técnica de teste de funcionalidades durante o desenvolvimento de um jogo que muitas empresas grandes utilizam durante a produção de um projeto. Mesmo sendo usado em empresas grandes, é algo bem simples de fazer e ajuda muito!\n","title":"Como ser um programador de jogos: Playground","type":"posts"},{"content":"O Gameconfs é um site bem simples e com objetivo de ser um diretório de todos os eventos da indústria de games que acontecem pelo mundo, até eventos brasileiros como o Brasil Game Show está listado lá.\nDe eventos de gerais de jogos, como a E3 e Tokio Game Show, até eventos para desenvolvedores, como a GDC, o site lista tudo por mês. Encontrei até algumas game jams listadas, como a Global Game Jam. Vale a pena acompanhar!\n","date":"30 de setembro de 2013","externalUrl":null,"permalink":"/lista-eventos-industria-games/","section":"Blog","summary":"O Gameconfs é um site bem simples e com objetivo de ser um diretório de todos os eventos da indústria de games que acontecem pelo mundo, até eventos brasileiros como o Brasil Game Show está listado lá.\n","title":"Site lista todos os eventos da indústria de games","type":"posts"},{"content":"Este ano a indústria de games perdeu a melhor e mais antiga publicação sobre desenvolvimento de jogos, a Game Developer Magazine. Mas agora, todo seu conteúdo está disponível gratuitamente através do GDC Vault.\nPraticamente todas edições de 1994 até 2013 estão disponíveis para download no GDC Vault. As primeiras edições são muito legais, pois estão comentando sobre desenvolvimento para PSOne e N64, sendo que na época esta revista era um dos principais meios de divulgação de tecnologias, e até empregos! As mais recentes contam com entrevistas e postmortems de jogos de sucesso dos últimos anos.\nEsta revista sempre deixará saudades em quem acompanhava, mas agora pelo menos temos acesso gratuito a todo seu histórico (e épico) contéudo. A revista continua, mas apenas em forma de coluna no site Gamasutra.\n","date":"27 de setembro de 2013","externalUrl":null,"permalink":"/gd-magazine-gratuita/","section":"Blog","summary":"Este ano a indústria de games perdeu a melhor e mais antiga publicação sobre desenvolvimento de jogos, a Game Developer Magazine. Mas agora, todo seu conteúdo está disponível gratuitamente através do GDC Vault.\n","title":"Game Developer Magazine disponível gratuitamente","type":"posts"},{"content":"Muitas vezes temos a vontade de fazer algo, mas não temos uma motivação forte o bastante para levamos nosso projeto a diante. Concursos de desenvolvimento de jogos são motivadores incríveis para começar projetos, e ainda pode te ajudar a entrar na área.\nTem muita gente que não se acha criativa para ter ideias de jogos, ou até tem várias ideias diferentes e não sabe qual fazer. As vezes você tem um grupo de amigos que não consegue decidir qual jogo fazer por te varias ideias disponíveis, e ninguém querer abrir mão da sua própria ideia.\nBom, tudo isso pode ser resolvido participando de concursos! Na verdade, participar de concursos pode te dar mais do que isso, pois além de você aprender a fazer um jogo, este jogo pode se tornar um produto para ser publicado em sua própria empresa indie ou até usar como um portfólio para entrar em uma empresa de games. Eu acredito que concursos de desenvolvimento de jogos são um parte importante na formação do profissional que quer trabalhar com jogos.\nConcursos geralmente tem um tema revelado pouco antes de seu início, o que da uma condição justa para todas equipes. Com um tema ficam mais fácil pensar na ideia do jogo. Você pode se basear em outros jogos semelhantes ou tentar usar uma mecânica completamente diferente e adaptar ao seu jogo. Acredite, com um tema fica muito mais fácil de começar.\nExistem também concursos que não tem tema, e geralmente as pessoas enviam seus melhores jogos para concorrer. Existem concursos internacionais, como o IGF (Indie Games Festival), que já premiou e deu fama a jogos incríveis como Braid, Super Meat Boy, FEZ, Minecraft, entre outros. Aqui a competição é alta, e novos padrões são criados. Confira como foi a premiação deste ano no video abaixo.\nUma versão bem menor disso, e nacional, é a SBGames (Simpósio Brasileiro de Desenvolvedores de Games), que inclusive será mês que vem em São Paulo. Aqui são enviados jogos prontos ou em fase de desenvolvimento, e existem categorias para participar. Este ano sou finalista nas categorias Melhor Jogo Completo e Melhor Jogos Mobile com o jogo Combo Nuts, o qual participei como programador (leia aqui o postmortem deste jogo).\nEstes são dois exemplos de concursos sem temas definidos, e geralmente você se prepara com muita antecedência para participar. Muitas empresas e grupos independentes inscrevem seus jogos e estas premiações são muito bem-vindas para a equipe, além de dar fama ao jogo.\nAgora vou falar de outros concursos, que são curtos e baseados em temas, também conhecidos como jams. Game jams acontecem durante todo o ano, e existem muitas disponíveis. No Brasil o mais famosos é o SP Jam, que este ano foi no final de agosto, onde equipes se junta em um local comum para criar um jogo em 48 horas seguindo um tema. Os principais desafios aqui são a pressão em fazer o jogo sem perder tempo e a tensão que sempre pode acontecer entre os membros da equipe.\nExistem também jams virtuais, que podem ser feitos sozinhos, como o Ludum Dare, que é um desafio de fazer um jogo baseado em um tema específico sozinho. O video abaixo é uma compilação de vários jogos desenvolvidos durante uma edição do Ludum Dare, com mais de 2.000 jogos desenvolvidos em 1 fim de semana. É incrível o que pode ser feito com vontade, criatividade e muito café para não dormir!\nExistem diversos outros concursos anuais, como a Imagine Cup da Microsoft (para estudantes) e o e-Games do SENAC (fui finalista duas vezes neste). Há também o site GameJolt, que é uma comunidade de desenvolvedores independentes que publicam seus jogos lá. Eles organizam vários concursos durante o ano, principalmente jams. Participei uma vez e recomendo.\nNão faltam opções de concursos para você participar com seu jogo, ou game jams para você criar algo em um fim de semana, sozinho ou com uma equipe. Se você não tem ideias ou não sabe por onde começar a fazer um jogo, participar de concursos é uma boa opção para ter um primeiro contato.\n","date":"25 de setembro de 2013","externalUrl":null,"permalink":"/como-ser-um-programador-de-jogos-concursos/","section":"Blog","summary":"Muitas vezes temos a vontade de fazer algo, mas não temos uma motivação forte o bastante para levamos nosso projeto a diante. Concursos de desenvolvimento de jogos são motivadores incríveis para começar projetos, e ainda pode te ajudar a entrar na área.\n","title":"Como ser um programador de jogos: Concursos","type":"posts"},{"content":"Mais um postmortem exclusivo para o blog, e desta vez é um jogo que eu participei do desenvolvimento como programador. Sabia como foi o precesso de produção do jogo Combo Nuts!\nCombo Nuts é um jogo independente da Aplay Studios para iOS e Android, que foi desenvolvido por uma equipe formada por ex-funcionários de grandes empresas, como Ubisoft, Glu Mobile e Electronic Arts.\nEste postmortem é muito especial para mim por que eu participei do desenvolvimento deste jogo em sua fase final e no primeiro update para ambas as plataformas.Toda a experiência com desenvolvimento de jogos da equipe foi empregada na produção de Combo Nuts, um jogo muito divertido e viciante!\nEu aprendi bastante, principalmente sobre o processo de publicação do jogo na App Store e no Google Play, mas isto é um assunto para outro post. Muito obrigado Sandro pelo postmortem e pela oportunidade de participar deste projeto! Alias, este jogo está concorrendo a Melhor Jogo Completo e Melhor Jogo Mobile na SBGames 2013, que acontece mês que vem em São Paulo.\nPostmortem: Combo Nuts # Descrição # Combo Nuts é um endless casual game com uma jogabilidade simples e intuitiva, com partidas rápidas e emocionantes.\nO jogador controla Albert Squirrel, um esquilo voador que deve recolher as nozes que caem do céu roubadas pelos irmãos Wrong. A melhor maneira de recolher um grande número de nozes é através das sequências de nozes que aparecem, dessa maneira o jogador pode fazer diversos “combos”, recolhendo mais nozes e ganhando mais pontos.\nO jogo é freemium e as formas de monetização implementadas foram através de propagandas e vendas de in-app purchases.\nO jogo foi lançado para iOS e Android.\nLinks para download:\niOS: http://bit.ly/combonuts_ios\nAndroid: http://bit.ly/combonuts_android\nEquipe # No início do projeto a equipe consistia em 3 pessoas, um game designer, um artista e um programador. Trabalhamos de forma remota, a principal forma de comunicação foi através de e-mails e reuniões via Skype e com encontros presenciais esporádicos. Ao final do projeto, mais 2 programadores nos auxiliaram para finalização do jogo.\nConceito # A idéia era criar um jogo casual no estilo endless com uma jogabilidade simples e divertida, onde as partidas fossem rápidas e dinâmicas.\nAnalisamos o mercado e o público alvo que gostaríamos de atingir. Estudamos os estilos de jogo e gameplay que gostaríamos de produzir, que fosse algo simples, divertido, bonito e original onde cada membro da equipe aprenderia algo de novo em sua respectiva área.\nEstrutura para produção # Para a definição, organização e compartilhamento dos trabalhos utilizamos as seguintes ferramentas:\nGoogle Docs: criação e organização dos documentos e tabelas (www.docs.google.com); Trello: Definição das tasks e prazos (www.trello.com); Dropbox: Armazenamento dos assets de arte, plugins, GDD etc (www.dropbox.com); BitBucket: repositório online para o projeto (www.bitbucket.com); Engine: Unity (http://unity3d.com/); TestFlight: Serviço para teste de builds remotamente (https://testflightapp.com/). Prototipagem # Desenvolvemos o Game Design Document (GDD) com o detalhamento inicial do gameplay principal do jogo, com as principais guidelines a respeito da mecânica do jogo para iniciarmos o quanto antes a prototipagem.\nCom o decorrer da prototipagem e testes, fomos definindo na engine os editores que precisaríamos para criação e ajustes de todos os elementos do jogo como: posição, tamanho e velocidade do aparecimento dos objetos, criação dos padrões de sequência de objetos, controle dos intervalos de tempo e dos objetos para termos controle da curva de aprendizado e dificuldade etc.\nEstudos iniciais # Paralelamente, fomos desenvolvendo o estilo artístico do jogo, estudando a melhor forma para a implementação dos elementos gráficos levando em conta a otimização dos recursos técnicos da engine e a beleza e composição da arte.\nNesse momento foram feitos estudos de animação na engine e nos principais devices para encontrar um equilíbrio entre otimização dos recursos técnicos e resultado artístico desejado.\nGame Design Document # No GDD foram detalhadas todas as mecânicas necessárias para implementação no jogo, funcionamento da câmera, personagem e controle, comportamento de todos os elementos do jogo, progressão de jogabilidade, signs e feedbacks, fluxograma das telas e das ações, interface de usuário, conteúdo do jogo, detalhamento do funcionamento da “loja” do jogo etc.\nA medida que os elementos eram implementados e testados, ajustes eram feitos e essas informações eram atualizadas no GDD para manter a organização do projeto.\nProdução # Durante a produção do jogo adquirimos os efeitos sonoros e música que seriam implementados no jogo através do site http://www.premiumbeat.com/\nAlém dos in-app purchases foi adotado como método de monetização as propagandas dentro do jogo, nós utilizamos 2 serviços para isso:\nAdMob: serviço de banner in-game do Google (www.admob.com); Chartboost: serviço de banners intersticiais (www.chartboost.com). No nosso projeto, o serviço do Chartboost é o mais efetivo e com maior retorno financeiro.\nFoi comprado também diversos plugins para a Unity para facilitar a implementação de diversos elementos no jogo como integração com Game Center da Apple, Chartboost, AdMob, Flurry etc, os plugins foram adquiridos no site: http://prime31.com/plugins\nNa fase final do projeto, contamos com mais 2 programadores para ajudar na implementação desses plugins.\nBalanceamento, QA, bug fixes e polimento # O balanceamento do jogo foi constantemente executado durante o jogo, de todos os objetos, inimigos, itens especiais etc, com o objetivo de encontrar o melhor equilíbrio entre diversão e o estilo de gameplay com sessões rápidas e dinâmicas.\nO QA (quality assurance) é o momento onde verificamos a integridade do jogo, se todos os elementos estão funcionando de acordo com o planejado e onde podemos melhorar para tornar melhor a experiência para o jogador. Fizemos sucessivos testes a fim de descobrir erros no jogo e solucioná-los.\nDepois de implementado os principais itens do jogo iniciamos o procedimento de bug fixes, categorizando em 3 níveis, do mais ao menos crítico que influenciasse o gameplay e a experiência do jogador.\nNesse momento iniciamos o polimento do jogo, analisando o fluxo das telas e ações do jogo, colocando os assets de arte finais, revisando textos, melhorando signs e feedbacks etc.\nValidação e divulgação # Após os últimos testes, enviamos as builds finais para a validação do projeto, para iOS a validação levou 10 dias e para Android cerca de 3 horas.\nPara a divulgação de nosso jogo, preparamos os seguintes meios:\nWebsite: http://www.aplaystudios.com/games.html Press release: http://www.mediafire.com/?zsvd8o2njdjed Facebook Fan Page: https://www.facebook.com/combonuts?fref=ts Twiiter: https://twitter.com/aplaystudios Canal no YouTube: https://www.youtube.com/user/aplaystudios/feed Trailer do jogo: \u003e - Vídeo mashup com a banda He Saike: \u003e \u003e No lançamento, entramos em contato com diversos sites e blogs, nacionais e internacionais, especializados na cobertura e análise de jogos mobile, para apresentar o jogo. \u003e \u003e ## Downloads, Feedbacks, métricas e updates \u003e \u003e Durante a primeira semana de lançamento foram muitos downloads para iOS e Android, e no decorrer das próximas semanas esse número diminui e estabilizou até uma certa média. Porém os números do Android continuam a subir e atualmente já ultrapassou, e muito, os números de downloads do iOS. \u003e \u003e Após o lançamento nos atentamos para os feedbacks dos jogadores através da área de comentários das lojas App Store e Google Play e das redes sociais. \u003e \u003e Analisamos os números e estatísticas do jogo através de sites como App Annie ([http://www.appannie.com/](http://www.appannie.com/)) e Distimo ([http://www.distimo.com/](http://www.distimo.com/)) para \u003e \u003e O Flurry ([http://www.flurry.com/](http://www.flurry.com/)) é uma ferramenta para analisar o comportamento do usuário em relação a seu aplicativo e/ou jogo. Através dele verificamos quais são os itens e ações mais e menos acessados e executados pelos jogadores o que nos auxilia a melhorar o nosso jogo nos próximos updates. \u003e \u003e Após avaliarmos a série de feedbacks que recebemos, nos organizamos e definimos quais são os mais importantes para o primeiro update. \u003e \u003e ## Problemas / Dificuldades \u003e \u003e **1) Ritmo de produção** \u003e \u003e O ritmo de desenvolvimento não foi constante, algumas vezes não conseguíamos nos dedicar todos os dias e ficamos período sem produzir nada no projeto o que comprometeu no número de iterações que gostaríamos para melhorar características e mecânicas do jogo. \u003e \u003e **2) Balanceamento inicial** \u003e \u003e No primeiro balanceamento a dificuldade do jogo estava muito alta, foi uma decisão tomada conscientemente, com o objetivo de tornar as partidas mais rápidas e dinâmicas, mas através dos feedbacks percebemos que poderíamos melhorá-lo nesse ponto oferecendo ao jogador 3 tentativas ao invés de apenas uma. Melhoramos isso no primeiro update que lançamos. \u003e \u003e **3) Pouco divulgação** \u003e \u003e Apesar dos esforços para divulgarmos nosso jogo, tivemos pouco exposição a respeito dele. Não tínhamos condição de investir nenhum valor nesse sentido, no que refletiu no baixo número de downloads do jogo. Uma característica interessante são os números do Android que, mesmo sem divulgação, mantém-se num número interessante e estável. \u003e \u003e ## Sucesso / Aprendizado \u003e \u003e **1) Experiência no processo de desenvolvimento** \u003e \u003e Sem dúvida nenhuma, o principal ponto positivo do projeto foi a experiência adquirida em todo o processo necessário para lançar um jogo, desde a criação do conceito inicial, organização e produção para execução do projeto, cadastramento e processo de validação de um jogo, conhecer e trabalhar no processo de divulgação de um jogo, análise dos downloads, métricas e feedbacks gerados pelo jogo. \u003e \u003e Diferente de experiências anteriores, onde todos os membros da equipe já trabalharam em empresas de jogos em suas áreas específicas, em nosso projeto tivemos que aprender e trabalhar em diferentes áreas como produção, marketing, análise de métricas etc, e todo esse conhecimento serviu para melhorar a nossa percepção em relação a produção de um jogo. \u003e \u003e **2) Custo direto relativamente baixo** \u003e \u003e O principal investimento do projeto foi o tempo de cada membro da equipe. Como utilizamos equipamentos próprios e a maioria das ferramentas eram grátis, conseguimos produzir um jogo sem custos muito elevados. \u003e \u003e Os principais gastos foram em licenças para a engine, cadastramento para ser desenvolvedores nas lojas, efeitos sonoros e música, plugins e manutenção do site para divulgação. \u003e \u003e **3) Uso da Unity no projeto** \u003e \u003e Produzir o jogo desde no início utilizando a Unity nos ajudou e muito no processo. \u003e \u003e Com um grande número de usuários, documentações e plugins disponíveis, e com a possibilidade de compilar o jogo para diferentes plataformas (iOS e Android na primeira fase) foi a melhor opção para produzirmos nosso jogo. \u003e \u003e ## Conclusão \u003e \u003e A experiência em produzir um jogo do início ao fim foi o melhor aspecto de todo o projeto. \u003e \u003e Muitos erros foram cometidos e aprendemos bastante a respeito de outras áreas tão importantes além do desenvolvimento direto na produção dos jogos, como análise dos números e métricas do jogo, criação de uma estratégia de marketing para otimizar a divulgação etc. \u003e \u003e A criação de jogos envolve diversos setores distintos e a oportunidade de trabalhar e conhecer esses diferentes setores foi uma parte muito importante para a execução do projeto. \u003e \u003e O objetivo agora é aplicar todo o conhecimento adquirido nos nossos próximos jogos, para que essa experiência e conhecimento possam nos ajudar a criar jogos cada vez melhores. \u003e \u003e Obrigado pelo o seu tempo e atenção lendo esse Post Mortem e um obrigado especial para o Bruno Cicanci que ofereceu esse espaço para compartilharmos a nossa experiência, e pela ajuda direta em nosso jogo também, muito obrigado. \u003e \u003e **Sandro Junki Morishita** \u003e \u003e e-mail: [sandromorishita@aplaystudios.com](mailto:sandromorishita@aplaystudios.com) \u003e \u003e portifólio: [www.junki1978.com](http://www.junki1978.com)","date":"24 de setembro de 2013","externalUrl":null,"permalink":"/postmortem-combo-nuts/","section":"Blog","summary":"Mais um postmortem exclusivo para o blog, e desta vez é um jogo que eu participei do desenvolvimento como programador. Sabia como foi o precesso de produção do jogo Combo Nuts!\n","title":"Postmortem: Combo Nuts","type":"posts"},{"content":"Unite é o evento da Unity realizado anualmente desde 2007, e este ano a sétima edição já passou por Coréia, China, Japão, Canadá, e está chegando ao Brasil dia 15 de outubro, no Expo Center Norte em São Paulo.\nEu estou muito empolgado com este evento! Não é como ter uma GDC aqui, até por que talvez não temos empresas o suficiente para um evento deste porte. Mas, como quase todo mundo usa Unity por aqui, o Unite é um evento muito bem vindo e que acertou bem no seu público-alvo: estudantes e desenvolvedores indie.\nO ingresso custa R$110, um valor bem razoável se levarmos em conta a estrutura do evento, palestras e o mais importante: networking. Neste evento estarão profissionais da área que trabalham com Unity, e isso é muita gente! É uma oportunidade excelente para conhecer pessoas, trocar figurinhas e aumentar sua rede de contatos.\nConfira aqui a agenda do evento, que começa as 8h e acaba as 20h. Eu já comprei meu ingresso, nos vemos lá!\n","date":"20 de setembro de 2013","externalUrl":null,"permalink":"/unite-evento-da-unity-no-brasil/","section":"Blog","summary":"Unite é o evento da Unity realizado anualmente desde 2007, e este ano a sétima edição já passou por Coréia, China, Japão, Canadá, e está chegando ao Brasil dia 15 de outubro, no Expo Center Norte em São Paulo.\n","title":"Unite, o evento da Unity chega ao Brasil","type":"posts"},{"content":"Livros sobre desenvolvimento de jogos são, na minha opinião, uma das melhores fontes de aprendizado disponíveis para iniciantes. Neste post vou falar onde encontrar livros importados em inglês e também vou dar algumas dicas de livros brasileiros.\nNo post anterior desta série, defendi que não existem cursos bons o bastante para ensinar a fazer jogos, e que vale a pena focar em uma área e depois se especializar em jogos. Esta especialização pode ser algum curso, que mesmo sendo básico vai complementar sua experiência, ou através de livros.\nExistem livros incríveis sobre desenvolvimento de jogos em inglês, e poucos chegam ao Brasil traduzidos. Se você não se importa de esperar entre 20 e 30 dias para receber seu livro, e quer pagar o preço de capa, eu recomendo comprar seus livros na Amazon. Eles aceitam cartão de crédito internacional e entregam no Brasil sem problemas, pois livros não são taxados por impostos quando entram no país. Eu comprei uns 80% dos meus livros lá, e sempre recomendo. Existem versões para Kindle também, que por serem digitais você recebe na hora, e as vezes possuem preço menor do que a versão impressa.\nPor aqui até encontramos alguns livros em inglês importados, porém muitas vezes não é a versão mais nova e geralmente custam muito mais do que a conversão de dólares para reais. Existem duas livrarias em São Paulo que eu já comprei livros de desenvolvimento de jogos e outros assuntos relacionados a computação por um preço bem juntos, que é a Livraria Martins Fontes e a Livraria Cultura, ambas na Avenida Paulista. É possível comprar pelos sites também, mas as vezes na loja física é mais barato.\nFalando de livros brasileiros, vou listar aqui os melhores que li até agora, sendo que os dois primeiros são de autores brasileiros e os demais são traduções.\n– Desenvolvimento de Jogos Eletrônicos: Teoria e Prática, da editora Novatec\n– Blender 3D: Jogos e Animações Interativas, da editora Novatec\n– Regras do Jogo: Fundamentos do Design de Jogos (4 volumes), da editora Blucher\n– Level Up! Um guia para o design de grandes jogos, da editora Blucher\n– Introdução ao Desenvolvimento de Games (4 volumes), da editora Cengage Learning\nEste post foi uma visão bem geral de onde comprar livros para estudar e algumas dicas de livros em português, em breve farei posts sobre livros mais específicos para cada área.\n","date":"18 de setembro de 2013","externalUrl":null,"permalink":"/como-ser-um-programador-de-jogos-livros/","section":"Blog","summary":"Livros sobre desenvolvimento de jogos são, na minha opinião, uma das melhores fontes de aprendizado disponíveis para iniciantes. Neste post vou falar onde encontrar livros importados em inglês e também vou dar algumas dicas de livros brasileiros.\n","title":"Como ser um programador de jogos: Livros","type":"posts"},{"content":"O TexturePack é um software utilizado para gerar sprite sheets compatíveis com diversos frameworks, como Cocos2d e Corona SDK. Ele possui diversas opções de otimização, e um recurso bem interessante é o de gerar sprite sheets para varias resoluções.\nSprite sheet é, basicamente, uma imagem que contem diversas outras imagens menores, podendo ser frames de uma animação ou apenas imagens isoladas. Este tipo de recurso é muito usado em jogos para otimizar o consumo de memória, pois manter uma imagem na memória custa menos para o hardware do que diversas menos, além de ser mais pratico de usar.\nPosso definir o TexturePacker como essencial e incrível, pois ele não somente junta imagens para formar a sprite sheet como também faz isso da maneira mais otimizada possível. Algumas vezes ele até girar as imagens para agrupar melhor, mas isso não influencia na hora de usar, você não precisa girar a imagem de volta. O TexturePacker possui suporte para vários frameworks 2D.\nAo publicar uma sprite sheet, a imagem com todos sprites é gerada junto com um arquivo de configuração, que pode ser desde um XML ou plist, até um script Lua (no caso do Corona). Basta importar ambos no código e usar. Cada frameworks possui sua maneira de carregar estes arquivos, aqui vou mostrar como é feito no Corona SDK.\nO primeiro passo é importar as imagens para o TexturePacker. Você pode selecionar uma ou mais imagens, ou uma pasta inteira. Neste caso eu selecionei as imagens em “Add Folder”. Depois selecionamos o framework que iremos utilizar. O Corona possui duas opções, mas eu sinceramente não sei a diferenças, pois testei com ambos e o resultados é o mesmo. Eu geralmente seleciono a opção “Corona TM SDK”.\nAgora vamos a parte mais legal, que é gerar para múltiplas resoluções a partir de um sprite sheet. Para ter o melhor resultado, sempre gere a partir da maior resolução. Neste exemplo usei imagens para iPad Retina, que é a maior tela com iOS, e vou gerar para iPad 2 e iPhone a partir dele. Embora eu esteja fazendo este exemplo para iOS, você pode gerar para qualquer dispositivo móvel ou desktop, o importante é partir da maior resolução que você vai suportar no seu jogo.\nClicando em “AutoSD”, a janela abaixo é apresentada. Nela, selecionamos a opção “corona @4X/@2X” para gerar as imagens para iPad Retina (4X), iPad 2 (2X) e iPhone.\nApós selecionar esta opção, clique em Apply e os dois grupos abaixo serão criados. Neste post não irei alterar os valores default apresentados, mas algumas melhorias podem ser feitas aqui, como selecionar um nome padrão para as imagens (se você não gostar de @4X e @2X) e modificar o tamanho da spritesheet máximo.\nDepois de fechar esta janela (você clicar fora dela para fechar, ou clicar em Apply), é necessário renomear os arquivos que serão gerados, como mostrado na imagem abaixo. No final do nome, antes da extensão, adicione “@4X” ou o nome que você colocou na imagem anterior para o iPad Retina.\nCom isso pronto, clique no botão “Publish”. Serão gerados dois arquivos, um PNG com todos sprites juntos (que é a sprite sheet) e um arquivo LUA (por que selecionamos Corona SDK) para cada tamanho (normal, 2X e 4X). Copie estes dois arquivos para dentro do seu projeto feito no Corona SDK, pode colocar no mesmo lugar que está o seu “main.lua” se tiver dúvidas. Para exibir um sprite, basta executar o código abaixo. Estou considerando que o nome da sprite sheet de tamanho normal é “firefox”.\n-- aqui carregamos o arquivo LUA local sheetInfo = require (\u0026#34;firefox\u0026#34;) --normal local sheetInfo2x = require (\u0026#34;firefox@2x\u0026#34;) --ipad 2 local sheetInfo4x = require (\u0026#34;firefox@4x\u0026#34;) --ipad retina -- aqui carregamos o arquivo PNG local imagesSheet = graphics.newImageSheet(\u0026#34;firefox.webp\u0026#34;, sheetInfo:getSheet()) --normal local imagesSheet2x = graphics.newImageSheet(\u0026#34;firefox@2x.webp\u0026#34;, sheetInfo2x:getSheet()) --ipad 2 local imagesSheet4x = graphics.newImageSheet(\u0026#34;firefox@4x.webp\u0026#34;, sheetInfo4x:getSheet()) --ipad retina -- aqui carregamos a imagem chamada firefox00.webp, mas sem a extensão local image = display.newSprite(imagesSheet, {frames={sheetInfo:getFrameIndex(\u0026#34;firefox00\u0026#34;)}}) --normal local image2x = display.newSprite(imagesSheet2x, {frames={sheetInfo2x:getFrameIndex(\u0026#34;firefox00\u0026#34;)}}) --ipad 2 local image4x = display.newSprite(imagesSheet4x, {frames={sheetInfo4x:getFrameIndex(\u0026#34;firefox00\u0026#34;)}}) --ipad retina Note que para carregar a imagem, procuramos pelo nome do frame adicionado no TexturePacker, ou seja, o nome da imagem individual. Este exemplo acima é apenas para mostrar como podemos carregar cada tamanho, você deve usar isso de maneira mais otimizada, como carregar apenas o que for utilizar ao invés de todos tamanhos de imagem.\nEspero que tenham gostando deste tutorial do uso do TexturePacker com Corona SDK, qualquer dúvida deixe um comentário! Conheça também as outras features legais do TexturePacker clicando aqui.\nVocê pode baixar a versão trial do TexturePacker aqui, que possui versões para Windows, Mac e Linux. Eu recomendo comprar, pois é uma ferramenta incrível para desenvolver jogos, principalmente mobile. Muito obrigado ao Andreas Leow, da CodeAndWeb, que me enviou a licença para testar o TexturePacker. Em breve postarei outro sobre outro produto deles, o PhysicsEditor.\nAs imagens utilizadas aqui são do jogo open source BrowserQuest, disponível no GitHub do Mozilla.\n","date":"17 de setembro de 2013","externalUrl":null,"permalink":"/sprite-sheets-texturepacker-corona-sdk/","section":"Blog","summary":"O TexturePack é um software utilizado para gerar sprite sheets compatíveis com diversos frameworks, como Cocos2d e Corona SDK. Ele possui diversas opções de otimização, e um recurso bem interessante é o de gerar sprite sheets para varias resoluções.\n","title":"Sprite sheets em múltiplas resoluções com TexturePacker e Corona SDK","type":"posts"},{"content":"Eu não sou artista, mas achei este tutorial muito bom do artista torstan, postado no devianart. Ele ensina a criar mapas isométricos a partir da visão superior (top down).\nO tutorial é tão simples que você acaba pensando como não fez isso antes. A imagem abaixo resume todo o processo, mas para conferir os detalhes de cada parte acesse o link do tutorial aqui.\nVocê pode usar isso para criar o mapa para seu jogo isométrico, ou até um esboço ou concept art para o documento de game design.\n","date":"16 de setembro de 2013","externalUrl":null,"permalink":"/desenhando-mapas-isometricos/","section":"Blog","summary":"Eu não sou artista, mas achei este tutorial muito bom do artista torstan, postado no devianart. Ele ensina a criar mapas isométricos a partir da visão superior (top down).\n","title":"Desenhando mapas isométricos","type":"posts"},{"content":"O MMORPG Word of Warcraft da Blizzard não é só um jogo muito bom e um sucesso comercial que fez a empresa e o mercado de MMOs crescer muito, ele também tem uma API impressionante para programar addons.\nAntes de falar sobre a programação no WoW, vou explicar algumas definições. API, ou Application Programming Interface, é uma especificação de funções que podem ser executadas para a comunicação entre dois softwares, neste caso o jogo e o seu add-on. O addon é um módulo ou plugin para um programa que complementa ou expande suas funcionalidades.\nAgora vamos ao WoW! Da para imaginar a complexidade e o tamanho do seu projeto só pelo tamanho do jogo, mais de 30GB de conteúdo, e isso é só o que no nosso computador, existem ainda aplicações rodando nos servidores e bancos de dados, o que faz a arquitetura dele ser algo muito impressionante.\nMais impressionante do que isso é que ainda existe uma API para ter acesso a muitas coisas do jogo, e com isso podemos escrever addons para praticamente qualquer coisa! Os add-ons são programados em Lua, uma linguagem script brasileira que ficou muito famosa pelo seu uso no WoW.\nPor ser uma linguagem script ela não precisa ser compilada, então o jogo (já compilado) consegue interpretar seu código dentro dele, é como se o WoW fosse o seu compilador para Lua. Neste site existe uma lista das funções disponíveis na API, além de exemplos de código e um fórum para você tirar suas duvidas.\nEste site é do autor do livro WoW Programming, que é um guia completo para a criação de addons. Existem os mais diversos addons disponíveis na comunidade do jogo, desde coisas que ajudam no jogo (dicas de quests, notícias, etc), até coisas inusitadas como mini-jogos (como o jogo bejeweled na imagem anterior) pra passar o tempo e aplicativos para pedir comida sem sair do jogo. Quanto mais addons o jogador tiver no jogo, menos ele vai precisar minimizar o WoW pra fazer alguma outra coisa no computador.\nPode parecer nerd demais fazer addons para o WoW, mas isso ensina muito sobre uso de APIs e programação em Lua, além da sensação de estar trabalhando dentro de um jogo gigante. Existem limitações, não é possível interferir muito no jogo, mas ao mesmo tempo não há limites para o uso da sua criatividade.\nAcesse o site do WoW Programming para saber mais!\n","date":"13 de setembro de 2013","externalUrl":null,"permalink":"/programacao-na-api-do-world-of-warcraft/","section":"Blog","summary":"O MMORPG Word of Warcraft da Blizzard não é só um jogo muito bom e um sucesso comercial que fez a empresa e o mercado de MMOs crescer muito, ele também tem uma API impressionante para programar addons.\n","title":"Programação na API do World of Warcraft","type":"posts"},{"content":"Essa parte é bem polêmica, pois profissionais da área tem uma opinião diferente dos acadêmicos. Poucos profissionais da área dão aula em cursos de desenvolvimento de jogos, e muitos acadêmicos que dão aula nunca fizeram um jogo e publicaram. Eu acreditava que muitos profissionais não davam aula por falta de tempo, mas quando dei aula no final do ano passado de XNA comecei a perceber o real motivo.\nNo geral, programar jogos é muito diferente de programar sistemas ou sites, pois envolve muitas disciplinas além de fazer código. Você pode fazer um curso de algumas semanas e aprender a programar sistemas e sites, mas isso não é verdade para jogos.\nPor exemplo, para fazer um simples PONG é necessário ter uma base de matemática, física, lógica de programação e inteligência artificial, isso se você fizer um jogo sem som e com risquinhos no lugar da arte. Não estou falando que você precisa saber tudo isso, inclusive algumas coisas são bem simples no caso do PONG, mas mesmo assim é muito mais complexo do que programar sistemas e sites.\nJogos são tão complexos que para fazer um Super Mario, e realmente entender cada parte do desenvolvimento, seria necessária pelo menos um curso de 2 anos, com diversas matérias. Talvez eu esteja exagerando um pouco, mas isso é pra deixar claro como fazer jogos é complicado, e que cursos rápidos não vão te ensinar a fazer, vão apenas mostrar uma base.\nVocê quer programar jogos? Então faça Ciência da Computação ou Engenharia da Computação, essas são as formações que estão em qualquer vaga de programador de games como pré-requisito. Depois de fazer a graduação, ai você pode se especializar em games. Esse é o caminho que segui, e deu muito certo no meu caso. Me formei em Ciência da Computação, aprendi muitas coisas úteis pra games, depois fiz uma pós-graduação em produção e programação de games, e no final do curso já estava trabalhando na Glu Mobile e participando de concursos. Depois que apresentei meu TCC entrei na Electronic Arts. Infelizmente ambas empresas fecharam no Brasil, mas isso é uma discussão para outro post.\nO que eu quero deixar claro aqui é que você precisa aprender a programar antes de aprender a programar games, e que um curso de programação de games vai te mostrar uma base bem básica, e que continuar depende apenas de você. Uma coisa que eu não consigo concordar é ver professores que nunca fizeram um jogo ensinando como desenvolver games, isso não faz o menor sentido. O que você acha de um médico que teve aula de cirurgia específica com um professor que nunca fez uma esta cirurgia, apenas leu sobre o assunto?\nTudo que falei neste tópico foi focado para programadores, e falei apenas em relação à cursos no Brasil. Porém, muitas dessas coisas são verdade para outras áreas também, pense bem antes de começar um curso de games, muitas vezes você aprenderá mais com livros. Porém algumas pessoas precisam ver esta base em um curso, mesmo que seja básico.\n","date":"11 de setembro de 2013","externalUrl":null,"permalink":"/como-ser-um-programador-de-jogos-cursos/","section":"Blog","summary":"Essa parte é bem polêmica, pois profissionais da área tem uma opinião diferente dos acadêmicos. Poucos profissionais da área dão aula em cursos de desenvolvimento de jogos, e muitos acadêmicos que dão aula nunca fizeram um jogo e publicaram. Eu acreditava que muitos profissionais não davam aula por falta de tempo, mas quando dei aula no final do ano passado de XNA comecei a perceber o real motivo.\n","title":"Como ser um programador de jogos: Cursos","type":"posts"},{"content":"A editora Cengage Learning lançou a tradução da segunda edição do livro Introdução ao desenvolvimento de games, e eu recebi o Volume 1: Entendendo o universo dos jogos, e fiquei bem impressionado com o conteúdo.\nAcho que eu esperava apenas mais um livro de desenvolvimento de jogos, mas este aqui superou minhas expectativas pela abordagem do assunto. Este é o primeiro volume de quatro livros organizados por Steve Rabin, que é o principal engenheiro de software da Nintendo nos EUA e também é professor na Digipen. Ele reuniu um time de profissionais da industria games, como o idealizador do Vídeo Games Live Tommy Tallarico, entre outros, e juntos criaram esta obra que aborda praticamente tudo que envolve desenvolver jogos.\nNeste post vou focar no primeiro volume, que trata da história dos vídeo games até o design de jogos. Logo de inicio fiquei surpreso pelo resumo da história da industria de games. Muita gente conhece como começou, mas talvez não todos os detalhes e nomes. Este industria é bem nova, mas posso dizer que tem muita coisa já registrada para podermos chamar de história dos vídeo games.\nAlém de falar da criação do primeiro jogo eletrônico, Tennis for Two (video abaixo), e o primeiro vídeo game comercial, Atari, o livro da destaque para detalhes que normalmente não são lembrados quando falamos da história da industria, que é a importância que alguns profissionais e estúdios tiveram para definir muitas coisas que vemos nos jogos hoje. Mais do que curioso, ler estas historias é motivador!\nDepois de estabelecer como começou a maior industria de entretenimento do mundo, são tratados assuntos que relacionam jogos com a sociedade, passando por questões culturais, sociais, demográficas e até filosóficas. Neste ponto existem outro livros mais profundos, porém este é um resumo muito bem feito, pois é apenas a base para os próximos capítulos.\nPor fim, vamos ao assunto principal deste livro, que game design, e é aqui que me impressiono de novo. De uma maneira bem clara e objetiva, praticamente todos os aspectos do que é o design de um jogo são abordados. De assuntos mais teóricos, como quem é o jogador e o que é o jogos, até a definição de elementos de jogabilidade e interface, o livro consegue passar a idéia de tudo que é necessário saber para começar. Pontos interessantes como uma definição de um modelo de jogo e prototipagem valem ser destacados.\nNovamente, este livro é uma introdução sobre design de jogos, e existem outros livros que abordam o assunto de maneira mais abrangente, assim como existem coisas que somente a pratica vai ensinar. No final do livro temos um capitulo dedicado a conta historias interativas, ou storytelling. Devo dizer que este capitulo foi o que mais me ensinou, pois é um assunto que conheço pouco e não esta relacionado a game design, é algo para roteiristas mas muito interessante para o publico em geral.\nEu gostei bastante deste livro, e como introdução esta praticamente perfeito para quem quer começar a desenvolver jogos. A tradução esta muito boa e reflete a qualidade do livro. Muito obrigado a Cengage Learning por me enviar este livro, e parabéns pelo excelente trabalho.\nSiga a Cengage Learning no Facebook e no Twitter para ficar por dentro dos lançamentos da editora.\n","date":"9 de setembro de 2013","externalUrl":null,"permalink":"/introducao-ao-desenvolvimento-de-games/","section":"Blog","summary":"A editora Cengage Learning lançou a tradução da segunda edição do livro Introdução ao desenvolvimento de games, e eu recebi o Volume 1: Entendendo o universo dos jogos, e fiquei bem impressionado com o conteúdo.\n","title":"Introdução ao desenvolvimento de games, volume 1","type":"posts"},{"content":"Pode não parecer, mas seu primeiro projeto de jogo pode definir sua carreira. Não estou falando no sentido de que seu primeiro game vai ser um Angry Birds, pelo contrário. Não tente fazer um jogo parecido com Angry Birds, nem um joguinho tipo Super Mario, ou um RPG simples. Nada disso. Seu primeiro jogo precisa ser algo tão simples quanto um PONG.\nPor que PONG? É um jogo que muita gente sabe como funciona, é relativamente simples de programar, e não demora muito para fazer seu gameplay básico. Mas por que você deve fazer um jogo fácil como PONG? E por que isso pode definir sua carreira?\nÉ normal pessoas desistirem na primeira dificuldade, agora imagina diversas dificuldades? Se você começar com uma ideia grande você vai desistir antes mesmo de fazer um quadrado aparecer na tela. Você vai se preocupar com a história, arte, som, etc, e na hora de programar vai ficar travado por não saber nem por onde começar. Seu primeiro jogo precisa ser simples, pra você conseguir fazer do começo ao fim e mostrar para seus amigos.\nDepois que você estudou alguns tutoriais e quer fazer um jogo do zero comece com algo fácil. Quanto mais rápido você fizer seus primeiro jogos, mais experiência você terá para criar jogos cada vez mais complexos. É muito legal fazer algo, mesmo que seja simples, e mostrar para as pessoas. E mesmo que o jogo seja simples, você pode adicionar novos elementos para melhorar o gameplay, a sua criatividade é o seu limite.\nE isso não vale só para fazer jogos sozinhos, se você conseguir montar uma equipe, mesmo que todos tenha experiência com jogos, o primeiro jogo de vocês têm que ser simples, pois o primeiro projeto irá criar diversos padrões para o grupo seguir, e vai ajudar a equipe ficar mais entrosada. Quando mais jogos simples a equipe fizer, cada vez mais sua experiência irá aumentar, e em pouco tempo estarão fazendo jogos mais complicados, mas com a facilidade de fazer um PONG.\nEsse é um dos motivos que me fez criar esta outra série de posts, que irá ensinar a programar o PONG em diversas engines e frameworks, começando por HTML5.\n","date":"4 de setembro de 2013","externalUrl":null,"permalink":"/como-ser-um-programador-de-jogos-primeiro-jogo/","section":"Blog","summary":"Pode não parecer, mas seu primeiro projeto de jogo pode definir sua carreira. Não estou falando no sentido de que seu primeiro game vai ser um Angry Birds, pelo contrário. Não tente fazer um jogo parecido com Angry Birds, nem um joguinho tipo Super Mario, ou um RPG simples. Nada disso. Seu primeiro jogo precisa ser algo tão simples quanto um PONG.\n","title":"Como ser um programador de jogos: Primeiro jogo","type":"posts"},{"content":"Ontem no evento Unite 13 foi anunciado que a próxima versão da Unity, a 4.3, terá suporte nativo a desenvolvimento de jogos 2D, além de tools internas para criar spritesheets, animações e física com Box2D.\nFazer jogos em 2D na Unity não é impossível, mas não é fácil. Existem diversos problemas pela falta de suporte da engine, que eram resolvidos utilizando diversos plugins a venda na Asset Store. Existem plugins muito bons, mas todos pagos, e isso fazia algumas pessoas optarem por tecnologias que já possuem suporte a 2D, como Corona SDK ou Cocos2d-x.\nMas agora a Unity fez algo incrível, que vai trazer muitos desenvolvedores que gostam de fazer jogos 2D, ela criou suas próprias tools de 2D dentro da engine. Pelo video abaixo podemos ver que as novas ferramentas parecem muito fáceis de usar, e possibilitam diversas oportunidades. Agora temos suporte a spritesheets, animações, camadas, física implementada com a famosa Box2D, tudo isso especialmente para fazer jogos em 2D.\nCom esse passo a Unity está cada vez mais perto de se tornar a melhor e mais usada engine para estudantes e desenvolvedores independentes. Se você não conhece ainda esta engine, entre no site e baixe a versão gratuita, que permite exportar seu jogo para PC, Mac, Android, Web, iOS e Windows Phone.\n[Unity Native 2D Tools, via Unity Technologies Blog, em inglês]\n","date":"29 de agosto de 2013","externalUrl":null,"permalink":"/unity-suporte-nativo-2d/","section":"Blog","summary":"Ontem no evento Unite 13 foi anunciado que a próxima versão da Unity, a 4.3, terá suporte nativo a desenvolvimento de jogos 2D, além de tools internas para criar spritesheets, animações e física com Box2D.\n","title":"Nova versão da Unity terá suporte nativa a 2D","type":"posts"},{"content":"No post anterior desta série escrevi sobre a importância de começar a programar com coisas simples como fazer um Hello World para conhecer melhor uma tecnologia, agora vou destacar as diferenças entre Engine e Framework.\nAlém da linguagem de programação, você deve aprender sobre engines e frameworks. Uma game engine é um software completo para criação de um jogo. Um framework é uma biblioteca de programação, sem interface gráfica, que você utiliza para programar seu jogo.\nEm uma analogia meio feia, podemos falar que uma engine é como se fosse o Microsoft Word (você pode criar textos de diferentes formas, utilizando várias coisas prontas). Já o framework é como uma caixa de Lego, você constrói o jogo com as peças que quiser, seguindo um manual (tutorial no caso de um jogo) ou sua criatividade.\nAtualmente a game engine mais famosa entre estudantes e desenvolvedores independentes, e que também é utilizada em empresas grandes, é a Unity, que permite o desenvolvimento de jogos com modelos 3D para PC, Mac, Web, Chrome, iOS e Android (tudo isso na versão gratuita!). A Unity conta com muita material na internet, principalmente vídeos e tutoriais, porém poucos (e desatualizados) livros. Se você quer estudar desenvolvimento de jogos 3D recomendo começar pela Unity, nela você pode programar em C#, Javascript ou Boo (uma variação de Python).\nEnquanto a Unity tem muito destaque como game engine, é difícil falar de apenas um framework. O primeiro framework que estudei foi o XNA da Microsoft, principalmente por utilizar C#, linguagem que eu trabalhei por alguns anos antes de entrar na área de games. Por isso consegui aprender bem rápido a usar o XNA, participei de concursos e fiz meu TCC da pós em games com ele, e até dei aula de programação com XNA. Infelizmente a Microsoft já anunciou que não vai continuar com o XNA por causa do Windows 8, eu pelo menos vou ficar com saudades.\nSe você quer desenvolver jogos para Windows, e não tem medo de C/C++, eu recomendo a SDL, um framework bem legal e fácil de usar. Fiz um jogo na pós com ele, foi uma boa experiência. O que eu mais gostei no SDL é sua transparência, mas isso fica um pouco complicado de explicar neste post.\nExistem dois frameworks para desenvolvimento de jogos mobile que eu sempre recomendo: Corona SDK, onde você programa em script Lua, e Cocos2d-x, framework open source em C/C++. Ambos são excelentes frameworks, com ótimas features, e muito utilizados no mercado, principalmente por desenvolvedores independentes. Considero sua principal diferença a linguagem, onde no Corona é interpretada e no Cocos2d-x é compilada.\n","date":"28 de agosto de 2013","externalUrl":null,"permalink":"/como-ser-um-programador-de-jogos-engine-vs-framework/","section":"Blog","summary":"No post anterior desta série escrevi sobre a importância de começar a programar com coisas simples como fazer um Hello World para conhecer melhor uma tecnologia, agora vou destacar as diferenças entre Engine e Framework.\n","title":"Como ser um programador de jogos: Engine vs Framework","type":"posts"},{"content":"No primeiro post desta serie você conheceu um pouco sobre os pré-requisitos básicos para começar a programar um jogo, agora vamos falar do primeiro contato com o código em uma tecnologia.\nHello World\nSe você quer programar jogos, antes deve aprender a programar coisas mais simples, como o famoso “Hello World”. Isso nada mais é do que escrever um código que exibe uma mensagem na tela. Parece simples, mas isso vai te ensinar a configurar o seu computador para rodar a tecnologia que você quer usar.\nDepois disso, estude algoritmos e estruturas de dados. Essas matérias são deixadas de lado por quem faz uma faculdade de computação, pois acham que nunca vão utilizar. Nos 4 anos que trabalhei como analista de sistemas realmente usei muito pouco, mas quando comecei a trabalhar com games isso começou a fazer falta, e tive que rever muita coisa que tinha esquecido.\nSe você está desenvolvendo para um hardware específico, tente rodar o seu “Hello World” no aparelho. Garanto que na primeira vez que você quiser fazer isso vai perder algumas horas para entender como rodar seu jogo em um aparelho. Esse tipo de contato de “primeira vez” é muito importante para adquirir confiança e experiência. Outra coisa ainda mais complicada é lançar o jogo na App Store, mas isso é bem mais avançado, e você precisa ter seu jogo pronto e rodando bem pra poder pensar nisso!\n","date":"21 de agosto de 2013","externalUrl":null,"permalink":"/como-ser-um-programador-de-jogos-hello-world/","section":"Blog","summary":"No primeiro post desta serie você conheceu um pouco sobre os pré-requisitos básicos para começar a programar um jogo, agora vamos falar do primeiro contato com o código em uma tecnologia.\n","title":"Como ser um programador de jogos: Hello World","type":"posts"},{"content":"Esta é mais uma série de posts nova no blog para ser um complemento da “Como ser um programador de jogos”. Lá eu escrevo sobre vários aspectos, muitos teóricos, sobre a formação e aprendizagem para se tornar um programador de jogos. Aqui vou mostrar programação de jogos, mas sempre com o jogo PONG.\nPor que sempre o PONG? A ideia é mostrar desenvolvimento de jogos com diversas tecnologias e em várias plataformas, por isso sempre irei mostrar como programar o mesmo jogo, assim ficará mais clara a complexidade de uma determinada tecnologia em relação a outra. Outro motivo também é que o PONG é um jogo relativamente simples de programar, e todo mundo conhece!\nNeste primeiro post vou mostrar como programar o PONG utilizando o canvas do HTML5 e código em Javascript. Todo o código comentado (que não é muito grande) está disponível no link no final do post. Aqui vou destacar apenas algumas partes mais importantes em relação ao canvas do HTML5 e algumas partes mais complexas do Javascript. Na conclusão deste post irei falar minha opinião sobre usar esta tecnologia para desenvolver jogos.\nIntrodução # O HTML5 surgiu há alguns anos com a proposta de adicionar mais interatividade à páginas web, querendo inclusive substituir o Flash como recurso multimedia. O HTML5 é um padrão que ainda está sendo implementado pelos navegadores, então alguns recursos podem ter funcionamento diferente em cada navegador, mas o básico já tem em todos.\nExistem muitas bibliotecas javascript para desenvolver jogos, aplicativos e sites com HTML5 em javascript, mas neste post vou mostrar como fazer um PONG apenas utilizando recursos do HTML5 e Javascript “puro”, sem nada externo.\nPara desenvolver com HTML5 e Javascript você precisa apenas de um aplicativo de bloco de notas e navegadores. Eu recomendo o Sublime Text 2 para programar (tem versões para Windows e MacOSX) e pelo menos alguns navegadores mais usados para testar (Internet Explorer, Chrome, Firefox, Safari e Opera). Não precisa ter todos, mas pelo menos mais de um é recomendado.\nPONG # O código do jogo é bem simples, para começar precisamos definir o nosso canvas do HTML5. O tamanho está definido para termos uma área fixa, assim fica mais fácil fazer este exemplo, caso contrário o código ficaria bem mais complexo para fazer o jogo ser adaptável a qualquer tamanho.\n\u0026lt; canvas id=\u0026#34;canvas\u0026#34; width=\u0026#34;600\u0026#34; height=\u0026#34;480\u0026#34; \u0026gt;\u0026lt; /canvas \u0026gt; Com isso já podemos começar a brincar com o Javascript. Não vou adicionar todo o código aqui, como a inicialização das variáveis, mas você poderá ver o código completo no link no final do post. Uma parte importante da inicialização é adicionar os eventos para receber uma notificação quando uma tecla for pressionada e quando for solta. Este exemplo é baseado nas teclados de seta pra cima e para baixo do teclado. Outro evento importante é o setInterval, que executará uma função de game loop a cada 30 frames.\ndocument.addEventListener(\u0026#39;keyup\u0026#39;, keyUp, false); document.addEventListener(\u0026#39;keydown\u0026#39;, keyDown, false); setInterval(gameLoop, 30); Existem três partes principais no game loop relacionados a lógica do jogo: Jogador, Oponente e a Bola. Vamos primeiro ao jogador, que é mais simples, ele se move com o movimento das teclas.\nif (jogadorParaCima) { if (jogadorPosY \u0026gt; 0) { jogadorPosY -= velocidadeJogador; } } else { if (jogadorPosY \u0026lt; (canvas.height - barraHeight)) { jogadorPosY += velocidadeJogador; } } O comportamento do oponente é praticamente o mesmo, a única diferença é que o seu movimento é constante, e não depende das teclas pressionadas para se deslocar para cima e para baixo, respeitando os limites da tela.\nif (oponenteParaCima) { oponentePosY -= velocidadeOponente; if (oponentePosY = canvas.height - barraHeight) { oponenteParaCima = true; } } Por fim temos a bola, que é um pouco mais complexa pois existe a verificação da colisão dos jogadores com ela, e isso faz seu deslocamento ser invertido. Este código é maior, porém suas verificações são simples para determinar se alguém encostou na bola. Se a posição da bola estiver contida na posição do jogar, a movimentação da bola é invertida, e também é aplicada uma transformação matemática aleatória para que o seu angulo ao ser rebatida seja variado.\nif ((bolaPosX - 10) jogadorPosY) \u0026amp;\u0026amp; (bolaPosY - 10 \u0026lt; jogadorPosY + barraHeight)) { bolaParaDireita = true; if (jogadorParaCima) { bolaAngulo = Math.floor(Math.random() * 10) - 9; } else { bolaAngulo = Math.floor((Math.random() * 10)); } } } else if ((bolaPosX - 10) \u0026gt; (oponentePosX - barraWidth)) { if ((bolaPosY + 10 \u0026gt; oponentePosY) \u0026amp;\u0026amp; (bolaPosY - 10 \u0026lt; oponentePosY + barraHeight)) { bolaParaDireita = false; if (oponenteParaCima) { bolaAngulo = Math.floor(Math.random() * 10) - 9; } else { bolaAngulo = Math.floor((Math.random() * 10)); } } } if ((bolaPosY - 10 canvas.height)) { bolaAngulo = bolaAngulo * -1; } bolaPosY += bolaAngulo; if (bolaParaDireita) { bolaPosX += velocidadeBola; } else { bolaPosX -= velocidadeBola; } A lógica do PONG é bem simples, e será sempre parecida em todos os posts desta série, sendo a única diferença a tecnologia utilizada. Outro detalhe importante neste post é que não existem imagens para os jogadores e a bolinha, tudo foi desenhado no próprio código Javascript utilizando recursos do canvas do HTML5, como demonstrado abaixo.\n// Jogador e Oponente context.fillRect(jogadorPosX, jogadorPosY, barraWidth, barraHeight); context.fillRect(oponentePosX, oponentePosY, barraWidth, barraHeight); // Bola context.beginPath(); context.arc(bolaPosX, bolaPosY, bolaDiametro, 0, Math.PI * 2, true); context.closePath(); context.fill(); Por fim, temos mais pedaços de código responsáveis por exibir o placar, desenhar as linhas e os jogadores, contar a pontuação (basicamente é só verificar se a posição da bolinha está fora do canvas), entre outros detalhes que estão comentados no código completo no link abaixo.\nClique aqui para baixar o código completo!\nConclusão # Pode parecer que a única novidade é a marcação canvas, mas por trás disso o HTML5 implementa muitas melhorias de desempenho e gráficas, além de definir melhor o padrão para desenvolvimento web. Existem bibliotecas que podem reduzir muito o código aqui mostrado, mas a ideia era mostrar como fazer apensa utilizando o que já está disponível por padrão nos navegadores.\nA vantagem de fazer exemplos e testes com os recursos do HTML5 é que você acaba aprendendo mais do que usando direto uma biblioteca, que vai ocultar muitas dessas coisas para simplificar o seu trabalho.\nOutra vantagem é que, por ser HTML, você pode rodar isso em qualquer coisa que tenha um navegador (PC, celulares, tablets, video games, etc). Existem muitos aplicativos mobile que são, na verdade, uma “casca” com um código que executa um HTML dentro do aplicativo.\nEspero que tenham gostado! Estou ansioso para o próximo post desta série!\n","date":"20 de agosto de 2013","externalUrl":null,"permalink":"/pong-html5-javascript/","section":"Blog","summary":"Esta é mais uma série de posts nova no blog para ser um complemento da “Como ser um programador de jogos”. Lá eu escrevo sobre vários aspectos, muitos teóricos, sobre a formação e aprendizagem para se tornar um programador de jogos. Aqui vou mostrar programação de jogos, mas sempre com o jogo PONG.\n","title":"Programando PONG com HTML5 e Javascript","type":"posts"},{"content":"Essa é uma dúvida bem comum que vejo nos comentários do blog, e até recebo por email, então resolvi escrever esse post sobre o assunto. A minha ideia inicial era fazer apenas um texto falando sobre isso, mas durante o texto percebi que seria legal criar um mini guia com os passos para se tornar um programador de jogos.\nTenha em mente que este guia foi criado baseado na minha experiência com desenvolvimento de jogos, nos conhecimentos adquiridos na minha pós-graduação em games, nas empresas que trabalhei (Glu Mobile e Electronic Arts), e também em livros e sites sobre o assunto, além de conversas com profissionais da área. Apesar de ser um post focado para programadores, ele é útil também para artistas e game designers.\nPré-requisitos\nInglês. É muito importante você ter uma boa lógica de programação, conhecer a linguagem que está usando, aprender mais sobre o hardware que vai rodar o seu jogo, saber usar bem a engine ou framework escolhido, entre outras coisas. Mas tudo isso, tudo isso mesmo, depende de você saber pelo menos ler inglês.\nPraticamente não existem livros sobre programação de jogos em português, e os que existem já estão desatualizados por serem antigos. A melhor maneira de aprender hoje é através da internet (fóruns, blogs, sites, tutoriais, vídeos) e livros em inglês.\nSe você realmente quer trabalhar com jogos, vai precisar conversar em inglês. Eu vi isso no meu dia-a-dia, respondendo emails e fazendo reuniões com pessoas em outras partes do mundo por telefone ou skype. É realmente necessário saber ler, escrever e falar. Você não precisa ser fluente, mas fazer um curso de inglês por aqui, além de ler, ouvir e assistir coisas em inglês, ajuda muito.\nMeu inglês não é dos melhores, eu aprendi jogando, ouvindo música, estudando na faculdade, e também fiz um curso de inglês. Isso ajudou demais na hora em que precisei conversar com as pessoas de fora. É claro que nas primeiras vezes eu travei muito, mas com o tempo e prática você ganha mais confiança em falar.\nOutro item importante é jogar com olhar crítico. Não para falar quem um jogo é ruim ou bom, mas para saber analisar como aquele jogo foi feito. Um bom exercício é pegar um jogo e pensar em como você faria a lógica da sua jogabilidade, sem se importar com código, apenas pense e tente entender como o programador do jogo fez aquilo funcionar. Tente também sair da zona de conforto e jogar jogos que você normalmente não jogaria, isso também ajuda aprender a programar jogos.\n","date":"14 de agosto de 2013","externalUrl":null,"permalink":"/como-ser-um-programador-de-jogos-pre-requisitos/","section":"Blog","summary":"Essa é uma dúvida bem comum que vejo nos comentários do blog, e até recebo por email, então resolvi escrever esse post sobre o assunto. A minha ideia inicial era fazer apenas um texto falando sobre isso, mas durante o texto percebi que seria legal criar um mini guia com os passos para se tornar um programador de jogos.\n","title":"Como ser um programador de jogos: Pré-requisitos","type":"posts"},{"content":"Dei uma entrevista para o blog Projeto Hero do Sandro Cavallote. Respondi 20 perguntas falando sobre o mercado de desenvolvimento de jogos no Brasil, cursos para entrar na área, jogos independentes, e outras coisas interessantes. Muito obrigado pela entrevista, Sandro!\nUPDATE: Acho que o blog do Sandro saiu do ar, então publiquei abaixo a entrevista.\nNome\nBruno Cicanci\nEmpresa em que atua\nRevMob Mobile Ad Network (http://revmob.com)\nFormação\nBacharelado em Ciência da Computação e pós-graduado em Produção e Programação de Games\nEmpresas onde já trabalhou\nNa área de jogos trabalhei quase 1 ano na Glu Mobile (http://glu.com) e 2 anos na Electronic Arts (http://ea.com), ambas em São Paulo.\nQual seu jogo preferido\nEssa é uma pergunta muito difícil, é difícil até falar de um jogo preferido em uma determinada plataforma. Vou citar 5 jogos que foram muito importantes para minha carreira:\nStar Wars: Racer, Counter-Strike, Phantasy Star Online, Batman Arkham City e Jetpack Joyrider (não listei jogos das franquias Zelda, Mario, Sonic e Pokemon pois gosto de praticamente todos!).\nDo que se trata o site developergames.com ?\nInicialmente era o meu portfolio, depois comecei a escrever sobre minhas esperiências e também sobre o que está acontecendo na indústria brasileira e internacional.\nComente o passado/presente/futuro do mercado de games no Brasil\nDo ponto de vista de desenvolvimento de games, não existiu praticamente um passado, o presente está crescendo, e no futuro eu acredito que terá uma importância grande no mercado mundial, mas não acredito que será um boom como aconteceu em Montreal. Aqui as coisas são mais complicadas, como abrir empresa e até comprar licenças para desenvolvimento. Hoje temos muitos estúdios independentes batalhando no mercado, e acredito que o futuro da indústria será definido pelos desenvolvedores indies de hoje.\nQual a relação entre arte e videogames?\nVideo games é o conjunto de várias artes, o que, na minha opinião, faz o jogo ser algo grandioso. Jogos reúnem desenhos, animações, “filmes”, música, efeitos sonoros, efeitos visuais, roteiro, dublagem, localização, história, entre outras coisas. Tudo isso é arte, e tudo isso junto (e interação) é jogo, isso sem falar em programação, teste, hardware, marketing, e milhares de outras coisas que fazer parte de um jogo. Um jogo é um produto tão amplo e complexo que merecia mais respeito de que muitas outras formas de arte. A indústria de jogo fatura mais do que filmes e músicas juntos, mas não vemos muitos eventos e prêmios voltados para isso, ou com tanto destaque quanto merecem.\nO Brasil está preparado para tornar-se um desenvolvedor de jogos, ou apenas de mão de obra?\nO Brasil tem algumas pessoas talentosas que fazem de tudo para correr atrás de seus sonhos. Se você tirar essas pessoas esforçadas que realmente fazem jogos, o resto são apenas pessoas que acham que sabem fazer jogos ou entendem algo do assunto sem ter feito nada. Essas pessoas talentosas estão preparadas para criarem jogos incríveis (como já fazem), o resto não.\nComo é a cultura de games independentes no Brasil?\nPraticamente todos estúdios por aqui são independentes, não possuem um publisher ou alto investimento. Eu acho que essa é a cara das empresas daqui, serem indies. Agora o mercado consumidor é diferente, muitos jogadores tem pre-conceito de jogos indie e brasileiros, isso sem falar na pirataria.\nHá faculdades e cursos que atendam a expectativa dos estudantes?\nDepende. Existem cursos que atendem a expectativa dos estudantes sim, mas não existem cursos que atendam a expectativa do mercado. Desenvolver jogos não é fácil, principalmente por ser algo multi-diciplinar. Por isso, vale mais a pena um programador fazer um curso de Ciência da Computação ou Engenharia da Computação e depois se especializar em games do que fazer um curso de programação de games onde você vê tudo de forma introdutória. Existem muitos livros americanos execelentes para ensinar a desenvolver jogos, além de sites.\nQuais as principais diferenças entre um game indie e um da grande indústria?\nUm game indie é (geralmente) produzido sem investimento e sem um publisher para divulgar o jogo depois de pronto. Um game feito em uma empresa grande conta com investimento para ter uma equipe grande e tudo que precisar para desenvolver, além de uma equipe de marketing para divulgar o jogo e fazê-lo vender.\nVocê acredita que há desenvolvedores que possam atender uma possível demanda por games de conteúdo nacional no Brasil?\nAcho que por causa do pre-conceito dos gamers não existe demanda por jogos com conteúdo brasileiro. Talvez apenas em jogos para público infantil vale a pena investir em conteúdo nacional. Porém, algo que todo jogo deve ter (e não é muito complicado de fazer) é a tradução para portugues também, mesmo que o idioma principal seja inglês, isso faz as pessoas jogarem.\nA estrutura dos videogames é montada principalmente em modelos americanos e japoneses. Você acredita que o Brasil poderia ter seu próprio estilo inovador, baseado em nossa cultura?\nO brasileiro é famoso por ser criativo, e isso é visto tanto na criação de um jogo quanto na criação de um estúdio e formação de equipes. Pelos custos (e retorno) nossa indústria sempre se dará bem desenvolvendo jogos independentes para plataformas como mobile e redes sociais, mas não há muito o que inovar na maneira de fazer.\nComo o governo tem se portado com relação ao segmento? Estão ajudando em alguma coisa?\nBom, por mais que digam que existe investimentos e tudo mais, na prática os estúdios estão ralando sozinhos, e tudo que eles conquistam é apenas mérito deles.\nPlataformas como jogos para Facebook e mobile são boas portas de entrada para desenvolvedores independentes?\nCom certeza, pois o custo é muito baixo para desenvolver (considerando licenças e publicação, não a equipe), e existe muito conteúdo por ai para ajudar nisso.\nHá alguma empresa no Brasil que pode ser considerada relevante diante do contexto mundial do segmento?\nExistem algumas empresas que estão conseguindo muito destaque fazendo bons jogos. Não vou citar nomes para não cometer injustiças, mas posso dizer que também existem empresas que não acrescentam em nada. Essa matéria que saiu na folha tem algumas das principais empresas brasileiras: http://www1.folha.uol.com.br/infograficos/2013/08/19379-games-independentes-brasileiros.shtml\nVocê acredita que, por mais inovadores que sejam, os desenvolvedores brasileiros tem noção das dificuldades e organização relacionadas ao empreendedorismo?\nEu acredito que muitos desenvovedores brasileiros não se preocupam muito com isso, eles apenas se concentram em fazer o jogo. Em alguns casos, o jogo não é um sucesso por falta de planejamento e divulgação. Agora, quando existe a estrutura de empresa, ai sim alguém é responsável por isso.\nO que é mais importante para você na hora de desenvolver um game?\nManter os pés no chão e ser humilde. Muita gente tem ideias boas e não consegue colocar em prática, outras tem ideias ruins e acreditam cegamente que seu jogo é o melhor do mundo. Começar com jogos simples também é o ideal, e nunca se achar melhor do que ninguém.\nFinalizando: você acha que o Brasil tem se preocupado com a TEORIA envolvendo a montagem de um game da mesma maneira que se preocupa com a PRÁTICA?\nNão, acredito que nos cursos os professores se preocupam demais com a teoria do que com a prática, principalmente por que a maioria deles nunca fez um jogo. Eu acredito que o mais importante para um profissional da área de games é ter um portfolio para mostrar, e não um diploma dizendo que fez um curso de games.\n","date":"13 de agosto de 2013","externalUrl":null,"permalink":"/minha-entrevista-projeto-hero/","section":"Blog","summary":"Dei uma entrevista para o blog Projeto Hero do Sandro Cavallote. Respondi 20 perguntas falando sobre o mercado de desenvolvimento de jogos no Brasil, cursos para entrar na área, jogos independentes, e outras coisas interessantes. Muito obrigado pela entrevista, Sandro!\n","title":"Minha entrevista para o blog Projeto Hero","type":"posts"},{"content":"O Blender 3D é muito conhecido como um software gratuito e opensource para modelagem e animação em três dimensões, mas não é apenas isso. Allan Brito mostra em seu livro, Blender 3D: Jogos e animações interativas publicado pela Novatec, que podemos desenvolver jogos com sua engine própria.\nQuando conheci o Blender fiquei impressionado pela qualidade do software. Eu não sou artista de 3D, mas pelo pouco que conheço não deixa a desejar se comparado com famosos softwares como XSI, Maya ou 3D Max. É claro que existem diferenças, mas por ser bom e gratuito o Blender é muito utilizado.\nMuitas game engines como a Unity, CryEngine e UDK possuem suporte para importar modelos e animações criadas no Blender. Outra característica bem legal é que ele é um software multi plataforma e roda nos sistemas operacionais Windows, Linux e MacOSX. Por ser opensource, muitas empresas o adotam e alteram seu código para coisas mais especificas.\nO que mais me chamou a atenção foi sua utilização para desenvolver jogos. Eu já tinha ouvido falar, mas só conheci lendo este livro. Você pode criar jogos completos no Blender através de programação visual, juntando blocos de lógica e ligando em seus modelos e animações. Por não precisar de código, o Blender facilita o desenvolvimento de jogos para quem não é programador.\nÉ claro que não é fácil se você não tem alguma noção de lógica, pois estes blocos são a abstração da programação do jogo representados em pedaços ligados nos objetivos dentro do Blender. Para programadores isso pode parecer meio estranho, pra mim pareceu, mas realmente facilita para artistas.\nEste livro apresenta muitas características legais do Blender, desde conceitos básicos de modelagem e animação, até criação de menus, física, controles, colisão e outros itens necessários para fazer um jogo. O Blender exportar o jogo como um executável para desktop, com suporte aos sistemas operacionais que ele roda.Confira abaixo um video de demonstração com animações criadas no Blender.\nO Allan fez um excelente trabalho neste livro explicando desde o básico até coisas mais complexas, por isso recomendo o livro para quem nunca viu nada de 3D e também para quem já trabalha com isso. Da mesma maneira que é bom um programador estudar outras linguagens de programação, um artista não deve ficar preso a uma tecnologia.\nO autor também possui outro livro sobre Blender para animações, já que o foco deste livro é o uso do software para criar jogos. É interessante, e até relaxante, brincar com a engine de jogos do Blender, é como criar algo unindo bloquinhos de Lego.\nDe uma chance ao Blender, é gratuito e muito completo. Muito obrigado a Novatec por me enviar o livro! Você pode comprar Este livro pelo site da Novatec clicando aqui.\n","date":"12 de agosto de 2013","externalUrl":null,"permalink":"/livro-blender-3d/","section":"Blog","summary":"O Blender 3D é muito conhecido como um software gratuito e opensource para modelagem e animação em três dimensões, mas não é apenas isso. Allan Brito mostra em seu livro, Blender 3D: Jogos e animações interativas publicado pela Novatec, que podemos desenvolver jogos com sua engine própria.\n","title":"Blender 3D: Jogos e Animações Interativas","type":"posts"},{"content":"Este é o segundo postmortem de um jogo brasileiro que recebo para postar aqui no blog, desta vez é um jogo para o publico infantil desenvolvido com a Unity pelo Andre Dantas e publicado para Android. Confira os desafios que o Andre enfrentou em publicar seu primeiro jogo abaixo. Se você também fez um jogo e publicou em algum lugar, e quer publicar um postmortem aqui, entre em contato!\nHappy Star Adventures é um jogo casual, direcionado para crianças, mas também é divertido para pessoas de todas as idades. Trata-se das aventuras de uma estrelinha que deve acumular pontos e fugir dos perigos entre céu, terra e mar.\nPara vencer a aventura o jogador deve alcançar 1000 pontos em menos de 3 minutos ajudando a estrelinha a coletar itens e fugir dos vilões. Para guiar a estrela é preciso apenas deslizar o dedo pela tela do dispositivo, ou tocar no local onde deseja que a estrela se desloque.\nBoa aventura!\nSOBRE\nEste é o primeiro jogo para plataformas móveis, desenvolvido por mim. A primeira versão foi desenvolvida em dez dias, logo após o nascimento da minha filha. Desde então, o jogo já recebeu cinco atualizações, e novas aventuras foram adicionadas. O game está disponível para Android e, em breve, para iOS.\nQuem estiver interessado em jogar o jogo, antes de ler o Post Mortem abaixo, é só acessar os links:\nhttps://play.google.com/store/apps/details?id=com.TOPgames.Happy_Star_Adventures\nhttp://happystar-adventures.tumblr.com/\nCONCEITO\nA idéia do jogo veio durante os meus estudos de Unity, para desenvolvimento de jogos para celulares. Eu havia ativado a licença grátis do Android para o Unity3d (versão 3.5) para publicar os jogos para esta plataforma. Os meus jogos anteriores haviam sido desenvolvidos para WEB (Heli Escape e Pale Blue) então eu não sabia se seria tão fácil desenvolver jogos para Android, já que várias funções são específicas das plataformas móveis.\nDecidi fazer um cubo seguir o meu toque. Onde eu tocasse, o cubo deveria ir. Parece ser uma tarefa fácil, mas como o Unity trabalha com um espaço 3D, e as diferentes resoluções e proporções de tamanho de tela (Aspect Ratio) devem ser consideradas, demorei algumas horas para resolver este problema.\nCom este problema resolvido, comecei a imaginar um jogo, onde pudesse utilizar esta funcionalidade. No fim, pensei num jogo onde as pessoas devessem deslizar o dedo pela tela, coletando alguns itens e evitando tocar em outros.\nNo desenvolvimento do Happy Star Adventures, encontrei algumas dificuldades e aprendi algumas lições, que irei compartilhar aqui.\nPROBLEMAS/DIFICULDADES\nIniciar o jogo sem um Game Design Document (GDD) Como parti de uma ideia não muito concreta, terminei por desenvolver um jogo completamente sem projeto/planejamento. Agora, aprendi que isto um erro grave, pois se o desenvolvedor não tem ideia do que pretende fazer, não saberá quando acabou e durante o andamento do projeto, terá inúmeras ideias que poderão ser difíceis de incluir durante o projeto já iniciado.\nPor exemplo, a minha ideia inicial era de fazer apenas uma fase, sem inimigos. Apenas uma estrela passeando enquanto coisas se moviam no background, e os itens para coleta não davam pontos para o jogador. Mostrando aos amigos e familiares, todos sentiram falta de um sistema de pontuação e de algum tipo de perigo a ser evitado. Para implementar estas sugestões, desenvolvi um sistema de pontuação e perigos que, quando tocavam na estrela, subtraíam pontos do jogador. Consequentemente, precisei desenvolver algo que mostrasse se o jogador venceu ou não a partida. Então, limitei o jogo a 3 minutos, no quais o jogador deveria atingir 1000 pontos, ou perderia a partida.\nNada destas funções estavam previstas incialmente e me tomou um bom tempo para inserir tudo isso num projeto em andamento.\n“Fracasso” de Público Apesar deste item não ter sido um erro técnico, adicionei ele neste Post Mortem, pois impacta diretamente no sucesso de um jogo.\nNo começo do projeto, pesquisei em alguns fóruns e vi que o retorno financeiro de jogos grátis, utilizando propagandas internas ao jogo, chegaria a US$1000 facilmente, mesmo em jogos mais simples. Porém, para chegar a esse valor, a quantidade de downloads do jogo deve ultrapassar 10.000 (estimativa).\nDei continuidade ao projeto, e após o lançamento… a frustração. Após 2 meses, apenas 100 pessoas baixaram o meu jogo e a receita das propagandas somavam US$1,33.\nApesar de eu ter feito este projeto como aprendizado, sem expectativas grandes de ganhar dinheiro com isso, eu não achava que o resultado seria tão ruim assim. Comecei a questionar se deveria continuar desenvolvendo jogos ou não.\nUm ponto importante para este problema é que o jogo é direcionado para o público infantil. Mas esse problema eu não poderia resolver mais neste jogo, então precisei procurar outra solução.\nVamos lá. Cada fracasso gera uma nova oportunidade. Não desanimei e comecei a pesquisar mais sobre como fazer um jogo ter uma maior quantidade de downloads. Aprendi que a coisa não é tão fácil quanto me diziam. É extremamente importante planejar uma estratégia de marketing antes mesmo de começar a desenvolver um jogo. Monte o seu site/blog, entre em contato com outros desenvolvedores para opinarem, escreva sobre o andamento do seu projeto, coloque versões Betas para todos verem, mande press releases para sites especializados em jogos… Tudo isto tem que ser feito para aumentar as suas chances de sucesso após o lançamento.\nAntes de começar a colocar esta estratégia em prática, achei que um dos problemas para a falta de popularidade do jogo é que ele possuía apenas uma fase (no Espaço) e resolvi desenvolver uma nova fase (no Campo), lançada 2 meses depois da data de lançamento do jogo.\nEstranhamente, 10 dias antes do lançamento da nova fase, a quantidade de downloads começou a aumentar ligeiramente e logo depois, disparou rapidamente, atingindo uma média do último mês de aproximadamente 35 downloads por dia. As instalações totais, que demoraram 2 meses para chegar a 100, em mais 2 meses, atingiram 1800. As receitas com propagandas já atingem US$61,76.\nA criação da terceira fase (no fundo do mar) já não elevou a quantidade de downloads consideravelmente, como ocorreu no lançamento da segunda fase.\nA minha expectativa inicial ainda não foi atingida, mas pelo menos o resultado já não é tão frustrante quanto no início.\nFalta de Fluidez no Jogo Depois de um tempo notei que, mesmo em dispositivos mais poderosos, o jogo ficava travando rapidamente, prejudicando a fluidez nos movimentos da estrela.\nPesquisando sobre o assunto, achei duas possíveis causas para isto: Excesso de uso do Instantiate (Criação de um objeto durante o jogo) e o uso de planos com múltiplas faces no mesh, para as texturas.\nPara resolver o problema do Instantiate, mudei a estratégia de CRIAR e depois DESTRUIR os objetos de jogo várias vezes, para fazer apenas o reposicionamento deles. Quando um objeto sair da tela, ele volta à posição inicial, sem precisar ser destruído e depois recriado. Esta estratégia melhorou a fluidez parcialmente.\nEm relação aos planos, utilizei um plano criado no Blender, com apenas 1 face (2 triângulos) para substituir o plano nativo do Unity, com 100 faces (200 triângulos). Com isso, reduzi a quantidade de triângulos de aproximadamente 40 mil para 400, otimizando o processamento e melhorando mais ainda a fluidez do jogo.\nDiferenças nas Telas dos Dispositivos Este problema tirou o meu sono várias vezes. Mesmo já tendo chegado a uma solução, sempre que eu tentava fazer ajustes, os objetos ficavam desproporcionais dependendo do Aspect Ratio utilizado, e eu tive dificuldades para entender totalmente como o Unity tratava estas mudanças.\nInicialmente, por meio de programação, fazia cálculos baseado no comprimento (x) e altura (y) da tela. Descobri uma constante que deveria ser aplicado ao tamanho dos objetos, e multiplicava este valor pelo tamanho atual do objeto, fazendo todos os elementos do jogo aumentarem ou diminuírem, dependendo do Aspect Ratio utilizado. Que loucura!\nApós a segunda atualização do jogo, decidi estudar mais este problema. Descobri que o Unity ajusta automaticamente o tamanho da câmera do jogo, dependendo do tamanho da tela em Pixels. Mas se o Aspect Ratio for diferente o tamanho da câmera deve ser ajustado via programação. Assim, descobri qual a fórmula que deveria ser utilizada para ajustar o tamanho da câmera e não precisei mais alterar o tamanho dos objetos. Ficou perfeito para o meu caso, mas esta solução apenas funciona para uma câmera em modo Ortográfico, modo comum em jogos 2D.\nSUCESSOS/APRENDIZADO\nUnity e Playmaker Sem a game engine Unity, eu acho que não teria condições de fazer este jogo, já que eu não tenho muitas habilidades de programação e o Unity permite que muitas funções sejam realizadas por funções já pré-programadas na engine. Sua capacidade de exportar um mesmo jogo para várias plataformas diferentes, praticamente sem configuração extra, torna o desenvolvimento ainda mais fácil. E o melhor, a licença Indie para o Unity é gratuita.\nComo não sei programar muito bem, o Playmaker foi indispensável para que eu conseguisse programar o jogo. O Playmaker é um plugin que permite que a programação seja realizada por meio de diagramas de blocos, substituindo a necessidade de programar diretamente nas linguagens do Unity (Javascript ou C#). O Happy Star Adventures foi totalmente desenvolvido com o Playmaker, sem a necessidade de digitar uma linha de código. Foram os US$45 mais bem gastos da minha vida!\nArte Vetorial As minhas habilidades artísticas deixariam uma criança de 6 meses com inveja. Por isso, decidi me aprimorar tecnicamente, aprendendo a utilizar um programa de desenho vetorial (Inkscape) e usar figuras como modelos para fazer as texturas do jogo. Desta forma, não precisei desenvolver minhas habilidades artísticas, mantendo a arte simples o suficiente para não fazer a minha incompetência aparecer.\nApesar de saber que um artista de verdade faria algo muito melhor, estou satisfeito com o resultado final. Ficou bem melhor do que eu esperava.\nDinheiro! Como já falei, estou recebendo bem menos do que esperava, mas já foi o suficiente para aprender algumas coisas sobre como ganhar dinheiro com aplicativos e jogos grátis.\nEu utilizo o AdMob (do Google) para colocar as propagandas no meu jogo e o AdMob me paga por cada clique que algum usuário dá nestas propagandas.\nDepois que a quantidade de usuários dos Estados Unidos, Canadá e Austrália começaram a baixar mais o meu jogo, descobri uma coisa interessante. O valor pago pelo AdMob por clique nestes países chega a ser 6,3 vezes maior que o que me pagam por clique de brasileiros. Então, definitivamente, façam seus jogos também em inglês e se preocupem em divulgar seus jogos em sites e blogs estrangeiros.\nOutra coisa que aprendi é que, se o jogo for curto, as pessoas não terão tempo suficiente para clicar nas propagandas. Por isso é importante planejar o jogo desde o início para que ele dure o máximo possível para ser terminado.\nRapidez e Simplicidade Por ter mantido o jogo simples desde o início, consegui terminar a primeira versão em apenas 10 dias e já publicá-lo no Google Play.\nSe o jogo levar muito tempo para ser desenvolvido, principalmente se for o seu primeiro, vai dar a você muita dor de cabeça e o fará querer desistir várias vezes durante o processo. Você ainda estará aprendendo a usar as ferramentas e se encontrar um desafio maior, após tanto ter batalhado para chegar aonde chegou, pode colocar tudo a perder, achando que nunca poderá fazer um jogo do início ao fim.\nFelizmente, não senti esta pressão neste jogo e pude, logo após o lançamento da primeira versão, aprender rapidamente onde havia errado e já partir para encontrar as soluções necessárias.\nAlgumas pessoas não acreditam, mas quem nunca fez um jogo do início ao fim, não tem muita ideia de como é difícil fazer um jogo sozinho. Terminar este primeiro jogo te dará moral para conseguir um emprego na área ou para conseguir se unir a uma equipe maior e começar a fazer jogos ainda melhores.\nCONCLUSÃO\nCada vez que começo um projeto deste tipo, me impressiono com a quantidade e complexidade de ferramentas e habilidades que temos que dominar do início ao fim, sem perder o foco. Ao fim, no entanto, a satisfação de ver o seu jogo disponível para todo o mundo é maior do que jogar todos os jogos de uma vez só.\nMas para que isso aconteça, se prepare, seja humilde, aprenda com os erros dos outros e se dedique ao máximo.\nCaso alguém tenha algum questionamento adicional, pode me contatar pelo e-mail localizado no final do site: http://happystar-adventures.tumblr.com/\nPara finalizar, gostaria de agradecer a todos os que me apoiaram durante o desenvolvimento deste jogo, e ao Bruno Cicanci por publicar este Post Mortem em seu blog.\nAbraços para todos.\n","date":"11 de agosto de 2013","externalUrl":null,"permalink":"/postmortem-happy-star/","section":"Blog","summary":"Este é o segundo postmortem de um jogo brasileiro que recebo para postar aqui no blog, desta vez é um jogo para o publico infantil desenvolvido com a Unity pelo Andre Dantas e publicado para Android. Confira os desafios que o Andre enfrentou em publicar seu primeiro jogo abaixo. Se você também fez um jogo e publicou em algum lugar, e quer publicar um postmortem aqui, entre em contato!\n","title":"Postmortem: Happy Star Adventures","type":"posts"},{"content":"Em outubro, entre os dias 16 e 18, a Universidade Presbiteriana Mackenzie em São Paulo recebe o XII Simpósio Brasileiro de Jogos e Entretenimento Digital, também conhecido como SBGames.\nEste é o maior evento da industria de desenvolvimento de games no Brasil, e contará com muitas atracões, como palestras e discussões. Embora seja um evento acadêmico, os poucos profissionais dessa industria também participam, então é uma ótima maneira para conhecer essas pessoas e ampliar seu networking.\nA SBGames tem também uma parte dedicada a artigos acadêmicos, onde você pode escrever um artigo sobre algum tema definido pelo evento e enviar para ser avaliado e publicado. Você pode submeter o artigo em alguma trilha, como Arte e Design, Cultura, Computação e Industria, entre outras.\nCada trilha possui alguns tópicos que podem ser usados como tema para o artigo, então dê uma olhada antes no site. Você tem até o dia 10/07 para enviar o resumo do artigo,e até o do 20/07 para entregar a versão final. No site do evento tem um modelo de artigo em um arquivo doc, sugiro utilizar aquele arquivo e seguir seu padrão.\nAlém dos artigos, você também pode participar desenvolvimento jogos no Festival de Jogos Independentes. Confira aqui o regulamento para saber mais detalhes.\nFique atento as datas e participe! Não sei se é oficial, mas também existe esta pagina no Facebook.\n","date":"3 de julho de 2013","externalUrl":null,"permalink":"/sbgames-2013-em-sao-paulo/","section":"Blog","summary":"Em outubro, entre os dias 16 e 18, a Universidade Presbiteriana Mackenzie em São Paulo recebe o XII Simpósio Brasileiro de Jogos e Entretenimento Digital, também conhecido como SBGames.\n","title":"SBGames 2013 em São Paulo","type":"posts"},{"content":"As vezes recebo emails de desenvolvedores independentes brasileiros mostrando seus jogos recém lançados, e as vezes perguntam se eu posso divulgar. Como este blog é sobre desenvolvimento de jogos, e também meu portfólio, sempre respondi falando exatamente isso. Até que um dia recebi mais um emails desses, do Bernardo Dias, e dessa vez tive uma ideia diferente, que seria interessante para o blog, e também uma forma de divulgar o jogo: pedi para ele me enviar um postmortem do jogo.\nUm postmortem é um documento muito importante de pós-produção, ou seja, é feito após o jogo ter sido lançado. O principal objetivo desse documento é contar as coisas que deram certo e errado, para que todos da equipe possam aprender e melhorar para próximos projetos.\nPor ser um documento que tem como objetivo ensinar, e não é “confidencial” como um documento de game design, muitas empresas divulgam esses documentos após o término do projeto. No site Gamasutra existem muitos publicados, de empresas gigantes e grupos independentes pequenos. Este é o documento mais incrível que podemos conhecer sobre um jogo, pois nele podemos aprender tudo que foi feito para o jogo ser um sucesso, e tudo que não deu certo.\nPara iniciar essa nova categoria aqui no blog, convidei o Bernardo para escrever um postmortem do seu primeiro jogo lançado para Android e iOS, o Come On Rio. O texto abaixo foi escrito por ele, contanto suas experiências e, até mais do que isso, a realização pessoal de fazer um jogo.\nOlá, sou Bernardo Dias, criador de Come On Rio para iOS e Android, um jogo de lógica que tem como tema a cidade do Rio de Janeiro. Estou escrevendo esse artigo para mostrar um pouco do meu primeiro projeto de jogo, como também partilhar um pouco da experiência que pude adquirir e apontar alguns pontos que deram certo e outros que deram errado.\nPrimeiramente, acho importante mencionar que se você pretende desenvolver um jogo de maneira independente, esteja preparado para enfrentar dificuldades que se originam em questões completamente divergentes uma da outra, ou seja, o que quero dizer é que, por exemplo, quando a questão financeira estiver te atrapalhando, aparecerá outro problema diferente, como uma parte da programação que não está funcionando como você desejaria, etc.\nÉ possível pensar depois de ler o parágrafo anterior: “isso é normal e acontece em qualquer tipo de projeto”, ok, mas já parou para pensar em todos esses problemas caindo apenas sobre uma cabeça: a sua, ou então, no máximo na cabeça de cinco ou seis pessoas? É bem complicado… imagina ter que pensar em todo o design do jogo (enredo, GDD, etc), criar toda a arte visual e sonora, a arquitetura e a usabilidade, programar o jogo, corrigir bugs, entre outros, e ainda ter todos esses problemas a sua volta? Isso sem citar os problemas que enfrentamos na vida, no trabalho…\nOutro fator que quero citar é a mudança que o projeto vai sofrer conforme o mesmo for se desenvolvendo, claro que ele não ficará completamente diferente do conceito aplicado inicialmente, porém você terá um projeto bem modificado devido a diversos fatores, como otimização por exemplo. Mas acredite, isso é muito bom porque se trata de um fator essencial no refinamento do projeto, fazendo com que no final você perceba que algumas de suas idéias iniciais eram simplesmente bizarras.\nPara aproveitar o fator das mudanças, citarei algumas que aconteceram na minha experiência de desenvolvimento em Come On Rio através de algumas coisas que deram certo e outras que não foram tão bem assim.\n• Coisas que deram certo:\nA realização de um sonho.\nIndependente do dinheiro ou do sucesso que seu jogo poderá adquirir, acho que nada mais gratificante e importante que você ter uma ideia, trabalhar em cima dela, enfrentar diversos obstáculos para no final, aleluia, você ver o seu jogo disponível para download em todos os continentes do mundo e para milhares de pessoas. Nada mais prazeroso do que estar num local, olhar para o lado e ver uma criança que você não conhece, jogando o seu jogo! Acredito que no final; para o seu primeiro projeto, aquele que vai te colocar dentro do sonho de criar um jogo; não importa se você não ficou milionário com ele ou se ele não fez sucesso mundial, seu jogo não foi um fracasso e sim um vitória! Ele é seu primeiro projeto concluído com êxito que te dará experiência e força para outros futuros projetos.\nSem qualquer tipo de censura.\nDiante de tantos jogos que abordam tiros, sangue, violência ou zumbis, como escolha pessoal, queria que meu primeiro projeto pudesse abordar um tema que não houvesse qualquer tipo de censura, que pudesse ser jogado desde uma criança de sete anos, até uma senhora de sessenta anos sem qualquer tipo de preconceito. No final das contas, percebi que essa ideia principal seguiu ao meu lado até o fim.\nTema único e originado de uma maneira diferente.\nPor vontade própria, eu não queria fazer um jogo clichê de corrida, zumbi ou de arma (apesar de gostar muito de todos esses). Penso que a ideia de um jogo que se passa nos principais pontos turísticos da cidade, presente em Come On Rio, nunca foi utilizada antes. Engraçado que tudo surgiu naquele dia abençoado em que num simples passeio de carro pela cidade, olhando para o maravilhoso Pão de Açúcar à minha esquerda, houve o momento em que uma pessoa que estava comigo definiu a cidade do Rio de Janeiro da melhor maneira que eu já escutei: “o Rio é a cidade mais linda do mundo, pois em nenhum outro lugar há uma harmonia tão grande entre o urbano e a natureza como há nela”. Bem, uniu a vontade de criar um jogo com uma ideia originada a partir de uma definição perfeita para mim: a harmonia entre o urbano e a natureza presente no Rio de Janeiro.\nSe divertir e aprender ao mesmo tempo.\nEngajando no ponto citado anteriormente, com o surgimento da ideia de um jogo sobre o Rio de Janeiro, acho que consegui completar outro objetivo que eu tinha para o projeto após a definição do tema. Penso que foi possível fazer as pessoas se divertirem aprendendo, foi possível passar um pouco de cultura e um pouco da cidade de uma maneira diferente.\n• Coisas que deram errado\nVários jogos em um só.\nPois é, a princípio a minha ideia era em que cada ponto turístico que a pessoa acessasse, fosse possível jogar um jogo diferente. Bem, isso era simplesmente inviável por causa de diversos problemas como o tamanho final do jogo, otimização e tempo que o projeto levaria, sem contar o fato de fazer todos esses diversos jogos com atenção e cuidado total. Por isso no final, optei por fazer apenas um e poder dar total atenção, cuidado, vontade, etc a ele.\nTerminar o projeto em meses.\nQuando finalmente coloquei a mão para trabalhar em Come On Rio, pretendia termina-lo em alguns meses, porém só consegui finaliza-lo depois de um pouco mais de um ano. Acredite, o seu projeto vai demorar muito mais do que você espera. Você não tem 100% do seu tempo para se dedicar ao jogo pois tem que trabalhar ou estudar, como também você não tem milhões de reais para investir em uma equipe e em uma estrutura que vá acelerar o andamento do projeto.\nCriar o jogo exatamente igual em todas as plataformas em que eu lançasse.\nApesar de não afetar a parte do jogo em si e sim a parte mais informativa de Come On Rio, não foi possível (pelo menos por enquanto) disponibilizar as fotos dos pontos turísticos para o projeto no Android, como é disponibilizado no iOS. Por querer atingir o máximo número de dispositivos Android possíveis, por questão de otimização, foi necessário retirar a parte informativa que mostrava lindas fotos do Rio de Janeiro.\nFicar rico\nPois é, pelo menos por enquanto eu não fiquei rsrsrsrs. Realmente é extremamente difícil no primeiro projeto, com pouquíssimos recursos, você conseguir captar muito dinheiro com ele. Você não tem fundos para investir em propagandas em diversos lugares e a única coisa que te resta é trabalhar muito, mas muito mesmo, para tornar o seu jogo famoso.\nComo dito no início do artigo, se você conseguir ter uma ideia, trabalhar em cima dela e no final você ver essa sua ideia obtendo êxito, parabéns, você é um vitorioso! Você conseguiu superar todos os obstáculos e está iniciando seu caminho onde você sempre sonhou caminhar: desenvolvendo jogos. Uma vez li um artigo sobre desenvolvimento de jogos onde Chet Faliszek (roteirista de Half-Life 2, Portal e Left 4 Dead) deu a sugestão para quem quer trabalhar com jogos: apenas faça um. Lembro de ter lido que para ele não tem mistério, basta criar um jogo, todo dia que chegar em casa após o seu trabalho, continue o seu projeto, faça isso até que ele fique pronto e depois coloque-o disponível para venda. Eu fiz isso durante meu projeto e acredito realmente que esse seja o segredo e então sigo-o totalmente todos os dias da minha vida.\nEsse foi o meu primeiro projeto onde foi possível adquirir bastante experiência no desenvolvimento de um jogo para em breve começar a lançar uns projetos em 3D usando a Unity ou outra engine que eu venha a me adaptar melhor. Só para concluir, acredite em uma coisa, você não conseguirá criar um projeto totalmente sozinho. Apesar de ter sido eu a colocar toda a mão na massa para criar tudo em Come On Rio, tive ajudas essenciais para o sucesso do mesmo, primeiramente Deus por me dar forças e recuperar minhas energias todos os dias, um grande amigo que me ajudou criando algumas artes e idéias, uma irmã que simplesmente fez um trabalho fenomenal em passar o jogo todo para inglês,familiares apoiando, e outros grandes amigos que foram beta testers por diversas vezes, inclusive alguns da faculdade que paravam de fazer o que estavam fazendo para me ajudar.\nBem, espero que esse artigo seja útil para quem quer desenvolver um jogo, e que minhas palavras tenham ajudado de alguma maneira. Obrigado a todos e principalmente ao Bruno Cicanci que me deu a excelente ideia de criar esse artigo.\nQuem se interessar em ver como é o jogo, basta baixa-lo gratuitamente nos links abaixo:\nAndroid: https://play.google.com/store/apps/details?id=com.brevo.comeonrio\niPhone/iPod/iPad: https://itunes.apple.com/br/app/come-on-rio/id595551098?l=pt\u0026amp;ls=1\u0026amp;mt=8\nPágina do jogo: http://www.comeonrio.com\nPágina do facebook: http://www.facebook.com/comeonrio\nAbraços,\nBernardo Dias\nEu gostei bastante do texto, e o jogo é divertido. Clique nos links acima para baixar, e confira o trailer abaixo. Bernardo, muito obrigado por compartilhar suas experiências e boa sorte nos seus próximos projetos.\nA partir de agora, sempre que eu receber algum email de sobre jogos, vou sugerir de fazer um postmortem para ser publicado aqui desta mesma forma. Se você, leitor, tem algum jogo publicado e quer compartilhar suas experiências contanto o que deu certo e errado n seu projeto, envie um email para mim (está em Contato).\n","date":"25 de junho de 2013","externalUrl":null,"permalink":"/postmortem-come-on-rio/","section":"Blog","summary":"As vezes recebo emails de desenvolvedores independentes brasileiros mostrando seus jogos recém lançados, e as vezes perguntam se eu posso divulgar. Como este blog é sobre desenvolvimento de jogos, e também meu portfólio, sempre respondi falando exatamente isso. Até que um dia recebi mais um emails desses, do Bernardo Dias, e dessa vez tive uma ideia diferente, que seria interessante para o blog, e também uma forma de divulgar o jogo: pedi para ele me enviar um postmortem do jogo.\n","title":"Postmortem: Come On Rio","type":"posts"},{"content":"Esta foi a segunda palestra que apresentei este ano sobre desenvolvimento de jogos para dispositivos móveis, e desta vez a tecnologia escolhida foi o Corona SDK, um framework bem completo para desenvolver jogos com linguagem script Lua.\nFoi uma experiência bem legal apresentar uma palestra no evento WICA que ocorreu esta semana na Unicsul. Minha apresentação foi no campus do Anália Franco, em São Paulo. Acredito que parte do público foram estudantes do curso de jogos digitais, espero que eles tenham gostado da apresentação!\nAbaixo está a apresentação completa, não deixem de ver também os últimos slides que possuem vários links interessante de livros, sites e revistas sobre desenvolvimento de jogos e sua indústria.\nAlém de alguns códigos com exemplos da utilização do Corona SDK, existem também slides com informações sobre desenvolvimento de jogos, protótipos, dicas, e outras coisas legais.\nMuito obrigado ao pessoal da Unicsul que organizou o evento e por me convidarem para participar!\n","date":"20 de junho de 2013","externalUrl":null,"permalink":"/palestra-corona-sdk-unicsul/","section":"Blog","summary":"Esta foi a segunda palestra que apresentei este ano sobre desenvolvimento de jogos para dispositivos móveis, e desta vez a tecnologia escolhida foi o Corona SDK, um framework bem completo para desenvolver jogos com linguagem script Lua.\n","title":"Como foi a palestra sobre Corona SDK na Unicsul","type":"posts"},{"content":"Hoje, ás 20h, irei apresentar uma palestra sobre desenvolvimento de jogos utilizando o Corona SDK no evento WICA 2013, realizado na Universidade Cruzeiro do Sul (Unicsul), no campus Anália Franco, em São Paulo.\nConfira aqui como chegar lá, e também as outras palestras do evento que começou ontem e vai até amanha em todos os campus da Unicsul em São Paulo.\n","date":"18 de junho de 2013","externalUrl":null,"permalink":"/palestra-unicsul-corona-sdk/","section":"Blog","summary":"Hoje, ás 20h, irei apresentar uma palestra sobre desenvolvimento de jogos utilizando o Corona SDK no evento WICA 2013, realizado na Universidade Cruzeiro do Sul (Unicsul), no campus Anália Franco, em São Paulo.\n","title":"Palestra na Unicsul sobre desenvolvimento de jogos com Corona SDK","type":"posts"},{"content":"Scott Rogers, game designer e autor do livro “Level Up! Um guia para o design de grande jogos“, concedeu uma excelente entrevista para o blog sobre game design. Fiquei muito feliz com a entrevista, e estava ansioso para postar aqui!\nEle trabalha há muitos anos como game designer, participou de projetos como Pac-Man World, Maximo, God of War Collection, Darksiders, entre vários outros, e atualmente é produtor de jogos na Disney e professor em uma universidade na Califórina. Abaixo está a entrevista original, em inglês, e depois uma tradução que fiz. As respostas do Scott foram tão boas que fiz questão de traduzir para todo mundo poder ler e aprender com as dicas desse excelente game designer! Não deixe também de conferir meu posto sobre o livro Level Up!, e você pode comprar o livro clicando aqui.\nVersão em inglês (original):\n1) What do you think is the most important thing for a Game Designer create great games?\nWhat does “great” mean? That a game makes a lot of money? Is very popular? Gets positive reviews? Spawns a series of sequels? Gets adapted into a movie or action figures? “Great” by any of those definitions is too hard and unrealistic a target for a designer to hit. Besides, “great” is like “fun” and if you’ve read my book “Level Up! The Guide to Great Game Design” you know how much I dislike the term “fun.” It’s too subjective a term. A game you might think is great, I might think is just okay or even bad.\nWhat the designer needs to make “great” is their design (I realize that my book has the word “great” in the title but I am referring to “great game design” not just making a “game great” – there is a difference.) – when the design is great, the game will be great and all of those other things I mentioned about will come. Or not. Just like famous screenwriter William Goldman says “No one knows anything.” Which means you’re never going to predict how well a game does when it is released. All you can do is make the most interesting, challenging, exciting game you can design.\nMake sure all the playable elements are stable (camera, controls, character for starters) and that you are making a game that YOU would want to play. If you don’t want to play it, why would anyone else? The most important thing for a game designer to do is to make a game they CARE about playing. That excitement and enthusiasm will come through in the game to the player, trust me on this. Players can tell when a designer is just going through the motions – they can feel it in the game. Then you might just have a great game.\n2) A game designer should play tons of different games?\nAbsolutely.\nPlay great games and play crappy games. Play more of the crappy games than the good ones. You will learn more from the bad ones because you will learn what you don’t like and not repeat those mistakes in your game. Make sure you play games that you normally wouldn’t play. Even if you don’t play sports games or casual games or JRPGs, there are important things to learn from each and everything genre which you can apply to your own game – even if it’s something as simple as how the pause screen appears. You should keep your mind open because you never know where a good idea will come from.\n3) In your book ‘Level Up’ you introduced the 3 Cs (Character, Camera and Control). How do you end up with that definition?\nThey all started with the letter C.\nI grouped them together in “Level Up!” and gave them so much attention (a chapter each!) because they are the most important things to get right when starting to make a game. Most players will stop playing your game if any of these three elements doesn’t work. And if a player stops playing your game, you’ve lost. From a production perspective, if you change any of these three while you are in the middle of production you will ruin your game… or at least cause you lots of headaches and excessive work.\nI have seen it happen to many teams, many times during my career. I hope that readers come away with realizing that these three elements are very important and give them a good hard look as they start to design their game.\n4) Beside game design books, what other stuff a student should read?\nEverything. And don’t just read about game design. You should be reading everything you can get your hands on because inspiration comes from everywhere. Will Wright, the designer of the Sims, read books on biology, Japanese gardening and urban planning. These were his hobbies but they inspired him to create one of the most successful game franchises of all times. If every game designer only reads comics and video game design books, we’ll end up with every game feeling similar and what good is that? It’s variety that keeps our industry alive and fresh and exciting! But even more importantly, it’s your own personal interests and perspectives that give games their unique voice. Find what gets you exciting and turn that into gameplay!\n5) We have a very different industry here, but thinking in the North America industry what it’s the best way to break into a game company as a game designer?\nMake games.\nWe live in a time where it hasn’t been easier for an individual (or a group of individuals) to make a game. There are so many cheap and free tools to make games. There are so many ways to hook up with other like minded people to make a game with – school, the internet, social circles. There’s no excuse not to make a game these days. It used to take thousands of dollars and dozens of people to make a game. Now it doesn’t. So what’s stopping you? Only yourself.\nOnce you have made a game, you now have a calling card. Even if you don’t sell your game, you can show it to others. Nothing communicates a game idea quicker than letting someone play the game. This is why I’m such a big fan of prototyping. If your game idea is fun to play at a prototype stage, then it will be fun to play as a final game. Once you have your made your game prototype go to conventions, drink-ups, ask to talk to game developers to show off your stuff. Don’t be afraid to share – no one is out to steal your idea. Or, if you feel your game is great, sell it on Steam or through the iTunes store or on XBLA if you can get them to accept it. Then people will come to you.\n6) What a game designer (student or professional) should do to keep improving their skills?\nMake games. (I’m starting to feel like a broken record here!) Work on other people’s games (sometimes it’s best to check your ego at the door and do some hard work on someone else’s idea for a while) Play games (even the bad ones). Learn to talk and think critically about games. Always provide a “because” when you give your opinion to others. Keep honing those writing skills and those pitching skills. Game design is all about communication. Communication of your ideas to the team, communication of your design to the investors, communication of mechanics and storytelling to the player. You can never be a strong enough communicator and even the best communicators always feel they could learn more. Never stop learning.\nVersão em português (minha tradução):\n1) O que você acha que é o mais importante para um Game Designer fazer excelentes jogos?\nO que “excelente” significa? Um jogo que faz muito dinheiro? Muito popular? Tem muitas avaliações positivas? Milhares de sequências? É adaptado em um filme ou bonecos? “Excelente” por qualquer uma daquelas definições é muito difícil e um objetivo não realista para um game designer alcançar. Além disso, “excelente” é igual “divertido”, e se você ler meu livro “Level Up! Um guia para o design de grande jogos” você verá o quanto eu não gosto do termo “divertido”. É um termo muito subjetivo. Um jogo que você pensa ser excelente, para mim pode ser apenas ok ou até ruim.\nO que o designer precisa para fazer “excelente” jogos é o seu design (eu percebi que meu livro tem a palavra “excelente” no título, mas eu estou me referindo a um “excelente game designer”, não apenas fazer um “jogo excelente”) – quando o design é excelente, o jogo será excelente e todas aquelas outras coisas que eu mencionei virão. Ou não. Como o famoso escritor William Goldman diz “Ninguém sabe nada”. O que significa que você nunca irá prever quão bom um jogo será até o seu lançamento. Tudo que você pode fazer é o jogo mais interessante, desafiador e excitante que você pode criar.\nTenha certeza de que todos elementos de jogo são estáveis (câmera, controles, personagens para iniciantes), e que você esta fazendo um jogo que VOCÊ gostaria de jogar. Se você não quer jogá-lo, quem iria querer? A coisa mais importante para um game designer fazer é criar um jogo que ele se importe com a jogabilidade. Aquela excitação e entusiasmo virão para o jogador através do jogo, confie em mim nisso. Um jogador pode falar quando um designer está indo pela emoção – eles conseguem sentir isso no jogo. Então você pode ter um excelente jogo.\n2) Um game designer deve jogar muitos jogos diferentes?\nAbsolutamente.\nJogar excelente jogos e jogar jogos ruins. Jogador mais jogos ruins do que bons. Você irá aprender mais de jogos ruins por que você vai aprender o que você não gosta e não irá repetir aqueles erros no seu jogo. Tenha certeza de que você jogue jogos que você normalmente não jogaria. Mesmo que você não jogue jogo de esporte, jogos casuais ou RPG japonês, existem coisas importantes para aprender de cada gênero que você pode colocar no seu próprio jogo – mesmo coisas simples como a maneira que a tela de pause aparece. Você deve manter sua mente aberta por que você nunca sabe quando uma boa ideia surgirá.\n3) No seu livro “Level Up!” você introduziu os 3 Cs (Character (Persoangem), Cêmera e Controle). Como você chegou nessa definição?\nTodos começam com a letra C.\nEu agrupei eles juntos no “Level Up!” e dei muita atenção (um capítulo para cada!) por que eles as coisas mais importantes para acertar quando se começa a fazer um jogo. Muitos jogadores irão parar de jogar o seu jogo se um desses três elementos não funcionar. E se um jogador parar de jogar o seu jogo, você perdeu. Da perspectiva de produção, se você alterar qualquer um desses três elementos enquanto você está no meio da produção, você irá arruinar o seu jogo… ou pelo menos causar muita dor de cabeça e trabalho excessivo.\nEu tenho visto isso acontecer com muitas equipes, muitas vezes durante minha carreira. Eu espero que os leitores percebam que esses três elementos são muito importantes e deem a eles uma boa atenção quando começarem a desenvolver seus jogos.\n4) Além de livros de game design, que outras coisas um estudante deve ler?\nTudo. E não somente ler sobre game design. Você deve ler tudo que puder por que a inspiração vem de todo lugar. Will Wright, o designer do jogo The Sims, lê livros de biologia, jardins japonses e planejamento urbano. Esses eram os seus hobbies mas eles o inspiraram a criar uma das fraquinas de jogos de maior sucesso de todos os tempos. Se todo game designer ler apenas quadrinhos e livros de game design, vamos ter muitos jogos similares, e o no que isso é bom? É a variedade que mantém a indústria viva, estimulante e excitante! Mais importante ainda, são os suas perspectivas e interesses pessoais que dão aos jogos sua voz única. Descubro o que de deixa animado e transforme isso em jogabilidade!\n5) Temos uma indústria muito diferente aqui (no Brasil), mas pensando na indústria norte americana, qual é a melhor maneira de entrar em uma empresa de jogos como game designer?\nFaça jogos.\nVivemos em um tempo que é fácil para uma pessoa (ou um grupo de pessoas) fazer um jogo. Existem tantas ferramentas gratuitas e baratas para fazer jogos. Existem tantas maneiras de se conectar com outras pessoas para criar jogos – escola, internet, circulos sociais. Não existem desculpas para não fazer um jogo hoje em dia. Antes precisavamos de milhares de dólares e dezenas de pessoas para fazer um jogo. Hoje não precisamos mais. Então, o que está te impedindo? Apenas você mesmo.\nQuando você fizer um jogo, você terá um cartão de visita. Mesmo se você não vender seu jogo, você pode mostrar para os outros. Ninguém explica uma ideia de jogo tão rápido quando deixar alguém jogar o jogo. É por isso que eu sou um grande fã de protótipos. Se a sua ideia de jogo é divertida de jogar no estágio de prototipagem, então o jogo final será divertido também. Quando você tiver feito seu protótipo, vá para convenções, happy hours, mostre para desenvolvedores de jogos. Não tenha medo de compartilhar – ninguém vai roubar sua ideia. Ou, se você sentir que o seu jogo é excelente, venda no Steam, ou iTunes, ou XBLA, se você conseguir fazer seu jogo ser aceito. Então, as pessoas virão até você.\n6) O que um game designer (estudante ou profissional) deve fazer para continuar melhorando suas habilidades?\nFaça jogos (estou começando a me sentir como um disco quebrado aqui!) Trabalhe nos jogos de outras pessoas (as vezes é melhor deixar o seu ego de lado e trabalhar duro na ideia de outra pessoa por um tempo). Jogue jogos (mesmo os ruins). Aprenda a falar e pensar de maneira crítica sobre jogos. Sempre diga um “por que” quando der sua opinião para outras pessoas. Continue aprimorando as habilidades de escrita e criação. Game design é comunicação. Comunicação das suas ideias para a equipe, comunicação do seu design para os investidores, comunicação da mecânica e história para o jogador. Você nunca será comunicativo o bastante, e mesmo os melhores comunicadores sempre sentem que podem aprender mais. Nunca pare de aprender.\nSabe como consegui essa entrevista com ele? Apenas entrei em contato com ele para elogiar o seu livro, e acabamos conversando um pouco por email. Quando sugeri de fazer a entrevista e ele ficou feliz e aceitou! Então, uma dica pessoal para vocês: NÃO TENHA MEDO DE ENTRAR EM CONTATO COM PROFISSIONAIS DA INDÚSTRIA DE GAMES! =)\nMuito obrigado, Scott!\n","date":"5 de junho de 2013","externalUrl":null,"permalink":"/entrevista-scott-rogers/","section":"Blog","summary":"Scott Rogers, game designer e autor do livro “Level Up! Um guia para o design de grande jogos“, concedeu uma excelente entrevista para o blog sobre game design. Fiquei muito feliz com a entrevista, e estava ansioso para postar aqui!\n","title":"Entrevista: Scott Rogers, game designer e autor do livro Level Up!","type":"posts"},{"content":"Apesar de eu ser programador, sempre gostei de ler sobre game design. Já li alguns livros, mas este é realmente o mais prático e direto de todos. Level Up: Um guia para o design de grandes jogos, de Scott Rogers, é uma obra essencial para estudantes e profissionais da indústria de games.\nO livro foi lançado recentemente no Brasil pela editora Blucher, a mesma que trouxe a coleção Regras do Jogo, e a qualidade é novamente muito boa. Eu já tinha ouvido falar desse livro, mas nunca tinha lido. Eu fiquei impressionado só de ler o conteúdo no índice do livro, cada capítulo ensina tudo que você precisa saber sobre design de jogos de uma maneira bem objetiva e didática.\nNa introdução do livro o autor explica diversas coisas básicas sobre desenvolvimento de jogos, como diferenças de gêneros, quem faz o quê na equipe, distribuição do produto, entre outras coisas essenciais para uma boa base, antes de partir para o game design. Logo no começo o livro apresenta algo que eu não vi em outro livro: um documento de game design (GDD). E não apenas isso, mas mostra a importância de começar o documento antes mesmo de iniciar o projeto, pois lá que estará definido tudo o que terá em seu livro.\nApós a introdução, o autor apresenta a definição dos três “Cs”: Character, Camera e Control. Cada um dos “Cs” é importante para definir a jogabilidade, pois envolve pensar no personagem e seus atributos, a câmera do jogo e com será o controle do jogo. É simples, mas muito inteligente e eficaz. Definindo os três “Cs” no seu GDD, seu jogo estará caminhando para uma jogabilidade bem definida. É claro que isso não quer dizer que será divertida ou viável, essas coisas você só descobrirá testando com protótipos.\nO autor também fala de usabilidade da interface, design de níveis, inimigos, multiplayer, música, feedback, entre vários outros aspectos que devem ser bem definidos no GDD. Outra parte muito impressionante no livro é o apêndice, que contém muitas coisas legais, como um modelo de GDD e até um exemplo completo! O livro é muito completo, com leitura fácil, muitas ilustrações e um conteúdo muito bom.\nSabe por que esse livro é tão bom? O autor, Scott Rogers, trabalha na indústria de jogos a mais de 20 anos, e chegou a trabalhar com jogos 16 bits para Super Nintendo e Mega Drive. Vou citar alguns dos jogos que ele participou do desenvolvimento: Pac-Man World, Maximo, God of War Collection, Darksiders, entre outros. Atualmente ele trabalha na Disney Interactive como Produtor, além de ser professor de Level Design na Universidade do Sul da Califórnia e autor de dois livros (este e um outro de game design para touchscreens).\nEste livro é muito bom por que foi escrito por alguém que realmente trabalha com game design, e entende muito do assunto. A própria linguagem do livro é mais fácil, pois você sente como se o autor estivesse do seu lado te explicando como fazer um bom game design. Esse livro é obrigatório para estudantes e game designers, e essencial para programadores e artistas que querem conhecer mais sobre game design.\nQuero agradecer a editora Blucher por ter me enviado uma cópia desse livro, muito obrigado!\n","date":"16 de maio de 2013","externalUrl":null,"permalink":"/level-up-game-design/","section":"Blog","summary":"Apesar de eu ser programador, sempre gostei de ler sobre game design. Já li alguns livros, mas este é realmente o mais prático e direto de todos. Level Up: Um guia para o design de grandes jogos, de Scott Rogers, é uma obra essencial para estudantes e profissionais da indústria de games.\n","title":"Level Up: Um guia para o design de grandes jogos","type":"posts"},{"content":"Carlos Estigarribia começou a trabalhar com jogos para dispositivos móveis quando estes aparelhos ainda eram tijolos monocromátivos. Quando eu entrei na Electronic Arts, ele era o Diretor do estúdio no Brasil, e ano passado deixou a empresa e abriu a RightZero para explorar um nicho muito importante para o mercado de jogos por aqui. Confira a entrevista abaixo!\nComo surgiu o interesse em trabalhar com jogos? Desde o início seu interesse foi por mobile?\nBom, como quase todo mundo que trabalha na área o interesse surgiu desde que comecei a jogar quando era pequeno. Depois do Atari passei logo para o PC XT, com tela “verde”, daquelas que deixavam o olho vendo tudo meio rosa depois de horas de jogo.\nO interesse real veio na época da faculdade, mais para o final do curso, quando tinha que decidir o que fazer e não me via trabalhando como desenvolvedor de software para bancos ou coisas “caretas”. Surgiu uma oportunidade de estágio numa empresa que fazia CD-ROM de jogos educacionais (meados dos anos 90) e por ali iniciei a carreira. O interesse por mobile veio anos depois, na época que eu comecei não havia nem telefone celular ainda.\nSua formação em Engenharia da Computação ajudou no início da sua carreira?\nCom certeza, me deu uma excelente base de programação em qualquer linguagem, pois focávamos muito em algoritmos, estrutura de dados e orientação a objeto, sem focar numa linguagem específica. Isso ajuda até hoje, já que linguagens novas surgem toda hora e na prática são todas iguais, sabendo bem os conceitos é questão de aprender a sintaxe.\nAlém das matérias ligadas à desenvolvimento de software tinhamos também muita coisa ligada à “hardware”, circuitos elétricos e protoboards (e programação em Assembly). Na época achava que não iria usar, e realmente não usei diretamente, mas ajudou a aguçar o sentido de explorar e de se divertir mexendo em tudo o caísse na frente.\nVocê trabalhou alguns anos na LocZ e na SkyZone, como foi começar a trabalhar com jogos em uma época que os celulares eram aparelhos extremamente limitados para entretenimento?\nNós começamos na primeira geração de aparelhos, tínhamos fazer jogos WAP e SMS. O desafio era como fazer jogos que cativassem o jogo usando só texto. O grande aprendizado foi que é possível sim, e que na verdade o bom gameplay é que faz o diferencial. Claro que tendo mais recursos certos estilos de jogos ficam mais interessantes (e outros estilos aparecem), mas as premissas de criação de jogos são as mesmas, independente da sofisticação do console, celular ou PC.\nO fundamental é entender o que cada meio tem de melhor e como o jogador se comporta enquanto joga. Para celular saber que o jogador tera sessões curtas e interrupções constantes foi algo que aprendemos logo nos primeiros jogos.\nDepois disso, você foi um dos responsáveis por começar o estúdio da Electronic Arts Mobile em São Paulo. Quais foram os desafios para começar um estúdio de uma empresa de fora aqui?\nO maior desafio foi adequar e treinar o time rapidamente nas ferramentas workflow de uma empresa grande, de modo a sermos produtivos rapidamente.\nOutro ponto importante foi de ter a noção de fazer parte de uma empresa global, com projetos sendo feitos em conjunto com até 4 estúdios ao mesmo tempo, essa foi uma grande quebra de paradigma, até então nós produzíamos tudo em um estúdio só, esse modelo de co-produção era novidade para nós.\nComo diretor da EA Mobile, sua visão de negócios mudou em relação a visão que você tinha antes?\nSim, mudou muito. Na EA eu consegui ver o lado “big business” do mundo dos games, até então eu tinha uma visão de startUP, me ajudou muito a entender os dois lados e as decisões difíceis que precisam ser tomadas regularmente.\nComo você vê o fim do estúdio da EA Mobile em São Paulo, em relação ao mercado de desenvolvimento de jogos no Brasil?\nO que aconteceu na EA é normal, a cada 5 anos sempre ocorre readequação das grandes empresas de jogos para otimizar o lucro, não vejo muito como essa história poderia ter sido diferente, o corte atingiu praticamente todos os estudios de mobile e social da EA, foi uma mudança de mentalidade da matriz, não teve nada a ver com o resultado do estudio aqui, que era positivo.\nEm relação ao mercado daqui o que eu adoraria ver seria o time da EA (e o da Glu também) conseguindo investimento para montar um novo estudio nacional de mobile, pois os profissionais são altamente qualificados e será uma pena se o time seguir para outras áreas, isso pra mim é a grande perda, mais de 7 anos de treinamento que podem ir por água abaixo se ninguem aproveitar os talentos e criar um novo estúdio rápido.\nSua empresa atual, a RightZero, tem como foco auxiliar empresas de games que querem fazer negócios no Brasil. Como surgiu a oportunidade de explorar esse nicho?\nDesde 2011 eu comecei a ser consultado por muitas empresas de fora querendo dicas para entrar aqui. Na época estava ainda na EA e não poderia atuar em outros negócios. Decidi então sair e montar novamente um negócio próprio, focando nessa necessidade dos americanos, europeus e asiáticos de entender o mercado brasileiro de jogos. O negócio surgiu depois que eu identifiquei essa demanda.\nComo as empresa de fora veem o mercado brasileiro (consumidores e desenvolvedores)?\nNa parte de mercado consumidor o Brasil é a bola da vez, basta ver o número de empresas lançado jogos localizados para cá, ninguem faz isso se não houver mercado. A tendência é de crescer mais ainda, pois o número de pessoas que estão finalmente tendo acesso à banda larga e a computadores bons o suficiente para rodar jogos não pára de crescer. O mesmo vale para mobile, a migração para SmartPhones e Tablets está acelerada.\nNo que se refere a desenvolvimento o Brasil ainda não tem história, então eu vejo pouca chance de um estúdio querer entrar aqui para desenvolver. Os casos que tivemos no passado da Glu e EA foram iniciativas que partiram do porting para o mercado local e depois expandiram para produção de jogos para fora, mas não vejo essa necessidade para jogos de iOS, Android ou Browser, dá pra fazer lá fora.\nVocê aconselharia alguém que quer trabalhar com jogos no Brasil a abrir sua própria empresa? Por que?\nSim, mas o fundamental é ter os sócios certos, a meu ver a empresa de jogos (ou qualquer outra em industrias criativas de tecnologia) precisam ter 3 figuras distintas:\n– diretor de tecnologia\n– diretor de design/produto\n– diretor de desenvolvimento de negócios\nSem isso a empresa vai acabar não conseguindo vender seu peixe, ou o produto vai ser bom mas sem um “wow” factor, ou vai ser bonito mas não vai escalar bem.\nO grande problema é que geralmente as empresas não tem 3 pessoas que se complementem, e mesmo que seja apenas 2 socios bem intencionados chega num ponto em que vai faltar tempo (ou saco) para tocar essas 3 áreas. Nessa hora as empresas começam a contratar alguem que supra o que falta, mas é necessário que a pessoa seja sócia para realmente dar certo.\nQue dica você daria para quem quer ser um empreendedor na área de games no Brasil?\nAlém dos toques basicos do tipo “fale ingles MESMO”, “estude muito”, “se prepare para ficar noites sem dormir”, etc, a dica que dou para qualquer pessoa (independente de ser de games ou não) que queria montar uma empresa é: tem que estar disposto a arriscar MESMO, no sentido de saber que cada dia que você está com sua própria empresa é um dia a menos que você poderia estar empregado e recebendo no final do mês, então você deve ter um plano muito claro de onde está investindo o seu tempo e o que realmente deseja alcançar no final. Se você pudesse estar recebendo mais e se realizando mais estando em uma empresa, não faz sentido pra mim ter seu próprio negócio.\nAs pessoas as vezes confundem um chefe chato, ou uma empresa ruim com “eu queria mesmo era ter a minha própria empresa”, e não é isso.\nEmpreender dentro de uma empresa já existente pode ser o caminho para muita gente, emprender não é so montar uma empresa, mas ter uma visão clara do que você quer pro seu futuro e de coisas realmente vão te dar satisfação. Pode ser dentro de uma empresa ou montando a sua própria, vai de cada um, mas o conceito de empreender é que muita gente não entende realmente.\n","date":"29 de abril de 2013","externalUrl":null,"permalink":"/entrevista-carlos-estigarribia/","section":"Blog","summary":"Carlos Estigarribia começou a trabalhar com jogos para dispositivos móveis quando estes aparelhos ainda eram tijolos monocromátivos. Quando eu entrei na Electronic Arts, ele era o Diretor do estúdio no Brasil, e ano passado deixou a empresa e abriu a RightZero para explorar um nicho muito importante para o mercado de jogos por aqui. Confira a entrevista abaixo!\n","title":"Entrevista: Carlos Estigarribia, diretor na RightZero","type":"posts"},{"content":"Pouca gente sabe, mas a Electronic Arts tinha um estúdio de desenvolvimento de jogos aqui no Brasil até hoje, em São Paulo, no qual trabalhei por 2 anos. Esse estúdio, que começou com projetos de porting J2ME, chegou a participar de desenvolvimento de jogos para Android em conjunto com o estúdio da Electronic Arts de Montreal.\nTive o privilégio de conhecer e trabalhar com excelentes profissionais brasileiros, canadenses, russos, romenos, indianos, entre outros. Como muitos estúdios no mundo cuidavam de uma parte (framework interno, franquias, porting, etc), a gente tinha contato com muita gente de outros países durante os projetos.\nNesses 2 anos participei de 4 projetos grandes, sendo que em dois deles fui líder da pequena equipe de 3 programadores (contando comigo). Foi uma oportunidade única trabalhar em uma empresa grande como a EA na versão de Android de jogos de franquias famosas. Abaixo estão os 4 principais projetos (android) que trabalhei, sendo que meu nome consta nos créditos de 3 deles:\nBejeweled 2 Tetris (creditado como Programmer) FIFA 12 (creditado como Programmer) Scrabble (creditado como Software Engineer) Uma das coisas que tenho pendente para colocar no blog é o meu portfólio atualizado com todos projetos que trabalhei na Electronic Arts e na Glu Mobile, duas empresas incríveis que infelizmente fecharam as portas no Brasil. Agora essas empresas fazem parte de um grupo que já têm Gameloft e Ubisoft – empresas grandes que vieram para o Brasil, duraram alguns anos, e fecharam).\nÉ triste ver essas empresas grandes fechando por aqui. Cada uma teve um motivo diferente, mas independente disso quem sofre é a indústria e os profissionais. Boa sorte a todos que fizeram parte da história da Electronic Arts no Brasil, foi muito bom enquanto durou.\nUPDATE:\nSegundo post no Gamasutra, houve demissões na EA Montreal também: http://migre.me/e4QF7\n","date":"11 de abril de 2013","externalUrl":null,"permalink":"/electronic-arts-fecha-estudio-de-sao-paulo/","section":"Blog","summary":"Pouca gente sabe, mas a Electronic Arts tinha um estúdio de desenvolvimento de jogos aqui no Brasil até hoje, em São Paulo, no qual trabalhei por 2 anos. Esse estúdio, que começou com projetos de porting J2ME, chegou a participar de desenvolvimento de jogos para Android em conjunto com o estúdio da Electronic Arts de Montreal.\n","title":"Electronic Arts fecha estúdio de São Paulo","type":"posts"},{"content":"Voltei hoje para São Paulo após uma experiência muito legal em Blumenau. A palestra sobre desenvolvimento de jogos com Cocos2d-x foi muito boa, e fiquei contente com a recepção e perguntas do público!\nO auditório da biblioteca da Universidade de Blumenau logo encheu, com mais de 200 pessoas segundo o professor Everaldo.\nA palestra correu bem e acreditamos que os alunos que assistiram gostam, principalmente pelas perguntas que fizeram no final da apresentação. Foi muito bom também conversar com as pessoas que vieram até nós após a palestra.\nDepois vou postar mais fotos do evento aqui. Abaixo está a apresentação como foi prometido! Fiquem a vontade para baixar, tem links muito legais nos últimos slides. Qualquer dúvida é só deixar um comentário aqui que logo responderemos!\nMuito obrigado ao pessoal da FURB pela oportunidade de ir até lá falar sobre desenvolvimento de jogos, especialmente o professor Everaldo e o Júlio. Obrigado!\n","date":"10 de abril de 2013","externalUrl":null,"permalink":"/palestra-cocos2d-x-blumenau/","section":"Blog","summary":"Voltei hoje para São Paulo após uma experiência muito legal em Blumenau. A palestra sobre desenvolvimento de jogos com Cocos2d-x foi muito boa, e fiquei contente com a recepção e perguntas do público!\n","title":"Como foi a palestra sobre Cocos2d-x em Blumenau","type":"posts"},{"content":"Amanhã irei apresentar uma palestra sobre desenvolvimento de jogos com a Cocos2d-x na Universidade de Blumenau, em Santa Catarina!\nA palestra faz parte de um evento da universidade chamado Semana Acadêmica. Nossa palestra apresentará a Cocos2d-x e as facilidades que este framework oferece para o desenvolvimento de jogos mobile. Também apresentaremos uma base de programação de jogos (visão geral), falaremos sobre protótipos e por onde começar um projeto de jogo.\nPreparamos alguns slides com diversos links interessantes com artigos, sites, revistas, livros, e outras informações. Após a palestra os slides serão publicados aqui!\n","date":"8 de abril de 2013","externalUrl":null,"permalink":"/palestra-furb-cocos2d-x/","section":"Blog","summary":"Amanhã irei apresentar uma palestra sobre desenvolvimento de jogos com a Cocos2d-x na Universidade de Blumenau, em Santa Catarina!\n","title":"Palestra na Universidade de Blumenau sobre Cocos2d-x","type":"posts"},{"content":"Tenho que começar esse post pedindo desculpas pela falta de novos posts aqui no blog, fiquei sem tempo pra escrever aqui nos últimos meses, mas agora vou voltar a manter este blog atualizado! Pra começar o ano, decidi escrever sobre as novidades e tendências este ano para os desenvolvedores de jogos independentes.\nHá alguns anos atrás existiam poucas tecnologias boas e gratuitas para desenvolver jogos independentes ou por hobbie, e menos ainda lugares e oportunidades para publicar e divulgar os jogos. A geração atual de video games, e também o rápido crescimento do mercado mobile, fez surgir muitas ferramentas gratuitas para desenvolver jogos incríveis, aliadas a oportunidades para fazer dinheiro com isso sem precisar de uma empresa.\nEm 2013 muita coisa legal vai acontecer, e a maior parte delas já começaram em 2012. Separei em tópicos algumas das coisas que eu considero mais importantes para ficar de olho este ano, mas isso não quer dizer que é “apenas” isso.\nOUYA\nO OUYA é projeto milhonário financiado pelo através de um projeto no Kickstarter saiu do papel ano passado, e algumas unidades destinadas a desenvolvedores começaram a ser enviadas. Até mesmo empresas brasileiras, como a Flux, já receberam seu kit de desenvolvimento e começou um projeto em parceria com outro studio brasileiro, o Reload.\nA próxima etapa é começar a produção comercial do console. Eu acredito que o OUYA irá crescer muito com jogos independentes, sendo uma opção mais barata (e não menos divertida) do que um console “tradicional”. Empresas como a Unity estão apoiando o console com concursos para desenvolver e promover o OUYA, que roda jogos desenvolvidos para Android.\nSmartphones e Tablets\nHá 2 anos eu estava trabalhando na Glu Mobile com jogos em J2ME, que deveriam rodar em milhares de aparelhos, inclusive alguns hardwares muito fracos com telas de 128×160 pixels. O mercado mobile está crescendo tão rápido que em 2 anos os aparelhos estão cada vez melhores e avançados. Ano passado a HTC lançou um aparelho com tela Full HD (1920×1080), embora seja um resolução que está ficando comum para tablets, este foi o primeiro smartphone com esta tela absurda, e este ano as demais empresas do mercado também irão lançar aparelhos com resolução Full HD, ou até maior.\nEstamos chegando em um nível tão avançado de hardware que poderíamos rodar jogos mais pesados de console e PC sem problemas. Eu disse “poderíamos” pois existem dois problemas que são barreiras para tormar um smartphone ou tablet em uma plataforma definitiva para jogos: bateria e memória.\nExistem muitos jogos legais e viciantes para aparelhos móveis, porém você deixa de jogar para economizar bateria, pois poderá precisa do celular para outras coisas, e acaba não jogando. Outro problema é o tamanho que o jogo ocupa na memória. O FIFA 12, por exemplo, ocupa 1.5GB, o que é bastante para um jogo de celular, mas pouco para a qualidade e conteúdo desse jogo. Talvez a solução para esse problema seja aumentar a memória absurdamente, ou fazer streaming de jogos.\nStreaming de jogos\nServiços como o OnLive permitem que você jogue em seu smartphone ou tablet jogos de PC com alto desempenho, só precisa uma conexão muito boa para jogar sem Lag. Nesse streaming, o jogo roda em um servidor do OnLive, que envia em tempo real a imagem para seu smartphone ou tablet.\nEste é um serviço que pode virar uma tendência no futuro, pois mesmo que um tablet ou smartphone possa rodar um jogo pesado, eles não tem espaço na memória suficiente para armazenar um ou vários jogos. A grande barreira atualmente é o alto custo para os servidores que rodam os jogos, e também exige uma conexão de internet muito rápida e estável para ficar em Lag.\nNovos sistemas operacionais mobile\nPor enquanto temos, aparelhos Blackberry que rodam BlackBerry OS, aparelhos da Apple que rodam iOS, aparelhos de alguns fabricantes que rodam Windows, e aparelhos de diversos fabricantes que rodam Android. Porém, agora algumas empresas querem lançar seus próprios sistemas operacionais mobile, compatíveis com aparelhos que rodam Android.\nCom esses novos sistemas operacionais, como o Firefox OS e o Ubuntu Phone, essas empresas estão buscando meios de incentivar os desenvolvedores a criarem aplicativos e jogos para seus sistemas. Muitos incentivos são destaques em suas lojas, além de softwares e suporte adequado para facilitar ao máximo a programação. Provavelmente outros sistemas operacionais irão surgir, mas não sei se esta fragmentação ainda maior do mercado mobile é interessante para os desenvolvedores.\nSBGames em São Paulo\nA SBGames, o maior evento brasileiro de games com foco acadêmico e profissional, será realizado este ano em São Paulo, na Universidade Presbiteriana Mackenzie, em outubro. Eu, particularmente, estou empolgado e quero participar desse simpósio, talvez com um artigo.\nConfiram no site as datas, palestras e tudo mais que irá acontecer na SBGames. Se você é de São Paulo, não perca essa oportunidade de conhecer outras pessoas que trabalham e estudam desenvolvimento de jogos.\nJogos com conteúdo em português\nGrandes empresas estão cada vez mais preocupadas em localizar seus jogos para o emergente mercado brasileiro. Se jogos AAA estão saindo com legenda e até dublagem (como excelente trabalho feito no Forza Horizon abaixo), por que seu jogo independente não pode ter?\nOs desenvolvedores independentes brasileiros sempre miram no mercado externo (o que está absolutamente correto), mas é legal também agradar aos jogadores de seu país com conteúdo localizado.\nTV digital\nJogos em TVs estão ficando mais comuns lá fora, e aqui estamos começando a ver TVs com loja de aplicativos e jogos ficarem populares. Este é um mercado pouco explorado, onde poucas empresas estão dominando por ausência de concorrentes.\nNão conheço muitos detalhes de como funciona para publicar um jogo, mas existe muita oportunidade nesta plataforma, que conta até com sensor de movimento e reconhecimento de voz.\nO blog\nInfelizmente, o blog ficou alguns meses parados. Porém, nesse tempo, eu fiquei organizando muita coisa que quero postar aqui, então logo os posts serão mais frequentes. Além disso, em breve o blog ganhará um novo layout que já está em desenvolvimento, e muitas novidades virão! Aguardem! =)\n","date":"9 de fevereiro de 2013","externalUrl":null,"permalink":"/como-sera-2013-para-os-desenvolvedores-independentes/","section":"Blog","summary":"Tenho que começar esse post pedindo desculpas pela falta de novos posts aqui no blog, fiquei sem tempo pra escrever aqui nos últimos meses, mas agora vou voltar a manter este blog atualizado! Pra começar o ano, decidi escrever sobre as novidades e tendências este ano para os desenvolvedores de jogos independentes.\n","title":"Como será 2013 para os desenvolvedores independentes","type":"posts"},{"content":"A DICE, empresa sueca que desenvolveu os jogos da franquia Battlefield e Mirror’s Edge, possui uma página (e uma conta no SlideShare) onde são divulgados diversas apresentações técnicas de áreas como programação, arte, design, áudio, entre outras relacionadas a desenvolvimento de jogos.\nMuitos assuntos avançados são abordados usando como exemplo a tecnologia utilizada em seus jogos mais recentes, como Battlefield 3, e sua game engine, Frostbite 2, que também foi utilizada no jogo Need for Speed: The Run.\nO conteúdo (em inglês) é bem legal para quem está estudando desenvolvimento de jogos e quer saber o que as empresas grandes fazem para produzir seus jogos, e com qual tipo de tecnologia e problemas elas lidam no seu dia-a-dia.\nSelecionei algumas apresentações que achei interessantes, mas não deixe de conferir as demais no site deles. São tantas apresentações legais que fica difícil escolher algumas para postar, mas essas são algumas das que mais me interessei em ler.\n","date":"15 de outubro de 2012","externalUrl":null,"permalink":"/apresentacoes-tecnicas-da-dice/","section":"Blog","summary":"A DICE, empresa sueca que desenvolveu os jogos da franquia Battlefield e Mirror’s Edge, possui uma página (e uma conta no SlideShare) onde são divulgados diversas apresentações técnicas de áreas como programação, arte, design, áudio, entre outras relacionadas a desenvolvimento de jogos.\n","title":"Apresentações técnicas da DICE","type":"posts"},{"content":"A Unite é uma conferência anual que a empresa por trás da game engine Unity realiza desde 2007 para apresentar novidades e realizar palestras sobre cases e melhores práticas. Os vídeos da edição desse ano, realizada em Amsterdã, já estão no site e você pode conferir aqui!\nAlém de palestras técnicas, detalhes da nova versão da Unity e apresentação de cases, o evento também contou com a presença de Peter Molyneux, famoso game designer de Fable e Black \u0026amp; White, que fez uma apresentação junto aos fundadores da Unity (vídeo abaixo). Não deixe de conferir também os vídeos dos anos anteriores.\nSe você não conhece, a Unity é uma game engine (um software para criação de jogos), com versão gratuita, que permite o desenvolvimento de jogos com modelos 3D e programação em C#, Javascript ou Boo. Uma das suas principais características é que o mesmo jogo feito nela pode ser compilado para iOS, Android, PC/Mac, Flash, Web, Wii, Xbox 360, PS3, e já anunciaram suporte ao WiiU (lembrando que cada plataforma exige uma licença diferente, só para PC/Mac e Web é gratuita). Faça o download no site e brinque um pouco, ela é gratuita para publicar jogos no PC e Web, e com certeza você vai gostar!\nOutra novidade sobre a Unity é que a Rovio, produtora do famoso Angry Birds, lançou um jogo essa semana com os porquinhos, chamado Bad Piggies (vídeo abaixo), e este jogo 2D também foi feito com a Unity. O mais impressionante é que a Unity não tem suporte a 2D, apenas 3D, então deve ter dado muito trabalho para fazer aquele jogo! Eles travaram a câmera 3D para mostrar o jogo em plataforma, mas não sei como fizeram as animações, é realmente impressionante.\n","date":"2 de outubro de 2012","externalUrl":null,"permalink":"/unite-2012/","section":"Blog","summary":"A Unite é uma conferência anual que a empresa por trás da game engine Unity realiza desde 2007 para apresentar novidades e realizar palestras sobre cases e melhores práticas. Os vídeos da edição desse ano, realizada em Amsterdã, já estão no site e você pode conferir aqui!\n","title":"Unite 2012 - Vídeos da conferência anual da Unity","type":"posts"},{"content":"A Cocos2d-x é um framework para desenvolvimento de jogos mobile em código nativo (C/C++), para Android e iOS, entre outras plataformas. Este framework é uma versão da Cocos2d, que serve para desenvolvimento de jogos apenas para iOS, pois a programação é em Objective-C.\nMuitos desenvolvedores independentes, e até empresas, estão utilizando a Cocos2d-x para desenvolver seus jogos, pois isso permite a publicação do mesmo jogo em mais de uma plataforma mobile, sem a necessidade de refazer o jogo. Basta apenas compilar para a plataforma desejada (depois de configurar o ambiente de desenvolvimento e o projeto corretamente).\nA Cocos2d-x é opensource e está disponível no GitHub, junto com a versão iOS/Objective-C (cocos2d-iphone), HTML5/Javascript (cocos2d-html5) e C#/XNA (cocos2d-x-for-xna). Essas quatro versões são diferentes entre si, cada uma serve para uma plataforma distinta, porém sua arquitetura e conteúdo são praticamente os mesmo, a única diferença é a linguagem de programação.\nEntão, se você entender como funciona qualquer versão, poderá utilizar as demais com facilidade. Outra vantagem desse padrão é que existem excelentes ferramentas que suportam a Cocos2d, como o TexturePacker (para criar sprite sheets), o PhysicsEditor (para adicionar física ao jogo) e o Tiled (que criar mapas 2d e perspectiva). Eu já usei essas três ferramentas com a Cocos2d-x, e recomendo! Existe também algumas ferramentas do site Game Dev Helper, que são parceiros do Cocos2d-x, mas eu nunca usei.\nAlém dos tutoriais do site da Cocos2d-x, existem muitos exemplos espalhados pela internet. Se você encontrar algo, mas estiver em Objective-C (cocos2d), provavelmente vai existir a mesma coisa na Cocos2d-x em C/C++, você só precisa ter paciência e converter o código para achar o seu correspondente.\nPara desenvolver no Windows você deverá utilizar o Visual Studio Professional ou Express, e a Cocos2d-x possui templates para as versões 2008, 2010 e 2012. No Mac OSX você deverá utilizar o Xcode para programar, e também existem templates para adicionar a Cocos2d-x na hora de criar um novo projeto. Existe também suporte ao Linux, mas não sei qual IDE é a mais indicada. Lembrando que apenas no Mac OSX você poderá desenvolver para iOS (iPhone e iPad), os demais sistemas operacionais tem suporte apenas ao Android.\nNo site da Cocos2d-x também existem vários tutoriais muito bons que ajudam a configurar o ambiente de desenvolvimento no sistema operacional que você quiser utilizar. Se você não conhece, dê uma chance a Cocos2d-x, acho que você vai gostar!\nEste mês o blog ficou meio parado, sem posts novos. Mas agora voltarei a postar com uma frequência maior, e em breve haverão novidades por aqui! Não deixe de curtir e acompanhar a página do blog no Facebook, lá também posto alguns links interessantes de artigos, vídeos e sites.\n","date":"29 de setembro de 2012","externalUrl":null,"permalink":"/cocos2d-x/","section":"Blog","summary":"A Cocos2d-x é um framework para desenvolvimento de jogos mobile em código nativo (C/C++), para Android e iOS, entre outras plataformas. Este framework é uma versão da Cocos2d, que serve para desenvolvimento de jogos apenas para iOS, pois a programação é em Objective-C.\n","title":"Desenvolvimento de jogos utilizando a Cocos2d-x","type":"posts"},{"content":"O livro Regras do Jogo: Fundamentos do Design de Jogos (Rules of Play: Game Design Fundamentals) é uma obra famosa sobre Design de Jogos, uma referência em diversos cursos de desenvolvimento de jogos no mundo inteiro, e a editora Blucher lançou no Brasil uma versão traduzida deste livro.\nEscrito por Katie Salen e Eric Zimmerman (ambos designers de jogos e professores em universidades americanas), este livro trata a criação de um jogo de forma lúdica, desde os conceitos básicos sobre o que é jogar, segundo o filósofo Johan Huizinga (que escreveu Homo Ludens), até conceitos mais atuais, todos aplicados a Design de Jogos.\nSua abordagem é muito ampla, cobrindo tudo que um Game Designer precisa saber a respeito de criar conceitos e mecânicas de jogos. Este livro também faz o leitor pensar e rever conceitos sobre a importância da atividade lúdica para o ser humano. Eles livro é um guia para o Designer de Jogos entender vários aspectos que um jogo possui, como sua influência cultural, e também ensina a explorar mais a capacidade lúdica que os jogos possuem.\nA editora Blucher dividiu o livro em 4 volumes, cada um com uma parte diferente do livro. Abaixo está o conteúdo de cada volume:\nVolume 1 – Principais Conceitos – tem como temas a interação lúdica significativa, o design, os sistemas, a interatividade, a definição de jogos e de jogos digitais, o circulo mágico e os esquemas primários.\nVolume 2 – Regras – tem como temas a definição das regras, as regras em três níveis e dos jogos digitais, os jogos como sistemas emergentes, de incerteza, de teoria da informação, de informação, cibernéticos, da teoria dos jogos e por fim como sistemas de conflitos, além de abordar a quebra das regras.\nVolume 3 – Interação Lúdica – tem como temas a definição de interação, os jogos como experiência lúdica e do prazer, os jogos como interação lúdica de significados, narrativa e da simulação, e ainda os jogos como experiência social.\nVolume 4 – Cultura – tem como temas a definição de cultura e os jogos como retórica cultural, cultura aberta, resistência cultural e ambiente cultural.\nA qualidade da tradução do livro está muito boa, e este é um livro obrigatório para estudantes e game designers! A leitura é bem tranquila, e o conteúdo é realmente bom para qualquer pessoa que gosta de desenvolvimento de jogos. Mesmo pesquisadores que desenvolvem trabalhos acadêmicos relacionados a video games podem aproveitar este livro, graças a visão única dos autores e de todo material que eles pesquisaram para criar este livro.\nQuero agradecer a editora Blucher por gentilmente me enviar os 4 volumes da coleção Regras do Jogo, muito obrigado! Vocês podem comprar os livros no site da editora ou em livrarias.\n","date":"14 de agosto de 2012","externalUrl":null,"permalink":"/regras-do-jogo-editora-blucher/","section":"Blog","summary":"O livro Regras do Jogo: Fundamentos do Design de Jogos (Rules of Play: Game Design Fundamentals) é uma obra famosa sobre Design de Jogos, uma referência em diversos cursos de desenvolvimento de jogos no mundo inteiro, e a editora Blucher lançou no Brasil uma versão traduzida deste livro.\n","title":"Regras do Jogo (Rules of Play) lançado no Brasil pela editora Blucher","type":"posts"},{"content":"Eu não lembro como encontrei isso, mas neste link está publicado o manual de desenvolvimento para o Nintendo 64, com vários detalhes de sua arquitetura e hardware!\nO Nintendo 64 foi provavelmente o console de video game que eu mais joguei, passei muito tempo com 007 Gondeneye, Mario Kart, Pokemon Stadium e Conker’s Bad fur day. Ele foi um console fantástico, com muitos jogos bons que são lembrados até hoje. Claro que o Playstation teve mais destaque nessa época, mas eu ainda prefiro e sinto saudades do meu Nintendo 64.\nNaquela época nem imaginava que hoje eu trabalharia com jogos. Como programador, é muito interessante ler sobre como funcionava o desenvolvimento de outras plataformas, e o Nintendo 64 provavelmente deixou muitos desenvolvedores empolgados com seu kit de desenvolvimento (devkit) e as incríveis possibilidades que seru hardware oferecia.\nTudo que você precisa saber sobre a arquitetura, programação, pipeline gráfica, e várias outros detalhes do hardware do Nintendo 64 está nesse manual de março de 1999, e a parte mais legal dele são as palavras “Nintendo® Confidential” no rodapé das páginas.\n","date":"7 de agosto de 2012","externalUrl":null,"permalink":"/devkit-nintendo-64/","section":"Blog","summary":"Eu não lembro como encontrei isso, mas neste link está publicado o manual de desenvolvimento para o Nintendo 64, com vários detalhes de sua arquitetura e hardware!\n","title":"Manual de desenvolvimento para Nintendo 64!","type":"posts"},{"content":"Após 2 anos de filmagem, o projeto Critial Path saiu do papel, e conta com um acervo online composto por diversas entrevistas de veteranos da indústria de games.\nCkiff Blesinski (Gears of War), Will Wright (The Sims, Spore), Nolan Bushnell (Fundador da Atari), Ken Levine (Bioshock), Sid Meier (Civilization), Warren Spector (Deus Ex, Epic Mickey), John Carmack (Quake, Doom) e Hideo Kojima (Metal Gear) são alguns nomes famosos que mudaram a indústria de jogos e contribuiram para esse documentário online, contando um pouco sobre suas experiências.\nO foco desse documentário é bem diferente do pessoal que fez o Indie Game: The Movie, pois este retratou exemplos da cena independente da indústria de jogos. O Critial Path mostra a opinião dos veteranos, pessoas que fazem jogos milionários com grandes equipes. É muito legal ouvir a opinião desse pessoal, principalmente suas dicas.Não deixe de conferir os vídeos do Critical Path!\n[Game Gurus Finally Get Some Screen Time in Documentary Interviews, em inglês, via AllThingsD]\n","date":"24 de julho de 2012","externalUrl":null,"permalink":"/critical-path/","section":"Blog","summary":"Após 2 anos de filmagem, o projeto Critial Path saiu do papel, e conta com um acervo online composto por diversas entrevistas de veteranos da indústria de games.\n","title":"Critical Path, o documentário online com veteranos da indústria","type":"posts"},{"content":"O OUYA é um projeto de console de video game, baseado na plataforma Android, que precisava de “apenas” $1 milhão de dólares para sua produção e comercialização, e eles já conseguiram mais de $5 milhões no Kickstarter.\nSua proposta é revolucionar a indústria de games oferecendo um console de baixo custo (cerca de $99 dólares), com muitos jogos gratuitos (e alguns bem baratos), sem a necessidade de mídia física. Seu hardware possui uma boa configuração para rodar o sistema operacional Android, totalmente aberto e pronto para ser explorado em todos seus limites pelos desenvolvedores (e hackers).\nO modelo de negócios pretendido pelo OUYA é uma versão muito melhorado do falido console brasileiro Zeebo. Diferente do Zeebo, o hardware do OUYA é bom para rodar jogos mobile, e provavelmente muitos títulos famosos e atuais estarão disponíveis na sua loja virtual.\nUma das características que me chamou mais a atenção é o suporte que eles darão aos desenvolvedores. Qualquer console pode ser utilizado para desenvolvimento, e o devkit não precisa ser comprado, nem sequer uma licença para desenvolver. Por ser um sistema Android, o desenvolvimento é basicamente o mesmo que mobile, apenas é necessário adaptar o jogo para usar o controle do OUYA e sua lib.\nPodem ser necessárias algumas adaptações de gameplay, pois todo jogo android é baseado em touch, mas essa deve ser uma das poucas camada de desenvolvimento necessárias para fazer um jogo android rodar no OUYA. Mais detalhes sobre o projeto podem ser vistos no site do Kickstarter, e o IGN fez uma mini review no vídeo abaixo para apresentar o console.\n","date":"23 de julho de 2012","externalUrl":null,"permalink":"/ouya/","section":"Blog","summary":"O OUYA é um projeto de console de video game, baseado na plataforma Android, que precisava de “apenas” $1 milhão de dólares para sua produção e comercialização, e eles já conseguiram mais de $5 milhões no Kickstarter.\n","title":"OUYA, o projeto de console baseado em Android","type":"posts"},{"content":"Hoje fiz minha apresentação na trilha de games da TDC 2012 em São Paulo, sobre desenvolvimento de jogos mobile. Mesmo com frio, chuva e véspera de feriado, muita gente foi ao evento e a sala estava cheia durante minha apresentação!\nEu havia anunciado a palestra durante a semana neste post, e agora estou postando a apresentação completa. Respondendo aos pedidos do outro post, infelizmente não houve filmagem da palestra.\nMuito obrigado ao pessoal que foi assistir e a equipe da Global Code pela oportunidade de falar sobre desenvolvimento de jogos em um evento que está cada vez maior no Brasil!\n","date":"8 de julho de 2012","externalUrl":null,"permalink":"/palestra-jogos-mobile-tdc-2012/","section":"Blog","summary":"Hoje fiz minha apresentação na trilha de games da TDC 2012 em São Paulo, sobre desenvolvimento de jogos mobile. Mesmo com frio, chuva e véspera de feriado, muita gente foi ao evento e a sala estava cheia durante minha apresentação!\n","title":"Palestra sobre Desenvolvimento de Jogos Mobile na TDC 2012 São Paulo","type":"posts"},{"content":"Eu estava fuçando em alguns links antigos e achei uma apresentação bem legal sobre o hardware do Playstation 3. São vários slides com vários detalhes técnicos sobre desenvolvimento, arquitetura e programação no PS3.\nEste é um material (em inglês) criado pelo diretor do centro de pesquisa e desenvolvimento da Sony na Europa, indispensável para quem deseja conhecer como funciona o PS3 por dentro, e como é a programação em seu ambiente.\nDetalhes sobre o gerenciamento de memória, processamento, renderização, entre outros são apresentados e explicados. Existe até alguns slides explicando por que consoles são diferentes de computadores em relação ao hardware.\nConfira abaixo a apresentação, ou faça download do PDF aqui.\n","date":"7 de julho de 2012","externalUrl":null,"permalink":"/conheca-o-hardware-do-ps3-em-detalhes/","section":"Blog","summary":"Eu estava fuçando em alguns links antigos e achei uma apresentação bem legal sobre o hardware do Playstation 3. São vários slides com vários detalhes técnicos sobre desenvolvimento, arquitetura e programação no PS3.\n","title":"Conheça o hardware do PS3 em detalhes","type":"posts"},{"content":"No dia 4 de julho (daqui a dois dias) começa o evento The Developer’s Conference São Paulo 2012, na Universidade Anhembi Morumbi – Campus Vila Olímpia. Organizado pela Global Code, o TDC 2012, que vai até o dia 8 de julho, conta com várias trilhas relacionadas à tecnologia.\nEste ano irei realizar uma palestra sobre Desenvolvimento de Jogos Mobile na trilha de Games, que acontece no último dia do evento (8 de julho, às 13h10). Abaixo está um resumo que escrevi para o evento sobre o que seria a minha palestra:\nConheça como está o mercado de jogos para dispositivos móveis, uma das plataformas que mais cresceu nos últimos anos, e está presente em todo o mundo. Com tantas opções de plataformas mobile para desenvolver jogos e aplicativos, é preciso conhecer como melhor aproveitar essa tecnologia e garantir que seu produto seja um sucesso. O HTML5, novo padrão web, veio para ajudar também o desenvolvimento de webapps e jogos multiplataformas. Saiba como escolher a melhor tecnologia para desenvolver um jogo, como funciona o processo de desenvolvimento de um game, e conheça algumas dicas para estudar e desenvolver sua carreira como desenvolvedor de jogos.\nSe algum leitor for no dia da trilha de games, fique a vontade para falar comigo! =)\nUPDATE: A apresentação utilizada na palestra foi postada aqui.\n","date":"2 de julho de 2012","externalUrl":null,"permalink":"/tdc-sao-paulo-2012/","section":"Blog","summary":"No dia 4 de julho (daqui a dois dias) começa o evento The Developer’s Conference São Paulo 2012, na Universidade Anhembi Morumbi – Campus Vila Olímpia. Organizado pela Global Code, o TDC 2012, que vai até o dia 8 de julho, conta com várias trilhas relacionadas à tecnologia.\n","title":"TDC São Paulo 2012: Minha palestra na trilha de games!","type":"posts"},{"content":"O André Kishimoto, professor do curso de Jogos Digitais na Unicsul, engenheiro de software na Electronic Arts e autor do ebook gratuito Programação Windows: C e Win32 API com ênfase em multimídia, publicou sua palestra “Máquina de Estados: Controlando o Jogo, do Menu à IA“, que foi apresentada no evento WICA 2012 (Workshop de Informática e Computação Aplicada), na UNICSUL Liberdade em São Paulo.\nAlém da palestra, o Kishimoto também disponibilizou o código-fonte com os exemplos de implementação de máquinas de estado em um jogo. O exemplo foi programado com XNA (C#), porém seu conceito é genérico, e pode ser utilizado com qualquer outra linguagem de programação. O código-fonte e a apresentação estão disponíveis no GitHub do Kishimoto.\nO uso de máquinas de estado para controlar o fluxo do jogo é muito utilizado, pois possibilita um controle maior do fluxo e estado do jogo. Não importa se o seu projeto é um Jogo da Velha ou um World of Warcraft, o conceito de máquina de estados pode ser implementado praticamente da mesma maneira em qualquer projeto.\n","date":"13 de junho de 2012","externalUrl":null,"permalink":"/maquina-de-estados-aplicada-a-jogos/","section":"Blog","summary":"O André Kishimoto, professor do curso de Jogos Digitais na Unicsul, engenheiro de software na Electronic Arts e autor do ebook gratuito Programação Windows: C e Win32 API com ênfase em multimídia, publicou sua palestra “Máquina de Estados: Controlando o Jogo, do Menu à IA“, que foi apresentada no evento WICA 2012 (Workshop de Informática e Computação Aplicada), na UNICSUL Liberdade em São Paulo.\n","title":"Máquina de estados aplicada a jogos","type":"posts"},{"content":"Hoje é o lançamento mundial do documentário sobre desenvolvimento de jogos independentes, chamado Indie Game: The Movie. O filme, que é uma produção independente financiada com crowdfunding (duas vezes, aqui e aqui), foi feito com o depoimento de diversos desenvolvedores de jogos independentes famosos, como os criadores dos fantásticos Super Meat Boy e Braid.\nAtravés do site é possível comprar o filme (DRM-free), e assistir online (streaming) ou baixar para assistir em qualquer aparelho. Também é possível comprar no iTunes e no Steam. O filme custa apenas $9.99 dólares e tem muito material legal sobre como é realmente a produção de um jogo independente, o que deu certo, o que deu errado, as decisões difíceis, a emoção de criar um sucesso indie, entre várias outras coisas.\nSe você está estudando desenvolvimento de jogos, trabalha na área, ou simplesmente é um jogador que gosta de jogos indie, eu recomento comprar o filme. Eu comprei pelo site oficial, e lá o vídeo tem opções para download em HD e Full HD, além de versões com legendas em Inglês, Português, Francês, Italiano, Chinês Tradicional e Árabe. Eu estou baixando o filme agora, e depois de assistir pretendo fazer uma review e postar aqui. Existem algumas reviews no IMDB, além de outras informações mais técnicas, caso você queira saber.\nEste documentário contou com apoio de muitos desenvolvedores de jogos e ganhou alguns prêmios. É um trabalho incrível e feito por pessoas que acreditam na importância dos jogos independentes para a indústria, e fizeram esse filme para que esses desenvolvedores pudessem contar toda a sua experiência em criar jogos incrívelmente viciantes e simples. Se você ainda não está tão empolgado quando eu, assista o trailer abaixo! Você também pode ver mais vídeos no canal oficial no Youtube.\n","date":"12 de junho de 2012","externalUrl":null,"permalink":"/indie-game-the-movie/","section":"Blog","summary":"Hoje é o lançamento mundial do documentário sobre desenvolvimento de jogos independentes, chamado Indie Game: The Movie. O filme, que é uma produção independente financiada com crowdfunding (duas vezes, aqui e aqui), foi feito com o depoimento de diversos desenvolvedores de jogos independentes famosos, como os criadores dos fantásticos Super Meat Boy e Braid.\n","title":"Indie Game: The Movie","type":"posts"},{"content":"Pensando na próxima geração de consoles, a Square Enix desenvolveu uma nova game engine. E, para demonstrar todo o poder do seu novo motor gráfico, foi apresentado uma tech demo chamada Agni’s Philosophy, baseado no universo de sua famosa franquia Final Fantasy.\nExiste mais um detalhe que torna essa demonstração ainda mais impressionado: a animação é renderizada em tempo real! Animações, como filmes ou cutscenes, geralmente são pré-renderizados, para não exigir muito do hardware e garantir que a qualidade fique boa.\nSe prestarem atenção no vídeo, poderão reparar nos detalhes como poeira, fumaça, fluídos e muitos outros efeitos gráficos que enriquecem a qualidade da engine e impressionam por serem feitos em tempo real.\nEu nem consigo imaginar o tamanho dos arquivos desse projeto, e as técnicas gráficas avançadas implementadas, mas tenho certeza de uma coisa: a próxima geração de consoles contarão com tecnologias incríveis para os desenvolvedores!\nDica do Diego Dedize! Não esqueçam de curtir a página do blog no Facebook!\n","date":"8 de junho de 2012","externalUrl":null,"permalink":"/agnis-philosophy/","section":"Blog","summary":"Pensando na próxima geração de consoles, a Square Enix desenvolveu uma nova game engine. E, para demonstrar todo o poder do seu novo motor gráfico, foi apresentado uma tech demo chamada Agni’s Philosophy, baseado no universo de sua famosa franquia Final Fantasy.\n","title":"Agnis Philosophy - a impressionante tech demo da Square Enix","type":"posts"},{"content":"Esta é a última parte da série de posts com dicas sobre como organizar seu projeto de jogo. Neste último post farei um comparativo sobre o uso dos serviços na nuvem, apresentados nos posts anteriores, e o que vale a pena manter offline. Confiram aqui a parte 1, parte 2, parte 3 e parte 4.\nOnline vs Offline\nTudo que foi apresentado até aqui visa manter todas as informações do projeto na nuvem da internet, para que todos os membros tenham fácil acesso a qualquer hora, através de qualquer computador ou dispositivo móvel. Pelos motivos apresentados, como compartilhar sempre arquivos atualizados e facilitar a organização do projeto, todos estes serviços online são incrivelmente úteis.\nPorém, existem coisas que podem funcionar melhor localmente. Por exemplo, para armazenamento da arte do jogo, que muitas vezes pode ter vários gigas, o DropBox pode ser pequeno e lento demais. Neste caso, é recomendado a utilização de um servidor local com dois HDs grandes em RAID 1, para garantir que os dados não sejam perdidos, além de backups de segurança em algum HD externo ou PC. Isso pode parecer exagero, ou um pouco demais para um simples projeto, mas acredite: é melhor ser organizado e prevenido do que perder dias, semanas ou meses de trabalho.\nAlém da arte, os arquivos de som podem ser grandes demais para serem armazenados no DropBox, por isso vale a pena guardar apenas documentos do projeto lá. O código-fonte sempre deverá ficar em um local seguro e de fácil acesso, como o GitHub ou BitBucket. Para não peder muito tempo com os arquivos de arte e som, eu recomendo armazenar junto com o código-fonte apenas os arquivos finais, como um arquivo PNG, e armazenar os fontes em algum lugar como foi sugerido no parágrafo anterior, como um arquivo PSD que gerou o PNG.\nÉ sempre bom ter alguns backups locais, em caso de precisar acessar rapidamente os arquivos mesmo sem conexão com a internet, mas lembre-se de que se algo acontecer com o seu computador, seu trabalho poderá ser perdido se não estiver em um local seguro. Por esse motivo, eu utilizo o DropBox para arquivos, BitBucket para código-fonte, e todo o resto deixo em um HD externo. Pouca coisa fica apenas no meu computador, o que é bom pois eu posso acessar qualquer coisa ao mesmo tempo em qualquer computador, sem precisar de um pendrive ou compartilhar na rede.\nEspero que vocês tenham gostado desta série, nunca é tarde para organizar um projeto! Não importante o tamanho do seu projeto, na verdade nem importa se é um jogo, o importante é cuidar bem e organizar tudo que foi desenvolvido durante o projeto.\n","date":"7 de junho de 2012","externalUrl":null,"permalink":"/organizacao-projeto-jogo-parte-5/","section":"Blog","summary":"Esta é a última parte da série de posts com dicas sobre como organizar seu projeto de jogo. Neste último post farei um comparativo sobre o uso dos serviços na nuvem, apresentados nos posts anteriores, e o que vale a pena manter offline. Confiram aqui a parte 1, parte 2, parte 3 e parte 4.\n","title":"Organização de um projeto de jogo (parte 5)","type":"posts"},{"content":"Esta é a quarta parte da série de posts sobre como organizar o seu projeto de jogo, e terá como foco o gerenciamento do projeto e divisão de tarefas. Vejam também a parte 1, parte 2 e parte 3.\nGerenciamento do projeto e divisão de tarefas\nTodo projeto precisa ser gerenciado, não por um gerente de projetos, mas os membros da equipe precisam desse tipo de organização para dar uma direção ao projeto, e fazê-lo chegar ao seu objetivo. Mesmo em projetos onde a equipe é uma única pessoa precisa ter todas as tarefas definidas e organizadas.\nAs vezes, no início de um projeto, pode parecer que o trabalho necessário para programar o jogo não é muito, mas quando todo o trabalho é divido em tarefas, e essas tarefas são divididas novamente por terem ficado grandes demais, ai sim conseguimos ver o tamanho real do projeto. Mesmo um jogo da velha pode ter funcionalidades complicadas, que as vezes ficam ocultas no meio das fáceis, mas aparecem no final do projeto para atrasá-lo.\nO Scrum é uma metodologia ágil que funciona muito bem em jogos, se você não conhece esta metodologia recomendo ler sobre o assunto. Esta metodologia pode te ajudar a dividir o projeto em backlogs e tarefas, e então podemos utilizar um organizador de tarefas como o Springpad, que também possui funções de colaboração entre membros. Eu uso bastante o Springpad para adicionar organizar idéias de jogos, aplicativos e posts para o blog, é bem legal e possui versão para navegador e mobile.\nExiste também um web app para reuniões bem legal, chamado YAM (Yet Another Meeting). Com ele é possível organizar reuniões, juntar todo mundo em um chat e fazer anotações enquanto a reunião está rolando. Isso parece algo bem simples de fazer com papel e caneta, mas o YAM possui diversos recursos colaborativos para ajudar na hora de compartilhar infomações.\nNa hora de conversar sobre o andamento do projeto, podemos utilizar as sugestões dadas em comunicação da equipe, porém é muito interessante que sejam feitas reuniões presenciais ou por Skype, pelo menos uma vez por semana. Este tipo de relacionamento com a equipe torna o projeto mais “humano”, além de descontrair um pouco.\n","date":"6 de junho de 2012","externalUrl":null,"permalink":"/organizacao-projeto-jogo-parte-4/","section":"Blog","summary":"Esta é a quarta parte da série de posts sobre como organizar o seu projeto de jogo, e terá como foco o gerenciamento do projeto e divisão de tarefas. Vejam também a parte 1, parte 2 e parte 3.\n","title":"Organização de um projeto de jogo (parte 4)","type":"posts"},{"content":"Nesta terceira parte, o foco será a comunicação entre os membros da equipe, e como fazer com que todas as pessoas envolvidas no projeto tenham acesso a informações sobre o projeto e discussões. Confiram também a parte 1 e a parte 2 desta série de posts.\nComunicação entre os membros do grupo\nComunicação sempre foi e sempre será um grande problema em equipes. Cada vez temos mais opções de tecnologias e serviços para facilitar a comunicação, e cada vez mais encontramos maneiras de não utilizá-los. Há um tempo atrás eu recomendaria a criação de uma Wiki para compartilhar informações do projeto, e o Google Groups para comunicação entre os membros do projeto. Porém, hoje acredito que o grupo criado no Facebook funciona muito melhor do que isso.\nÉ possível criar grupos privados e invisíveis aos demais usuários, sendo que novos usuários poderão acessar o grupo somente através de convites. O grupo no Facebook tem as mesmas funcionalidades que um perfil, porém as atualizacões são publicadas apenas para seus membros. Com o grupo é possível também agendar reuniões (eventos), adicionar fotos, e publicar arquivos.\nIsso não resolve problemas de comunicação, que sempre existirão, mas ajuda bastante, pois o grupo funciona como um lugar reservado aos membros do projeto, que podem postar qualquer coisa e comentar em atualizações. O melhor de tudo é que qualquer atualização no grupo é avisada no Facebook de todos os membros, e como todo mundo sempre acessa o Facebook para ver o que os amigos estão fazendo, será inevitável não ver!\nMuita gente gosta de fazer grupos de e-mails, como o Google Groups, ou até criar um e-mail único para o projeto. Nesse caso acho interessante o uso do grupo do Facebook, pois toda informação fica disponível para os membros do grupo, sem a necessidade de procurar e-mails para encaminhar para algum membro novo. Utilizar grupos também ajuda na hora de criar post mortens do projeto, pois todas as dificuldades encontradas e suas soluções estaram lá registradas.\n","date":"5 de junho de 2012","externalUrl":null,"permalink":"/organizacao-projeto-jogo-parte-3/","section":"Blog","summary":"Nesta terceira parte, o foco será a comunicação entre os membros da equipe, e como fazer com que todas as pessoas envolvidas no projeto tenham acesso a informações sobre o projeto e discussões. Confiram também a parte 1 e a parte 2 desta série de posts.\n","title":"Organização de um projeto de jogo (parte 3)","type":"posts"},{"content":"Na parte 1 falei sobre a importancia do armazenamento de arquivos em locais que todos os membros da equipe possam acessá-los, e indiquei o serviço gratuito do DropBox. Nesta segunda parte falerei sobre serviços online gratuitos para armazenamento de código-fonte e controle de versão.\nArmazenamento e controle de versão para código-fonte\nO código-fonte requer um cuidado especial. Simplesmente jogá-lo dentro do DropBox fará todo mundo ter sempre o código atualizado, o que não é bom, pois se você fizer alguma besteira pode estragar o código de todos que estão trabalhando, pois a atualização é automática depois que você salva qualquer arquivo.\nPara cuidar bem do seu código-fonte, existem recursos online para que todos os programadores baixem o código para trabalhar no seu computador, e depois atualizem no servidor apenas os arquivos que eles desejam, inclusive comentando o por que das alterações no código. Essa prática coloca uma versão em cada arquivo, e você pode comparar versões para identificar mudanças.\nEu utilizo bastante o BitBucket, um serviço gratuito que permite a criação de infinitos repositórios GIT ou Mercurial, privados, sem limite de espaço, limitado a 5 usuários por conta. Caso você queira que mais usuários acessem um repositório privado, existem planos pagos que permitem isso.\nSe você não quer se preocupar com o número de usuários que podem trabalhar no seu projeto, e não liga de criar repositórios públicos, o GitHub é uma excelente opção! Eu utilizo ele para guardar alguns projetos de jogos que fiz para portfólio, e ao mesmo tempo compartilhar publicamente com qualquer pessoal que queira ver o código-fonte. Existem também planos pagos, que permitem a criação de repositórios privados, visíveis apenas aos usuários que você quiser.\nPara mais informações sobre como funciona o GitHub, e quais jogos eu compartilhei lá, leiam este post!\n","date":"4 de junho de 2012","externalUrl":null,"permalink":"/organizacao-projeto-jogo-parte-2/","section":"Blog","summary":"Na parte 1 falei sobre a importancia do armazenamento de arquivos em locais que todos os membros da equipe possam acessá-los, e indiquei o serviço gratuito do DropBox. Nesta segunda parte falerei sobre serviços online gratuitos para armazenamento de código-fonte e controle de versão.\n","title":"Organização de um projeto de jogo (parte 2)","type":"posts"},{"content":"Durante um projeto de jogo muitas informações são criadas, e podem ser pedidas se não forem organizadas. Por ser multidisciplinar, um projeto de jogo terá arquivos de arte, música, documentos de design, diagramas, código-fonte, e é muito importante que tudo isso seja bem guardado, pois são os recursos utilizados para fazer seu jogo.\nProjetos de jogos antigos podem ser utilizados como referência, e podem até ter parte do seu código reaproveitado para um jogo novo. Músicas e artes podem ser utilizadas no desenvolvimento, enquanto os novos recursos não estiverem prontos. É possível até reaproveitar o projeto inteiro, apenas mudando a arte e o tema do jogo, mas mantendo toda a base de código e jogabilidade, o que também é conhecido como reskin.\nEsta é a primeira parte de uma série que irei publicar esta semana sobre organização de um projeto de jogo, principalmente jogos indie. As dicas abaixo me ajudaram a organizar diversos projetos pessoais, como trabalhos da pós-graduação e jogos que inscrevi para concursos. Se você tem alguma sugestão para ser adicionada aqui é só deixar um comentário!\nDocumentos compartilhados na nuvem # Com a moda de colocar tudo na nuvem da internet, surgiram algumas soluções bem legais que basicamente substituem o uso de um pendrive. O serviço que eu mais utilizo é o DropBox, que te dá 2GB de armazenamento e mais 500MB por cada amigo que você convidar para se cadastrar (máximo de 18GB na conta gratuita).\nO DropBox possui versão desktop (Windows e Mac), mobile (Android e iOS) e pode ser acessado através de um navegador de internet. As versões desktop e mobile possuem sincronização automática, ou seja, você pode escrever um documento no seu PC, ler no seu celular a caminho do trabalho, e acessar novamente no seu computador do trabalho. É realmente útil, e mais seguro do que carregar coisas em pendrive. Você também não terá problemas com documentos desatualizados, você sempre acessará a versão mais recente de tudo.\nA maior vantagem do uso do DropBox em um projeto é a possibilidade de compartilhar pastas com seus amigos, e todos podem trabalhar ao mesmo tempo. Para evitar problemas, o DropBox possui um controle de alterações dos arquivos, e você pode recuperar uma versão mais antiga de um documento, caso seja necessário.\nEu recomendo utilizar o DropBox para arquivos como documentos, apresentações, planilhas, músicas, artes, e versões estáveis do código-fonte. Porém, não eu não recomendo utilizar o DropBox para armazenar o código-fonte durante o desenvolvimento, para isso existem outros recursos mais legais no próximo tópico.\nAlém do DropBox, eu já utilizei também o Google Drive, que está em Beta fechado, por isso acho melhor o DropBox. Se você precisar de mais de 18GB (lembre-se que esse é o espaço máximo gratuito por usuário), você ainda pode contratar planos maiores através do site deles.\n","date":"3 de junho de 2012","externalUrl":null,"permalink":"/organizacao-projeto-jogo-parte-1/","section":"Blog","summary":"Durante um projeto de jogo muitas informações são criadas, e podem ser pedidas se não forem organizadas. Por ser multidisciplinar, um projeto de jogo terá arquivos de arte, música, documentos de design, diagramas, código-fonte, e é muito importante que tudo isso seja bem guardado, pois são os recursos utilizados para fazer seu jogo.\n","title":"Organização de um projeto de jogo (parte 1)","type":"posts"},{"content":"Nate Rode fez um tutorial interativo em flash bem legal em seu site para explicar conceitos básicos de programação da física de jogos 2D . No tutorial são apresentados conceitos de gravidade, velocidade, aceleração, entre outros, todos com exemplo pra você ver em tempo real e o código-fonte para você entender a lógica.\nSão conceitos bem básicos, mas que da pra fazer muita coisa legal! Um jogo como Angry Birds tem muito desses conceitos simples implementados, junto com alguns cálculos mais sofisticados. Se você quer fazer um jogo em 2D e está com dúvida em algumas implementações de física básica, este tutorial vai te ajudar muito. Clique aqui para ver o tutorial (em inglês).\nPor falar em Angry Birds e física, eu vi essa imagem sendo compartilhada no Facebook e decidi colocar aqui. Infelizmente não sei quem criou para dar os créditos, mas ficou bem legal. Se alguém souber da onde é me fala nos comentários que eu atualizo aqui.\n","date":"25 de maio de 2012","externalUrl":null,"permalink":"/tutorial-de-fisica-2d-para-jogos/","section":"Blog","summary":"Nate Rode fez um tutorial interativo em flash bem legal em seu site para explicar conceitos básicos de programação da física de jogos 2D . No tutorial são apresentados conceitos de gravidade, velocidade, aceleração, entre outros, todos com exemplo pra você ver em tempo real e o código-fonte para você entender a lógica.\n","title":"Tutorial de física 2D para jogos","type":"posts"},{"content":"O Nuuvem é um serviço de venda de jogos em formato digital pela internet criado em cima do modelo de comércio de jogos digitais consolidado pelo Steam, da Valve. O Steam sempre foi a melhor saída para comprar jogos pelo mesmo preço que é lançado lá fora, além da possibilidade de jogar no mesmo dia de lançamento, pois basta comprar e baixar para jogar sempre que quiser.\nAgora temos o Nuuvem, uma alternativa brasileira para compra jogos digitais, com suporte em português e diversas formas de pagamento. O melhor de tudo é que o Nuuvem têm promoções muito boas, como a pré-venda de Max Payne 3 por R$79, sendo que no Steam o jogo está $45 (cerca de R$90 hoje).\nEsta notícia não é muito relacionada diretamente ao desenvolvimento de jogos, mas é sempre bom vermos avanços no mercado de jogos no Brasil, principalmente na distribuição digital. Quem sabe o Nuuvem não se torna um serviço amigo do desenvolvedor brasileiro também, dando oportunidade para pequenas empresas e equipes indepentendes? Isso só o tempo dirá, por enquanto estão disponíveis apenas jogos indies que fizeram sucesso no mundo inteiro.\nNa minha opinião, devemos sempre apoiar essas iniciativas, e ajudar nosso país a ter mais coisas legais no mercado de jogos. Pequenas atitudes, como comprar um jogo brasileiro de $1 na App Store, fazem diferença sim!\n","date":"16 de maio de 2012","externalUrl":null,"permalink":"/nuuvem-o-steam-brasileiro/","section":"Blog","summary":"O Nuuvem é um serviço de venda de jogos em formato digital pela internet criado em cima do modelo de comércio de jogos digitais consolidado pelo Steam, da Valve. O Steam sempre foi a melhor saída para comprar jogos pelo mesmo preço que é lançado lá fora, além da possibilidade de jogar no mesmo dia de lançamento, pois basta comprar e baixar para jogar sempre que quiser.\n","title":"Nuuvem, o Steam brasileiro","type":"posts"},{"content":"World of Level Design é um site que reúne diversos tutoriais sobre desenvolvimento de níveis, para estudantes e artistas. No site estão disponíveis tutoriais para criar níveis para jogos como Left 4 Dead 1 e Left 4 Dead 2, níveis em game engines como CryEngine 3 SDK e Unreal Development Kit (UDK), modelagem 3D utilizando Maya, e muitos tutoriais sobre como começar a criar níveis, técnicas e até desafios.\nEste é um site bem legal para que tem interesse em aprender Level Design (criação de níveis), que é algo diferente de Game Design (criação de mecânicas de jogo). Muitas vezes um Game Designer faz o papel de um Level Designer, e vice-versa, porém são carreiras distintas.\nAh, se você se inscrever no newsletter do site ainda ganha 2 ebooks sobre Level Design de graça! Os ebooks, Ultimate Level Design Guide e 11 Day Level Design: How I Created a Map in 11 Days, foram escritos pelo autor do site, Alex Galuzin. Eu me inscrevi e baixei os livros para dar uma olhada, são mais de 200 páginas bem legais. É um material de qualidade e disponibilizado gratuitamente pelo autor.\nAlex também possui um outro site, sobre arte 3D para ambientes, que é mais utilizado em projetos de arquitetura e decoração de interiores. Se você quer aprender sobre Level Design, veja os tutoriais no site! Tem muita informação legal lá que você não encontra em cursos ou livros.\n","date":"14 de maio de 2012","externalUrl":null,"permalink":"/world-of-level-design/","section":"Blog","summary":"World of Level Design é um site que reúne diversos tutoriais sobre desenvolvimento de níveis, para estudantes e artistas. No site estão disponíveis tutoriais para criar níveis para jogos como Left 4 Dead 1 e Left 4 Dead 2, níveis em game engines como CryEngine 3 SDK e Unreal Development Kit (UDK), modelagem 3D utilizando Maya, e muitos tutoriais sobre como começar a criar níveis, técnicas e até desafios.\n","title":" Level Design com quem entende do assunto","type":"posts"},{"content":"Muitos se perguntam como é trabalhar em uma empresa de jogos, e é algo realmente legal. No Brasil, os estúdios são pequenos, com poucas personalizações, mas lá fora existem empresas com estúdios realmente grandes. Tão grandes que possuem complexos com prédios, quadras esportivas, academia, biblioteca de jogos, sala de jogos, restaurantes, cafeterias, entre várias outras coisas para fazer seus funcionários felizes e deixar todo mundo com vontade de trabalhar em um ambiente assim.\nAbaixo estão alguns vídeos que pesquisei para mostrar como são algumas das maiores empresas de jogos do mundo, espero que gostem!\nElectronic Arts Canada – EA Sports (FIFA)\nDICE (Battlefield, Mirror’s Edge)\nBlizzard Entertainment (World of Warcraft, Starcraft, Diablo)\nUbisoft Montreal (Assassin’s Creed, Rainbow Six)\nCodemasters (Grid, Dirt, F1)\nNaughty Dog (Uncharted)\nEpic Games (Unreal, Gears of War)\nBethesda (Fallout, Skyrim)\n","date":"1 de maio de 2012","externalUrl":null,"permalink":"/estudios-de-jogos-do-mundo/","section":"Blog","summary":"Muitos se perguntam como é trabalhar em uma empresa de jogos, e é algo realmente legal. No Brasil, os estúdios são pequenos, com poucas personalizações, mas lá fora existem empresas com estúdios realmente grandes. Tão grandes que possuem complexos com prédios, quadras esportivas, academia, biblioteca de jogos, sala de jogos, restaurantes, cafeterias, entre várias outras coisas para fazer seus funcionários felizes e deixar todo mundo com vontade de trabalhar em um ambiente assim.\n","title":"Como são alguns dos maiores estúdios de jogos do mundo","type":"posts"},{"content":"A Turma do Chico Bento trás os personagens de Mauricio de Sousa em um jogo para as redes sociais Facebook e Orkut. Em desenvolvimento pela Insólita, e publicado pela Level Up! Games, este jogo está sendo produzido por brasileiros e para um público brasileiro.\nO Game Design do jogo está sendo desenvolvido pelo produtor Winston Petty, e pela Game Designer Mariana Boucault, que fez uma entrevista para o blog contanto como se tornou uma Game Designer.\nTurma do Chico Bento tem características presentes em jogos como FarmVille e CityVille, ambos da Zynga. O jogo está em desenvolvimento desde o final de 2011 e atualmente está em teste fechado. Logo deverá ser lançado, e estamos torcendo para este jogo brasileiro fazer sucesso nas redes sociais.\n[Chico Bento ganha jogo para redes sociais desenvolvido no Brasil, via G1]\n","date":"30 de abril de 2012","externalUrl":null,"permalink":"/turma-do-chico-bento/","section":"Blog","summary":"A Turma do Chico Bento trás os personagens de Mauricio de Sousa em um jogo para as redes sociais Facebook e Orkut. Em desenvolvimento pela Insólita, e publicado pela Level Up! Games, este jogo está sendo produzido por brasileiros e para um público brasileiro.\n","title":"Turma do Chico Bento - um jogo social desenvolvido no Brasil!","type":"posts"},{"content":"Sexta-feira passada o Kotaku divulgou um documento, publicado por um usuário no Flamehaus. Segundo o usuário que o publicou, um funcionário da Valve teria enviado este handbook para um candidato conhecer a maneira de trabalhar na Valve.\nO Kotaku informou que iria verificar a autenticidade do documento com a Valve, mas pela qualidade das informações e ilustrações eu não duvido que este seja realmente um documento real. A Valve tem fama de ser um dos melhores lugares para se trabalhar na área de games, então faz sentido o conteúdo desse handbook para novos funcionários.\nSe você quiser saber como é trabalhar na Valve, clique aqui para ler o PDF do handbook.\n","date":"21 de abril de 2012","externalUrl":null,"permalink":"/handbook-da-valve/","section":"Blog","summary":"Sexta-feira passada o Kotaku divulgou um documento, publicado por um usuário no Flamehaus. Segundo o usuário que o publicou, um funcionário da Valve teria enviado este handbook para um candidato conhecer a maneira de trabalhar na Valve.\n","title":"Handbook da Valve para seus novos funcionários","type":"posts"},{"content":"Você consegue imaginar como era programar um jogo em 1989? Naquela época o Apple II era um muito popular entre os desenvolvedores de jogos, e muitos deles programavam sozinhos seus projetos. E foi assim que Jordan Mechner desenvolveu o primeiro Prince of Persia.\nAntes de comentar sobre como o código foi recuperado, eu quero contar sobre o processo de desenvolvimento do Prince of Persia. Jordan se graduou em Yale e começou a desenvolver jogos em algumas empresas. Quando teve a idéia para Prince of Persia, ele também pensou em uma maneira muito criativa de recriar os movimentos do personagem: ele gravou seu irmão pulando e subindo em paredes, e colocou esses movimentos no jogo, isso em 1985!\nNo vídeo acima o que o irmão de Jordan fez para ajudá-lo a criar o sucesso que seria lançado em 1989 para Apple II. Jordan também lançou um ebook Making of Prince of Persia, onde ele conta muitos outros detalhes sobre o desenvolvimento do primeiro capítulo de uma das franquias mais famosos dos video games.\nAgora, voltando ao código. Por muitos anos Jordan pensou ter perdido o código de seu grande sucesso, até um dia em que seu pai enviou-lhe uma caixa com algumas coisas antigas, como jogos, disquetes e o código original do Prince of Persia! Nesse momento Jordan publicou um post em seu blog contanto isso, e começou a planejar como iria recuperar o código.\nA revista Wired acompanhou o dia em que especialistas em recuperar dados de disquetes antigos e programadores de Apple II ajudaram Jordan a recuperar o código do jogo, vale muito a pena ler a matéria toda, pois mais coisas foram recuperadas além do Prince of Persia.\nO mais legal de tudo isso é que Jordan liberou o código do jogo no GitHub , inclusive com documentos técnicos para ajudar quem quiser tentar compilar o código. Eu baixei um emulador de Apple II para Windows, mas não faço idéia ainda de como compilar esse código.\nEu acho incrível ver o código de um jogo de tanto sucesso, escrito em uma época com computadores limitados e programadores criativos. Esse código representa um sonho que tornou-se realidade, divertiu muita gente, inspirou pessoas, e agora mostra para todos como era bem complicado fazer um jogo simples, bom e viciante.\n","date":"20 de abril de 2012","externalUrl":null,"permalink":"/codigo-do-prince-of-persia/","section":"Blog","summary":"Você consegue imaginar como era programar um jogo em 1989? Naquela época o Apple II era um muito popular entre os desenvolvedores de jogos, e muitos deles programavam sozinhos seus projetos. E foi assim que Jordan Mechner desenvolveu o primeiro Prince of Persia.\n","title":"Código do Prince of Persia de 1989 encontrado e compartilhado!","type":"posts"},{"content":"Demorou, mas chegou! Agora temos a categoria de jogos na App Store brasileira, a loja de aplicativos da Apple para seus aparelhos com iOS. Isso é uma ótima notícia para os jogadores, que agora poderão comprar seus jogos com uma conta e cartão de crédito brasileiro, mas também é uma ótima notícia para nós desenvolvedores de jogos!\nAgora os desenvolvedores de jogos brasileiros, assim como os estrangeiros, podem colocar seus jogos a venda no Brasil, que é tem um mercado de dispositivos móveis que cresce cada vez mais. Eu tenho certeza de que quem compra um aparelho com iOS vai preferir pagar menos de R$2 em um jogo (mesmo preço que o mundo inteiro paga), do que pagar para desbloquear o seu aparelho.\nComo acontece em outros países, o preço do jogo não é diferenciado, é sempre o mesmo em dólar. Esse valor é convertido para a moeda local do país na fatura do cartão de crédito.\nCom a categoria de jogos no Brasil, jogos de entretenimento e advert games podem atingir o público brasileiro, que já provou ser muito viciado em jogos sociais. Android sempre foi uma alternativa, mas mesmo o número de aparelhos com o sistema operacional do Google ser bem expressivo, a App Store é consolidada como uma melhor opção do que o Google Play. Isso pode mudar um dia, mas por enquanto é bom aproveitar.\nEsse lançamento no Brasil foi meio em silêncio, sem grandes alardes por parte da Apple, mas podemos considerar um dos principais acontecimentos desse ano para a indústria de jogos no Brasil. Estou muito empolgado com isso, acredito que agora teremos mais conteúdo feitos pro brasileiros, e para brasileiros.\n","date":"5 de abril de 2012","externalUrl":null,"permalink":"/jogos-na-app-store-brasileira/","section":"Blog","summary":"Demorou, mas chegou! Agora temos a categoria de jogos na App Store brasileira, a loja de aplicativos da Apple para seus aparelhos com iOS. Isso é uma ótima notícia para os jogadores, que agora poderão comprar seus jogos com uma conta e cartão de crédito brasileiro, mas também é uma ótima notícia para nós desenvolvedores de jogos!\n","title":"Apple adicionou a categoria de jogos na App Store brasileira","type":"posts"},{"content":"Nem parece, mas este blog já está há 3 anos no ar. Em abril de 2009, eu era um recém formado Bacharel em Ciência da Computação, trabalhava como Analista de Sistemas, estava no primeiro semestre da minha pós-graduação em Produção e Programação de Jogos, e estava começando minha a estudar desenvolvimento de jogos.\nNesses 3 anos, publiquei 62 posts, em 20 categorias, com 169 tags e 303 comentários. Atualmente, o blog está com uma média de acessos de 150 visitantes por dia, o que é um número muito expressivo para um blog pessoal sobre desenvolvimento de jogos no Brasil. Mês passado o blog teve 4.330 acessos, sendo 3.206 únicos e 7.942 visualizações de página. Cada vez mais a indústria de jogos no Brasil está crescendo e ganhando destaque, mas ainda falta muito para chegarmos perto de polos de desenvolvimento de jogos em grandes cidades do mundo, como São Francisco e Montreal.\nHoje, depois de um ano que terminei minha pós-graduação, estou a quase 2 anos na indústria de jogos. Trabalhei 8 meses na Glu Mobile, com porting de jogos J2ME e Android (Java). Atualmente estou na Electronic Arts, em São Paulo, há 1 ano e 1 mês, como Engenheiro de Software, trabalhando em jogos para Android (Native). Já apresentei uma palestra sobre desenvolvimento de jogos para dispositivos móveis na Universidade Federal do Rio de Janeiro, e tenho um cartão de visita bem legal:\nEm 3 anos estudei muito sobre desenvolvimento de jogos, participei de concursos, desenvolvi projetos pessoais, concluí minha pós-graduação, e consegui entrar em uma empresa muito grande na área de jogos. Não foi fácil chegar aqui, mas com esforço e dedicação consegui iniciar minha carreira em programação de jogos.\nAgora começa uma nova etapa, onde irei melhorar minhas habilidades em programação de jogos, principalmente em C/C++ e OpenGL, desenvolver mais projetos pessoais, estudar novas tecnologias como HTML5, e tentar terminar mais jogos da minha quase infinita pilha de jogos! =)\nUma boa parte da minha conquista eu devo a este blog. Este blog me ajudou a encarar desafios, divulgar meus projetos, e entrar em duas empresas. E não poderia deixar de agradecer a você leitor que acompanha meus posts! Meu maior incentivo de continuar escrevendo aqui é ajudar a todos que tem interesse nessa área, divulgando informações e contando sobre minhas experiências. Muito obrigado por acompanhar o blog, espero que continuem gostando do conteúdo, e prometo que tentarei aumentar a frequencia de posts.\nNos próximos meses haverão mudanças no blog, como um novo layout, uma área para sugestões de posts e talvez um fórum, entre outras novidades. Portanto, continuem acompanhando e obrigado mais uma vez por me incentivar a escrever sobre desenvolvimento de jogos! Para finalizar este post, listei abaixo os 5 posts que mais marcaram a minha carreira neste blog:\nfinalista no e-games 2009 com um dos 5 melhores jogos! fim do TCC da pós-graduação: Oniro finalista no e-Games 2010! 1 ano na indústria de games palestra sobre desenvolvimento de jogos na UFRJ – GECOM 2011 E vocês, tem algum post preferido? Algum tema que gostariam de ler por aqui?\n","date":"2 de abril de 2012","externalUrl":null,"permalink":"/retrospectiva-dos-3-anos-do-blog/","section":"Blog","summary":"Nem parece, mas este blog já está há 3 anos no ar. Em abril de 2009, eu era um recém formado Bacharel em Ciência da Computação, trabalhava como Analista de Sistemas, estava no primeiro semestre da minha pós-graduação em Produção e Programação de Jogos, e estava começando minha a estudar desenvolvimento de jogos.\n","title":"Uma retrospectiva dos 3 anos do blog e da minha carreira","type":"posts"},{"content":"A Slightly Mad Studios, desenvolvedora do Need For Speed Shift e Shit 2: Unleashed (ambos publicados pela Electronic Arts), iniciou um projeto ousado para criar o melhor jogo de corrida para PC. Por que apenas para PC? Bom, segundo eles é muito difícil competir com a série Gran Turismo no Playstation e a série Forza Motorsport no Xbox.\nEles decidiram fazer o melhor jogo de corrida para PC, onde não existe uma franquia dominante. Claro que existem diversos jogos bons de corrida, mas o pessoal da Slightly Mad quer fazer o melhor jogo de todos os tempos. E estão indo muito bem.\nO vídeo acima mostra a qualidade do trabalho desenvolvido até agora. Algumas coisas básicas estão faltando, como as mãos do piloto no volante, mas reparem nos detalhes dos carros. O movimento dos espelhos, as mangueiras ligadas no volante, a suspensão oscilando de acordo com a pista, efeitos de luz, detalhes do painel do carro, e a sensação de velocidade. Eu estou muito empolgado com esse jogo, promete ser realmente um dos melhores jogos de corrida para PC, se não se tornar o melhor.\nApesar da qualidade gráfica estar boa, parte graças ao DirectX 11, este jogo está apenas em Alpha. Quer saber mais um detalhe interessante sobre esse projeto? Ele esta sendo financiado parte pelos fãs, através do sistema de crowd funding. O jogador pode doar o a quantia que desejar, dentro das quantias estabelecidas, e cada quantia lhe dá recompensas, que vão desde acesso ao alpha e beta do jogo e seu nome como um competidor no jogo, até ser um produtor que pode participar de reuniões e dar sua opinião sobre o projeto. Para saber mais detalhes sobre esse projeto, e como você pode contribuir, acesse o site do WMD Portal.\n","date":"1 de abril de 2012","externalUrl":null,"permalink":"/project-cars/","section":"Blog","summary":"A Slightly Mad Studios, desenvolvedora do Need For Speed Shift e Shit 2: Unleashed (ambos publicados pela Electronic Arts), iniciou um projeto ousado para criar o melhor jogo de corrida para PC. Por que apenas para PC? Bom, segundo eles é muito difícil competir com a série Gran Turismo no Playstation e a série Forza Motorsport no Xbox.\n","title":"Project C.A.R.S. - o projeto ambicioso da Slightly Mad Studios","type":"posts"},{"content":"O HTML5 é uma tecnologia recente, que veio com o objetivo de padronizar muita coisa do desenvolvimento web e talvez eliminar o Flash e seu plugin. Aos poucos, novos exemplos do poder do HTML5 estão surgindo, e essa semana foi publico um jogo online multiplayer incrível chamado BrowserQuest.\nDesenvolvido por 2 pessoas, um artista e um programador, e publicado pela Mozilla, este jogo prova que é possível fazer jogos online de qualidade com HTML5 e WebSockets. Além da demonstração da tecnologia, BrowserQuest é um jogo muito bonito e divertido, e roda em qualquer navegador (desktop e mobile).\nA Mozilla também publicou um texto explicando a tecnologia utilizada no jogo, e seu código-fonte foi publicado no GitHub. Apesar de ainda existirem problemas no HTML5, como a segurança, mas isso não vai impedir o avanço desta tecnologia nos próximos meses.\n","date":"28 de março de 2012","externalUrl":null,"permalink":"/browserquest/","section":"Blog","summary":"O HTML5 é uma tecnologia recente, que veio com o objetivo de padronizar muita coisa do desenvolvimento web e talvez eliminar o Flash e seu plugin. Aos poucos, novos exemplos do poder do HTML5 estão surgindo, e essa semana foi publico um jogo online multiplayer incrível chamado BrowserQuest.\n","title":"BrowserQuest, o incrível MMO em HTML5 publicado pela Mozilla","type":"posts"},{"content":"O GitHub é um website de “social coding” – uma rede social de projetos open source, com perfis de programadores e empresas que compartilham seus códigos. Empresas grandes como Facebook, Twitter, Microsoft e Mozilla tem seus repositórios de código público no GitHub, e qualquer pessoal pode baixar ou clonar o repositório para ver o código. Projetos famosos, como o framework Cocos2D também estão no GitHub.\nAlém das grandes empresas, o GitHub é um local para se encontrar diversos projetos pessoais de programadores que decidiram tornar público seu código, compartilhando seus aplicativos, bibliotecas e jogos. O GitHub também permite que equipes utilizem sua estrutura como repositório para seus projetos, porém os repositórios são sempre públicos. Qualquer pessoa pode ver seu projeto, mas apenas sua equipe poderá editá-lo.\nÉ possível também criar repositórios privados, mas para isso tem que pagar uma mensalidade. Não é muito caro, e vale a pena para pequenas empresas/equipes. É possível aprender muito fuçando nos projetos disponíveis no GitHub, pois muitos são desenvolvidos pelos melhores programadores de suas empresas.\nExiste vários repositórios gratuitos por ai, como o Bitbucket (que eu uso), mas o GitHub sem dúvidas é o mais utilizado por trabalhar com git. Outro fato interessante é que algumas empresas gostam de ver os projetos em que seus candidatos participam e compartilham no GitHub, para ter uma noção de como é o código da pessoa e o tipo de projeto que já fez.\nAlgumas pessoas, como eu, não ficam muito confortáveis em compartilhar o código de seu projeto. Bom, eu quero mudar isso, e vou começar a compartilhar meus projetos de jogos no meu perfil. Pra começar, compartilhei esses três projetos, que na verdade são o mesmo jogo mas em 3 plataformas/tecnologias diferentes:\nSpaceShip 4042 em J2ME (projeto da pós-graduação em 2009) SpaceShip 4042 em XNA (finalista do e-Games 2009) SpaceShip 4042 em HTML5 (projeto que iniciei em 2010, ainda não finalizado) ","date":"27 de março de 2012","externalUrl":null,"permalink":"/codigo-fonte-de-jogos-no-github/","section":"Blog","summary":"O GitHub é um website de “social coding” – uma rede social de projetos open source, com perfis de programadores e empresas que compartilham seus códigos. Empresas grandes como Facebook, Twitter, Microsoft e Mozilla tem seus repositórios de código público no GitHub, e qualquer pessoal pode baixar ou clonar o repositório para ver o código. Projetos famosos, como o framework Cocos2D também estão no GitHub.\n","title":"Código-fonte de jogos no github","type":"posts"},{"content":"André Kishimoto, professor do curso de Jogos Digitais na Unicsul e engenheiro de software na Electronic Arts, escreveu o livro Programação Windows: C e Win32 API com ênfase em multimídia, que agora está sendo disponibilizado gratuitamente para download.\nAlém do ebook, foi disponibilizado também o código fonte de todos os exercícios do livro.\nÉ um livro bem legal para quem quer estudar programação com C em aplicações multimídia como jogos.\nO livro e o código fonte estão disponíveis no github. Conheça também seus dois blogs, tupinihon e pronz.\n","date":"15 de março de 2012","externalUrl":null,"permalink":"/livro-gratuito-sobre-programacao-em-c/","section":"Blog","summary":"André Kishimoto, professor do curso de Jogos Digitais na Unicsul e engenheiro de software na Electronic Arts, escreveu o livro Programação Windows: C e Win32 API com ênfase em multimídia, que agora está sendo disponibilizado gratuitamente para download.\n","title":"Livro gratuito sobre programação em C com ênfase em multimídia","type":"posts"},{"content":"A Mariana Boucault trabalhou comigo na Glu Mobile, era foi QA em alguns projetos de porting de jogos em J2ME que participei. Ela também foi QA em jogos de iOS desenvolvedos no estúdio da Glu Mobile em São Paulo, como o Circus City (vídeo na entrevista abaixo).\nAlém de achar bugs nos jogos e me fazer corrigir, a Mari estudava na Anhembi Morumbi para se tornar uma Game Designer. Enquanto estava na faculdade, ela participou do desenvolvimento de alguns projetos de jogos, os vídeos de dois desses jogos estão na entrevista abaixo. Após se formar, Mari entrou na Insolita Studios como Game Designer, e hoje trabalha para criar mecânicas bem legais para os jogos do estúdio.\nPor ser uma Game Designer, a entrevista teve algumas perguntas parecidas com a entrevista do Nicholas, mas suas respostas e experiências são únicas, por isso vale a pena conferir um pouco da trajetória de uma das poucas Game Designers do Brasil. Ah, não deixe também de conferir seu portfólio!\nPor que você decidiu ser uma Game Designer?\nEssa escolha na verdade foi muito sem querer, eu nem sabia que existia essa profissão alguns anos atrás. Eu sempre joguei vídeo games, desde que me tomo por gente, e já tinha decidido que ia trabalhar na área de qualquer jeito. Na hora de prestar vestibular tinha me aplicado em vários tipos de engenharia, porque na inocência, achava que das opções era a melhor que tinha. Até achar um panfleto da Anhembi com o curso de Design de Games. Na hora que eu vi, já tinha decidido que ia fazer, mesmo tendo passado nas engenharias. Devo ter deixado algumas pessoas decepcionadas com isso, mas agora não consigo me ver fazendo mais nada diferente.\nAno passado você se formou em Design de Games na Anhembi Morumbi. Você achou que esse curso te preparou para ser uma Game Designer?\nEstudar na Anhembi com certeza mudou meu jeito de ver game design, mas como toda teoria, a prática é completamente diferente. Acredito que o que mais fez diferença na Anhembi foram os projetos interdisciplinares, uma série de projetos que nos fizeram experimentar na prática o que é fazer um jogo, mas sempre temos que estudar porque é uma área que muda muito rápido.\nNo curso você participou do desenvolvimento de jogos bem legais, como “The Eerie Crooked Show” e “Gedanken”. Como foi desenvolver o Game Design desses jogos?\nComo a equipe que estávamos trabalhando nesses dois projetos era pequena (4 pessoas), o game design inicial foi feito em conjunto, cada um dos membros trazendo idéias de como a mecânica básica tinha que funcionar, levando em consideração os pontos fracos e fortes da equipe. Depois de decidido, cada um foi para sua área e eu fiquei responsável para resolver os detalhes que ainda não haviam sido solucionados, também ajudando na parte de level design.\nSua carreira na área de jogos começou na Glu Mobile como QA. Trabalhar como QA, testando jogos bem diferentes, te ajudou a aprender sobre Game Design também?\nTrabalhar como QA (Quality Assurance, para quem não sabe) fez com que eu tivesse a chance de testar outros jogos que eu normalmente não jogaria, no ponto de vista gamer, e isso me ensinou como é importante não ter preconceitos contra outros gêneros de jogos. Você pode aprender muito com eles e usar esse conhecimento para construir jogos mais ricos no futuro.\nMuita gente acha que testar jogos é um trabalho fácil, mas sabemos que não é bem assim. Quais são as maiores dificuldades em testar um jogo?\nÉ, testar jogos não é “ficar jogando joguinho” o dia todo. Eu diria que a parte mais difícil de testar um jogo é manter o foco depois da 300ª vez que está testando a mesma fase para mesmo assim encontrar um bug e reportar ele corretamente. É um trabalho que precisa ter muita paciência também, porque muitas vezes a versão do jogo vem quebrada e tudo que você testou já não é mais válido e você tem que recomeçar.\nApós se formar, você saiu da Glu Mobile e entrou na Insolita como Game Designer. Como foi conseguir uma vaga tão disputada por diversos outros alunos do seu curso?\nFoi uma grande sorte na verdade! Conseguir vaga de game designer no Brasil, ao contrário do que a mídia tradicional diz, é extremamente difícil. Se você quer realmente entrar na área é mais fácil seguir na parte de programação ou arte. Eu fiquei MUITO feliz quando tive a resposta (ainda por cima foi no meu aniversário!), foi aquele momento que todo o esforço valeu a pena.\nO trabalho de um Game Designer é exatamente como você imaginava no início do curso ou sua visão mudou agora que está formada e trabalhando na área?\nUm pouco dos dois, estou criando jogos como achei que faria, sem necessariamente mexer em código e arte, mas é muito mais complicado do que eu achei que seria. Envolve muita criação de sistemas, vários fluxogramas, decisões sobre o que colocar ou não no jogo e até equações de segundo grau que podem salvar ou afundar o jogo.\nAgora que está formada, você pretende fazer algum outro curso de especialização?\nPor enquanto não, estou mais focada em ter um pouco mais de experiência no desenvolvimento prático de jogos para quem sabe no futuro fazer uma pós ou mestrado no exterior e aprender novas técnicas.\nComo você vê o mercado de desenvolvimento de jogos no Brasil?\nO desenvolvimento de jogos no Brasil ainda é jovem e muito pequeno em comparação com outros países que já estão instalados. Boa parte das empresas faz advergames, jogos educacionais e mobile. Por enquanto acho que estamos longe de se tornar uma indústria de AAAs, mas por outro lado, existem muitas pessoas talentosas que estão correndo atrás e fazendo seus jogos acontecerem.\nQuais jogos, livros e Game Designers que influenciaram sua carreira?\nQuanto a jogos, é difícil deixar conciso, diria principalmente a série Tomb Raider, a maior parte dos jogos do Mario, Resident Evil, Portal, Silent Hill, Full Throttle, Claw e Chips Challenge. Entre os diversos designers estão Toby Gard, Shigeru Miyamoto, Kim Swift e Tim Schafer. E livros, tem alguns da área, como Theory of Fun e Level UP!, e outros nem tão ligados, mas não menos importantes, como um de psicologia (Flow) e um de orientação a objetos (OOA\u0026amp;D).\nO que você recomenda para iniciantes que querem seguir nessa profissão?\nAlém de estudar bastante e jogar com olhos críticos, fazer um projeto por fora, para ter experiência prática, vai fazer bastante diferença. É bom começar desde cedo também pensar em uma das diversas áreas que o desenvolvimento de jogos tem e focar em uma delas, e dar o máximo de si para aprender sobre ela. Por exemplo, se você quer ser level designer, você pode baixar e treinar seus levels num editor de level de jogo como source e udk, se você quer ser designer, tente quebrar um jogo que você conheça e reproduzi-lo e melhorá-lo, e por aí vai.\nMari, obrigado pela entrevista!\n","date":"12 de março de 2012","externalUrl":null,"permalink":"/entrevista-mariana-boucault/","section":"Blog","summary":"A Mariana Boucault trabalhou comigo na Glu Mobile, era foi QA em alguns projetos de porting de jogos em J2ME que participei. Ela também foi QA em jogos de iOS desenvolvedos no estúdio da Glu Mobile em São Paulo, como o Circus City (vídeo na entrevista abaixo).\n","title":"Entrevista: Mariana Boucault - Game Designer na Insolita Studios","type":"posts"},{"content":"A game engine Unity mudou muita coisa no desenvolvimento de jogos independentes quando, em 2009, lançou uma versão gratuita ilimitada para desenvolvimento de jogos para PC, Mac e Web (com plugin próprio). Até então não existia uma opção gratuita (ilimitada) para estudantes, entusiastas e pequenos desenvolvedores independentes que queria desenvolver jogos com qualidade em 3D, porém utilizando uma game engine profissional.\nAgora a Unity está chamando a atenção dos desenvolvedores novamente, oferecendo gratuitamente as licenças para desenvolvimento para iOS e Android para qualquer pessoa até 8 de abril. Para se ter uma idéia, cada licença custava $400 dólares, e você pode pegar ambas de graça até o dia 8 de Abril.\nTudo que precisa fazer é acessar o site da Unity, clicar em “Store”, selecionar “Unity Free”, e depois em “Add Features” basta selecionar “Android” e “iOS”, ambos estão com um aviso escrito “Free Until 8th April”. Depois disso é só clicar em “Add to Cart”, criar uma conta (se não tiver), e se divertir com a possibilidade de criar jogos incríveis em 3D para iOS e Android. Não é necessário realizar pagamento algum, após criar a conta o site pula a etapa de pagamento e já te envia um e-mail com a sua key única.\nMesmo se você não tem interesse em desenvolver jogos mobile agora, ou não quer estudar uma game engine 3D, recomendo pegar essas licenças, pois uma vez que você criar a conta no site da Unity e “comprar” essas licenças gratuita, você receberá uma key por e-mail para poder usar quando quiser. Lembrando que para testar em iOS você ainda precisa de uma conta de Apple Developer (que custa $99 dólares por ano), e para testar em Android basta conectar o aparelho no computador e passar o jogo para ele.\nSe tiver qualquer dúvida sobre como pegar sua licença gratuita até 8 de abril deixe um comentário aqui que eu tentarei ajudar.\n","date":"11 de março de 2012","externalUrl":null,"permalink":"/game-engine-unity-para-ios-e-android-gratuita/","section":"Blog","summary":"A game engine Unity mudou muita coisa no desenvolvimento de jogos independentes quando, em 2009, lançou uma versão gratuita ilimitada para desenvolvimento de jogos para PC, Mac e Web (com plugin próprio). Até então não existia uma opção gratuita (ilimitada) para estudantes, entusiastas e pequenos desenvolvedores independentes que queria desenvolver jogos com qualidade em 3D, porém utilizando uma game engine profissional.\n","title":"Game Engine Unity para iOS e Android gratuita até 8 de abril","type":"posts"},{"content":"O Rafael Martins, também conhecido como Alemão, tem alguns anos de experiência com desenvolvimento de jogos para dispositivos móveis. Começou a trabalhar como programador em jogos J2ME e BREW na Skyzone.\nEntrou na Electronic Arts, pouco tempo depois do escritório da EA Mobile ser aberto em São Paulo. Na EA viu a transição dos jogos simples para celulares, para jogos muito grandes para smartphones e tablets. Atualmente é Technical Manager, e meu chefe!\nEle é formado em Sistemas de Informação na Mackenzie, onde atualmente está cursando um mestrado em Engenharia da Computação. Além disso, também já foi jogador profissional de basquete, e atualmente joga no time do Clube Circulo Militar de SP, é torcedor do Dallas Mavericks. Nem todo programador é sedentário! hahaha\nNa entrevista abaixo, ele conta um pouco da transição das tecnologias para jogos em dispositivos móveis e comenta muitos aspectos técnicos sobre o desenvolvimento de jogos para mobile.\nComo surgiu o interesse em trabalhar com jogos?\nO interesse em trabalhar com jogos surgiu no começo da adolescencia. Era atleta e estudante e já pensava em estudar ciencia da computação para poder trabalhar com aplicações multimídia e jogos. Acabei me tornando atleta profissional, mas no meio da graduação acabei parando com o basquete, trabalhando um pouco em T.I. e depois consegui uma vaga em uma empresa de jogos coreana, a Skyzone.\nSeu primeiro contato profissional com jogos foi na Skyzone, com J2ME e BREW, certo? Como era trabalhar com jogos naquela época?\nO meu primeiro contato profissional foi na Skyzone sim. Trabalhavamos basicamente com J2ME, Brew e Sidekick. Naquela época o processo de desenvolvimento era bem complicado, se formos comparar com o que rola atualmente. Pouca memória, centenas de dispositivos e muita fragmentação, o que dificultava e atrasava muito a produção ou porting de um título. Contudo, tambem era desafiador poder trabalhar em algo tão limitado.\nDepois da Skyzone, você entrou na Electronic Arts, para trabalhar com dispositivos móveis. Como foi entrar para uma das maiores empresas de jogos do mundo?\nParece meio clichê, mas sempre que jogava alguns jogos da EA nos consoles, pensava em como era trabalhar em uma empresa como essa. Acho que todo mundo que gosta de jogos, deve pensar. A EA é uma empresa que muita gente conhece, mesmo os não fanáticos por jogos, por causa das marcas que a empresa detém. Com certeza foi emocionante começar a trabalhar aqui, ainda mais com um grupo que já vinha se consolidando em tecnologia móvel em São Paulo. Unindo isso ao fato de ser a EA, só tenho que agradecer a oportunidade.\nNa Electronic Arts você viu a transição de J2ME e BREW para Android e iOS, entre outras tecnologias. Você acha que a indústria de games cresceu com essas novas tecnologias?\nSem dúvida a indústria cresceu demais com a chegada de novas plataformas móveis. Fora isso, houve um crescimento altíssimo no número de empresas que fornecem tecnologia para a fabricação desses dispositivos, assim como empresas que desenvolvem jogos nessa camada. Já temos quase 1 celular por habitante no mundo, a indústria só tem a crescer com a quantidade de pessoas que ela pode atingir.\nJogos para dispositivos móveis estão cada vez mais próximos de jogos de console e computador. Você acha que jogos grandes poderiam ser portados para mobile? Quais seria as dificuldades técnicas?\nSou suspeito para falar (risos). Se pudesse só faria porting de jogos de computador para dispositivos móveis. Com certeza muitos jogos hoje em dia podem ser portados para celulares com grande capacidade, como o iPhone e alguns modelos Android. Acredito que a dificuldade técnica envolveria todas as vertentes da produção, uma vez que nem todos os jogos utilizam a mesma tecnologia, padrões de modelos 2D e 3D, formatos de áudio, entre outros. Empresas grandes dispõe hoje de tecnologias portadas de console para suprir o mercado móvel, acho que isso deve chegar a desenvolvedores independentes ou pequenas empresas.\nQuais são os maiores problemas relacionados a programação que normalmente temos no desenvolvimento de jogos para dispositivos móveis?\nDependendo do tamanho do projeto ou o tipo de título que voce trabalha, difícil citar problemas específicos (sempre aprendemos algo). Acredito que os maiores problemas na área de programação ainda são referentes à memória e render. No passado isso era muito agravante, mas o fato de os aparelhos terem cada vez mais capacidade, faz com que tenhamos menos problemas como estes ou problemas semelhantes aos consoles ou consoles portáteis. Acredito que o Game Designer tenha um trabalho bem difícil tambem, pois precisa limitar sua área útil e proporcionar uma boa jogabilidade.\nComo você acha que os jogos para mobile serão daqui pra frente?\nAcredito que o futuro seja a integração dos jogos móveis com outros dispositivos, como TV interativa, consoles e web. Acho que a união dessas tecnologias fará com que cada dispositivo tenha seu meio de interação especial e faça dos jogos mais atrativos para os jogadores casuais. Acredito tambem que para os gamers hardcores, haverá umaaceitação maior, tendo em vista o crescente aumento de performance dos celulares atuais.\nO que você acha do mercado de desenvolvimento games no Brasil?\nAcho que o mercado de desenvolvimento ainda tem muito o que produzir. As maiores empresas situadas no país ainda são as filiais de empresas internacionais. Acredito que um foco maior das universidades do país na área somada à incentivos do governo podem ajudar as empresas nacionais a crescer e começarem a fazer algo mais parecido com o mercado lá fora.\nAtualmente você está fazendo um mestrado em Engenharia da Computação. Seus projetos no curso são relacionados com jogos?\nTento fazer meus projetos dentro dos créditos envolvendo jogos, seja qual for a disciplina que estou cursando. Minha tese não está totalmente definida, mas meu foco será jogos móveis e educação usando algum sistema especialista. (Em breve saberei)\nNa sua opinião, quais são os cursos mais indicados para quem quer trabalhar com programação de jogos?\nAcredito que para trabalhar com programação, os cursos de Ciência e Engenharia da Computação e de Sistemas de Informação, podem ajudar o aluno há enfrentar melhor os problemas relacionados a jogos. Muitas pessoas que converso e não são da área, muitas vezes não fazem idéia da complexidade de se criar um jogo.\nAs graduações em Jogos do país tambem são recomendadas, mas poucas tem o foco total em programação (apesar de conhecer muitos programadores bons vindos de cursos de Jogos e desculpe se desconheço alguma graduação com esse perfil).\nAlguma dica para quem quer ser um desenvolvedor de jogos?\nAcho que o primeiro passo é ter foco e pé no chão. Em algumas visitas em universidades e tambem papeando com entusiastas, pude perceber que o foco em fazer jogos AAA é muito grande (e não é exagero, coisas do tipo: Vou entrar na faculdade e fazer Gears of War).\nPrimeiro conheça o mercado, os desenvolvedores, veja se as etapas de produção de um jogo atendem exatamente suas expectativas. Conheça as disciplinas envolvidas e tente se especializar em algo que o mercado nacional precisa primeiramente e depois quem sabe, tentar uma vaga fora (se for um sonho talvez).\nE a última dica é ter sempre um portfólio em mãos, seja qual for sua disciplina de atuação (sim, programdores precisam de portfólio).\nAlemão, muito obrigado pela entrevista! Espero que tenham gostado, mais entrevistas com pessoas que trabalham na indústria de jogos estão por vir!\n","date":"8 de março de 2012","externalUrl":null,"permalink":"/entrevista-rafael-martins/","section":"Blog","summary":"O Rafael Martins, também conhecido como Alemão, tem alguns anos de experiência com desenvolvimento de jogos para dispositivos móveis. Começou a trabalhar como programador em jogos J2ME e BREW na Skyzone.\n","title":"Entrevista: Rafael Martins - Technical Manager na Electronic Arts","type":"posts"},{"content":"Forza Motorsport 4 é um dos melhores e mais completos simuladores de corrida já feitos, e eu considero seu maior defeito ser exclusivo para Xbox 360, pois existem volantes e placas de vídeo incríveis para PC que seriam perfeitos para tornar a experiência de jogá-lo ainda melhor. Infelizmente, o Xbox 360 tem poucos volantes disponíveis, e apenas um “profissional” criado pela Fanatec. Mensalmente, Forza 4 recebe um pacote (pago) com carros novos, e o pessoal da Turn 10 Studios, que desenvolveu o jogo, de vez em quando faz alguns vídeos sobre como eles gravam o som de um carro, reconstroem uma pista de corrida, e modelam os carros do jogo. Esses vídeos são bem legais, pois o pessoal da parte técnica do desenvolvimento explica as técnicas e dificuldades em realizar tais tarefas, para garantir que o jogador tenha uma experiência muito próxima da realidade.\nEste primeiro vídeo abaixo mostra as duas maneiras em que um carro é modelado no jogo: a partir de fotos ou mapeando sua estrutura. Além do modelo, as fotos também ajudam na hora de fazer as texturas do carro e garantir todos seus detalhes únicos. No final do vídeo tem um pouco de como eles gravam o som do motor de um carro.\nNeste outro vídeo também é mostrado como eles gravam o som de um motor, mas dessa vez um dos mais barulhentos que eles já gravaram, o Mazda 787B Dyno. O barulho desse carrão é tão algo que eles ficaram preocupados com os equipamentos de gravação, pois são muito sensíveis ao som.\nE, por último, talvez uma das tarefas mais complexas dos desenvolvedores no jogo, que é recriar pistas famosas nos mínimos detalhes. Além de vídeos gravados de dentro de carros e fotografias para referências, a equipe também precisa se preocupar com a elevação de todos os pontos da pista, utilizando alguns GPSs para medir cada centímetro das elevações da pista. É um trabalho enorme e incrível, pois o resultado final é impressionante. Além das pistas, o pessoal da Turn 10 também tem o cuidado de recriar o cenário ao fundo, como árvores e montanhas.\nForza 4 me deixou muito impressionado pela qualidade técnica que a Turn 10 colocou no jogo. Não é apenas um simples jogo de corrida, é um simulador com diversas opções de customização e ajuste de carros, além de diversos campeonatos no jogo e online. A Turn 10 organiza mensalmente eventos que premiam os jogadores com melhores tempos em uma pista escolhida pelos desenvolvedores e um carro específico. Se quiser ver mais vídeos como estes, assine o canal da Turn 10 Studios no youtube.\n","date":"7 de março de 2012","externalUrl":null,"permalink":"/making-of-forza-motorsport-4/","section":"Blog","summary":"Forza Motorsport 4 é um dos melhores e mais completos simuladores de corrida já feitos, e eu considero seu maior defeito ser exclusivo para Xbox 360, pois existem volantes e placas de vídeo incríveis para PC que seriam perfeitos para tornar a experiência de jogá-lo ainda melhor. Infelizmente, o Xbox 360 tem poucos volantes disponíveis, e apenas um “profissional” criado pela Fanatec. ","title":"Making of Forza Motorsport 4","type":"posts"},{"content":"Conheci o Nicholas em 2006, quando trabalhamos juntos como estagiários na Level Up! Games. Nessa época, Nicholas estava em seu último ano da primeira turma de Design de Jogos da Universidade Anhembi Morumbi. Além de ser um dos primeiros Game Designers formados no Brasil, ele também ganhou um concurso chamado JogosBR.\nDepois disso, abriu uma empresa com seu sócio na incubadora de empresas de Osasco, chamada ImaginePlay. Pouco tempo depois, entrou na Ubisoft, quando o escritório em São Paulo foi aberto. Na Ubisoft, Nicholas participou do desenvolvimento dos jogos Imagine: Detective Adventure (Nintendo DS , 2009), como Game Designer, e Michael Jackson: The Experience (Nintendo DS e Sony PSP, 2010), como Lead Game Designer. Com o fechamento do estúdio da Ubisoft no Brasil, Nicholas entrou na Glu Mobile, onde nos encontramos novamente trabalhando na mesma empresa. Na Glu Mobile, ele participou do desenvolvimento de Blood \u0026amp; Glory (Android e iOS, 2011), como Lead Game Designer.\nNesta entrevista, Nicholas conta um pouco de tudo isso que falei acima, e também da dicas importantes para quem quer ser um Game Designer.\nPor que você decidiu ser um Game Designer?\nVi meu primeiro jogo, Space Invaders, com 5 anos de idade. Dizem que já fiquei vidrado! De lá pra frente, acompanhei o mercado, joguei muita coisa, mas sempre tinha umas ideias para jogos e fui descobrindo que o que eu queria fazer mesmo era dar forma aos jogos, criar mecânicas e sistemas. Foi então que me matriculei no primeiro curso de Design de Games da Universidade Anhembi Morumbi e decidi dar prosseguimento a carreira.\nQuais foram suas maiores dificuldades para começar essa carreira?\nAs principais dificuldades foram a falta de pessoas experientes em game design para me darem uma luz, a pouquissima abertura do mercado brasileiro ao game designer, que até hoje em dia é um cargo cuja importância é muito pouco entendida no Brasil e a falta de empresas de games no pais.\nComo foi vencer o JogosBR e abrir sua própria empresa?\nFoi muito bom. Naquela época estava cursando o último ano da universidade, trabalhando e ainda sem perspectiva de quando poderia realmente desenvolver um jogo. Quando surgiu o JogosBR, com o auxilio de meu professor na época, Odair Gaspar, pude criar um game design doc que chamou a atenção e foi um dos projetos vencedores. Dai pra frente pude tocar juntamente com meu sócio, a abertura de uma pequena empresa de desenvolvimento de advergames e soluções interativas. Essa experiência me fez aprender muito sobre como vender o produto e pensar como diretor, que é bem diferente do pensamento que você tem quando é empregado de alguém.\nDepois de abrir sua empresa, você conseguiu entrar na Ubisoft quando o escritório em São Paulo foi aberto. Foi difícil entrar lá?\nFoi muito difícil mas ao mesmo tempo muito mais recompensador. Na época que a Ubisoft deu a notícia e começou a receber currículos eles tiveram que selecionar a equipe de desenvolvimento entre 40.000 candidatos. Eram 13 vagas. Quando me chamaram para a primeira entrevista eu fiquei super animado. A entrevista foi bem puxada, toda em inglês, e com um observador da Ubisoft Montréal. Sai muito confiante de lá. Depois me chamaram para uma segunda entrevista e fiquei algum tempo sem resposta. Quando o produtor do estúdio entrou em contato e me parabenizou, foi um momento único de felicidade.\nSua visão de o que é um Game Designer mudou após trabalhar em jogos de DS e PSP na Ubisoft?\nSim, mudou. No Brasil ainda temos muito a visão de Game Designer como um criador de roteiros e histórias, uma pessoa que trabalha somente com seu lado criativo, elaborando monstros, personagens e etc. Lá aprendi que nossa concepção é totalmente errada. Game Designer é aquele profissional que cria as mecânicas prototipando com o programador, desenvolve as regras matemáticas para score do jogo, encaixa todas as features para que nenhuma delas tenha problema de lógica, e cria os fluxogramas do flow do jogo.\nQual foi sua sensação ao ver seu nome nos créditos de um jogo publicado?\nFoi muito legal. Acho que mais animal ainda é segurar a caixa do jogo em suas mãos e dizer: “Eu projetei este jogo”. Ao olhar os créditos você se lembra dos longos meses de trabalho e todos os problemas que se deparou e as soluções que encontrou.\nAtualmente você está na Glu Mobile, é muito diferente fazer o game design para jogos mobile?\nÉ e não é ao mesmo tempo. A parte de dedicação para criação das mecânicas, controles e jogabilidade é bem parecida pois hoje em dia os devices permitem uma interação muito precisa com os jogos. Sendo assim, os consumidores estão mais exigentes, demandando jogos de qualidade. O que difere é que ao contrário de um jogo de caixinha você tem que criar uma economia e dificuldade mais aberta por poder lidar com atualizações e reagir aos dados em tempo real do jogo. Num jogo de caixa, você cria essa economia e dificuldade e nunca mais mexe.\nComo você vê o mercado de jogos no Brasil?\nPara o público consumidor de jogos ele está crescendo. Temos mais acesso a jogos e os de console estão se tornando cada vez mais baratos pela diminuição de impostos e outras iniciativas. Para o mercado de desenvolvimento, já sou um pouco cético. Temos poucas empresas desenvolvendo jogos para o mercado externo com nível de produção alto e acho que é um quadro que não vai mudar tão cedo.\nQuais jogos, livros e Game Designers que influenciaram sua carreira?\nLivros eu diria Theory of Fun e Rules of Play. Os game designers que me influenciaram são David Jaffe, Shigeru Miyamoto, Shinji Mikami, Suda 51, Cliff Blezinsky e Sid Meyer. Jogos, eu diria: Mario 64, Bayonetta, a série Elder Scrolls, Civilization, Resident evil 4 e Gears of War.\nO que você recomenda para iniciantes que querem seguir nessa profissão?\nEstudem bastante os jogos que jogam. Olhem eles com olhar mais técnico, tentando entender como cada parte do jogo foi feita. Se você pudesse arrumar algo que está ruim, o que faria? São algumas das perguntas que ajudam para que você possa se tornar um bom game designer. Estudem bastante sobre fluxogramas, criação de macros e planilhas no Excell para que possam simular sistemas dos jogos.\nEspero que tenham gostado da entrevista!\n","date":"14 de fevereiro de 2012","externalUrl":null,"permalink":"/entrevista-nicholas-souza-game-designer/","section":"Blog","summary":"Conheci o Nicholas em 2006, quando trabalhamos juntos como estagiários na Level Up! Games. Nessa época, Nicholas estava em seu último ano da primeira turma de Design de Jogos da Universidade Anhembi Morumbi. Além de ser um dos primeiros Game Designers formados no Brasil, ele também ganhou um concurso chamado JogosBR.\n","title":"Entrevista: Nicholas Souza - Game Designer","type":"posts"},{"content":"O maior problema que um programador de jogos sempre enfrenta não está relacionado a algoritmos, problemas de hardware ou falta de café. Seu maior problema é a arte para seu jogo.\nUm desenvolvedor independente (indie) muitas vezes é um programador que não entende nada de arte, e só conhece outros programadores que também não entendem de arte. Muitas vezes para poder demonstrar a idéia do seu jogo para conseguir um investidor, ou até para conseguir mais membros para sua equipe, o programador precisa de imagens para seu jogo.\nExistem sites como o Sprite Database com diversas imagens de jogos antigos que um desenvolvedor pode usar, mas quando o objetivo é fazer um jogo sério e ganhar dinheiro com isso, você não pode usar sprites do Super Mario Bros. e Street Fighter.\nUma solução bem legal para a criação de elementos simples de arte em 2D é a iniciativa do Chris Hildenbrand, um artista que decidiu criar um blog com tutoriais para ajudar programadores a fazer artes simples em 2D utilizando softwares gratuitos como Inkscape e Gimp. Eu não conhecia o Inkscape, é um software bem simples e legal de trabalhar. Abaixo está um exemplo de tutorial que o Chris fez para criação de um personagem em 2D utilizando o Inkscape.\nClaro que não é algo simples e rápido de fazer, mas com um pouco de prática da para aprender coisas bem legais nesses tutoriais. Eu mesmo fiz alguns de brincadeira, só pra saber se eram fáceis de entender, e realmente são! Consegui fazer sprites no Inkscape praticamente iguais aos do tutorial acima.\nAcho muito difícil um programador fazer toda a arte do jogo, principalmente por que exige tempo para o desenvolvimento de novas habilidades e técnicas, mas com esses tutoriais é possível fazer uma arte simples e original para protótipos e demonstrações, ou até mesmo TCC. Esses tutoriais também ajudam artistas iniciantes, pois ensinam várias técnicas legais, é só ter dedicação para estudar!\nAh, caso tenha interesse em sprites prontos de personagens diferentes, o autor também vende alguns packs com imagens em diferentes tamanhos. Isso é bem interessante, pois por um valor muito baixo você pode comprar sprites legais e bem feitos para o seu jogo, além de ajudar o autor a continuar o seu ótimo trabalho que ajuda nós programadores.\nNo caso de modelos e animações em 3D é mais complicado para programadores, acho que o jeito é procurar modelos gratuitos na internet ou encontrar uma pessoa para fazê-los. Como grande parte dos jogos independentes são em 2D, para que fiquem simples, bonitos e com um game design diferenciado, esses tutoriais são muito úteis. Para finalizar o post, uma arte feita por mim no trabalho, enquanto meu projeto compilava, provando que programadores conseguem fazer artes simples até no papel (hahaha):\n","date":"12 de janeiro de 2012","externalUrl":null,"permalink":"/arte-2d-para-programadores/","section":"Blog","summary":"O maior problema que um programador de jogos sempre enfrenta não está relacionado a algoritmos, problemas de hardware ou falta de café. Seu maior problema é a arte para seu jogo.\n","title":"Arte 2D para programadores","type":"posts"},{"content":"Ed Fries, um veterano da indústria de jogos, criou uma versão do Halo para Atari 2600 e apresentou seu jogo na Classic Gaming Expo, em 2010. No evento, Ed vendeu alguns cartuchos limitados com seu jogo e depois publicou gratuitamente na internet para ser rodado em emuladores de atari ou gravado em curtuchos, como o Harmony Cartridge.\nVocê já imaginou como é desenvolver um jogo para um hardware muito antigo, utilizando programação Assembler e apenas 4KB de memória? Eu também não tinha muita noção, até ver o código fonte desse jogo, que foi publicado neste ano, um ano após sua apresentação na Classic Gaming Expo.\nO código fonte, disponível aqui, é um arquivo único com extensão ASM, que pode ser aberto em editores como o Notepad++ (alias, indispensável para programadores!). Para quem está acostumado com linguagens de programação como C/C++, C# e Java, esse código vai parecer muito estranho. É uns script com 3580 linhas que contém um jogo capaz de rodar em um Atari 2600, incrível não?\nNão se preocupe se o código parecer confuso, eu precisaria pesquisar várias instruções para poder entender bem este código. Hoje em dia acho muito difícil alguém querer fazer jogos para Atari, embora seja desafiador. Acho que no futuro eu tentaria fazer um Hello World para rodar em um emulador, só para ver como funciona. Se você está aprendendo a desenvolver jogos, não recomendo tentar fazer um jogo assim. Vale mais a pena estudar bastante as tecnologias mais novas, e depois dar uma olhada nisso por curiosidade.\nVocê pode jogar também a versão em flash do Halo 2600 disponível aqui. Recomendo, pois é muito divertido. Ed conseguiu simplificar Halo o bastante para colocar em um jogo de Atari, bem como balancear a dificuldade do jogo e deixá-lo parecido com os jogos da época. Um trabalho respeitável e muito bem feito.\n","date":"20 de dezembro de 2011","externalUrl":null,"permalink":"/halo-2600-jogo-desenvolvido-para-atari/","section":"Blog","summary":"Ed Fries, um veterano da indústria de jogos, criou uma versão do Halo para Atari 2600 e apresentou seu jogo na Classic Gaming Expo, em 2010. No evento, Ed vendeu alguns cartuchos limitados com seu jogo e depois publicou gratuitamente na internet para ser rodado em emuladores de atari ou gravado em curtuchos, como o Harmony Cartridge.\n","title":"Halo 2600 - jogo desenvolvido para Atari","type":"posts"},{"content":"Eu conheci o jogo indie Minecraft em dezembro de 2010. Na época, seu desenvolvimento tinha passado da fase alpha para a fase beta. Duas coisas me deixaram muito curioso: (1) era um jogo que dependia da criatividade do jogador, lembrava Lego, e também tinha monstros que apareciam a noite e em cavernas que o jogador poderia explorar; e (2) o seu modelo de comercialização, onde o jogo era vendido inacabado durante sua fase de produção.\nUm começo com pé direito\nO desenvolvimento de Minecraft foi iniciado oficialmente em 10 de maio de 2009, por Markus “Notch” Persson. Notch largou seu emprego de desenvolvedor de jogos para tornar-se um desenvolvedor independente, já que acreditava muito na sua ideia. Desde o seu início, o jogo foi oferecido como uma prévia para ser jogado no navegador ou uma versão para jogar no computador com mais algumas coisas, e essa versão era paga. Mas como assim, comprar por um jogo que ainda estava em desenvolvimento?\nEm um primeiro momento achei estranho, quem compraria um jogo em fase alpha, com poucas features e com risco de não ser finalizado? Bom, eu como muitas outras pessoas acreditas no jogo por que achamos divertido, e também havia a promessa de que quem comprasse antes teria acesso a todos updates do jogo e pagaria menos pela sua cópia. Durante a fase alpha o jogo foi comercializado a €10, depois na fase beta por €15, e agora está sendo vendido a €20.\nEm pouco tempo o jogo de Notch ficou famoso, chegando a impressionantes 4 milhões de unidades vendidas antes do seu lançamento na sexta-feira passada durante a MineCon. E, junto com o sucesso do jogo, nasceu uma cultura relacionada a marca Minecraft, que começou com camisetas e papercrafts, até um documentário e seu próprio evento de dois dias realizado em Las Vegas. Notch conseguiu dinheiro mais do que suficiente para aumentar seu studio, Mojang, terminar Minecraft e poder produzir tranquilamente o jogo que quiser pelos próximos anos sem se preocupar com investidores.\nAgora que eu falei um pouco do fenômeno Minecraft, vou analisar mais de perto alguns de seus aspectos técnicos. Pensei em dividir minha análise em duas partes, como um documento de post mortem: “O que deu certo?” e “O que deu errado?”. Como falar que algo deu errado em Minecraft não é algo muito lógico, vou chamar essa parte de “O que não deu tão certo?”. Meu objetivo não é analisar o Game Design do jogo, mas sim toda sua parte técnica, como programação e distribuição.\nO que deu certo?\nNotch desenvolveu seu jogo indie utilizando a linguagem de programação Java, pois ele queria que seu jogo fosse acessível para todos. Nisso ele conseguiu se dar bem, por que graças à JVM (Java Virtual Machine) Minecraft pode rodar em Windows, MacOS, Linux, Solaris, e qualquer outro sistema operacional com suporte a JVM. Para a programação foi utilizado também o LWJGL (Lightweight Java Game Library), um framework gratuito para desenvolvimento de jogos com Java, além do JOrbis (Ogg decoder) e 3D Sound System (som para ambientes tridimensionais).\nMinecraft possui um modo de jogo Cliente-Servidor, onde os jogadores podem participar da mesma sessão no mesmo mundo, onde juntos podem construir mais coisas e mais rápido. Este modo multiplayer também foi desenvolvido utilizando Java e alguns pacotes nativos da linguagem com suporte a rede. Embora seja uma linguagem de programação não muito utilizada para jogos, ainda assim ela possui muitos pacotes e frameworks gratuitos úteis para dar suporte ao desenvolvimento.\nEscolher Java também ajudou muito na conversão do jogo para smarthphones e tablets com o sistema operacional Android. Como o Android tem suporte a JVM, provavelmente foram necessários apenas ajustes relacionados ao hardware dos aparelhos, como optimizar consumo de memória e modificar os controles do jogo para touchscreen, por exemplo. O Java também permitiu a publicação de uma versão web do jogo, disponível para jogar no site utilizando o mesmo save game que a versão desktop.\nO que não deu tão certo?\nSe por um lado Java foi muito bom para tornar o jogo acessível para todos, ele limitou um pouco as plataformas em que o jogo poderia ser distribuído. C/C++ é a tecnologia mais utilizada hoje para desenvolvimento de jogos, e um dos grandes benefícios é ser multiplataforma e não depender de uma máquina virtual, pois roda nativamente em qualquer sistema operacional, de qualquer plataforma.\nCom C/C++, Minecraft poderia ter sido distribuído na App Store da Apple há algum tempo, pois poderia ser facilmente convertido de uma versão desktop para iOS, da mesma maneira que foi feita a conversão da versão Java para Android. E, graças ao NDK, o mesmo código nativo também funcionaria no Android. C/C++ daria mais flexibilidade ao código, podendo ser convertido para distribuição nas redes de consoles Xbox Live, Playstation Network e Wii Ware.\nComo o jogo foi lançado para iOS recentemente, e logo será lançado para Xbox Live, provavelmente houve uma conversão do código Java para C/C++. O tempo e o custo desta conversão poderia ter sido utilizados para melhorar ainda mais o jogo caso tivessem escolhido C/C++ desde o início, ao invés do Java. Mas, Notch teve um bom motivo para utilizar Java, provavelmente ela tinha um bom conhecimento prévio para começar um jogo indie utilizando Java ao invés de C/C++. Na minha opinião estes são pequenos detalhes que poderiam ser pensados desde o início do projeto.\nAo infinito e além\nNotch pode não ter sido feliz na escolha da sua tecnologia para criar Minecraft, mas isso não importa muito, pois o jogo é um sucesso. Apensar de que as versões mobile são bem limitadas, a versão de desktop melhorou muito e está muito divertida, vale a pena conferir. Alias, diversão é algo que sempre preocupou Notch, e ele garante que se uma feature não é divertida, ele não incluirá no jogo.\nAgora que a versão de desktop finalmente atingiu seu status Gold, a Mojang provavelmente irá focar no desenvolvimento de conteúdos extras para o Minecraft, conquistar novas plataformas e trabalhar em novos jogos, como o Scrolls, que foi anunciado este ano. E sabe qual é a parte mais legal disso tudo? Notch disse que no futuro, quando as vendas do Minecraft estiverem baixas, ele tornará o código fonte do jogo público para que todos possam ver como o jogo foi feito. Porém, do jeito que este jogo está vendendo, talvez isso demore um pouco.\nConclusão\nAtravés desta análise técnica eu tentei contar detalhes interessantes sobre o desenvolvimento do jogo indie milionário Minecraft, bem como analisar um pouco do que sei sobre as tecnologias e escolhas do seu desenvolvimento. Escrevi muita coisa baseada na minha opinião e experiência com desenvolvimento de jogos, espero que tenham gostado.\nEsta foi uma análise mais técnica, porém existem diversos ângulos que podemos analisar Minecraft, como seu Game Design, seu impacto cultural, seu modelo de negócios, suas mecânicas, usabilidade, interface, entre vários outros. Este jogo é um ótimo caso para ser estudado em diversas áreas relacionadas ao desenvolvimento e a indústria de jogos, e podem ficar horas falando sobre seus detalhes.\nSe você quiser saber mais sobre Minecraft visite o seu site oficial e o blog do Notch. Existem também uma comunidade muito ativa sobre o jogo, alguns conseguem criar coisas incríveis (e outras nem tanto) com os blocos de Minecraft. Para finalizar, um vídeo que demonstra que podemos até criar músicas dentro do jogo:\n","date":"22 de outubro de 2011","externalUrl":null,"permalink":"/a-tecnologia-por-tras-de-minecraft/","section":"Blog","summary":"Eu conheci o jogo indie Minecraft em dezembro de 2010. Na época, seu desenvolvimento tinha passado da fase alpha para a fase beta. Duas coisas me deixaram muito curioso: (1) era um jogo que dependia da criatividade do jogador, lembrava Lego, e também tinha monstros que apareciam a noite e em cavernas que o jogador poderia explorar; e (2) o seu modelo de comercialização, onde o jogo era vendido inacabado durante sua fase de produção.\n","title":"A tecnologia por trás de Minecraft","type":"posts"},{"content":"Ontem apresentei uma palestra sobre Desenvolvimento de Jogos para Dispositivos Móveis na Universidade Federal do Rio de Janeiro (UFRJ), á convite do Grupo de Eletrônica e Computação (GECOM) no Ciclo de Palestras 2011 que apresentou o tema “Computação e Informação, uma nova abordagem”. Fiquei muito feliz e honrado com o convite, e foi uma experiência incrível e única falar sobre a área que eu estudo e trabalho para pessoas interessadas em ouvir o que eu tinha para falar sobre o assunto.\nFoi a primeira vez que saí de São Paulo, e também a primeira vez que peguei um avião (outra experiência incrível no meu dia). Apesar do calor e ter ido apenas para a universidade, gostei do pouco que vi do Rio, e quero voltar lá um dia para conhecer melhor a cidade. Pelo que me falaram, a parte legal fica mais perto do centro da cidade, um pouco longe da Ilha do Fundão, onde fica a UFRJ.\nNa apresentação abordei alguns aspectos que considero essenciais para desenvolvedores independentes que querem fazer jogos para iOS e Android. Na primeira parte existem detalhes sobre o mercado de dispositivos móveis, com o foco em informações úteis sobre o iOS e o Android. A segunda parte fala sobre o** processo de desenvolvimento de um jogo**, desde seu conceito na pré-produção, passando pelo seu desenvolvimento na produção, e publicando o produto final em sua pós-produção. Na terceira e última parte da apresentação estão algumas dicas que considero valiosas para quem quer trabalhar com jogos, e no fim existe uma lista de sites, revistas e livros muito bons sobre desenvolvimento de jogos.\nTentei resumir muita coisa que aprendi desde que comecei a estudar desenvolvimento de jogos e trabalhar na área, além de focar todas as informações apresentadas no que os programadores precisam saber para fazer seus jogos e publicá-los. Espero que esta apresentação seja muito útil para todos que acessam o meu blog com interesse em desenvolver jogos.\nAgradeço muito a organização do evento pelo convite e pela espaço que me deram para minha apresentação. Espero que os alunos tenham gostado da apresentação tanto quando eu gostei de apresentar para eles!\n","date":"31 de agosto de 2011","externalUrl":null,"permalink":"/palestra-sobre-desenvolvimento-de-jogos-na-ufrj-gecom-2011/","section":"Blog","summary":"Ontem apresentei uma palestra sobre Desenvolvimento de Jogos para Dispositivos Móveis na Universidade Federal do Rio de Janeiro (UFRJ), á convite do Grupo de Eletrônica e Computação (GECOM) no Ciclo de Palestras 2011 que apresentou o tema “Computação e Informação, uma nova abordagem”. Fiquei muito feliz e honrado com o convite, e foi uma experiência incrível e única falar sobre a área que eu estudo e trabalho para pessoas interessadas em ouvir o que eu tinha para falar sobre o assunto.\n","title":"Palestra sobre desenvolvimento de jogos na UFRJ - GECOM 2011","type":"posts"},{"content":"A Crytek, criadora dos jogos da série Crysis e da game engine CryENGINE, disponibilizou uma versão gratuita do seu software de desenvolvimento de jogos para uso não comercial. Assim, a CryENGINE 3 SDK é mais uma ótima opção para quem quer estudar desenvolvimento de jogos para PC utilizando as mesmas ferramentas usadas pelas empresas de games. O download gratuito pode ser feito aqui.\nAlém da engine da Crytek, existe também a Unreal SDK (UDK) da Epic Games, gratuita para uso não comercial. Será que estas empresas começaram a disponibilizar versões gratuitas de suas game engines para atrair estudantes e desenvolvedores independentes?\nEste público, até então, tinha apenas engines “mais simples” como a Unity3D para usar. Eu acredito que o ponta pé inicial disso tudo foi a Unity3D oferecer uma versão gratuita de uma game engine muito boa, que começou a atrair pessoas que não queriam desenvolver jogos apenas programando – essas pessoas queriam algo visual, e isso atraiu não-programadores para a área de desenvolvimento de jogos. A Unity3D abriu uma porta incrível, e espero que a tendência seja que mais empresas grandes criem versões gratuitas de suas engines.\nQuem ganha com isso somos nós, estudantes e desenvolvedores independentes, que podem brincar com “brinquedos de gente grande”.\n","date":"19 de agosto de 2011","externalUrl":null,"permalink":"/cryengine-3-sdk-gameengine-gratuita-dos-criadores-de-crysis/","section":"Blog","summary":"A Crytek, criadora dos jogos da série Crysis e da game engine CryENGINE, disponibilizou uma versão gratuita do seu software de desenvolvimento de jogos para uso não comercial. Assim, a CryENGINE 3 SDK é mais uma ótima opção para quem quer estudar desenvolvimento de jogos para PC utilizando as mesmas ferramentas usadas pelas empresas de games. O download gratuito pode ser feito aqui.\n","title":"CryENGINE 3 SDK - game engine gratuita dos criadores de Crysis","type":"posts"},{"content":"O GMB (Game Music Brasil) é um concurso apresentado pela Oi e dividido em três categorias: Melhor Trilha Sonora, Melhor Banda e Melhor Game Indie. Ainda divulgaram a premiação, mas os participantes já podem se inscrever nestas categorias.\nO funcionamento do concurso é bem simples: em todas as categorias você deve cadastrar um link de um vídeo do seu trabalho postado no youtube, e os usuários do site podem votar nos melhores de cada categoria. Para votar também é necessário preencher um cadastro, pelo menos assim eles tem um controle melhor de quem vota.\nNa categoria de Melhor Game Indie também é necessário cadastrar uma descrição e um link para download ou uma página com informações sobre o jogo. Após a inscrição no jogo no concurso, suas informações não podem ser alteradas. Eu acho que eles fazem alguma verificação antes de publicar o jogo para ser votado, pois demora um pouco (alguns dias) para aparecer no site.\nEstou participando com o jogo Oniro, que foi o meu projeto de TCC da pós-graduação. A arte foi feita por Osmar de Melo Júnior. Como sempre digo nos posts sobre concursos de desenvolvimento de jogos, vale a pena participar! Ah, não esqueça de votar no meu jogo também! =)\n","date":"3 de agosto de 2011","externalUrl":null,"permalink":"/concurso-de-desenvolvimento-de-jogos-game-music-brasil/","section":"Blog","summary":"O GMB (Game Music Brasil) é um concurso apresentado pela Oi e dividido em três categorias: Melhor Trilha Sonora, Melhor Banda e Melhor Game Indie. Ainda divulgaram a premiação, mas os participantes já podem se inscrever nestas categorias.\n","title":"Concurso de desenvolvimento de jogos: Game Music Brasil","type":"posts"},{"content":"FlatRedBall é um framework gratuito feito em C# e XNA para desenvolvimento de jogos para PC, XBLA (Xbox Live Arcade), Silverlight e Windows Phone 7. Além disso, a FlatRedBall possui um conjunto de softwares chamado Glue, que tem como objetivo abstrair o usuário da programação do framework oferecendo ferramentas visuais.\nEu usei o framework da FlatRedBall no meu** TCC da pós-graduação**, o Oniro, e no geral foi uma experiência ótima! Eles possuem um fórum com um pessoal que sempre ajuda nas dúvidas, principalmente o criador da FlatRedBall. Eu escolhi utilizar apenas o framework ao invés do Glue, pois se usasse o Glue teria que aprender como utilizar seus softwares, e com a minha experiência prévia de C# e XNA apenas o framework foi suficiente.\nExistem muitas features legais no framework da FlatRedBall, com destaque para o sistema de gerenciamento de screens (telas) que é muito fácil de usar e funciona bem. Só esse sistema de screens já fez valer a pena utilizar a FlatRedBall, pois reduziu muito o trabalho de programar coisas básicas (porém úteis). Outros destaques são as classes de Sprites e Animação, que também são muito completas e permitem a criação e controle de animações utilizando conceitos similares ao Flash, e a classe de Física, que só deixou um pouco a desejar por que senti falta de coisas como detecção de colisão por pixel, por exemplo, que ainda estavam em desenvolvimento.\nHá um ano atrás, quando usei a FlatRedBall, a sua documentação já era muito boa e objetiva, hoje sua wiki está mais completa. E, se precisar de exemplos e demos, existe o GlueVault, site dedicado a códigos feitos utilizando o framework e o Glue.\nA limitação de usar XNA/C# e publicar jogos apenas para plataformas da Microsoft não é tão ruim. Acho que o mais importante que aprendi utilizando a FlatRedBall foi como sua arquitetura funciona, principalmente o gerenciamento de screens. Este tipo de conhecimento pode ser aplicado em outros projetos, inclusive feitos com outras tecnologias e linguagens.\nÉ importante entender que a FlatRedBall utiliza os recursos do XNA como base, então é como seu seu framework complementasse o framework do XNA, tornando a vida do programador mais fácil. Existem outros frameworks que podem ser utilizados com o XNA, e também há a possibilidade de fazer o jogo inteiro apenas com o XNA, você apenas terá mais trabalho para programar coisas básicas, como efeitos relacionados à Física ou Animações, por exemplo.\nA FlatRedBall é um framework bem fácil de utilizar, mesmo para quem nunca programou em C# e usou XNA. Sua arquitetura e conceitos são bem fáceis de entender e usar. Outro ponto legal é que se você fizer um jogo com a FlatRedBall, ele pode ser incluído no site oficial da engine, o único requisto é ter uma splas no início do jogo com o logo da FlatRedBall. O Oniro está lá no site deles, entre os jogos para PC.\n","date":"28 de julho de 2011","externalUrl":null,"permalink":"/game-engine-flatredball-xna/","section":"Blog","summary":"FlatRedBall é um framework gratuito feito em C# e XNA para desenvolvimento de jogos para PC, XBLA (Xbox Live Arcade), Silverlight e Windows Phone 7. Além disso, a FlatRedBall possui um conjunto de softwares chamado Glue, que tem como objetivo abstrair o usuário da programação do framework oferecendo ferramentas visuais.\n","title":"Game engine: FlatRedBall (XNA)","type":"posts"},{"content":"O e-Games é um concurso de desenvolvimento de jogos organizado pelo SENAC São Paulo com o foco principal em estudantes e desenvolvedores independentes de todo o Brasil. Como os prêmios geralmente são consoles de video game ou jogos, este tipo de concurso é muito mais atraente para estudantes, pois não vale a pena para uma empresa participar. Isso é uma grande vantagem, pois garante que empresas da área, mesmo pequenas, não participem já que o prêmio não é em dinheiro, além da visibilidade ser menor do que um concurso internacional.\nPor isso, recomendo a todos que gostam de desenvolver jogos a participar. Vale muito a pena! Na primeira edição deste evento, em 2009, fiz um porting de um jogo de celular (projeto de uma matéria da pós-graduação) para XNA, e consegui ser finalista entre os 5 melhores. No ano passado, na segunda edição do concurso, estava mais confiante de que teria chances de chegar na final, pois estava participando com o meu TCC da pós-graduação, e realmente consegui ficar entre os 5 melhores de novo. Este ano pretendo participar pela terceira vez seguida.\nNesta edição dividiram o concurso em três categorias: jogos para console/PC; jogos para celular (mobile); e jogos na nuvem. Esta última categoria ficou meio confusa pra mim, pois nada mais é do que um jogo que pode participar das duas outras categorias, mas que deve ter algo relacionado ao conceito de computação na nuvem, além de ser é obrigatório o uso da tecnologia Microsoft Azure. Na segunda edição, os projetos tiveram um nível de qualidade muito maior, se comparados com a primeira edição do concurso. Com certeza o nível da competição deverá estar maior este ano, e isso tende a aumentar a cada edição. Porém, acho que este ano existe a vantagem de ser a primeira vez em que os projetos participam em categorias diferentes, assim terão 15 finalistas (5 em cada categoria) e mais chances para os particpantes.\nAno passado o concurso recebeu destaque no site de games Kotaku Brasil. Tomara que este concurso continue crescendo e ganhando mais destaque e patrocínios, assim continuará a incentivar estudantes e entusiastas que gostam de desenvolver jogos. Eu pretendo continuar participando!\n","date":"18 de julho de 2011","externalUrl":null,"permalink":"/concurso-de-desenvolvimento-de-jogos-senac-e-games-2011/","section":"Blog","summary":"O e-Games é um concurso de desenvolvimento de jogos organizado pelo SENAC São Paulo com o foco principal em estudantes e desenvolvedores independentes de todo o Brasil. Como os prêmios geralmente são consoles de video game ou jogos, este tipo de concurso é muito mais atraente para estudantes, pois não vale a pena para uma empresa participar. Isso é uma grande vantagem, pois garante que empresas da área, mesmo pequenas, não participem já que o prêmio não é em dinheiro, além da visibilidade ser menor do que um concurso internacional.\n","title":"Concurso de desenvolvimento de jogos: SENAC e-games 2011","type":"posts"},{"content":"Há 11 meses escrevi um post aqui sobre meus primeiros 30 dias trabalhando em uma empresa de games. Hoje faz exatamente 1 ano que comecei a trabalhar com jogos e muita coisa mudou, inclusive a empresa que eu trabalhava. Comecei como Engenheiro de Software na Glu Mobile e hoje tenho o mesmo cargo na Electronic Arts, na divisão EA Mobile. Estou tendo uma oportunidade única de expandir meu conhecimento trabalhando em uma das maiores empresas do mundo, principalmente relacionado a jogos mobile.\nHá 1 ano atrás não imaginava que um dia poderia estar na EA, e há 2 anos e meio, quando estava no início do meu primeiro semestre da pós-graduação em Games do SENAC, não sabia o que esperar desta área ou onde iria trabalhar. Meu primeiro pensamento foi me tornar um desenvolvedor independente, e isso é algo que ainda quero fazer em paralelo para aprender mais. Porém, desenvolver um jogo independente divertido como requer muito tempo, dedicação e uma equipe pequena e focada. Claro que é possível desenvolver jogos independes bons em pouco tempo, mas isso ainda exige uma equipe.\nFazer jogos sozinho é muito difícil, mas você acaba aprendendo bastante. Eu, por exemplo, fiz um jogo de celular em J2ME como um projeto da pós-graduação e isso me ajudou a entrar na Glu. Porém, eu fiz apenas a programação, a arte foi feita por David Aguiar. Pouco tempo depois, portei este jogo para XNA (utilizando a mesma arte) e fui finalista no e-Games 2009. Um ano depois, fiz o meu TCC da pós-graduação com XNA, com a arte feita por Osmar de Melo Júnior, e fui finalista no e-Games 2010. Este ano pretendo participar novamente, e pelo menos chegar na final pela terceira vez.\nTrabalhar na área de games nem sempre é um trabalho divertido, pois isto vai exigir muito mais de você do que ser um programador de sistemas. Você trabalha com tecnologias tão novas que nem sempre estarão em sua versão final, e talvez você encontrará bugs em frameworks e SDKs devido ao nível de conhecimento que é necessário ter para corrigir um bug ou melhorar um código do jogo. Esse constante contato com software e hardware muito novos, as vezes antes do público em geral, faz esse trabalho ser muito desafiador. As vezes pode acontecer de você não encontrar uma solução para o seu problema, por se tratar de uma tecnologia nova, e nesse caso todo o conhecimento de programação é necessário para resolver problemas e propor soluções. Falta muito para eu ser fluente em C++ e OpenGL, por exemplo, mas tenho certeza de que estou no caminho certo, pois estou sempre estudando estas tecnologias e fazendo projetos para treinar.\nHoje meu principal trabalho é com Android, mas utilizando o NDK, uma interface em C++ para programação de aplicativos. Programar para Android com Java é bem mais tranquilo do que com NDK e C++, e o Google diz que não há diferença de performance utilizando linguagem nativa, então por que utilizá-la? Simples: portabilidade. Um código bem feito em C++ pode ser usado em qualquer hardware que aceite linguagem nativa, assim não é necessário refazer muita coisa para converter um jogo de iOS para Android, ou até mesmo para PS3 e Xbox. Tudo depende de ter uma arquitetura bem feita para isolar o que é código do jogo e o que é código específico de um hardware. Esse é mais um motivo pelo qual se exige muito do programador nesta área. Não basta dizer que sabe programar em C++ porque teve isso na faculdade, tem que saber arquitetura e engenharia de software para conseguir fazer um código reusável em diversos hardwares. Não vou me aprofundar muito neste assunto, pois quero escrever um post sobre isso e recomendar alguns livros.\nPara terminar, algumas dicas importantes que aprendi nesse 1 ano na indústria de games, e que pode ser muito úteis caso você queira trabalhar com desenvolvimento de jogos:\nEstude C++, OpenGL, Orientação a Objetos, Arquitetura de Software e Engenharia de Software! Além do básico, é muito importante fazer exercícios como pegar um código em C++ de um simples “Hello World” e fazê-lo rodar no PC, Android, Mac, iOS, e em qualquer outra plataforma que você tiver a chance de testar seu código. Pretendo fazer um tutorial ensinando como fazer um Hello World em C++ funcionar em Android e iOS em breve. Funcionou no emulador? Agora teste em um device de verdade! Muita coisa, muita coisa mesmo, funciona bem em emuladores por que eles usam o hardware do seu computador, quando o teste é feito em um device de verdade os reais problemas aparecem, como pouca memória, lentidão, entre outros. A partir disso você deve entender o que fazer para otimizar seu código. Funcionou em um device? Agora peça para todo mundo que você conhece testar! Isso é importante para encontrar bugs e para verificar se o jogo é realmente divertido. Mantenha o código do seu jogo flexível e atualizado! Existem repositórios gratuitos onde você pode compartilhar o código do seu jogo com a sua equipe (não estou falando de um arquivo zip =p), um bom exemplo é o BitBucket. Seu jogo ficou bom? Publique! Essa é uma incrível vantagem que temos hoje em dia, podemos publicar jogos para Android e iOS em suas respectivas lojas sem muitos problemas, e jogos de PC/Mac podem ser publicados digitalmente em muitos sites por ai, ou em seu próprio site. Não seja ganancioso! Publique seus primeiros jogos gratuitamente, para que as pessoas possam conhecer o seu trabalho. Depois você pode lançar novas versões pagas ou até conteúdo extra pago para seus jogos. Jogue! Mas não apenas jogos de gêneros que você gosta, jogue também aqueles que você não gosta. Isso é importante para você aprender como funciona determinada mecânica de jogo, e é um desafio entender e reproduzir esse tipo de coisa, além de tentar chegar no mesmo resultado (ou melhor). Nunca pare de estudar! A indústria de jogos é muito dinâmica, você precisa estar sempre atualizado. Mas não apenas tecnicamente, leia também sites que falam da parte de negócios da indústria de games, como o Gamasutra e o GamesIndustry. Estude Inglês! Não basta você dominar C++, para trabalhar com jogos você deve saber se comunicar em inglês. Isso pode ser decisivo para sua contratação em uma empresa de games. Participe de eventos, concursos e fóruns! Eventos como a SBGames e concursos como o e-Games são muito legais e importantes para você conhecer outras pessoas, talvez até sócios para começar uma empresa ou empresas para publicar seus jogos. Fazer Networking é muito importante na indústria de games, ainda mais aqui no Brasil onde é tão pequena. Visite meu blog constantemente! Tá bom, pode soar propaganda, mas aqui você encontrará muitas informações legais e úteis sobre desenvolvimento de jogos. =) Neste semestre pretendo atualizar o blog com mais frequência. Espero que tenham gostado das informações que compartilhei, qualquer dúvida ou sugestão é só deixar um comentário!\n","date":"12 de julho de 2011","externalUrl":null,"permalink":"/1-ano-na-industria-de-games/","section":"Blog","summary":"Há 11 meses escrevi um post aqui sobre meus primeiros 30 dias trabalhando em uma empresa de games. Hoje faz exatamente 1 ano que comecei a trabalhar com jogos e muita coisa mudou, inclusive a empresa que eu trabalhava. Comecei como Engenheiro de Software na Glu Mobile e hoje tenho o mesmo cargo na Electronic Arts, na divisão EA Mobile. Estou tendo uma oportunidade única de expandir meu conhecimento trabalhando em uma das maiores empresas do mundo, principalmente relacionado a jogos mobile.\n","title":"1 ano na indústria de games","type":"posts"},{"content":"Existem muitas revistas sobre games por ai, porém quase nenhuma fala sobre desenvolvimento de jogos. A revista EDGE, que durou pouco tempo no Brasil, ainda tinha algumas matérias interessantes sobre a indústria de games (inclusive no Brasil), mas era bem superficial para uma pequena parte do público que se interessa em ler sobre como grandes jogos são produzidos, qual técnica/software os estúdios usam para o desenvolvimento de um game, por que um jogo faz mais sucesso do que outro, por que um produto foi desenvolvido para determinado público (e se atingiu esse público), entre outras coisas.\nVocê sabe quando um jogo faz sucesso vendo suas notas, mas por trás disso existe um grande trabalho para deixar tudo perfeito. Faz parte deste trabalho tomar decisões certas e erradas, e algumas empresas publicam o que deu certo e errado na produção de um jogo. Além de alguns websites, como o Gamasutra e o GamesIndustry, existem algumas revistas que têm muitas notícias e matérias legais sobre a indústria de games, e o melhor é que muitas delas são disponibilizadas de graça!\nA seguir estão quatro revistas que eu conheço focadas na produção e no desenvolvimento de games, apenas uma delas é paga.\nDevelop\nEsta revista possui uma versão impressa que é vendida na europa, porém a versão digital é gratuita. Na minha opinião, é uma das melhores revistas sobre a indústria de games que eu já li. Possui conteúdos bem técnicos, como discussões sobre uma determinada tecnologia, até textos sobre investimentos, publicidade e marketing de um jogo. Esta revista é mensal e eu recomendo baixar o PDF para ler!\nCasual Connect\nCom o foco no mercado de jogos casuais, esta revista impressiona pela quantidade de informações que reúne. Nas edições digitais é possível encontrar dados preciosos sobre o mercado de jogos casuais, quais são as tendências, quais as técnicas de game design para criar um jogo casual, como fazer seu jogo ser um sucesso de vendas, estudos de casos, enfim, tem muita coisa interessante para quem está desenvolvendo jogos para redes sociais e dispositivos móveis.\nGame Sauce\nAssim como a Casual Connect, esta revista também possui muitas informações valiosas para quem é um desenvolvedor independente, porém seu foco não é apenas em jogos casuais, mas sim em toda a indústria. Sempre têm alguma reportagem ou entrevista com pessoas importantes da indústria, além de possuir também um conteúdo técnico.\nGame Developer Magazine\nEsta é uma das mais antigas revistas de games, e provavelmente a mais antiga sobre desenvolvimento de jogos. Seu conteúdo abrange todo o mercado de games, e possui entrevistas e matérias sobre jogos que acabaram de ser lançados ou que ainda estão em desenvolvimento. Existem versões impressa e digital, e ambas são pagas. Porém a assinatura anual da versão digital custa apenas $29 dólares, que é um preço bem razoável pela qualidade da revista, e você ainda ganha acesso às versões antigas.\nGame Carreer Guide\nDiferente das demais revistas que tem o foco em negócios, esta aqui é feita para estudantes que desejam trabalhar na indústria de games. Existem muitas matérias sobre cursos, algumas entrevistas e uma pesquisa anual de salários nos EUA. É gratuita e obrigatória para todos que tem interesse ou trabalham com games!\nGrande parte destas revistas tem o foco em negócios, algumas inclusive em marketing. A visão de um game como um produto é complicado para quem gosta de programação e modelagem, mas é muito importante para fazer seu jogo ser um sucesso de vendas e crítica. Existem outras coisas legais nas revistas, como anúncios de emprego e cursos, claro que todos nos EUA, Canadá ou Europa.\nDê uma olhada nas revistas, são muito legais e possuem informações sobre a indústria que podem até mudar sua maneira de pensar sobre o que é desenvolver um jogo.\n","date":"18 de maio de 2011","externalUrl":null,"permalink":"/revistas-sobre-desenvolvimento-de-jogos/","section":"Blog","summary":"Existem muitas revistas sobre games por ai, porém quase nenhuma fala sobre desenvolvimento de jogos. A revista EDGE, que durou pouco tempo no Brasil, ainda tinha algumas matérias interessantes sobre a indústria de games (inclusive no Brasil), mas era bem superficial para uma pequena parte do público que se interessa em ler sobre como grandes jogos são produzidos, qual técnica/software os estúdios usam para o desenvolvimento de um game, por que um jogo faz mais sucesso do que outro, por que um produto foi desenvolvido para determinado público (e se atingiu esse público), entre outras coisas.\n","title":"Revistas sobre desenvolvimento de jogos","type":"posts"},{"content":"Hoje, a animação com Computação Gráfica é algo comum em filmes e games, mas como isso começou? O vídeo abaixo mostra desde as primeiras animações para filmes com stop motion até a impressionante tecnologia utilizada em Avatar. É incrível como a tecnologia utilizada nos filmes evoluiu nos últimos anos.\nCada vez mais a tecnologia está deixando animações mais realistas nos filmes. Não podemos esquecer também dos filmes de animação, onde a Pixar foi pioneira com o Toy Story e conseguiu criar vários outros filmes com sua tecnologia de animação cada vez mais evoluída e com histórias cada vez mais criativas. Eu admiro muito a Pixar, acho que esta empresa deve ser um exemplo para todos que gostam de computação gráfica. Inclusive recomendo dar uma olhada no site deles, tem muito material legal, como este link que mostra como eles criam os filmes e este link que possui alguns artigos deles. Aproveitando o post, vou colocar o vídeo que mostra o que eles fizeram em seus 25 anos de existência:\nAgora, voltando um pouco para a indústria de games, você acha que a animação em jogos evoluiu bastante também? A indústria de jogos eletrônicos é bem mais nova do que a indústria de filmes, mas acredito que a evolução na área dos games é tão grande quanto nos filmes. Muitos jogos utilizam sistema de captura de movimentos, como os filmes fazem também, para deixar a movimentação do personagem mais realista.\nL.A. Noire, o novo jogo da Rockstar que sai este mês possui uma tecnologia desenvolvida por eles que utiliza diversas câmeras para capturar todos os movimentos do rosto de um ator e aplicá-los aos respectivos modelos 3D. Essa tecnologia é tão impressionante que o jogo será homenageado no Festiva de Filmes de Tribeca, sendo o primeiro game a conseguir chamar a atenção dos críticos de cinema, devido a sua impressionante qualidade de animações. O vídeo abaixo é uma entrevista com o pessoal da Rockstar sobre essa nova tecnologia, é bem interessante.\nEu jamais terminaria de escrever este post se ficasse colocando vídeos de outros jogos com tecnologias incríveis utilizadas no seu desenvolvimento. Inclusive acho uma injustiça não adicionar aqui outras obras de arte como Assassin’s Creed, Forza, Halo, Killzone, Alan Wake, Gears of War, Mass Effect, e muitos outros jogos que vão muito além de uma simples animação, eles transportam o jogador além do jogo, proporcionando uma imersão completa na história. Quem jogou Gears of War 2 e viu a cena do que acontece com a esposa do Dominic sabe o que eu quero dizer.\nQuando mais estudamos desenvolvimento de jogos, mais prestamos atenção aos mínimos detalhes e passamos a admirar cada parte de um jogo bem feito, emocionalmente e tecnicamente. As técnicas de computação gráfica estão evoluindo bastante na indústria de games, e a indústria de filmes pode começar a aprender algumas coisas com os jogos, como mencionado por Seth Hall que trabalhou no Dead Space 2.\n","date":"2 de maio de 2011","externalUrl":null,"permalink":"/evolucao-da-computacao-grafica/","section":"Blog","summary":"Hoje, a animação com Computação Gráfica é algo comum em filmes e games, mas como isso começou? O vídeo abaixo mostra desde as primeiras animações para filmes com stop motion até a impressionante tecnologia utilizada em Avatar. É incrível como a tecnologia utilizada nos filmes evoluiu nos últimos anos.\n","title":"Evolução da computação gráfica","type":"posts"},{"content":"Game Jolt é um portal de jogos bem legal, onde você pode publicar seus jogos para web ou download, e as pessoas que jogam podem comentar e dar notas para os games. O foco do Game Jolt são desenvolvedores independentes e até estudantes que querem mostrar ao mundo seus jogos. Eu publiquei dois jogos neste portal, um feito em flash há muitos anos (meu primeiro game), e outro que fiz recentemente usando a Unity, que podem ser acessados por este link.\nAlém deste suporte aos desenvolvedores, o Game Jolt também realiza concursos de desenvolvimento de jogos indie. Ano passado eles organizaram um concurso bem legal, onde você tinha que pegar um jogo indie como base e recriá-lo em 8 bits. O jogos que ganharam ficaram realmente legais.\nO concurso atual exige muita criatividade. O Invention Contest tem um tema: invenção. E você pode usá-lo como quiser para fazer um jogo criativo. Este concurso é bem parecido com o que a Microsoft faz na Imagine Cup, onde você recebe um tema e tem que fazer um jogo criativo, divertido e inovador. Claro que não podemos comprar este concurso com a Imagine Cup, mas a idéia é bem parecida.\nEu acho este tipo de concurso legal e desafiador, principalmente para quem quer ser game designer. Esta é uma boa oportunidade para você se testar e tentar ganhar um concurso internacional. Como os prêmios são bem simples, como um jogo indie, a concorrência é pouca. Apesar de ser um portal relativamente novo, ganhar um concurso desses pode não te deixar rico, mas te dará visibilidade e respeito.\nOutro aspecto que deixa o concurso interessante é o tempo: menos de um mês para fazer um jogo e enviá-lo. Por isso o jogo deve ser simples, mas sem deixar de ser divertido. Eu não sei se irei participar, provavelmente não por causa do prazo.\nBoa sorte para quem quiser participar!\n","date":"19 de janeiro de 2011","externalUrl":null,"permalink":"/concurso-de-desenvolvimento-de-jogos-game-jolt/","section":"Blog","summary":"Game Jolt é um portal de jogos bem legal, onde você pode publicar seus jogos para web ou download, e as pessoas que jogam podem comentar e dar notas para os games. O foco do Game Jolt são desenvolvedores independentes e até estudantes que querem mostrar ao mundo seus jogos. Eu publiquei dois jogos neste portal, um feito em flash há muitos anos (meu primeiro game), e outro que fiz recentemente usando a Unity, que podem ser acessados por este link.\n","title":"Concurso de desenvolvimento de jogos: Game Jolt","type":"posts"},{"content":"No Brasil, o e-Games é um dos poucos concursos de desenvolvimento de jogos organizados por aqui. Em outros países, talvez principalmente nos EUA, concursos de desenvolvimento de jogos são mais comuns e alguns dão prêmios muito bons em dinheiro, além de reconhecimento na indústria de games. Muitos jogos independentes que são famosos hoje conseguiram esta fama após ganhar alguns concursos deste tipo. Para participar destes concursos é muito importante ler o regulamento antes de entrar, pois podem haver restrições.\nMês passado foi aberta a inscrição para o concurso “Independent Propeller Awards at SXSW ScreenBurn” no indiePub Games, com prêmios de $150,000. Neste concurso você pode inscrever praticamente qualquer jogo, inclusive versão de demonstração. As inscrições terminam em 18 de fevereiro.\nSobre o concurso: http://www.indiepubgames.com/contest.php?contestId=2\u0026amp;show=info\nComo o prazo é curto, decidi inscrever o Oniro neste concurso. Fiz uma versão do jogo em os textos em inglês, assim fica mais fácil para quem quiser jogar. Estou participando apenas para ganhar experiência, sei que não tenho muitas chances de ganhar algo, até por que o nível de competição deste concurso deve ser altíssimo. O importante é participar!\nEsta é a página do Oniro no indiePub: http://www.indiepubgames.com/game/Oniro\nAgora que terminei minha pós-graduação, vou me dedicar a participar de concursos de desenvolvimento de jogos independentes, sempre que puder participar. E sempre que encontrar algum concurso assim vou postar aqui no blog informações sobre ele.\n","date":"4 de janeiro de 2011","externalUrl":null,"permalink":"/concurso-de-desenvolvimento-de-jogos-indiepub-games/","section":"Blog","summary":"No Brasil, o e-Games é um dos poucos concursos de desenvolvimento de jogos organizados por aqui. Em outros países, talvez principalmente nos EUA, concursos de desenvolvimento de jogos são mais comuns e alguns dão prêmios muito bons em dinheiro, além de reconhecimento na indústria de games. Muitos jogos independentes que são famosos hoje conseguiram esta fama após ganhar alguns concursos deste tipo. Para participar destes concursos é muito importante ler o regulamento antes de entrar, pois podem haver restrições.\n","title":"Concurso de desenvolvimento de jogos: indiePub Games","type":"posts"},{"content":"Este ano participei da segunda edição do e-Games, o concurso de desenvolvimento de jogos organizado pelo SENAC. Ano passado, na primeira edição, fui um dos finalistas e fiquei em quito lugar. Este ano participei com o jogo que desenvolvi para o TCC da minha pós-graduação em Games: Produção e Programação, e novamente consegui ficar entre os finalistas.\nO post anterior fala deste projeto, o Oniro. Ele ficou entre os cinco melhores projetos do concurso, de um total de quase 70 participantes inscritos. Infelizmente não fiquei entre os três primeiros colocados, e ainda não sei se fiquei em quarto ou quinto lugar, mas estou muito feliz por ser novamente um finalista neste concurso, que cada vez tem mais participantes com jogos realmente bons.\nNo concurso, o pessoal que foi para assistir teve a oportunidade de jogar os projetos finalistas, e fiquei feliz pelo público-alvo do meu projeto ter gostado do jogo, principalmente do tema.\nAno que vem pretendo participar novamente com ajuda do Osmar, que fez toda a arte do Oniro. Inicialmente, Oniro era apenas meu TCC, mas decidi participar do concurso com ele, já que a data de envio para o concurso era uma semana depois da data de entrega do meu TCC. Ao todo, seu desenvolvimento levou 4 meses, sendo que o Osmar teve apenas 1 mês para fazer toda a arte. Agora que temos mais tempo, provavelmente iremos criar um jogo ainda melhor!\n","date":"29 de dezembro de 2010","externalUrl":null,"permalink":"/finalista-no-e-games-2010/","section":"Blog","summary":"Este ano participei da segunda edição do e-Games, o concurso de desenvolvimento de jogos organizado pelo SENAC. Ano passado, na primeira edição, fui um dos finalistas e fiquei em quito lugar. Este ano participei com o jogo que desenvolvi para o TCC da minha pós-graduação em Games: Produção e Programação, e novamente consegui ficar entre os finalistas.\n","title":"Finalista no e-Games 2010!","type":"posts"},{"content":"Depois de 4 meses de desenvolvimento (game design, programação e arte), e algumas noites sem dormir, consegui terminar o meu TCC da pós-graduação em Games: Produção e Programação no SENAC. Meu projeto foi a versão de demonstração do Oniro, um jogo de aventura com plataformas em 2D, desenvolvido utilizando XNA e FlatRedBall.\nFiquei muito feliz, pois além de ter conseguido terminar o projeto no prazo ele ficou muito bom, tanto que tirei nota 10 na apresentação para a banca no SENAC. Não teria conseguido isto sem a ajuda do Osmar de Melo Júnior, que fez toda a arte. Obrigado!\nAqui está o link para download da versão demo do Oniro.\nEm um post mais antigo, escrevi sobre o início do projeto com a escolha da tecnologia utilizada baseada no estilo do meu jogo. Agora vou contar um pouco sobre o jogo e sobre o processo de desenvolvimento após a decisão de fazer um jogo de plataforma em 2D utilizando XNA. Isto é praticamente o post mortem do meu projeto. Dividi o processo em 4 partes: Game Design, Programação, Arte e Pós-produção.\nAqui é onde tudo começa. Com a idéia de fazer um jogo de plataforma 2D, comecei a pesquisar que tipo de jogo poderia utilizar como referência. Provavelmente o primeiro game que pensamos ao falar “Plataforma 2D” é o Super Mario Bros., mas no meu caso a inspiração veio de outro grande game: Braid. Este é um jogo de plataforma 2D independente, genial e muito bonito, sem falar na sua trilha sonora praticamente perfeita. Eu escolhi este jogo para ser uma base do que eu queria fazer, claro que não seria uma cópia dele, é apenas uma referência.\nCom a tecnologia e a mecânica do jogo definidas, faltou uma parte importante: o tema do jogo. No início do ano, quando comecei a pensar no meu TCC, eu estava com um grande interesse pelas obras de Neil Gaiman, principalmente Sandman. Decidi que o tema do jogo teria o deus grego dos sonhos Morfeus, mas para não ficar uma cópia da obra de Gaiman, eu fui atrás das referências que ele utilizou para criar Sandman, e sua principal fonte foi a mitologia grega. Assim, o jogo teria como personagem secundário o mesmo deus, porém teria mais mitologia do que a HQ de Gaiman.\nNeste contexto, encontrei o que diferenciaria meu jogo de Sandman, sem deixar de ter isto como uma forte referência: o mundo dos sonhos de Morfeu foi dominado por Pesadelos, e ele precisará da ajuda de um garoto para salvar o mundo dos sonhos e recuperar relíquias roubadas pelos Pesadelos de outros deuses gregos. Ai encontrei outro problema: como seria o mundo dos sonhos? Então tive a idéia de que o mundo dos sonhos é formado pelas lembranças de onde o garoto que irá ajudar Morfeu vive, porém suas lembranças foram distorcidas pelos Pesadelos. E o local escolhido foi também uma homenagem minha para o locar onde vivo, portanto escolhi a cidade de São Paulo como referência para o mundo dos sonhos pela visão do garoto. Assim, os níveis tem detalhes que são de alguns locais na cidade de São Paulo, porém em nenhum momento isto é revelado para o jogador. Esta é a sinopse do jogo:\nJogo de aventura onde um garoto, Paulo, é escolhido pelo Deus Grego dos Sonhos Morfeu para ajudá-lo a recuperar as 12 relíquias quer permitem o acesso dos doze dos Deuses do Olímpio ao Mundo dos Sonhos. As relíquias foram roubadas pelos Pesadelos, seres sombrios que querem dominar o Mundo dos Sonhos, lar e reino de Morfeu e seus irmãos, local onde todas as criaturas que sonham vão ao cair no sono.Oniro significa Sonho em grego. Este nome foi escolhido por que o jogo será baseado na mitologia grega e será ambientado no Mundo dos Sonhos do deus grego Morfeu. Jogo de aventura onde um garoto, Paulo, é escolhido pelo Deus Grego dos Sonhos Morfeu para ajudá-lo a recuperar as 12 relíquias quer permitem o acesso dos doze dos Deuses do Olímpio ao Mundo dos Sonhos. As relíquias foram roubadas pelos Pesadelos, seres sombrios que querem dominar o Mundo dos Sonhos, lar e reino de Morfeu e seus irmãos, local onde todas as criaturas que sonham vão ao cair no sono.\nOniro significa Sonho em grego. Este nome foi escolhido por que o jogo será baseado na mitologia grega e será ambientado no Mundo dos Sonhos do deus grego Morfeu.\nO público-alvo do Oniro são jogadores casuais com idade entre 15 e 20 anos, porém este produto também deve atingir outras faixas etárias e jogadores hardcore. O jogo apresentará um nível de dificuldade crescente em seus desafios além de diversas conquistas que o jogador não precisará conseguir para finalizar o jogo, mas são objetivos secundários que podem chamar atenção do público hardcore.\nCom o conceito definido, iniciei o Game Design Document (GDD). Ainda não encontrei um modelo de GDD que me agradou, o que utilizei é uma mistura de diversos outros modelos que encontrei na internet e em livros de Game Design. No documento, separei as características do jogo nestas categorias: Visão Geral; Produto; Game Design; Level Design; Personagens; História; Especificações Técnicas; Versão DEMO. Como eu não sou Game Designer, achei que ficou bem fraco este documento, talvez se tivesse o foco apenas nisso o documento e o jogo teriam ficado mais legais, mas como tive que pensar muito em programação, isto acabou me limitando e forçando a pensar em coisas simples.\nNeste link você pode baixar o GDD. Estou disponibilizando o documento para download por que fica mais fácil entender os conceitos do jogo e também para quem quiser ver o modelo de GDD que utilizei. Por favor, não reproduza este arquivo ou parte dele, use apenas como referência.\nEsta foi a parte em que mais me dediquei. Fiz muitas coisas que no final ajudaram muito, e outras nem tanto. Deste o início eu tive uma preocupação principal: deixar o código flexível para implementar facilmente qualquer alteração ou incluir novas funcionalidades. Nesta parte minha experiência de quase 4 anos como Analista de Sistemas ajudou muito, pois pude utilizar alguns design patterns e metodologia de desenvolvimento ágil que costumava utilizar em softwares comerciais. O resultado foi muito bom. Com exceção de algumas partes do código, tudo foi desenvolvido da maneira que imaginei, inclusive tive tempo para reescrever alguns trechos de código que não estava muito bem feitos ou que existiam uma maneira melhor para fazer.\nEu geralmente sou muito crítico com o que faço, e raramente acho que algo está tão bom que não precise ser melhorado, mas no caso deste jogo eu gostei do meu trabalho. Claro que daqui um ano quando eu olhar este código novamente vou achar vários defeitos e pontos que poderiam ser feitos de outra maneira. Acho que o com meu nível de conhecimento de programação de jogos, o código está bom o bastante para ser reutilizado ou continuado até a versão final do jogo.\nQuando escolhi utilizar o XNA foi devido ao meu conhecimento desta ferramenta e também de C#. E esta escolha foi muito inteligente, pois tive tempo para melhorar o código ao invés de estudar e pesquisar o funcionamento de coisas básicas. Porém, nem toda a decisão foi boa. Procurei frameworks complementares para o XNA, e encontrei três que pude analisar e escolher o mais indicado para minha necessidade:\nFarseer Physics Engine: Uma biblioteca para o XNA com foco na simulação de física muito simples de utilizar. Apesar ser muito boa para física, não possui suporte para outras partes de um jogo, como criação de níveis e animações. Utilizando a Farseer haveria a necessidade de desenvolver muitas funcionalidades para o jogo, funcionalidades que estavam sendo buscadas em um complemento para o XNA e, assim, focar apenas no desenvolvimento do jogo. Torque X 2D: Uma game engine muito fácil de utilizar que requer pouca programação, uma vez que tudo pode ser feito em sua interface visual. Apesar de possuir suporte a diversas funcionalidades, muitas delas são vendidas separadas da game engine, que também não é gratuita. Esta solução foi descartada devido ao investimento necessário, além de um problema maior: seria necessário aprender a utilizar esta game engine para o desenvolvimento do jogo, e uma das prioridades do projeto era não perder tempo. FlatRedBall: Esta biblioteca para XNA surgiu como a melhor solução para o que estava sendo buscado: um complemento com funcionalidades prontas para economizar tempo de desenvolvimento e focar no jogo. Com uma física inferior à da Farseer, porém com mais funcionalidades relacionadas à criação de níveis e animações, a FlatRedBall foi escolhida como complemento ao XNA. Esta game engine é gratuita, porém pede a inclusão de seu logo no início do jogo. A FlatRedBall possui diversos softwares para criação de animações, telas, entre outros, chamado Glue. Porém, ela permite a criação de tudo isso através de programação, funcionando apenas como uma biblioteca de recursos para o XNA. Assim, o projeto não ficou preso ao Glue, foi utilizada apenas a DLL da FlatRedBall no jogo. A decisão de utilizar a FlatRedBall junto com o XNA foi muito boa no início, mesmo perdendo alguns dias para testá-la. Durante o desenvolvimento do projeto, diversos recursos foram extremamente úteis, porém perto do final do projeto tive um grande problema: detecção de colisões. Nos testes que fiz, verifiquei a colisão de objetos simples, como dois quadrados, mas no jogo existem colisões mais complexas e simultâneas, e foi ai que tive problemas. Parte dos problemas foi culpa minha, porém depois que arrumei tudo que estava errado, comecei a esbarrar com limitações da FlatRedBall. Como esta engine é gratuita e está em desenvolvimento contínuo, muitos dos problemas que tive ainda não tinham uma solução definitiva ou não tinha sido implementado, então tive que escrever código que deveria estar na engine.\nEsta foi a parte quem que a minha decisão não foi tão boa. No final me arrependi um pouco de ter utilizado a FlatRedBall devido aos problemas que tive e a sua falta de recursos. Acredito que se tivesse utilizado a Farseer para a física e tivesse desenvolvido todo o resto que usei da FlatRedBall (basicamente recursos como sprites e screen) o resultado final teria sido melhor e menos problemático.\nDesde o início do projeto eu tinha idéia de como queria que a arte do jogo fosse feita, eu só não tinha gente pra fazer isso pra mim. Até tentei encontrar alguém, mas como não encontrei decidi começar o projeto utilizando imagens da internet, e depois que tivesse alguém para fazer a arte eu só teria o trabalho de substituir as imagens de teste pela arte final. Estava com medo de não encontrar alguém para desenhar o conteúdo do jogo, e pensei até em fazer um curso de desenho, mas não teria tempo para aprender o bastante pra fazer a arte do jogo. Outra idéia que tive era utilizar fotos com efeitos, porém acho que isso ficaria meio estranho.\nNesta parte eu tive sorte. Muita sorte mesmo. Durante o desenvolvimento do meu TCC eu entrei na Glu Mobile como engenheiro de software para trabalhar no porting de jogos feitos com J2ME para a América do Norte, e lá conheci o Osmar, que em apenas um mês conseguiu desenvolver toda a arte do jogo, e o resultado final ficou muito melhor do que eu imaginava. Trabalhar com ele foi bem legal, pois não precisei dizer o que eu queria, apenas falei das influências que tive quando pensei no jogo e mostrei o GDD para ele, a partir disso ele conseguiu criar a arte dos personagens e níveis que ficaram perfeitos para o jogo.\nEnquanto ele desenhava a arte e me enviava as imagens, fiquei surpreso que a minha idéia de programar com imagens da internet de depois substituir funcionou perfeitamente, eu praticamente não tive que alterar nada do meu código, tive apenas que substituir as imagens temporárias pelas novas. Outro recurso que fiz, e ajudou muito no final, foi utilizar arquivos de texto para definir como seria cada parte do nível, com as imagens, tipos de colisão, itens, armadilhas, inimigos e seus comportamentos.\nEste foi outro recurso simples que pensei no início do projeto, mas que na hora de montar o nível precisei escrever pouco código, toda a configuração estava no arquivo de texto. Neste ponto descobri que toda a minha preocupação com a flexibilidade do jogo tinha dado certo, o código estava bom o bastante para funcionar com qualquer coisa que eu quisesse fazer no nível, e com pouca ou nenhuma programação adicional. Também fiz um template para criar níveis. Só faltou mesmo fazer um editor de níveis visual, mas isso não era necessário para a versão demo e também tomaria um tempo que eu não tinha.\nAo todo, o desenvolvimento do projeto levou 4 meses: 3 meses em que fiquei programando toda a base do jogo com imagens temporárias e pensando no game design, e depois mais 1 mês onde o Osmar fez as imagens e eu criei os níveis com elas. Neste último mês também tive a oportunidade de melhorar o código e corrigir alguns bugs. Como sempre testei muito durante o desenvolvimento, não tinham muitos bugs para corrigir no final do projeto.\nExiste apenas uma coisa que não consegui fazer: a trilha sonora do jogo. Eu queria muito compor a música do jogo, principalmente por que toco teclado e guitarra há anos, era uma chance de incluir no meu jogo mais uma característica minha, porém não tive tempo e acabei utilizando músicas de domínio livre disponíveis na internet.\nAprendi diversas coisas durante o desenvolvimento deste projeto, que considero o meu primeiro jogo de verdade, embora seja uma versão de demonstração apenas. Este é um resumo das principais coisas que aprendi no projeto:\nCoisas que deram certo:\nA preocupação com a flexibilidade do código e uso de design patterns Escolher uma tecnologia que eu já conhecia para desenvolver o jogo: XNA Criar um sistema para criação/edição de níveis, mesmo que seja apenas um arquivo texto Utilizar imagens da internet durante o desenvolvimento e depois substituir pela arte final Coisas que NÃO deram certo:\nUtilizar a FlatRedBall pensando que não teria que me preocupar com nada Perder muito tempo estudando qual tecnologia iria utilizar – deveria ter utilizado XNA desde o início Fiz uns três cronogramas – ignorei todos =p Fazer a programação e o game design juntos – dei pouca atenção ao game design, estava mais preocupado com a programação desde o início Apesar da correria que feito fazer este projeto, parte por culpa minha mesmo, eu gostei muito. Eu não teria conseguido fazer um jogo tão legal se não fosse pela ajudar do Osmar também, espero fazer muitos outros jogos com ele. Por enquanto não tenho interesse em continuar este projeto, vou deixar ele parado por enquanto. Agora quero dar prioridade para estudar desenvolvimento para iOS, C++ e Unity. Outra prioridade que terei é atualizar mais vezes este blog.\nAqui está o link para download da versão demo do Oniro.\nEspero que você goste, e por favor deixe comentários sobre o que achou do jogo. Até mais!\nUPDATE:\nAdicionei um vídeo que mostra as fases do jogo, infelizmente não tem som:\n","date":"28 de dezembro de 2010","externalUrl":null,"permalink":"/fim-do-tcc-da-pos-graduacao-oniro/","section":"Blog","summary":"Depois de 4 meses de desenvolvimento (game design, programação e arte), e algumas noites sem dormir, consegui terminar o meu TCC da pós-graduação em Games: Produção e Programação no SENAC. Meu projeto foi a versão de demonstração do Oniro, um jogo de aventura com plataformas em 2D, desenvolvido utilizando XNA e FlatRedBall.\n","title":"Fim do TCC da pós-graduação: Oniro","type":"posts"},{"content":"Deixei o blog desatualizado por um tempo por causa do meu TCC da pós-graduação, que finalmente terminei e logo postarei aqui as informações sobre ele o a versão demo do jogo que fiz. Agora pretendo atualizar este blog com mais frequência, já que estou livre do TCC e com muito conteúdo para postar.\nHoje um game designer da empresa que trabalho enviou este vídeo muito legal que explicar o que você precisa fazer para tornar-se um bom game designer. As dicas do vídeo são muito boas, inclusive para que não é game designer. Eu gostei muito desse vídeo e concordo com tudo que foi apresentado. Game design é um trabalho bem mais complicado do que muitos imaginam, este vídeo é tão bom por que consegue mostrar um pouco do que um game designer faz e o que você precisa aprender para chegar lá.\n","date":"12 de novembro de 2010","externalUrl":null,"permalink":"/entao-voce-quer-ser-um-game-designer/","section":"Blog","summary":"Deixei o blog desatualizado por um tempo por causa do meu TCC da pós-graduação, que finalmente terminei e logo postarei aqui as informações sobre ele o a versão demo do jogo que fiz. Agora pretendo atualizar este blog com mais frequência, já que estou livre do TCC e com muito conteúdo para postar.\n","title":"Então, você quer ser um game designer?","type":"posts"},{"content":"O blog está meio parado por que estou enrolado com o meu TCC da pós-graduação e também por uma grande mudança na minha vida: Há 30 dias atrás deixei de ser um Analista de Sistemas e consegui um emprego como Engenheiro de Software na Glu Mobile, uma empresa que faz jogos e porting de jogos para celulares e smartphones. Depois de 1 ano e meio desde que comecei a estudar desenvolvimento de jogos mais a sério, consegui entrar na indústria de games. Estou trabalhado no departamento de engenharia responsável por porting de jogos para a região da América do Norte.\nAté chegar nisso foram muitos livros, aulas da pós-graduação e projetos – tudo relatado aqui neste blog. Agora começou uma nova etapa, onde eu estou aprendendo mais do que nunca sobre desenvolvimento de jogos (na prática) e como uma empresa desta área funciona, sem falar no contato com pessoas do mundo inteiro que possuem muitos interesses em comum. A empresa é incrível, com um ambiente bem característico com o que se espera de uma empresa de games.\nBom, mas você sabe o que é porting de jogos? Basicamente é pegar uma versão de um jogo, desenvolvida por outra equipe, e fazê-la funcionar em outros celulares, criando versões para cada tipo de configuração de celular. Porém isto não é tão fácil quanto parece, e nem tão simples quanto eu imaginava. Entre as tarefas relacionadas ao porting de um jogo estão: analisar e diminuir o consumo de memória e processamento, melhorar o desempenho do jogo, saber identificar problemas rapidamente, entender por que acontece uma coisa no emulador e outra no aparelho, entender código feito por outras pessoas, corrigir bugs (muitas vezes estranhos), entre muitas outras tarefas.\nNo geral, trabalhar com porting de jogos é bem desafiador. Existem diversas coisas que te obrigam a pensar e agir rápido, e você consegue desenvolver muitas habilidades de programação e engenharia. Após estes 30 dias tenho certeza que está é a indústria em que eu quero trabalhar. Porting não é fácil e eu tenho muito o que aprender, mas agora estou no caminho! Go go go!\nAh, sempre tem alguma vaga aberta na Glu, em diversas áreas como arte, programação e QA. Acesse o site para ver as vagas: http://www.glu.com/jobs\nExistem diversas coisas que quero postar aqui, mas está difícil de arrumar tempo para escrever. Vou tentar postar com mais frequência, mesmo que seja algo mais curto e direto, principalmente por que tenho muitas coisas sobre o desenvolvimento do meu TCC para contar aqui.\n","date":"12 de agosto de 2010","externalUrl":null,"permalink":"/30-dias-na-industria-de-games/","section":"Blog","summary":"O blog está meio parado por que estou enrolado com o meu TCC da pós-graduação e também por uma grande mudança na minha vida: Há 30 dias atrás deixei de ser um Analista de Sistemas e consegui um emprego como Engenheiro de Software na Glu Mobile, uma empresa que faz jogos e porting de jogos para celulares e smartphones. Depois de 1 ano e meio desde que comecei a estudar desenvolvimento de jogos mais a sério, consegui entrar na indústria de games. Estou trabalhado no departamento de engenharia responsável por porting de jogos para a região da América do Norte.\n","title":"30 dias na indústria de games","type":"posts"},{"content":"Faz algum tempo que não posto aqui, estou bem enrolado e empolgado com o desenvolvimento do meu TCC, um jogo de aventura e puzzles em 2D feito com XNA. Em breve irei postar algo sobre o início do desenvolvimento do meu projeto e do que estou utilizando.\nHoje vou postar aqui um trabalho que fiz na pós, na matéria de Música para jogos digitais. Foi uma matéria bem interessante pelas análises que o professor conseguia fazer de músicas e efeitos sonoros usados em jogos, e a partir disso tivemos que escrever um pequeno artigo sobre a importância da música e efeitos sonoros nos jogos digitais.\nEste é o texto que escrevi:\nQuando o Atari foi lançado seus jogos não possuíam música, devido à limitação técnica do hardware. Porém eram utilizados efeitos sonoros muito simples que, embora fossem apenas “bips” emitidos pelo vídeo game, completavam o jogo e a experiência do jogador.\nCom a evolução dos vídeo games e computadores, a música começou a ser empregada para “preencher” o ambiente. Aos poucos, tornou-se um elemento fundamental para um jogo, além dos efeitos sonoros e visuais. Hoje são itens essenciais em jogos, sendo que muitos jogadores que antes prestavam atenção apenas em belos gráficos, agora também reparam na melodia e nos sons que de um jogo.\nSem dúvidas a música é tão importante nos jogos quando em filmes e animações, mas por quê? Basta tentarmos jogar algum jogo digital com o som desligado: em muitos casos o jogo perde a graça. Existem jogos, ainda, que amarram a música ao enredo do jogo, de modo que as mudanças na narrativa do jogo são demonstradas pela música, como músicas agitadas indicando perigo, por exemplo. Braid, um jogo de aventura em plataforma, utiliza a música para informar ao jogador se há perigo ou não em uma fase, e inclusive brinca com os efeitos sonoros quando o jogador volta no tempo e desfaz uma ação.\nNeste caso, a melodia conduz o jogador e o convida a uma imersão no mundo do jogo. A alteração do ritmo da música durante uma fase transmite ao jogador sensações sobre o que está por vir. Para que todos estes recursos musicais funcionem deve haver uma grande harmonia entre as músicas e os efeitos sonoros, pois sem esta combinação de elementos todo o trabalho do músico será em vão, e a trilha sonora será apenas mais um enfeite no jogo.\nJogos como Resident Evil, um clássico de suspense e terror, usa muito a trilha sonora para ambientar o jogador e capturar sua atenção, tornando o jogo mais tenso em determinadas partes, inclusive utilizando a ausência de música e deixando apenas a respiração do jogador e os barulhos dos passos do personagem. Tudo isso ajuda no clima do jogo, aumentando a imersão do jogador no enredo, e fazendo-o sentir-se realmente dentro da história contada, além de aumentar o número de sustos, também.\nO ambiente, neste caso, é construído por sons e ruídos que são imprescindíveis para que o jogo transmita a sensação que os criadores pensaram. A exploração destes níveis de sons na trilha do jogo conseguiu criar este ambiente que combina perfeitamente com a arte do jogo e transmite ao jogador um sensação de imersão em uma realidade diferente: o mundo onde se passa o jogo.\nAlguns jogos são uma mistura de música com jogabilidade, como as séries Guitar Hero e Rock Band, onde o jogador tem sua imersão “tocando” músicas conhecidas com uma jogabilidade que tenta ser semelhante a tocar uma guitarra, baixo ou bateria. Este tipo de jogo sem música não faz sentido, devido à importância da música na sua narrativa, e ambienta o jogador de modo que ele se sente tocando em um show de rock, vibrando realmente após cada trecho complicado que ele conseguiu executar em seu instrumento música interativo.\nAo contrário do que alguns pensam, hoje o objetivo da música e dos efeitos sonoros não é “enfeitar” um jogo, é muito mais do que isso. Estes elementos devem ser utilizados em conjunto com a arte e a narrativa do jogo para proporcionar uma experiência mais rica para o jogador e aumentar a sua imersão com o mundo criado, criando ambientes a partir de sons, ruídos, ritmo, melodia e harmonia. Os exemplos de jogos citados confirmam esta importância da banda sonora em um jogo digital, sendo que a música tornou-se uma parte fundamental na obra de arte que é um jogo bem elaborado, divertido e com imersão.\nMuitos jogos executam esta união de música, arte e narrativa de maneira praticamente perfeita, e ganham diversos prêmios que valorizam o jogo como uma obra de arte. Em 2009, jogos como Batman: Arkham Asylum e Uncharted 2 foram os principais vencedores destes prêmios dados pela indústria de jogos e entretenimento, devido ao grande investimento em música e efeitos sonoros idéias para suas respectivas narrativas.\nApós o término da parte de programação do meu TCC irei compor e gravar a trilha sonora da minha demo. Esta matéria serviu para eu conhecer mais profundamente o que uma música ou efeito sonoro podem fazer na ambientação de um jogo, sem isso o jogo pode perder sua identidade e diversão.\n","date":"20 de junho de 2010","externalUrl":null,"permalink":"/a-importancia-da-musica-e-efeitos-sonoros-nos-jogos-digitais/","section":"Blog","summary":"Faz algum tempo que não posto aqui, estou bem enrolado e empolgado com o desenvolvimento do meu TCC, um jogo de aventura e puzzles em 2D feito com XNA. Em breve irei postar algo sobre o início do desenvolvimento do meu projeto e do que estou utilizando.\n","title":"A importância da música e efeitos sonoros nos jogos digitais","type":"posts"},{"content":"Este ano irei terminar a minha pós-graduação em Games: Produção e Programação no SENAC, e tenho que fazer o meu Trabalho de Conclusão de Curso (TCC), quer será uma versão demo de um jogo. O projeto do TCC começou ano passado, quando fiz um Game Design Document (GDD) sobre uma idéia de jogo que tive, porém descartei esta idéia e este ano comecei a trabalhar em outra mais simples.\nEmbora eu não tenha finalizado o novo GDD, defini algumas coisas importantes para o início do meu projeto: o tipo de jogo que pretendo fazer, qual público-alvo desejo atingir e em qual plataforma irei focar. A idéia inicial era fazer um jogo em 3D, porém após pensar muito, decidi fazer um jogo de plataforma 2D para PC, com elementos de aventura e puzzles, focado no público de jogadores hardcore, porém também atendendo aos jogadores casuais (como jogos de plataforma geralmente fazem). Porém, para chegar nesta definição eu precisei passar por alguns meses pesquisando tecnologias.\nEm outro post irei comentar mais sobre o processo de criação de um GDD, além de detalhar mais o que estou fazendo. Neste post irei focar a primeira etapa que um desenvolvedor tem que definir, após ter conhecimento da idéia inicial do jogo: que tecnologia utilizar para programar o jogo. Abaixo estão algumas tecnologias que pensei em utilizar, porém por algum motivo desisti, até chegar à que realmente irei utilizar para o meu projeto de TCC:\nUnity: Uma poderosa Game Engine que tornou-se gratuita no final do ano passado, possibilitando que desenvolvedores independentes tivessem acesso a uma ferramenta de desenvolvimento de jogos profissionais. Em meu post sobre a Unity fica bem claro que é uma excelente Game Engine, inclusive quando escrevi aquele post estava pensando em utilizá-la no meu TCC, porém desisti. O motivo: a Unity é incrível, porém para fazer um bom jogo nela eu iria precisar de um modelador 3D desde o início do projeto, e eu estou fazendo o projeto sozinho e não sou modelador.\nC++/SDL/OpenGL: Após desistir de uma Game Engine, parti para uma das opções mais voltadas para programação, decidi tentar a combinação da linguagem de programação C++ com SDL, que eu aprendi na pós, e OpenGL para os gráficos 3D. Esta combinação possui vantagens, como a possibilidade de compilar para Windows e Linux. C++ é uma das linguagens mais utilizadas para programação de jogos, e OpenGL é muito utilizado em programação de jogos para consoles. Eu havia escolhido estas tecnologias por que eu iria aprender muito do que eu preciso para desenvolver jogos profissionais, porém desisti por um simples motivo: no momento eu não tenho muito tempo disponível para aprender a trabalhar com OpenGL, e eu não quero fazer algo mal feito.\nC++/DirectX: Aprender OpenGL era complicado e iria exigir muito tempo, então resolvi tentar utilizar C++ com DirectX, pois assim eu ainda estaria aprendendo mais sobre C++, além de eu já ter feito algumas coisas com DirectX na pós-graduação. Comecei a planejar o desenvolvimento de pesquisar as coisas seriam necessárias para o desenvolvimento de um game em 3D. Utilizando DirectX eu ficaria preso ao desenvolvimento para PC, porém não considerei este um problema, já que é um mercado bem amplo. Porém, comecei a ficar um pouco preocupado ao pensar em um simples detalhe: e os modelos 3D? Comecei a pesquisar alguns sites que possuem modelos gratuitos e pagos, eu até estava disposto a comprar modelos não muito caros, porém acabei desistindo de vez de fazer um jogo 3D, pois embora eu estivesse com uma tecnologia que eu conheço um pouco melhor, eu voltei ao problema que me fez desistir da Unity: pode ser que eu termine a programação do jogo, mas não tenha modelos 3D legais para utilizar.\nXNA: Desde o início eu pensei: se eu ficar desesperado, largo tudo e faço com XNA, pois tenho 2 jogos feitos com XNA em meu portfólio, além de participar de um projeto com XNA na Octopus Team. Depois de pensar muito sobre o meu jogo, sobre a verdadeira razão pela qual eu quero fazê-lo, eu decidi optar por algo que eu conheço bem e é simples de utilizar, para poder focar em fazer um jogo bom, ao invés de gastar muito tempo aprendendo uma tecnologia. Eu poderia até conseguir fazer algo com as tecnologias anteriores, e iria aprender coisas novas, porém não acho que o jogo iria ficar bom. Este motivo também me fez optar por utilizar gráficos 2D e fazer um jogo de plataforma, pois desenhos mais simples eu consigo fazer ou encontrar alguém para fazer.\nTodo este processo de decisão de qual tecnologia eu iria adotar para o meu projeto custou caro: cerca de 3 meses de pesquisa e nenhum desenvolvimento. Embora eu tenha perdido todo este tempo, sendo que se eu tivesse pensado em utilizar XNA desde o início hoje eu já estaria bem adiantado no desenvolvimento, isto serviu para aprender diversas coisas em relação ao que priorizar em um projeto.\nNo início eu queria fazer um jogo para meu portfólio, por isso escolhi tecnologias que eu não conheço e acho importantes para eu aprender, porém agora estou com outra visão: não quero apenas mais um trabalho no meu portfólio, eu quero criar um produto que tenha chances reais de ser publicado e comercializado, e que talvez isto seja o início para eu abrir uma empresa.\nEmbora eu tenha escolhido uma tecnologia simples, e um modelo de jogo simples, vou focar no que realmente importa: divertir e entreter os jogadores com um jogo muito bom! Portanto, neste projeto o Game Design vai ser muito importante. Devido a esta importância eu ainda não finalizei muitas definições, pois quero fazer o melhor que puder. O que começou como uma idéia para um simples projeto de TCC, hoje se tornou o prelúdio de um sonho.\n","date":"7 de maio de 2010","externalUrl":null,"permalink":"/inicio-do-meu-projeto-de-jogo-para-tcc/","section":"Blog","summary":"Este ano irei terminar a minha pós-graduação em Games: Produção e Programação no SENAC, e tenho que fazer o meu Trabalho de Conclusão de Curso (TCC), quer será uma versão demo de um jogo. O projeto do TCC começou ano passado, quando fiz um Game Design Document (GDD) sobre uma idéia de jogo que tive, porém descartei esta idéia e este ano comecei a trabalhar em outra mais simples.\n","title":"Início do meu projeto de jogo para TCC","type":"posts"},{"content":"Em muitos jogos, a Inteligência Artificial é a principal responsável pela diversão que um game proporciona. Por exemplo, você consegue imaginar jogos como CALL OF DUTY ou GTA sem a inteligência que os NPCs possuem? Segundo este artigo do David Wong, a aprimoração da I.A. nos jogos é uma das coisas que os jogadores hardcore desejam. Quanto mais real, melhor para a experiência do usuário.\nA I.A. é muito importante, mas alguns jogos ficam perfeitos com uma I.A. simples e limitada, ao contrário de jogos como SPORE que deve ter uma implementação absurda de** Redes Neurais**. O desenvolvedor de jogos deve conhecer os principais algoritmos de I.A., mas não é necessário sempre usá-los em todos os projetos. Na pós-graduação, tivemos uma matéria dedicada a I.A. nos jogos digitais, onde o professor Murilo Garcia apresentou as principais técnicas e quais problemas elas ajudam a resolver.\nComo trabalho para avaliação, tivemos que implementar técnicas de I.A. que serão úteis em nossos TCCs. Abaixo está uma descrição do techdemo que fiz:\nNeste techdemo o quadrado verde fica patrulhando o canto superior esquerdo da tela, enquanto o usuário/jogador controla o quadrado azul com as teclas direcionais do teclado.\nO quadrado verde fica no estado de patrulha enquanto o quadrado azul estiver a certa distância dele. Quando o quadrado azul se aproximar, o quadrado verde ficará vermelho e mudará o seu comportamento para perseguição do quadrado azul.\nNo estado de perseguição, o quadrado azul deverá fugir, até ficar um pouco distante do quadrado vermelho. Quando estive longe do quadrado azul, o quadrado vermelho volta para o estado de patrulho no canto superior esquerdo e ficará novamente verde.\nPara a troca do comportamento do quadrado verde/vermelho foi feita uma máquina de estado, que varia entre Patrulha e Perseguição. Quando o quadrado está verde, a patrulha é fixa no canto superior esquerdo, sendo que esquete quadrado sempre voltará para patrulhar o seu canto quando o estado de Perseguição se tornar Patrulha.\nNo estado de perseguição, com o quadrado tornando-se vermelho, o quadrado azul é perseguido em uma velocidade constante, pouco inferior à velocidade do jogador, e só muda de estado quando a distância entre os dois quadrados se tornar grande o bastante para o quadrado verde voltar a patrulhar seu canto.\nEste techdemo foi desenvolvido com C++ e SDL, utilizando o Visual Studio 2008.\nA implementação das técnicas citadas pode não ser a mais perfeita do mundo, mas se você quiser ver como foi feita, o código fonte está neste link. Qualquer dúvida é só comentar aqui!\nVou aproveitar este post sobre I.A. e indicar mais um livro, este é um dos que foi utilizado pelo professor como bibliografia desta matéria, o Programming Game AI by Example de MatBuckland, que ensina vários conceitos e algoritmos de I.A. com exemplos de implementação. Este livro trata I.A. no geral, não exclusivamente para games, mas praticamente tudo que está nele é aplicável em um jogo digital:\n","date":"2 de abril de 2010","externalUrl":null,"permalink":"/inteligencia-artificial-nos-jogos-digitais/","section":"Blog","summary":"Em muitos jogos, a Inteligência Artificial é a principal responsável pela diversão que um game proporciona. Por exemplo, você consegue imaginar jogos como CALL OF DUTY ou GTA sem a inteligência que os NPCs possuem? Segundo este artigo do David Wong, a aprimoração da I.A. nos jogos é uma das coisas que os jogadores hardcore desejam. Quanto mais real, melhor para a experiência do usuário.\n","title":"Inteligência Artificial nos jogos digitais","type":"posts"},{"content":"Um dos objetivos da pós-graduação que estou fazendo é preparar o aluno para abrir uma empresa de games e procurar um publisher para publicar nossos jogos. No final do ano os TCCs, que são demos de jogos, serão apresentados a um publisher, e se tudo der certo, pode ser o que jogo seja desenvolvido e publicado. Esta é uma iniciativa muito legal do SENAC, pois faz nossos trabalhos terem mais sentido ao final do curso.\nPara isto, temos uma matéria muito importante no sentido de negócios, que é Empreendedorismo. Um fato curioso é que os dois professores que nos deram a matéria (metade da matéria cada um) não tem conhecimento da indústria de games, mas se mostraram bons ouvintes para entender as características únicas desta indústria. Estas aulas foram legais, principalmente pela grande experiência deles em empreendedorismo, já que são do FGVcenn (Centro de Empreendedorismo e Novos Negócios da FGV). Em alguns momentos era engraçado a falta de conhecimento deles em coisas que para nós eram claras.\nNesta matéria, o projeto foi desenvolver um Plano de Negócios para o nosso TCC, utilizando este roteiro. Inicialmente a idéia era criar uma empresa com um produto, que é o nosso jogo, porém todos preferiram criar um Modelo de Negócios com foco em um produto, já que este Plano de Negócios será apresentado a um publisher que está interessado no produto.\nFazer um Plano de Negócios não é fácil. É necessário juntar muita informação para embasar o produto que queremos desenvolver, e responder perguntas como “Qual o diferencial deste jogo que o tornará um sucesso e por quê?”. Uma boa fonte de informações sobre a indústria brasileira de games é o site da Abragames, porém as pesquisas estão um pouco desatualizadas, mas serve como uma base.\nInformações sobre a indústria de games no mundo inteiro são mais fáceis de encontrar na internet ou em sites como GamaSutra e GamesIndustry. Outra ferramenta legal é o Google Trends, onde você pode pesquisar a quantidade de pesquisas que um ou mais termos tiveram nos últimos anos e alguns fatos que marcaram este termo, como, por exemplo, este comparativo entre Wii, Xbox 360 e PS3.\nVou finalizar este post com duas dicas sobre empreendedorismo que o Augusto Camargo deu em um aula, que foi convidado por um dos professores para conversar conosco:\nO foco do negócio não é desenvolver um produto, e sim a emoção que ele irá proporcinar ao usuário final (no caso de games, não basta ter gráficos perfeitos e controles de movimentos, tem que divertir e fazer o jogador se sentir bem e feliz); Quando fizer o planejamento do fluxo de caixa, teste a projeção da empresa nos próximos meses em cenários ruins, como metade do volume vendido ou metade do faturamento, e veja se a empresa sobrevive (é algo muito simples de fazer com um Plano de Negócios, e quase todas as empresas novas quebram nesta simulação). Eu pretendo escrever mais posts sobre a indústria de games e também sobre como começar uma empresa de games no Brasil (startup), qual tipo de jogo é mais lucrativo aqui, onde e como exportar um game produzido aqui, entre outros assuntos que eu acho interessantes e não é algo muito claro para quem quer começar uma empresa de games. Eu não sei muitas dessas coisas, mas irei pesquisar e postar aqui os resultados, já que uma das possibilidades que estudo é abrir minha própria empresa de games.\nO Plano de Negócios, como praticamente qualquer tipo de documento, é bem chato de fazer, mas é muito útil também. Principalmente por que quando se escreve as idéias, fica mais fácil de ver as falhas e mudar coisas. Eu mudei boa parte do GDD (Game Design Document) do meu TCC após escrever o Plano de Negócios, pois na descrição de produto e estratégia de marketing encontrei problemas para a produção do jogo.\n","date":"1 de abril de 2010","externalUrl":null,"permalink":"/empreendedorismo-na-industria-de-games/","section":"Blog","summary":"Um dos objetivos da pós-graduação que estou fazendo é preparar o aluno para abrir uma empresa de games e procurar um publisher para publicar nossos jogos. No final do ano os TCCs, que são demos de jogos, serão apresentados a um publisher, e se tudo der certo, pode ser o que jogo seja desenvolvido e publicado. Esta é uma iniciativa muito legal do SENAC, pois faz nossos trabalhos terem mais sentido ao final do curso.\n","title":"Empreendedorismo na indústria de games","type":"posts"},{"content":"Antes de começar a estudar desenvolvimentos de games ano passado eu não imaginava o que realmente era um jogo, do ponto de vista da programação. Quem está acostumado com a estrutura de um sistema, não consegue imaginar muito bem que tipo de programa é um jogo sem estudar sua estrutura básica.\nBasicamente, um jogo é um programa em loop infinito. Fiquei surpreso nas primeiras aulas da pós-graduação quando percebi isso. Independente do tipo do jogo, todos têm isso em comum, chamado de Main Loop ou Game Loop, que é responsável por controlar tudo no jogo.\nA principal responsabilidade do Main Loop é receber entradas, atualizar o status do jogo e produzir saídas correspondentes, tudo isso em um ciclo contínuo, praticamente infinito. Neste ponto existe uma diferença entre o Main Loop de um jogo de PC e um jogo de console: no PC o Main Loop é finalizado quando o jogar fecha o jogo; em alguns Consoles o Main Loop é praticamente infinito, pois não existe um “sair do jogo”; em Consoles como o Nintendo Wii, é possível sair do jogo e voltar para a tela inicial do Wii, finalizando o Main Loop do jogo.\nOutra responsabilidade do Main Loop, que muitos iniciantes esquecem, é o Frame Rate. A taxa de quadros por segundo em que o jogo roda é importante por que sem este tipo de controle o jogo não fica sincronizado. Em alguns casos, o Frame Rate é escondido do programador e utiliza um valor default, como no XNA. Em outros, ele é obrigatório para o jogo rodar, como na SDL.\nO Frame Rate pode ser definido com um número que o programa deve esperar até executar o Main Loop novamente. Porém, não é simplesmente fazendo isso que o programa irá executar aquele mesmo rate sempre. Dependendo do consumo de processamento e memória, um loop pode ser mais lento do que outro, e utilizando um número fixo, o rate sempre será diferente, provocando lags para o jogador.\nUma solução para este problema é descontar do Frame Rate o tempo em o Main Loop gastou em sua execução, assim, o jogo rodará sempre no mesmo frame. Por exemplo: se o Frame Rate é 30, e o Main Loop gastou 3, o programa deve aguardar 27 (30 – 3) para executar novamente o Main Loop. Sem este controle, o programa iria aguardar 33 (30 + 3) para ser executado novamente, lembrando que o tempo do Main Loop pode variar sempre e o Frame Rate é uma constante. O diagrama abaixo ilustra o funcionamento do Main Loop Fixed Rate:\nO que escrevi neste post é algo que considero bem básico para a programação de um game, e acho que pode ser muito útil para iniciantes. Apesar de ser básico, a partir disso é possível procurar mais informações na internet, ou perguntar aqui mesmo qualquer dúvida sobre o assunto.\n","date":"1 de março de 2010","externalUrl":null,"permalink":"/programacao-de-jogos-main-loop/","section":"Blog","summary":"Antes de começar a estudar desenvolvimentos de games ano passado eu não imaginava o que realmente era um jogo, do ponto de vista da programação. Quem está acostumado com a estrutura de um sistema, não consegue imaginar muito bem que tipo de programa é um jogo sem estudar sua estrutura básica.\n","title":"Programação de jogos: main loop","type":"posts"},{"content":"Uma das coisas que tenho estudando bastante ultimamente, além da Unity e de C++, é o XNA. Por ser algo gratuito e bem difundido pela Microsoft, é bem fácil de encontrar ajuda na internet sobre qualquer coisa que você quer fazer ou algum erro estranho, principalmente no fórum oficial do XNA Creators Club, além dos exemplos e tutoriais que podem ser encontrados neste site. Mesmo assim, sempre existe aquele detalhe que você não consegue encontrar ou que simplesmente não funciona do jeito que deveria.\nIsto aconteceu comigo quando estava tentando montar um Grid em 3D com XNA. Eu queria criar um método para gerar um Grid dinâmico, com o número de linhas de colunas que seriam recebidos por parâmetros. Encontrei diversas soluções, porém nenhuma funcionou do jeito que eu queria, ou não consegui adaptar para o que eu precisava. Assim, tive que estudar como fazer desenho de pontos e retas em 3D e criar meu próprio método para isto.\nPrimeiro eu tinha pensando em desenhar uma célula, e depois utilizar um conjunto de células em uma classe Grid. Esta idéia não deu muito certo, pois ficaria bem complicado gerenciar o desenho de cada célula. A minha solução final ficou mais simples: criei uma classe Grid onde eu traço retas em pontos que formam o meu Grid, de acordo com o número de linhas e colunas. Abaixo trecho do código responsável por montar o Grid:\nApós montar o Grid em uma variável VertexPositionColor, basta utilizar o método DrawUserPrimitives() desenhando uma LineList. Para visualizar o Grid é necessário outras coisas além disso, como definir uma matrix de View e uma de Projeção, que são coisas bem mais básicas do que a lógica de desenhar um Grid. Além do XNA Creators Club, existe o XNA MSDN Library da Microsoft, que também é muito útil para aprender.\nEspero que isto seja útil para quem está aprendendo XNA. Qualquer dúvida é só perguntar nos comentários!\n","date":"21 de fevereiro de 2010","externalUrl":null,"permalink":"/como-montar-um-grid-3d-com-xna/","section":"Blog","summary":"Uma das coisas que tenho estudando bastante ultimamente, além da Unity e de C++, é o XNA. Por ser algo gratuito e bem difundido pela Microsoft, é bem fácil de encontrar ajuda na internet sobre qualquer coisa que você quer fazer ou algum erro estranho, principalmente no fórum oficial do XNA Creators Club, além dos exemplos e tutoriais que podem ser encontrados neste site. Mesmo assim, sempre existe aquele detalhe que você não consegue encontrar ou que simplesmente não funciona do jeito que deveria.\n","title":"Como montar um grid 3D com XNA","type":"posts"},{"content":"No final do ano passado, duas grandes game engines ganharam versões gratuitas, a Unity e a Unreal Development Kit (UDK). Talvez estas foram as melhores notícias para os desenvolvedores independentes e estudantes no em 2009, pois agora podemos desenvolver jogos utilizando game engines profissionais. Pra mim foi muito bom, pois poderei utilizar uma destas game engines no meu TCC neste ano.\nNa pós-graduação, em uma aula de Game Engine, meu grupo fez uma apresentação da Unity e um tech demo. A Unity tinha uma versão indie, que custava $200, que não é algo caro para uma pequena empresa, mas para quem quer apenas estudar isto não vale muito a pena, e foi esta versão que ficou gratuita. Existe também uma versão Pro, com muitas outras coisas a mais pelo preço de $1499.\nMinha primeira coisa que pensei ao abrir a Unity foi “certo… e agora?”. Para quem nunca viu, tudo pode parecer confuso, mas lembra bastante uma interface de um software de modelagem 3D como o Softimage XSI. Estudando a interface da Unity podemos aprender muitas coisas, pois quase tudo é intuitivo. O que realmente é necessário é ter uma noção de ambientes 3D e estudar algumas técnicas utilizadas em modelagem, isto pode facilitar bastante.\nCom a versão gratuita, podemos desenvolver jogos para plataforma Windows, MAC e Web (para Web é necessário instalar um plugin, semelhante ao flash). Existem complementos para a versão Pro que permite o desenvolvimento de jogos para iPhone e Wii. A programação pode ser feita utilizando C# (a Unity é baseada no Mono), JavaScript ou Boo (uma variação de Python, feita por um brasileiro).\nPodemos criar modelos 3D em diversos softwares e importar na Unity,de uma maneira incrivelmente fácil e simples: basta colocar o modelo no diretório da “Assets” do seu projeto, que ela automaticamente adiciona dentro do projeto, nem é necessário abrir e fechar o projeto. Isto é tão útil que podemos alterar o modelo salvo em Assets e visualizar o resultado dentro da Unity.\nApensar de ser um ambiente 3D, podemos criar um jogo em 2.5D, como o este exemplo de tutorial de jogo de plataforma. Outro ponto forte desta game engine é a utilização de audio e vídeo (vídeo só na versão Pro) nos jogos, da mesma maneira simples e prática que importamos um modelo 3D.\nEstas são algumas das features da Unity:\nEditor integrado: Fácil utilização, pode ser customizado, funciona com drag n’ drop Gráficos: Renderização em tempo real, sistemas de partículas, suporte a DirectX e OpenGL Importação de modelos: Aceita diversos formatos, com suporte a texturas, bones e animações Publicação: Windows, Mac, Web, Wii e iPhone Shaders, Luz e Sombra: Efeitos prontos, elementos naturais, editor de shaders Rede: Suporte a sincronização, acesso remoto e conexão Física: Utiliza a PhysX da Nvidia, e possui recursos específicos, como componente de física para rodas, por exemplo Programação: Suporte a C#, JavaScript e Boo. Pode ser integrado à uma solução do Visual Studio Debug: Todos os parâmetros de qualquer objeto ou modelo podem ser alterados em tempo de execução, além de existir a possibilidade de pausar a execução para verificar parâmetros Existem muitas outras features na Unity, porém estas acima já a torna uma grande game engine, cheia de recursos. Além desta parte técnica, existe algo na Unity que merece muito destaque: sua comunidade. Através do site, podemos entrar em contato direto com os desenvolvedores para dar sugestões e feedback. Existem também foruns diversos e ativos, com pessoas dispostas a te ajudar sempre que for necessário, além de um vasto material que inclui um FAQ, Wiki, dicas, repositório de exemplos e um chat (IRC). Ah, também existe uma revista publicada por eles, a Unity Develop Magazine.\nAlém de tudo isso, ainda podemos contar com um completo suporte, que oferece documentação técnica, manual, referências, exemplos de script, tutoriais, exemplos de projetos, vídeo aulas, artigos, e recursos gratuitos, como plugins desenvolvidos pela comunidade.\nPor enquanto encontrei apenas um livro dedicado a Unity, o Unity Game Development Essentials, do Will Goldstone. Em seu site, existem excelentes vídeo aulas sobre a Unity, e outros softwares. Eu fiz meu tech demo depois de assistir a primeira vídeo aula.\nHoje, grande parte dos jogos feitos com a Unity são para PC e/ou Mac (inclusive um MMO), enquanto jogos para Web enfrentam a barreira do Flash. Mais de 325 jogos foram feitos e publicados para iPhone, porém poucos foram feitos para Wii.\nAo abrir a Unity pela primeira vez, após instalar, ela carrega um projeto demo, que é de uma ilha que utiliza diversos recursos. Este demo é muito legal para estudar, pois possui uma infinidade de pequenos detalhes que mostram o poder da Unity.\nVale muito a pena dar uma olhada no site da Unity, que possui muitas coisas legais para os desenvolvedores. Existem também muitos sites e tutoriais espalhados pela internet, estes são alguns que eu já usei e recomendo:\nLearn Me Silly: http://www.learnmesilly.com/ Learn Unity3D: http://learnunity3d.com/ Unify Community: http://www.unifycommunity.com/ Unity: http://unity3d.com/ Eu comecei a estudar a Unity há pouco tempo, então não fiz muita coisa além de “brincar”. Provavelmente irei utilizar esta game engine no meu TCC da Pós-Graduação, e durante o desenvolvimento irei publicar aqui tutoriais sobre desenvolvimento de jogos com a Unity.\nUPDATE:\nMais um link de tutoriais, Unity3D Student: http://www.unity3dstudent.com/\n","date":"9 de fevereiro de 2010","externalUrl":null,"permalink":"/game-engine-unity/","section":"Blog","summary":"No final do ano passado, duas grandes game engines ganharam versões gratuitas, a Unity e a Unreal Development Kit (UDK). Talvez estas foram as melhores notícias para os desenvolvedores independentes e estudantes no em 2009, pois agora podemos desenvolver jogos utilizando game engines profissionais. Pra mim foi muito bom, pois poderei utilizar uma destas game engines no meu TCC neste ano.\n","title":"Game Engine Unity","type":"posts"},{"content":"O que o jogador quer? Este foi um tema de uma discussão em uma das aulas de Game Design, e rendeu uma boa discussão devido ao ponto de vista dos alunos, do professor e de alguns artigos que haviamos lido. Discutimos, principalmente, três públicos diferentes: jogadores hardcore, pais que jogam com seus filhos pequenos, e ex-jogadores. Cada público possui suas características e necessidades.\nNossa base para discutir sobre pais que jogam com seus filhos veio deste artigo no Gamasutra, What Gamers Want: Family Gamers, onde o autor levantou aspectos que os pais buscam em jogos para jogarem com seus filhos, e também o que estas crianças pequenas gostam em jogos.\nAbaixo estão algumas características que identifiquei neste público:\nNão gostam de tutoriais longos, preferem tutoriais in-game; O andamento do jogo deve ser gravado constantemente, para que não seja necessário jogar muitas vezes a mesma parte; A jogabilidade deve ser bem simples e intuitiva, com controles fáceis; Estes jogos devem ter um modo multi-player, pois os pais gostam de jogar com seus filhos; A linguagem utilizada no jogo deve ser clara e objetiva, para não confundir as crianças; Jogos muito complicados fazem a criança perder o interesse em jogar; Para este público, o preço de um jogo é muito alto, pois existem outras formas de entretenimento que podem ser feitas com o mesmo valor, já que a criança pode perder o interesse logo em um jogo. Outro público abordado na discussão, os ex-jogadores, são geralmente adultos que jogavam, mas que perderam o interesse em passar um tempo jogando, até por que eles podem não ter mais tempo para jogar. Baseamos nossa discussão neste artigo, What Gamers Want: Missing Gamers, também do Gamasutra, e identifiquei as características abaixo:\nAtualmente estes adultos preferem jogos casuais na internet e jogos em redes sociais, apenas para passar o tempo; Dão preferência para jogos de tabuleiro ou de carta, por causa da interação com outras pessoas; Foram jogadores no passado, mas hoje podem ter preconceito de ter um videogame; Sua principal motivação para jogar é desafiar os amigos em mini-games (o Nintendo Wii é o preferido deste público quando escolhem um videogame); Para este público o preço também é alto, pois não irão jogar o tempo todo, apenas quando estiverem reunidos com amigos. Os dois públicos acima fazem parte de um público maior, o de jogadores casuais. Porém, cada um com suas características próprias, e com certeza existem mais segmentações. Mas, existe um público que é único, com diferenças apenas no gênero de jogo preferido, que é o público hardcore.\nEste foi um ponto alto da nossa discussão em sala, pois praticamente todos os alunos são jogadores hardcore. Além disso, utilizamos como base o artigo A Gamer’s Manifesto, um dos melhores artigos sobre gamers que já li! Este é, sem dúvidas, o público mais difícil de agradar, devido a sua exigência. Abaixo estão as características que identifiquei neste público:\nQuerem uma Inteligência Artificial mais realista, que se comporte como um jogador; Gostam de multi-players, mas as vezes parece que deixaram de lado a I.A.; Ficam irritados com imagens utilizadas em propagandas e vídeos que são bem diferentes dos gráficos do jogo; O público feminino hardcore é geralmente esquecido; Eles gostam de jogos difíceis, mas não de jogos impossíveis ou estúpidos; Apesar de serem hardcore gamers, não acham legal ter que jogar 50 horas para conseguir uma feature que está na capa do jogo; Loadings demorados e animações muito longas diminuem o tempo de gameplay, e muitas vezes são desnecessárias (sem falar quando não da pra pular isso!); Imersão e interação com o ambiente são importantes para tornar o jogo realista; Hoje os jogos de console podem ser facilmente atualizados pela internet, porém isto pode tornar o jogador um beta tester, pois se ocorrer algum bug é só lançar uma atualização do jogo; Alguns desafios impostos para o jogador podem não fazer sentido ou serem desnecessários para o andamento do jogo. Com todas estas informações, a discussão que tivemos na aula e minha análise dos artigos, cheguei às seguintes conclusões a respeito do que cada tipo de jogador busca em um jogo:\nJogos para crianças não devem ser apenas “bonitinhos”, devem ter tudo que é necessário para proporcionar uma boa experiência para as crianças e seus pais, que sempre jogam juntos; Quem não joga videogames, ou faz isto poucas vezes, busca jogos simples e divertidos, para interagir com seus amigos; Jogadores hardcore sempre serão exigentes e, algumas vezes, estão certos em suas reclamações, pois alguns desenvolvedores deixam de ser jogadores quando fazem jogos. Compreender cada tipo de jogador e o que ele quer é muito importante para a elaboração do Game Design de um jogo. Entender o seu público alvo é um dos principais fatores para que um jogo seja um sucesso ou um fracasso, e é parte fundamental do processo de produção.\n","date":"24 de janeiro de 2010","externalUrl":null,"permalink":"/o-que-o-jogador-quer/","section":"Blog","summary":"O que o jogador quer? Este foi um tema de uma discussão em uma das aulas de Game Design, e rendeu uma boa discussão devido ao ponto de vista dos alunos, do professor e de alguns artigos que haviamos lido. Discutimos, principalmente, três públicos diferentes: jogadores hardcore, pais que jogam com seus filhos pequenos, e ex-jogadores. Cada público possui suas características e necessidades.\n","title":"O que o jogador quer?","type":"posts"},{"content":"Existem algumas maneiras de se analisar um jogo através de um olhar crítico. Na matéria de Game Design, na pós-graduação, uma das formas que utilizamos para analisar um jogo são as 6 características de jogos identificadas por Jasper Juul, em seu livro Half-Real: Video games between Real Rules and Fictional Worlds. Este livro, assim como o Game Design Workshop, são essenciais para game designers.\nNeste livro, Juul apresenta sua definição sobre o que um jogo é, o que ele deve proporcionar ao jogador, e quais são seus valores e influências:\n“Um jogo é um sistema formal baseado em regras com um resultado variável e quantificável onde diferentes resultados são associados a diferentes valores. Os jogadores depreendem esforços para influenciar o resultado sentindo-se ligados a estes resultados e as consequências desta atividade são opcionais e negociáveis” – Jasper Juul\nNesta descrição estão características básicas que diferenciam o jogo de uma brincadeira, como a regra, que direciona o jogo, dá um objetivo e torna o jogo divertido (ou não). Uma brincadeira não tem regras, ou se têm elas podem variar, diferenciando de um jogo que possui regras definidas. Porém, as regras de um jogo também podem ser alteradas, mas ainda sim possuem um objetivo, diferente de uma simples brincadeira.\nPodemos analisar um jogo completamente seguindo as 6 características de Juul que estão em sua definição: (1) Regras: Jogos são baseados em regras; (2) Resultados variáveis e quantificáveis: Os resultados dos jogos variam e podem ser quantificados; (3) Valorização do Resultado: Aos possíveis resultados de um jogo são atribuídos valores positivos e negativos; (4) Esforço do Jogador: O jogador exerce um esforço com a intenção de alterar o resultado; (5) O jogo é conectado ao resultado: O jogador percebe-se conectado ao resultado fica feliz ao ganhar e triste em perder; (6) Consequencias negociáveis: As consequencias do jogo no mundo real são opcionais.\nComplementar à estas características, podemos analisar também o tipo de **desafio **que um jogo proporciona. Os desafios podem segmentar um jogo em um determinado público alvo, pois desafios muito complexos vão atrair jogadores hardcore, enquanto desafios fáceis são preferidos por jogadores casuais. O game designer deve saber dosar o nível de desafios que o jogador enfrenta, pois isto também reflete em outros fatores como jogabilidade e diversão.\nO que mais um jogo deve ter? Além do que foi definido por Juul e dos desafios, um jogo também possui peças e arenas. O jogador utiliza as peças de um jogo para interagir em sua arena, de acordo com a jogabilidade e o objetivo do jogo.\nUtilizando todas essas características que um jogo deve ter, fiz uma análise do jogo Team Fortress 2, da Valve, e escrevi um artigo sobre isso. Na época que escrevi esse artigo, eu tinha jogado pouco do Team Fortress 2, mas já estava bem impressionado com a qualidade e diversão deste FPS. O arquivo está disponível para download aqui.\n","date":"17 de dezembro de 2009","externalUrl":null,"permalink":"/analise-de-jogos/","section":"Blog","summary":"Existem algumas maneiras de se analisar um jogo através de um olhar crítico. Na matéria de Game Design, na pós-graduação, uma das formas que utilizamos para analisar um jogo são as 6 características de jogos identificadas por Jasper Juul, em seu livro Half-Real: Video games between Real Rules and Fictional Worlds. Este livro, assim como o Game Design Workshop, são essenciais para game designers.\n","title":"Análise de jogos","type":"posts"},{"content":"A usabilidade de um jogo digital é tão importante quanto a interface de um web site ou software, e em alguns aspectos as interfaces são semelhantes. Assim, podemos usar os mesmos métodos de análise de interface e usuabilidade em todos estes produtos citados.\nUma interface fraca e confusa pode fazer um web site perder clientes da mesma forma que, em um jogo digital, o jogador pode desistir de explorar mais o conteúdo e não gostar do jogo. Por mais que o jogo seja inovador e divertido, uma interface ruim e mal desenhada pode estragá-lo.\nA análise de interface de um jogo digital é uma tarefa de game design, refletida no trabalho de programação de interfaces. Podemos utilizar vários métodos de análise de usabilidade, como os conceitos de Jacob Nielsen, que possui uma bibliografia muito boa sobre usabilidade e interface homem-máquina. Seus conceitos podem ser utilizados em qualquer tipo de produto que precise de uma interface com alta usabilidade.\nNeste semestre na pós-graduação tive aula de Projeto de Interfaces, onde estudamos a interação homem-máquina, usabilidade de sistemas e protótipos para validação de inteface. Sem dúvidas a parte mais surpreendente desta matéria foi o protótipo de papel.\nCom pedaços de papel, post-it, canetas e lápis, criamos a interface de um jogo, desde o menu, a configuração, modo de jogo e o jogo em si. Com isto, foi possível testar a interface e alterá-la entre um teste e outro. O resultado foi ótimo, conseguimos deixar a interface do nosso jogo com uma usabilidade muito boa após 3 testes, sendo um deles com dois jogadores simultâneos.\nEste é o conceito do jogo Luta Encarniçada, que criamos para testar a interface:\nEnfrente o exército inimigo comandando seus personagens até derrotar seu oponente em calabouços únicos. Cada mapa pode ser construído e customizado para que cada batalha necessite de estratégias diferentes. Cada guerreiro possui atributos de Ataque, Defesa, Mobilidade e Alcance balanceados, para que a montagem dos exércitos torne o jogo competitivo.\nO teste de interface funciona da seguinte maneira: nossa equipe era compostar por um observador (apenas observa as reações do jogador e faz anotações e verifica o que pode ser melhorado), um “CPU” (altera a interface de acordo com a ação do jogador, imitando o comportamento de uma máquina) e um facilitador (informa ao jogador o que está sendo exibido na tela e espera pela sua reação, não pode induzir o jogador a tomar uma decisão e nem falar o que ele deve fazer). O jogador deve explorar a interface sem “travar”, caso seja muito necessário o facilitador pode dar uma dica, mas isto significa que a interface possui uma falha que deve ser arrumada para o próximo teste.\nO protótipo feito com papel serve apenas para validar a interface e, se o jogo não for complexo, é possível validar um pouco da jogabilidade, que foi o que fizemos também. Esta é a conclusão do relatório da análise de interface que fizemos:\nO método de protótipo de papel é muito útil para avaliar a interface e a jogabilidade em jogos. Dependendo da complexidade do jogo, a jogabilidade fica difícil de ser testada devido à limitação do uso de papel e caneta, mas na validação de interface é perfeita e poupa re-trabalho.\nDe maneira bem rápida e prática podemos alterar a interface e deixá-la pronta para testes sem ter que mexer com imagens ou linhas de código. Este tipo de prototipagem deve ser simples para que funcione corretamente, e é muito importante observar as ações do usuário e não induzí-lo a realizar uma ação que desejamos e consideramos a mais correta.\nEste método de teste de interface é muito rápido, dinâmico e economiza muito tempo de programação e re-trabalho. É muito simples fazer um protótipo de papel – muito mais fácil do que criar uma demo para validar a interface. Acho bem legal também utilizar isto para validar a jogabilidade antes de pensar em programar, se a complexidade do jogo permitir isto.\n","date":"17 de novembro de 2009","externalUrl":null,"permalink":"/interface-de-jogos-com-prototipo-de-papel/","section":"Blog","summary":"A usabilidade de um jogo digital é tão importante quanto a interface de um web site ou software, e em alguns aspectos as interfaces são semelhantes. Assim, podemos usar os mesmos métodos de análise de interface e usuabilidade em todos estes produtos citados.\n","title":"Interface de jogos com protótipo de papel","type":"posts"},{"content":"Ontem foi a final da primeira edição do concurso de jogos digitais organizado pelo SENAC São Paulo, o e-Games. Eu e mais 4 equipes finalistas apresentamos nossos jogos para um banca que os avaliou e decidiram os 3 melhores. Infelizmente não fiquei entre os 3 melhores jogos, fiquei em 5º lugar. No fundo eu esperava isso, já que fiquei bem surpreso por ser um finalista, sendo que fiz o jogo em apenas uma semana. Segundo a organização do evento, pouco mais de 60 equipes se inscreveram para este concurso, e apenas 20 e poucas equipes enviaram tudo que era necessário para participar.\nExistem vários outros concursos como este que pretendo participar, com a Imagine Cup, o XNA Challenge e o Dream Build Play, mas agora vou me dedicar mais. Consegui um desempenho muito bom com um jogo simples e não muito original. Acho que uma desvantagem que tive foi fazer tudo sozinho, enquanto as demais equipes tinham pelo menos um artista. Preciso encontrar algum artista para me ajudar a fazer jogos, já que meu forte é a programação.\nO evento foi bem legal e muito bem organizado pelo SENAC. Todas as equipes deram entrevista para o Programa Novo da TV Cultura, teve um ótimo coffee break, ganhei uma camiseta e um certificado de finalista, e dei bastante risadas com as conversas com os demais finalistas. Embora eu não tenha ganho, valeu muito a pena participar disso tudo, e as equipes vencedoras mereceram o que conquistaram.\n","date":"6 de novembro de 2009","externalUrl":null,"permalink":"/final-do-e-games-2009/","section":"Blog","summary":"Ontem foi a final da primeira edição do concurso de jogos digitais organizado pelo SENAC São Paulo, o e-Games. Eu e mais 4 equipes finalistas apresentamos nossos jogos para um banca que os avaliou e decidiram os 3 melhores. Infelizmente não fiquei entre os 3 melhores jogos, fiquei em 5º lugar. No fundo eu esperava isso, já que fiquei bem surpreso por ser um finalista, sendo que fiz o jogo em apenas uma semana. Segundo a organização do evento, pouco mais de 60 equipes se inscreveram para este concurso, e apenas 20 e poucas equipes enviaram tudo que era necessário para participar.\n","title":"Final do e-games 2009","type":"posts"},{"content":"Hoje fiquei muito feliz com a notícia de que meu jogoSpaceShip 4042 feito com XNA para o concurso e-Games 2009, a primeira competição de jogos digitais do SENAC São Paulo, foi escolhido como um dos finalistas. Fiquei mais feliz ainda em descobrir que os finalistas deste concurso são apenas 5 jogos, entre eles o meu!\nEu não esperava ser um dos finalistas neste concurso, por diversos motivos. Porém, consegui ficar entre os 5 melhores jogos, o que para mim já é uma vitória. Fiz este jogo sozinho, sem conhecer muito bem XNA, em menos de uma semana, virando noites programando, tive diversos problemas, e apesar de tudo isso meu trabalho foi reconhecido e todo este esforço valeu muito a pena.\nO jogo vencedor será anuncia na quinta-feira (05/11) em um evento no SENAC Santo Amaro, no qual eu irie participar apresentando meu jogo para os jurados. Não sei se tenho chances reais de ganhar, não faço a menor idéia do que os demais participantes podem ter feito com mais tempo do que eu, mas vou tentar fazer o máximo e o melhor que eu puder para conseguir uma boa colocação final.\nEste é o primeiro concurso que participo sozinho, e fiquei muito feliz em ver a minha capacidade em criar algo em tão pouco tempo, com todas as dificuldades tecnológicas que tive, e ainda ser reconhecido por isto. Sem dúvidas isto é um grande insentivo para eu continuar a estudar e desenvolver jogos.\nApós a final, irei escrever aqui tudo que aconteceu e qual minha colocação final!\n","date":"30 de outubro de 2009","externalUrl":null,"permalink":"/finalista-no-e-games-2009-com-um-dos-5-melhores-jogos/","section":"Blog","summary":"Hoje fiquei muito feliz com a notícia de que meu jogoSpaceShip 4042 feito com XNA para o concurso e-Games 2009, a primeira competição de jogos digitais do SENAC São Paulo, foi escolhido como um dos finalistas. Fiquei mais feliz ainda em descobrir que os finalistas deste concurso são apenas 5 jogos, entre eles o meu!\n","title":"Finalista no e-games 2009 com um dos 5 melhores jogos!","type":"posts"},{"content":"O SENAC São Paulo organizou sua primeira competição de jogos digitais, o e-Games, onde os concorrentes deveriam criar um jogo utilizando XNA. Além do jogo feito com XNA, foi necessário entregar um vídeo, documento de game design, apresentação, resumo e guia de instalação. O Download do jogo pode ser feito clicando aqui, ele necessita do .Net Framework 3.5 e Microsoft XNA Framework Redistributable 3.1 instalados para rodar, não é necessário instalar o jogo, apenas executar o SpaceShip4042.exe.\nO prazo para entrega foi na última sexta-feira, e eu decidi participar disto uma semana antes e sozinho. Ou seja, tive apenas uma semana para fazer tudo isso, além de ter que trabalhar e ir para a faculdade. Como estava sem tempo, decidi criar uma versão do meu jogo de celular SpaceShip 4042 em XNA, pois já tenho todas as imagens para criar o jogo, além de ter todo o conceito pronto, só foi necessário programar.\nDepois de uma semana dormindo menos de 4 horas por dia, virando noites programando, o resultado não foi exatamente o que eu imaginei, mas consegui terminar meu jogo com tudo que a versão de celular tem, com excessão de som, pois tive dificuldades com isto e estava sem tempo. Além disso, no lugar de um High Score, fiz um Ranking top 5.\nEmbora eu tivesse apenas que programar, tive vários problemas por não conhecer muitas coisas no XNA e não ter tempo suficiente para estudar melhor. O maior problema que tive foi com a detecção de colisão por pixel. No JME existe uma função que verifica a colisião entre dois Sprites, inclusive existe o tipo de dado Sprite. Já no XNA não é tão fácil assim, não existe Sprite e método de detecção de colisão pronto.\nO método de colisão que utilizei consiste em verificar se existe a interseção entre a área da imagem dos dois Sprites que estão colidindo. Uma vez que esta interseção existe, vem a parte mais complicada que é verificar se existe a sobreposição dos pixels que não são transparentes na imagem, utilizando um vetor com a cor da cada pixel da imagem. Não é tão complicado quanto parece, mas é bem chatinho de fazer.\nResolvi o problema do Sprite criando uma classe com os atributos que achei necessários para a fazer a nave, os meteoros, os itens e os tiros. Os principais atributos são: um Vector2D para a posição do objeto, uma lista de Texture2D para guardar todos as imagens que compoem a animação do Sprite, um Rectangle para ser utilizado na detecção da colisão, um vetor de Color com as cores da imagem, um bool para a visibilidade, e inteiros para armazenar vida, frame da animação e movimentação do objeto. Criei métodos para desenhar, mover, esconder, causar dano e verificar se o sprite “morreu”.\nOutro problema que tive, mas que foi simples de resolver, foi a animação, pois o XNA também não possui algo que facilite isto como o incrível arquivo GameDesign do JME. Utilizando um inteiro, controlei a animação do Sprite em cada quadro. Também tive dificuldades com a criação das telas e sua maniulação. Criei uma interface para telas, e todas as telas implementam os métodos default do XNA: Update, Draw e LoadContent, além de um para controlar a inicilização das variáveis. A classe principal do jogo inicia todas as variáveis que representam as telas e tem responsabilidade de controlar a exibição de cada uma, de acordo com o estado do jogo.\nSe eu tivesse tido mais tempo, ou começado bem antes quando fiquei sabendo desde concurso, eu poderia ter feito muitas outras coisas e melhor, mas fiquei satisfeito em fazer um jogo em XNA em tão pouco tempo e sem conhecer tão bem as características desta tecnologia. Fiz muitas coisas básicas para um jogo 2D, e na minha opinião só faltou colocar som no jogo.\nAssim como no JME, que tive dificuldades no começo, tive dificuldades com o XNA também, mas meus próximos jogos 2D nessas plataformas ficarão muito melhores, e provavelmente levarei menos tempo para programar, pois aprendi muitas coisas desenvolvendo para plataformas diferentes com tecnologias distintas. Praticamente tudo que utilizei aprendi fuçando nos exemplos do XNA Creators Club e nas dúvidas no forum, são ótimas fontes de informações.\nMeu próximo passo agora é começar a estudar programação de jogos em 3D com C++. Este estudo é o primeiro passo para o meu TCC ano que vem, que provavelmente será um jogo em 3D com C++. Tenho algumas idéias para o jogo, mas nada decidido ainda, porém preciso aprender este tipo de programação, que eu tive contanto apenas no XNA para movimentação de modelos 3D simples na tela.\n","date":"25 de outubro de 2009","externalUrl":null,"permalink":"/e-games-meu-jogo-com-xna/","section":"Blog","summary":"O SENAC São Paulo organizou sua primeira competição de jogos digitais, o e-Games, onde os concorrentes deveriam criar um jogo utilizando XNA. Além do jogo feito com XNA, foi necessário entregar um vídeo, documento de game design, apresentação, resumo e guia de instalação. O Download do jogo pode ser feito clicando aqui, ele necessita do .Net Framework 3.5 e Microsoft XNA Framework Redistributable 3.1 instalados para rodar, não é necessário instalar o jogo, apenas executar o SpaceShip4042.exe.\n","title":"E-games: meu jogo com XNA","type":"posts"},{"content":"Este é o primeiro jogo que fiz para celulares, e também foi o primeiro projeto que terminei tudo o que eu planejava fazer. Fiz este jogo para a matéria de Jogos para Celular na pós-graduação utilizando Java Mobile (JME com CLDC 1.1/MIDP 2.0) e o Netbeans 6.7.1.\nComo eu conheço Java, não tive problemas com a programação. A principal dificuldade inicial era entender como um jogo funciona em um celular, entender suas limitações e arquitetura. Por ser bem limitado, deve-se ter muita paciência e cuidado na programação para celular, para que o código não exija muito processamento e também para que as imagens fiquem “leves”.\nO Netbeans ajudou muito no desenvolvimento do jogo, pois ele possui um tipo de arquivo chamado GameDesign, onde você importa imagens e cria sprites, cenários e cenas. Eu utilizei apenas para criar sprites do jogo, não precisei utilizar cenários e cenas.\nEste projeto levou cerca de 2 meses para ficar pronto, porém não foram 2 meses de trabalho diário, eu programava um pouco por semana. Tive ajuda do David Felicino com as imagens das naves, tela de abertura, fundo do jogo e itens. Obrigado!\nClique aqui para baixar este jogo!\nO objetivo do jogo é simples: permanecer o maior tempo possível e pontuar destruindo os meteoros ou desviando deles. O jogo acaba quando os 3 pontos de vida da nave chegarem ao fim, devido a colisões com os meteoros. Os meteoros também têm 3 pontos de vida.\nExistem dois itens: um para ganhar 1 ponto de vida e outro para transformar a nave em “nível 2”. Neste nível 2, o jogo dobra a velocidade e os meteoros são destruídos com apenas um tiro. Se for atingido pelo meteoro, neste modo, o jogador não perde vida, apenas o item e volta a ficar com a nave “nível 1”. A velocidade do jogo também dobra se acontecer uma determinada situação.\nA maior pontuação do jogar é sempre armazenada e pode ser vista através do meu “High Score”. Existe também uma opção para ver os controles e os créditos. O menu foi legal de fazer, pois o JME não dá suporte para menus apenas com imagens, então criei o menu com sprites que são trocados ou selecionados através dos botões “para cima” e “para baixo” do celular.\nAlém dos controles tradicionais (direcionais e botão central do celular), existe um suporte a eventos de toque na tela (apenas o jogo, o menu ainda não). O video abaixo é uma demonstração no meu celular, um Samsung Star S5230:\nO jogo também possui uma verificação para **talvez **funcionar em um maior número de celulares sem precisar ser portado. A verificação é a seguinte: se a resolução da largura (width) da tela do jogo for inferior a 240, são desabilitados o som e a imagem de fundo e a imagem de abertura e os meteoros são imagens com um tamanho menor.\nEste vídeo demonstra o jogo no emulador do Netbeans, em uma tela de 240 x 320:\nEste vídeo demonstra o jogo no emulador do Netbeans, em uma tela de 176 x 220:\nNo segundo vídeo é possível ver tudo que foi reduzido da versão normal (primeiro vídeo) . É claro que é ambição demais querer que este jogo realmente funcione em vários celulares diferentes, mas pelo menos tentei fazer com que isto seja possível de alguma forma.\nEste jogo funcionou nos seguintes celulares: Samsung Star S5230, Motorola A1200, Motorola V9, Sony Ericsson W380 (reduzido) e Sony Ericsson K550i (reduzido). Não consegui instalar no Motorola V3, ocorre um erro após transferir por bluetooth.\nExistem alguns bugs que estou corrigindo e muitas coisas para polir, mas o jogo já está em sua primeira versão jogável. O principal problema é que, as vezes, ao entrar no jogo pela primeira vez em celulares mais simples, aparece uma tela branca. Neste caso basta voltar para o menu e entrar novamente, porém isto não ocorre sempre. Estou trabalhando nesta e em outras coisas para deixar este jogo o mais perfeito possível.\nDesenvolver este jogo foi muito interessante, pois aprendi bastante sobre a arquitetura de um celular, programação com JME, algumas técnicas para diminuir o consumo do processamento, aplicação de design patterns no Java, gravar e ler informações no celular, e, principalmente, alguns dos vários problemas que podem acontecer ao testar o jogo fora do simulador.\nEspero que gostem do jogo, este é o primeiro de muitos que pretendo fazer! Comentários são bem-vindos, principalmente se forem sobre bugs! Até mais!\n","date":"13 de outubro de 2009","externalUrl":null,"permalink":"/spaceship-4042-meu-primeiro-jogo-para-celular/","section":"Blog","summary":"Este é o primeiro jogo que fiz para celulares, e também foi o primeiro projeto que terminei tudo o que eu planejava fazer. Fiz este jogo para a matéria de Jogos para Celular na pós-graduação utilizando Java Mobile (JME com CLDC 1.1/MIDP 2.0) e o Netbeans 6.7.1.\n","title":"SpaceShip 4042 - meu primeiro jogo para celular!","type":"posts"},{"content":"Eu pensava que animar um objeto 3D era tão complicado quando modelar, mas fiquei surpreso ao descobrir que o processo de animação no Softimage XSI é muito parecido com o do Adobe Flash. Embora sejam softwares diferentes, com finalidades distintas, a idéia básica de animar por Frames está presente em ambos.\nExistem dois tipos de animações: para Jogos e para Filmes. Quanto mais interatividade houver com o usuário, a animação tenderá para o lado do jogo, caso contrário a animação será um Filme. A interatividade pode variar muito de intensidade, dando ao usuário controle total, parcial ou nenhum.\nEste semestre tive a matéria de animação 3D, onde utilizei o XSI para aplicar as técnicas aprendidas. Embora tenham sido poucas aulas, aprendi várias técnicas e conceitos, que devem ser básicos, além de mudar minha visão de animação; agora sou mais critico.\nEu exportei todas as coisas toscas animações que fiz em vídeo, utilizando o Start Capture da câmera do view port 3D. As animações não estão perfeitas, algumas tentei melhorar mas acabei piorando, mas dá para ter uma noção das técnicas utilizadas em cada aula.\nAula 01: Cubo animado e com alteração da cor durante a animação.\nAula 01: Movimento de subir escada utilizando Pose to Pose, ou seja, cada movimento foi animado em um quadro. O “personagem” foi modelado com figuras geométricas.\nAula 02: Bola pingando utilizando Bouncing Balls. Existe uma tentativa de gravidade em cada pingo da bola.\nAula 03: Isto era para ser um sapo olhando uma mosca, utilizando Constraints para o caminho que a mosca deve percorrer e para que os olhos do “sapo” sigam a mosca.\nAula 04: O modelo do bipede foi fornecido pelo professor, apenas a animação foi feita. Este modelo possui Bones para animar cada parte e deixá-lo mais orgânico.\nAula 05: O modelo fo personagem foi fornecido pelo professor e também possui Bones para a animação. Utilizei a técnica de Walk Cycle para não precisar animar todos os quadros, apenas 3 foram animados, e o resto é repetição pelo número de frames desejado.\nAula 06: Utilizando a animação anterior, fiz alterações para fazer este personagem subir uma escada, bem parecido com a animação da primeira aula, porém está foi com um personagem com Bones e utilizando Walk Cycle para não fazer animação Pose to Pose.\nEstas animações não ficaram perfeitas, e nem eram para ficar. Aprendi as técnicas mencionadas e alguns truques novos no XSI que eu não conhecia. Mesmo não sendo artista ou animador, sei que estas aulas vão ser muito úteis para programação 3D, como foi a aula de modelagem 3D. Todas estas técnicas estão no livro The Animator’s Survival Kit do Richard Williams, comentado por mim neste post.\nAssim como modelagem 3D, a animação exige paciência e um pouco de perfeccionismo. Além de conhecer as técnicas e como aplicá-las nos softwares 3D, também é necessário ser observador para traduzir um movimento orgânico em digital. Como meu professor disse, vale até pedir para alguém ficar andando ou pulando para entender o movimento que o corpo faz e saber como reproduzi-lo em uma animação.\n","date":"6 de outubro de 2009","externalUrl":null,"permalink":"/animacao-3d-com-softimage-xsi/","section":"Blog","summary":"Eu pensava que animar um objeto 3D era tão complicado quando modelar, mas fiquei surpreso ao descobrir que o processo de animação no Softimage XSI é muito parecido com o do Adobe Flash. Embora sejam softwares diferentes, com finalidades distintas, a idéia básica de animar por Frames está presente em ambos.\n","title":"Animação 3D com softimage XSI","type":"posts"},{"content":"Programar um jogo 2D não é algo muito complexo, pois trabalhar com objetos em duas dimensões não exige muitos cálculos. Claro que existem exceções, mas, na maioria dos casos, a programação em um ambiente 2D é bem simples de fazer.\nProgramar um jogo 3D é um pouco mais complicado. Orientar um objeto em três dimensões não é simples de fazer, principalmente se for um objeto mais elaborado (diferente de um simples cubo, por exemplo). Este tipo de programação exige uma boa noção do que é trabalhar com três dimensões. É a mesma sensação que tive ao mexer pela primeira vez com um software de modelagem 3D; sua percepção tem que se adaptar ao ambiente 3D.\nNo semestre passado tive a matéria de programação 3D na pós-graduação. Por ter sido curta, não vi muitas coisas com a profundidade que gostaria, mas pelo menos a base eu tive. Nas aulas, utilizamos C++ com o Visual Studio 2005 e o DirectX SDK, que contém a biblioteca Direct3D para programação 3D.\nAntes de começar a programar em 3D, é necessário entender como isto funciona. Todo o processo que gera um objeto em 3D na tela passa por uma Pipeline Gráfica no hardware. Cada estapa é responsável por uma propriedade que foi programada, como Iluminação, Textura, Projeção, Transformações, entre outros.\nNa primeira aula, fiz um programar para desenhar 3 vetores, um em cada eixo (x, y e z), utilizando um array de vetores e a função DrawPrimitiveUP() para desenhar na tela. Também desenhamos um grid e os eixos. Esta foi a parte simples de fazer; a parte mais complicada é configurar o programa para funcionar, é um pouco trabalhoso, mas depois que a base está criada, podemos utilizá-la em vários outros projetos praticamente sem alterações, como foi o caso dos demais exercícios.\nDepois, brincamos um pouco com a Pipeline Gráfica desenhando figuras geométricas coloridas e realizado translações. É o mesmo processo utilizado para desenhar os vetores, além doD3DXMatrixTranslation() para as translações.\nUtilizamos um modelo 3D de um golfinho, fornecido pelo professor, para aprender como exibir um modelo 3D simples na tela. O modelo foi exportando na extensão .X, que é do DirectX, e desenhando na dela utilizando a função D3DXLoadMeshFromX(). Além deste função, existe uma configuração de *Material *para que o objeto (Mesh) possa ser desenhado na tela com a função DrawSubset() do mesh.\nAlém de modelos 3D, também utilizamos arquivos externos para Shaders. São arquivos .FX que contém efeitos que são aplicados em um objeto. A vantagem de utilizar este arquivo é que a configuração fica separada do código, e pode ser editada em softwares de criação de efeitos. O arquivo é carregado utilizando a função D3DXCreateEffectFromFile() e o efeito desejado é aplicado com a função SetTechnique() de uma variável do tipo LPD3DXEFFECT. Nesta mesma variável, a textura é aplicada com a função SetTexture().\nNo final desta matéria, tivemos que apresentar um projeto com um objeto 3D animado e um controlado pelo teclado. Não era obrigatório utilizar o Direct3D com C++ para isto, então utilizei XNA 3.1. Fiz um cubo com textura de dado, onde sua rotação é controlada pelo teclado, e uma esféra com shaders que fica girando em torno do dado.\nEu tive muita dificuldade em capturar eventos do teclado utilizando o Direct3D com C++, por isso resolvi utilizar o XNA. Com XNA eu já tinha feito algumas brincadeiras, porém apenas com 2D. Este projeto foi uma oportunidade para começar a programar em ambiente 3D no XNA, utilizando modelos exportados pelo Softimage XSI em extensão .X e a textura em um arquivo .webp.\nAlias, o dado que utilizei é exatamente o mesmo que modelei e apliquei textura na aula de modelagem 3D que tive no início do curso. Esta foi a melhor parte deste projeto, pois consegui exportar um modelo 3D que tinha feito no XSI (com textura feita no Photoshop) e utilizá-lo no XNA sem muitos problemas. A imagem da esfera também foi modelada no XSI com efeitos de shader, e utilizada no XNA.\nA maior dificuldade que tive foi exibir os dois modelos na tela no tamanho correto, pois cada um tinha um tamanho diferente e para corrigir isto alterei o zoom pela programação, além de fazer suas animações nos 3 eixos. Trabalhar com modelos 3D no XNA é muito fácil, pois ele tem um tipo de variável que é perfeita para isto, a Model. Para desenhar na tela, criamos um objeto ModelMesh e podemos aplicar efeitos de shader com BasicEffect no mesh.\nConhecendo a teoria, tendo uma noção de modelagem 3D e programação no XNA com C#, não é muito difícil de programar 3D, é necessário apenas muita paciência para deixar tudo certo. Ainda não fiz um jogo em 3D, apenas essas brincadeiras, mas pretendo logo criar algo bem simples para aprender mais sobre isso. A programação 3D é bem complexa, mas pelo menos no XNA isso fica mais simples. Acho que não tive uma boa experiência com Direct3D e C++, mas este é mais motivo para continuar aprendendo C++.\nPara os iniciantes em programação 3D, como eu, recomendo aprender as técnicas e aplicá-las no XNA, que é mais simples, e depois partir para o C++. E, embora eu seja programador, as aulas de modelagem 3D ajudaram muito! Por isso é sempre bom ter uma noção, pelo menos básica, de tudo que envolve o desenvolvimento de um game.\n","date":"2 de outubro de 2009","externalUrl":null,"permalink":"/programacao-de-jogos-3d/","section":"Blog","summary":"Programar um jogo 2D não é algo muito complexo, pois trabalhar com objetos em duas dimensões não exige muitos cálculos. Claro que existem exceções, mas, na maioria dos casos, a programação em um ambiente 2D é bem simples de fazer.\n","title":"Programação de jogos 3D","type":"posts"},{"content":"Há pouco tempo comecei a pesquisar e estudar o desenvolvimento de jogos para o Nintendo DS. Poucos estúdios de games têm a licença e o kit oficial para desenvolver jogos comerciais para o Nintendo DS, mas existe uma outra maneira para desenvolver jogos não comerciais, apenas para estudo, também conhecido como homebrew.\nA maneira que encontrei foi usar a biblioteca libnds e o compilador devkitARM, disponíveis no devkitPro, que foram desenvolvidos por uma comunidade dedicada ao desenvolvimento de homebrews para DS e algumas outras plataformas. Com esta ferramenta podemos desenvolver homebrews e rodar no próprio Nintendo DS (com R4 ou equivalente) ou em um emulador no PC.\nAntes de sair programando, é necessário entender algumas particularidades do Nintendo DS. Assim como um celular, o Nintendo DS possui um hardware limitado, porém muito poderoso e com uma arquitetura incrível, além de muitos recursos para criar diferentes tipos de gameplay. O diagrama abaixo parece complexo, mas não é muito. Entendendo como este hardware funciona, dúvidas e problemas podem ser resolvidos simplesmente olhando para o diagrama, como estouro de memória gráfica, por exemplo.\nA linguagem de programação utilizada é C/C++. Ao baixar e instalar o devkitPro, ele também irá instalar uma IDE para programação, o Programmer’s Notepad, que é praticamente um bloco de notas colorido que compila. Nada contra desenvolver utilizando este software, mas eu prefiro utilizar o Microsoft Visual Studio 2005/2008.\nNeste tutorial é demonstrado como configurar um projeto no Visual Studio 2005 e utilizar o compilador devkitARM – também funciona no Visual Studio 2008. Para completar o ambiente de desenvolvimento, você irá precisar de um emulador de Nintendo DS, pois a configuração deste tutorial permite que ao executar um programa no Visual Studio (F5), além de gerar um arquivo .NDS, este arquivo é carregado em um emulador para testar, incrível não?\nConfiguração do meu ambiente de desenvolvimento:\n– OS: Windows XP SP3\n– IDE: Visual Studio 2005/2008\n– Compilador: devkitARM\n– Biblioteca: libnds\n– Emulador: DeSmuMe\nPara testar no meu Nintendo DS estou usando o R4. Você só precisa compilar o programa para gerar o .NDS e colocar na micro SD do R4 para funcionar no Nintendo DS. É tão simples quando utilizar um emulador.\nÉ sempre bom testar no emulador e no Nintendo DS, pois a emulação do Nintendo DS no computador não é real. Como o emulador esta rodando em cima de uma arquitetura diferente da real, os limites do hardware do Nintendo DS geralmente não são levados em conta.\nA libnds possui muitas funções para interagir com o hardware do DS, e todas estão muito bem explicadas e com exemplos neste link. Após configurar meu ambiente de desenvolvimento, estudei os exemplos deste link e li os tutoriais abaixo, antes de começar a brincar:\nhttp://patater.com/files/projects/manual/manual.html\nhttp://ndsbr.blogspot.com\nhttp://www.double.co.nz/nintendo_ds\nPara começar a brincadeira, fiz uma programa onde na tela superior do DS aparece um texto e na inferior (touch) existe um quadrado que pode ser controlado com os direcionais ou arrastado utilizando touch. Não é nada muito complexo, estudando os links acima é possível fazer muitas coisas legais, inclusive algum jogo curto ou demo.\nClique aqui para baixar o .NDS do meu “Hello World”.\nNo momento estou estudando JME por causa de uma matéria na pós-graduação de Jogos para Celular, e preciso terminar um jogo (que irei postar aqui logo). Quando terminar este projeto pretendo me dedicar um pouco mais à “brincar” com o Nintendo DS. Qualquer dúvida sobre a configuração do ambiente ou sobre a programação para o Nintendo DS é só postar que eu tentarei ajudar!\n","date":"2 de setembro de 2009","externalUrl":null,"permalink":"/hello-world-no-nintendo-ds/","section":"Blog","summary":"Há pouco tempo comecei a pesquisar e estudar o desenvolvimento de jogos para o Nintendo DS. Poucos estúdios de games têm a licença e o kit oficial para desenvolver jogos comerciais para o Nintendo DS, mas existe uma outra maneira para desenvolver jogos não comerciais, apenas para estudo, também conhecido como homebrew.\n","title":"Hello World no Nintendo DS","type":"posts"},{"content":"Em outros países, existem diversos cursos para todas as áreas do desenvolvimento de jogos, inclusive universidades com cursos expecializados nisso, como a DigiPen. Aqui, temos poucos cursos voltados para o desenvolvimento de games, como a pós-graduação que estou cursando no SENAC.\nSe não existem tantos cursos assim no Brasil, como começar a estudar desenvolvimento de games? Existem diversos fóruns sobre o assunto na internet, alguns brasileiros, mas, na maioria das vezes, o fórum serve para tirar dúvidas, buscar ajuda quando você travar em um problema específico, dificilmente você aprenderá do zero os conceitos e técnicas para desenvolver um jogo.\nQual a melhor maneira neste caso? Os diversos livros de desenvolvimento de jogos que existem! Só existe um problema com estes livros: os melhores são em inglês. Se bem que isto não é um problema, já que nesta área temos que ter a lingua inglesa mais incorporada do que o português.\nVou comentar sobre livros que eu tenho, e depois alguns que eu acho interessante mas não comprei ainda.\nUm dos melhores e mais claros livros que eu já li sobre o assunto é um dos raros brasileiros. O livro Desenvolvimento de Jogos Eletrônicos, da Novatec, é muito bom para iniciantes. Muitas coisas que eu li no livro eu vi e estou vendo na pós-graduação. A melhor parte do livro é a primeira, pois fala muita coisa de teoria, realmente muito bom e recomendado para quem quer começar com programação de jogos, explica vários conceitos e técnicas básicas. As outras duas partes do livro são boas também, é a parte mais prática do livro, utilizando C++, porém com uma engine desenvolvida pelos autores, que pode ser baixada no site da Novatec.\nUm amigo, formado em Design de Games, me recomendou um livro de Game Design uma vez, pouco antes de começar a pós-graduação. Comprei o livro e fiquei impressionado com qualidade dele. O livro Game Design Workshop, de Tracy Fullerton, fala de muitas coisas que envolvem o desenvolvimento de um game além da parte técnica (programação e arte). Existem apenas versões em inglês, e pra mim é uma leitura obrigatória para desenvolvedores de jogos. O livro conta com muitos, muitos exercícios práticos que ensinam conceitos e técnicas para criar jogos, jogabilidades, testar, além de ter partes sobre produção de jogos.\nAlém destes livros, comprei alguns que não são da área de games, mas são de programação, e são muito bons para programar jogos também, como C++ Primer Plus, Jamsa’s C/C++/C# Programmer’s Bible e Beginning J2ME: From Novice to Professional. Também comprei um de programação de jogos em Java, quando comecei a aprender Java na graduação. É um livro muito bom, mas é voltado para** jogos de PC em Java**, que não é algo muito utilizado hoje em dia (já foi utilizado algum dia?).\nAgora vou falar de alguns livros que eu recomendo, que serão minhas próximas aquisições. Outro livro obrigatório para desenvolvedores de jogos, principalmente para Game Designers, é o Rules of Play: Game Design Fundamentals do Eric Zimmerman. Recentemente ele lançou outro livro, que complementa este, e um professor me disse que é tão bom quanto o primeiro, que é The Game Design Reader: A Rules of Play Anthology.\nExiste outro livro de programação de jogos em português que também é bom, mas não fala tanto de conceitos como o primeiro que mencionei. Programação de Jogos com C++ e DirectX da Novatec, como o nome já diz, ensina a programar jogos com C++, começando por jogos 2D até jogos 3D com DirectX, é bom para quem quer programar, mas ainda acho que a primeira opção tem muitos mais fundamentos importantes. Este livro aqui é praticamente um complemento para o anterior.\nExistem diversos livros de programação de jogos, bem técnicos, do Jonathan S. Harbour, que também são bons para ensinar a programar, principalmente em C++. Como falei de muitos livros de programação e alguns de design, não posso deixar de lado pelo menos um livro de animação que conheço. O livro The Animator’s Survival Kit não vai te ensinar a fazer modelos 3D em um programa específico, mas contém muitas técnicas de animação. O meu professor de Animação 3D está utilizando os conceitos deste livro nesta matéria.\nPra quem gosta de Engenharia de Software (como eu) e fica imaginando como isso pode ser aplicado ao desenvolvimento de jogos, existe um livro muito bom sobre o assunto. Software Engineering for Game Developers contém muitas técnicas utilizadas em sistemas e como aplicá-las em jogos.\nEstes livros são muitos bons, a maioria foi indicada para mim por professores da pós-graduação. Muitos links são da Amazon, que envia para o Brasil apenas Livros, CDs, e DVDs. Já comprei alguns livros neste site, inclusive livros usados por um preço muito baixo (o de J2ME comprei por $1,00 + frete), e também é mais barato importar do que comprar nas lojas por aqui, que são muito mais caros. O único problema é que demora um pouco para chegar, os usados demoram ainda mais, mas chegam!\nVocê já leu algum livro de desenvolvimento de jogos? Comente sobre eles! Até mais!\n","date":"21 de agosto de 2009","externalUrl":null,"permalink":"/livros-de-desenvolvimento-de-jogos/","section":"Blog","summary":"Em outros países, existem diversos cursos para todas as áreas do desenvolvimento de jogos, inclusive universidades com cursos expecializados nisso, como a DigiPen. Aqui, temos poucos cursos voltados para o desenvolvimento de games, como a pós-graduação que estou cursando no SENAC.\n","title":"Livros de desenvolvimento de jogos","type":"posts"},{"content":"Hoje assisti uma palestra na Alpha Channel sobre Web Games, que me incentivou a escrever este post, e também me lembrou de um web game em flash que fiz em 2005, seguindo um tutorial que achei no Google. Foi o primeiro jogo que fiz, quando estava aprendendo Flash no meu primeiro estágio de web designer.\nWeb games são jogos de desenvolvimento curto, geralmente simples e casuais, e que podem ensinar muitas coisas sobre o desenvolvimento de um jogo. Uma das principais vantagens de desenvolver este tipo de jogo é a possibilidade de fazer um bom jogo sozinho, além do Flash ser uma ferramenta poderosa e não muito complicada de mexer, bem mais simples de se familiarizar do que começar a desenvolver em C++, por exemplo.\nComo já escrevi neste post, o Flash é uma opção para começar a estudar o desenvolvimento de games, talvez a mais simples para quem não conheça muita coisa de programação. Este tipo de jogo, mesmo sendo simples e, muitas vezes, cópia de algum outro jogo existente, pode ajudar muito a formar um portifólio.\nAs empresas brasileiras que desenvolvem este tipo de jogo vendem isto como uma opção de solução de publicidade e marketing, também conhecido como Advert games. Esta deve ser a melhor forma de gerar lucro, pois jogos puramente de entretenimento não dão retorno financeiro, embora possa ser explorada a venda de publicidade no site em que o jogo está hospedado, tudo depende do modelo de negócio da empresa ou do desenvolvedor.\nEspero que gostem do jogo que fiz, comentários serão muito bem vindos!\n","date":"30 de julho de 2009","externalUrl":null,"permalink":"/flash-web-games/","section":"Blog","summary":"Hoje assisti uma palestra na Alpha Channel sobre Web Games, que me incentivou a escrever este post, e também me lembrou de um web game em flash que fiz em 2005, seguindo um tutorial que achei no Google. Foi o primeiro jogo que fiz, quando estava aprendendo Flash no meu primeiro estágio de web designer.\n","title":"Flash web games","type":"posts"},{"content":"Como havia comentado em outro post, vou falar sobre a matéria de Técnicas de Programação de Games que tive na pós, onde o foco era apresentar as principais técnicas de programação, muitas aplicáveis não somente a games, e fazer um primeiro contato com uma biblioteca específica para games, que neste caso foi a SDL.\nPara programar os exercícios, utilizamos o Visual Studio 2005 e a linguagem de programação C++. Ao final desta matéria, tivemos que entregar um game, ou pelo menos uma demo de um game, utilizando os conceitos que foram apresentados nas aulas.\nNeste post quero falar um pouco sobre o que vi, sem me aprofundar, e falar sobre o projeto de game que desenvolvi junto com meu grupo. Vou citar alguns dos conceitos, em outro post eu irei tratar mais a fundo estes conceitos e como aplicá-los em programação de games.\nTópicos que foram abordados nas aulas:\n– Conceitos gerais de programação com C++\n– Estruturas de Dados\n– Documentação com UML\n– Metodologia de Desenvolvimento Ágil XP (eXtreme Programming)\n– A biblioteca SDL\n– Técnica de Main Loop (parte do código onde o game é controlado)\n– Técnicas de Detecção de Colisão\n– Arquitetura de Software para Games\n– Máquina de Estados para Games\n– DirectX (overview)\n– Padrões de Projetos para Games (Design Patterns)\n– Conceitos de Otimização de código\nApesar de tudo ter sido apresentado sem muita profundidade, aprendi muitas coisas que não conhecia e que realmente fazem diferença na hora de programar. Foi praticamente o meu primeiro contato com C++, que não foi um “Hello World”.\nVamos ao projeto agora. O nome do jogo foi definido como “Don’t Panic!”, e o objetivo e as características do game deixa claro o por que do nome:\n– Jogo de estratégia casual 2D\n– Jogador controla um personagem, fazendo-o escapar das rochas que caem aleatóriamente da parte superior da tela\n– O objetivo é resistir pelo maior tempo possível sem ser atingido por uma rocha\n– As rochas que caem no chão podem ser empurradas, se não estiverem obstruídas por outras rochas nas laterais e em cima\n– Se as rochas formarem uma fileira horizontal completa, esta fileira desaparece dando mais espaço ao jogador e pontos\n– Se uma fileira de rochas não ficar completa, mais rochas irão cair em cima de outras rochas até o jogador não conseguir escapar\n– A pontuação é baseada no tempo em que o jogador resistir, mais um bônus recebido por cada fileira completa que desaparecer\nImagens do desenvolvimento do game, do início ao fim:\nNão conseguimos implementar tudo que queríamos. Criamos um demo, mas sem algumas coisas como pontuação e fazer o personagem pular e ficar em cima dos blocos. Algumas dificuldades que tivemos no desenvolvimento deste game:\n– Entender conceitos de movimentação do personagem\n– Controlar vários objetos ao mesmo tempo na tela\n– Verificar a colisão de cada objeto com os demais e o jogador\n– Dificuldades gerais com C++\n– Desenvolver arte para o jogo (por isso colocamos o personagem de Alex Kid)\n– Incluir música e efeitos sonoros no jogo\nEspero um dia terminar este game. Estou pensando em adaptá-lo para o DS, já que estou estudando desenvolvimento para esta plataforma (preciso escrever sobre isso também!).\n","date":"18 de junho de 2009","externalUrl":null,"permalink":"/primeiro-projeto-de-game-com-sdl-e-c/","section":"Blog","summary":"Como havia comentado em outro post, vou falar sobre a matéria de Técnicas de Programação de Games que tive na pós, onde o foco era apresentar as principais técnicas de programação, muitas aplicáveis não somente a games, e fazer um primeiro contato com uma biblioteca específica para games, que neste caso foi a SDL.\n","title":"Primeiro projeto de game com SDL e C++","type":"posts"},{"content":"Já me questionei muito isso, pensando em como poderia começar uma carreira de desenvolvedor de games, mesmo que seja indie. Encontrei algumas respostas e muitas dúvidas, que foram exclarecidas pela minha professora de Produção de Games da pós-graduação. Depois de pensar sobre todas as informações que tinha, e levando em conta a indústria de games no Brasil, encontrei três perfis distintos de programadores de games iniciantes, e também indie:\nJogos para Web: Provavelmente é o tipo de desenvolvimento de games que pode alcançar um grande número de pessoas muito rápido, já que basta acessar um site com o jogo para jogar. O Flash, aliado ao Action Script, fornece ao desenvolvedor um poderosa ferramenta para criar jogos muito criativos e viciantes para o ambiente Web. Acho que o principal porém do Flash é que se o jogo for muito elaborado e pesado para ser jogado no navegador, provavelmente não será tão jogado quanto um minigame mais simples. Muitos programadores web, e web designers que tenham afinidade com programação, podem optar por este caminho para começar a estudar o desenvolvimento de games, devido a sua facilidade.\nJogos para Celular: Aqui começa a complicar um pouco, pois é uma técnologia mais complexas e requer mais empenho do programador, sem falar que um jogo feito para um determinado celular pode não funcionar adequadamente em outro – necessita ser portado. A principal linguagem utilizada para este desenvolvimento é o J2ME (Java 2 Mobile Edition), e pode ser usada com softwares como Eclipse e Netbeans, entre outros. Muitas empresas no Brasil trabalham com desenvolvimento de jogos para celular ou porting. São jogos de desenvolvimento rápido e que geram renda para a empresa, porém existem limites nestes jogos, pois o processamento da maioria dos celulares é fraco, o que pode comprometer jogos mais ambiciosos e favorecer, novamente, minigames mais simples. Existe também o desenvolvimento de jogos para iPhone e iPod, que utilizam um software gratuito da Apple, porém que só roda em Mac, que torna este tipo de desenvolvimento bem restrito.\nOutros jogos: Uma pequena parte da indústria de games no Brasil está criando games que não são para Web ou para celular, são jogos para plataformas como Nintendo DS, PC e XBLA (Xbox Live Arcade). O desenvolvimento para estas plataformas são mais complexos e exigem mais dedicação, mas são experiências muito boas para conhecer muitas técnicas de programação de games avançadas, além de praticamente não ter limites para o que vocês quiser criar. Para PC, podemos criar games utilizando praticamente qualquer linguagem, mas as principais bibliotecas para o desenvolvimento de games são em C++ e Java. Para Nintendo DS, podemos criar Homebrew games com o devkitPro, que é um software para programar em C++ e gerar arquivos .nds para serem executados em emuladores de Nintendo DS, que torna o desenvolvimento muito legal pois você consegue ver como o seu jogo funciona em um DS emulado. Para a XBLA, podemos criar games utilizando o XNA Game Studio junto com Visual Studio C#, que é gratuito, você só precisa pagar se quiser ter uma conta premium para disponibilizar seus jogos na rede da Microsoft.\nEu, particularmente, estou optando por estudar o desenvolvimento de Homebrew para o Nintendo DS, pois quero estudar C++. Poderia até escolher o XNA, pois trabalho com C# a mais de 3 anos, ou desenvolver para celular já que tive Java nos 4 anos da faculdade, mas exatamente por isso escolhi começar estudar o desenvolvimento de jogos para DS, eu quero e preciso aprender melhor C++ e, por enquanto, estou apenas estudando C++ em jogos para PC na pós-graduação.\nE com tudo isso, acabei esbarrando em uma dificuldade que deve ser a principal que irei enfrentar: não sou artista, sou programador! Ou seja, mesmo que eu faço algum jogo divertido, não vai ficar muito bonito, preciso encontrar algum artista que goste de pixel art para fazer jogos comigo, já que quero começar fazendo games 2D. Minha meta é montar um portifólio com demos de games diferentes em algumas plataformas, como as que citei acima.\nNo próximo post irei falar sobre o primeiro game em C++ com a biblioteca SDL que desenvolvi com meu grupo na pós-graduação e mostrar o game, até mais!\n","date":"27 de maio de 2009","externalUrl":null,"permalink":"/programador-de-games-por-onde-comecar/","section":"Blog","summary":"Já me questionei muito isso, pensando em como poderia começar uma carreira de desenvolvedor de games, mesmo que seja indie. Encontrei algumas respostas e muitas dúvidas, que foram exclarecidas pela minha professora de Produção de Games da pós-graduação. Depois de pensar sobre todas as informações que tinha, e levando em conta a indústria de games no Brasil, encontrei três perfis distintos de programadores de games iniciantes, e também indie:\n","title":"Programador de games: por onde começar?","type":"posts"},{"content":"Geralmente, um programador tem dificuldades quando precisa fazer algum tipo de design, e vice-versa, principalmente na área de games onde um programador de games é muito mais que um programador web, e um artista é muito mais que um web designer, por exemplo. Eu sou programador, mas meus primeiros estágios foram em web design, então pelo menos sei que #FFFFFF é branco (rs), mas fazer algo como modelagem 3D é bem mais complicado.\nNa pós-graduação, tive aula de Modelagem 3D. No começo foi muito complicado me ambientar em um software de modelagem 3D, parece confuso, mas depois de mexer um pouco é fácil de se acostumar. O software que useri foi o Softimage XSI 6.5, no site da Softimage existe uma versão free deste software, o Softimage XSI Mod Tool 6.0, porém os dois não trabalham com o mesmo tipo de arquivo (o que foi um grande problema pra mim), ou seja, arquivos feitos em um não podem ser utilizados no outro.\nNão mexi ainda em outros softwares 3D como Blender, Maya e Studio Max, mas posso dizer que o XSI é bem simples de usar depois que você se acostuma com ele, até mesmo para quem nunca mexeu com isso. No site da Softimage é possível ver alguns jogos que foram feitos com XSI, entre eles Metal Gear Solid 4, Devil My Cry 4 e Ninja Gaiden 2.\nAprendi três técnicas para modelagem 3D: Primitivas Geométricas, Linhas (Extrusão e Revolução) e Livre (Poly By Poly e Box Modeling). Abaixo estão algumas modelagens que fiz no curso (as menos piores) utilizando as técnicas acima. Além da dificuldade em me acostumar com o ambiente, o que achei mais complicado foi abrir a malha (também conhecido como Mapeamento, consiste em desdobrar o modelo em um plano) e aplicar a textura, que é como montar um quebra-cabeça.\nDescrição (simplificada) das técnicas mencionadas acima:\nPrimitiva Geométrica: O modelo é montado utilizando figuras geométricas “encaixadas”. Na primeira imagem, do Boneco de Neve, utilizei várias esferas para formar o modelo.\nRevolução: Quando não há uma primitiva geométrica na forma que queremos, podemos desenhá-la com Revolução. Criamos uma linha com a forma que desejamos e, quando aplicamos a Revolução na linha, ela é duplicada diversas vezes em curva para dentro. Por exemplo, na segunda image, do Toad, fiz uma linha para o corpo do personagem, e utilizei revolução para criar o corpo. A Revolução pode ser utilizada em outros casos também, além deste.\nExtrusão: Criamos uma nova forma a partir da extrusão de uma face de um objeto. É como se a face fosse puxada para fora, duplicando-a.\nAbertura de malha: Abrimos o objeto criado como se fosse uma dobradura, esticamos suas faces em um plano. Isto é feito para aplicar a textura, e é uma das partes mais complicadas de fazer, dependendo da complexidade do modelo.\nTextura: Com a malha aberta, montamos o quebra-cabeça, encaixando cada parte da textura na face correspondente. É tão complicado quanto abrir a malha.\nAlém das técnicas acima, para a modelagem de personagens existem duas metodologias: Rotoscopia (utilizar uma imagem como base e modelar em cima) e Edge-Loop (criar linhas nas faces para mudar sua forma, muito utilizado para detalhes). As definições acima são minhas interpretações do que vi nas aulas, talvez não sejam academicamente corretas, mas espero que dê para ententer, qualquer coisa é só postar a dúvida.\nNo próximo post irei escrever sobre as aulas de Técnicas de Programação de Games.\nAté mais!\n","date":"29 de abril de 2009","externalUrl":null,"permalink":"/modelagem-3d-com-softimage-xsi/","section":"Blog","summary":"Geralmente, um programador tem dificuldades quando precisa fazer algum tipo de design, e vice-versa, principalmente na área de games onde um programador de games é muito mais que um programador web, e um artista é muito mais que um web designer, por exemplo. Eu sou programador, mas meus primeiros estágios foram em web design, então pelo menos sei que #FFFFFF é branco (rs), mas fazer algo como modelagem 3D é bem mais complicado.\n","title":"Modelagem 3D com softimage XSI","type":"posts"},{"content":"Ano passado terminei o meu curso de graduação em Ciência da Computação na Universidade São Judas Tadeu, e atualmente trabalho como Analista de Sistemas. Este ano queria estudar algo diferente, e como sempre gostei de games, comecei a pesquisar quais cursos exitem hoje para esta área, sendo que quando comecei a graduação (2005) acho que só tinha o curso de Designer de Games na Anhembi Morumbi.\nEncontrei um curso perfeito, que abrange todo o desenvolvimendo de um game, a pós-graduação Games: Produção e Programação no Senac de São Paulo. Não sabia ao certo o que esperar quando fui na entrevista, mas saí de lá muito empolgado pelo que foi apresentado pelo Prof. Claudio Bueno, que é coordenador e professor deste curso.\nO curso começou em março, e hoje, quase dois meses depois, estou vendo a minha concepção de gamer se tornar mais crítica, e estou começando a entender a indústria de games. Por enquanto tivemos aulas de Modelagem 3D (conceitos básicos) com o software Softimage XSI, Técnicas de Programação de Games e Produção de Games (está última começou agora, depois que terminou a matéria de Modelagem 3D).\nEstou gostando muito deste curso, e meu interesse em entrar na indústria de games está crescendo a cada dia. Estou com algumas idéias de games, e pretendo desenvolver vários projetos este ano, para estudar o desenvolvimento de games no geral, os vários tipos de jogos, programação em C++ (que é novo pra mim, pois só tive Java na faculdade) e compartilhar neste blog tudo que estou aprendendo.\n","date":"24 de abril de 2009","externalUrl":null,"permalink":"/um-novo-desenvolvedor-de-games/","section":"Blog","summary":"Ano passado terminei o meu curso de graduação em Ciência da Computação na Universidade São Judas Tadeu, e atualmente trabalho como Analista de Sistemas. Este ano queria estudar algo diferente, e como sempre gostei de games, comecei a pesquisar quais cursos exitem hoje para esta área, sendo que quando comecei a graduação (2005) acho que só tinha o curso de Designer de Games na Anhembi Morumbi.\n","title":"Um novo desenvolvedor de games","type":"posts"}]